🧰 MCP tool authorization

An MCP server exposes a fixed catalog of tools, each declaring a required_scope. Every invocation is authorized against the acting identity's scopes before the (simulated) tool ever runs — least privilege enforced right at the tool boundary, the MCP analog of OAuth scopes gating an API call.

You can invoke as one of your own agents, or present a delegation token minted on the A2A lab — authorization checks the token's attenuated scope, never the root agent's full scopes, and every hop in its chain is re-checked live. A killed agent (or a killed link in a delegation chain) can invoke nothing.

Try this: grant your agent only a couple of scopes and watch a tool outside them get denied. Then delegate an attenuated token that drops one of those scopes and invoke the SAME tool with the token — it's denied for the same reason, at the tool boundary. Finally, kill any agent in that delegation chain and invoke again with the same token — it fails chain_inactive, even if the root agent is still alive.

Learn → MCP tool authorization — least privilege at the tool boundary Learn → The agent registry & kill switch Learn → Agent-to-agent delegation — chains of machines acting for you

Tool catalog

Fixed and simulated — no tool here ever has a real side effect.

Invoke a tool

Tool policies

Holding a scope says WHICH tools an agent may call. A policy says HOW — capped, restricted, or forbidden outright — even when the scope alone would allow it. Policies compose as a strict AND on top of the scope gate above: they can only ever tighten a call the scope check would have allowed, never loosen one it denied.

Your rules

Listed in evaluation order: lowest priority first, ties broken by rule id — and the first rule that matches decides the call, so nothing below a match is even consulted. That is what lets a narrow allow sit above a broad deny. A rule scoped to one agent only takes part in that agent's calls; "all my agents" rules take part in every one.

No rules yet — every call falls through to each agent's default mode (below).

Add a rule

Agent Effect Tool Priority (lowest runs first)

Constraints (JSON array) One object per constraint, each naming one arg plus exactly one of equals / in / matches (regex) / max / min / prefix. A constraint has three outcomes, not two — it can hold, be violated, or be unevaluable (the argument is absent, or its type is outside what the constraint compares over). allow and deny resolve that third case in opposite directions, deliberately: an allow rule matches only when every constraint actually held, so an allowlist entry never fires on an argument it could not read — while a deny rule fails CLOSED and matches anyway, because "I cannot tell whether this is the call you told me to block" has to resolve to blocking it. So deny transfer_funds [{"arg":"amount","max":100}] denies a call that sends no amount at all. Treating that as "no match" was a real authorization bypass: reshaping an argument to a type the rule could not read walked straight past the guard to the default mode. Two more sharp edges worth knowing: matches is unanchored (a plain .test(), so "docs" matches /etc/docs-but-not-really/passwd — anchor it yourself with ^/$), and max/min coerce numeric strings, so "500" is compared as 500.

Per-agent default mode

What happens when NO rule matches. allow keeps today's unchanged behavior; deny is real least-privilege — nothing runs for that agent unless a rule explicitly permits it.

You have no agents yet.

Sample-invocation trace

Preview what the SAME evaluator mcp.ts's invoke path uses would decide for one of your agents — the tool never actually runs here.

Agent Tool Arguments (JSON)