Why are wildcards deliberately unsupported?

Because wildcard allowlists are how MCP integrations get exfiltrated: a pattern like *.example.com is one DNS rebinding away from matching an attacker’s host. Exact-string matching is more work to configure and we accept that trade-off — the allowlist should name what you actually authorized, byte-for-byte, nothing else.

What is a task-bound token, concretely?

A credential minted for one task that burns on first use. If it leaks in transit, in a log, or through a compromised agent, it fails twice over: it doesn’t authorize anything outside its task, and by the time an attacker replays it, it has already been spent. The refused replay lands on the signed record.

Does this replace authentication on my MCP servers?

No — it sits in front of it. Your MCP servers keep whatever auth they have; AnchorGate adds a gate that decides whether the call should happen at all: is the target authorized exactly, is a shell involved, is the token still valid for this task. Defense in depth, with the verdict signed either way.

MCP security

The tool call is the attack surface.

An agent with MCP tools doesn’t need to be jailbroken to do damage — one stolen token or one permissive allowlist is enough. AnchorGate gates every tools/call deny-by-default: exact-string target matching, shell invocations rejected outright, and tokens that are useless outside their task and useless twice.

Get started — it's free View on GitHub

The mechanisms

Three mechanisms, no soft edges

Each one is a deliberate trade-off: stricter than convenient, because the failure mode it prevents is worse than the inconvenience.

Exact-string allowlists

Authorized targets match byte-for-byte. Wildcards are deliberately unsupported — wildcards are how DNS rebinding and token harvesting happen. If a target isn’t on the list exactly, the call doesn’t happen.

Shell invocations rejected outright

A tool call that reaches for a shell is refused before any policy evaluation — there is no allowlist entry that permits it. The riskiest capability class is simply off the table.

TBAC: single-use, task-bound tokens

Each token is bound to one task and burns on first use. A stolen token is useless outside its task and useless twice — replay is refused with the burn on the record.

MCP security

An MCP gateway that assumes the token will leak

One stolen token is all an MCP integration needs to become an exfiltration path. Long-lived credentials and wildcard allowlists don’t stop it — so AnchorGate’s MCP gateway is built as if the leak already happened.

Exact-string target allowlists — wildcards deliberately unsupported, because wildcards are how tokens get harvested.
Shell invocations rejected outright. The posture is deny-by-default: if a target isn’t on the list byte-for-byte, the call doesn’t happen.
TBAC single-use, task-bound tokens that burn on first use — a stolen token is useless outside its task, and useless twice.

anchorproxy · MCP gateway deny-by-default

finance-agent · tools/call · send_report

Target matched allowlist byte-for-byte — forwarded, token burned after use.

admitted exact match token: single-use ✓

eng-agent-fleet · tools/call · run_command

Shell invocation detected in arguments — rejected outright, no evaluation needed.

refused shell: never

unknown-client · tools/call · send_report

Token already burned — single-use, bound to a finished task. Replay refused.

refused tbac: token spent

allowlist: exact-string · wildcards unsupported signed · ecdsa-p256

In the box

What ships today

Deny-by-default posture on every MCP tools/call
Exact-string target allowlists, matched byte-for-byte
Wildcards deliberately unsupported in allowlists
redirect_uri and target validation against authorized entries
Shell invocations rejected outright, no evaluation needed
TBAC tokens: single-use, bound to one task
Tokens burn on first use — replay refused
Every MCP verdict signed into the decision ledger

As shipped in AnchorGate v0.1 — every line above is checkable against the repository.

Works with the rest of the gate

Policy Enforcement

A deterministic policy DSL — IF condition THEN redact, alert, or block — compiled, human-approved, and evaluated before a request leaves. No LLM judging LLMs: the same input always gets the same verdict.

Learn more →

Signed Evidence

Every decision signed with ECDSA P-256 over RFC 8785 canonical JSON, appended to an immutable ledger, graded L1–L5. An auditor can replay who acted, what was touched, and which policy fired.

Learn more →

FAQ

MCP security questions

Why are wildcards deliberately unsupported?: Because wildcard allowlists are how MCP integrations get exfiltrated: a pattern like *.example.com is one DNS rebinding away from matching an attacker’s host. Exact-string matching is more work to configure and we accept that trade-off — the allowlist should name what you actually authorized, byte-for-byte, nothing else.
What is a task-bound token, concretely?: A credential minted for one task that burns on first use. If it leaks in transit, in a log, or through a compromised agent, it fails twice over: it doesn’t authorize anything outside its task, and by the time an attacker replays it, it has already been spent. The refused replay lands on the signed record.
Does this replace authentication on my MCP servers?: No — it sits in front of it. Your MCP servers keep whatever auth they have; AnchorGate adds a gate that decides whether the call should happen at all: is the target authorized exactly, is a shell involved, is the token still valid for this task. Defense in depth, with the verdict signed either way.

Assume the token will leak. Gate the call anyway.

Put a deny-by-default MCP gateway between your agents and their tools. Exact-string allowlists, shell rejection, single-use tokens — all open source.

Deploy the stack

or email hello@anchorgate.ai