Control which tools an AI agent may actually call

Tool access usually starts as a list of servers in a client configuration file. That file lives on a developer’s machine or in an agent’s repository, it is edited by whoever is shipping, and it grants whole servers rather than actions — so an agent that needs one read against the order database receives the refund endpoint sitting next to it. Nobody outside the team that wrote it can say what an agent may do, and the answer changes with the next commit.

The next attempt is a gateway that filters the tool list. That reads as access control and is not: a client can send a call for a tool name it was never shown, and an agent under the influence of a paragraph of retrieved text is precisely the component that will try. The filtered list is a usability feature — it stops a framework picking a model or a tool that will be refused three lines later — and the enforcement point has to be the call.

Then there is the surface almost nobody governs, which is the tool descriptor itself. A tool’s name, its description and its input schema are text the model reads and obeys, so an upstream server that changes them — through a compromise, a dependency swap, or an ordinary release nobody told you about — rewrites what your agent believes it is doing without touching a line of your code. The version that matters is the patient one: a tool that behaved for six weeks and then acquired a new sentence in its description.

The last is the argument. Teams reach for a permission model to express refunds over £200 need approval and discover that a permission carries an effect, a resource pattern and a set of actions, and nothing else. Putting the amount into the grant sounds attractive until somebody has to attest to it: a conditional grant that must be simulated before anybody understands it is not something a named reviewer can honestly sign during a recertification.

An action is allowed only when at least one permission on at least one of the agent’s roles explicitly allows it, and none denies it. There is no implicit grant anywhere in the evaluator: an agent holding no roles is refused, a role carrying an empty permission list grants nothing, and a resource no permission names produces a refusal whose recorded reason ends in deny by default — which is the string an operator will search the flight recorder for when an agent starts failing.

The deny path returns before any allow is settled on, which makes precedence independent of ordering. A guardrail role that denies one refund tool wins whether it is listed before the broad role that grants the payments namespace, after it, or inside the same role. That is what makes a subtractive guardrail a pattern you can rely on rather than a race: you can grant a namespace to a team and remove one action from one agent without rewriting or duplicating the broad grant.

Matching is deliberately dull. A resource pattern is a literal string in which an asterisk matches any run of characters including a slash; every other regular-expression metacharacter is escaped before the pattern compiles, so an operator who types a full stop gets a full stop rather than an accidental wildcard, and a permission on tool:orderdb/get_details does not match tool:orderdbXget_details. Actions are compared case-insensitively, and everything is evaluated as invoke today — the action field is genuinely matched, so a permission scoped to read denies an invoke on the same resource, but a finer verb set is reserved rather than issued.

Delegation is where a permission model usually leaks, and here it intersects. When one agent delegates to another, the effective set is the intersection of every agent in the chain, and the evaluator refuses at the first link that does not allow, recording which link it was and out of how many. The union is never taken: an orders agent and a payments agent that delegate to each other can jointly do nothing. That is inconvenient by design, because the failure mode of an intersection is under-privilege, which surfaces as a ticket somebody investigates, while the failure mode of a union is an escalation with an audit trail that looks entirely legitimate. The chain arrives as a request header and is asserted rather than proven, which the intersection is what makes acceptable: a forged chain can only add links, and every added link must also allow, so forging it buys an attacker strictly less than sending none.

There are two refusal shapes and the choice between them is deliberate. A tool the caller cannot see returns the JSON-RPC protocol error for an unknown tool, and existence and visibility collapse into that one answer on purpose, because confirming that a tool exists is an inventory disclosure. A tool the caller can see but may not use right now returns a successful JSON-RPC response whose result is flagged as an error: the model reads it, can explain it to the person, and can choose a different action. A protocol error in that position surfaces to most clients as a transport fault the model never gets to reason about.

Every refusal carries machine-readable metadata beside the prose — a typed code, a retryable flag, and an approval id where one exists — and the protocol-error form carries the same object under its error data. The gateway also states the contract in the instructions it returns at initialisation, so a client that has been told none of this reads it from the server: tools are namespaced and filtered to this agent’s grants, a refused call returns an error result with that metadata, and a call gated on approval is retried by repeating it with the approval id in the request’s metadata field.

Bounds are refusals rather than truncations, and they land on different sides of the call. Arguments that cannot be fully inspected are refused before anything runs, because returning the untouched remainder would forward precisely the bytes that were never governed. A result that cannot be fully inspected is withheld after the tool has already run, and the message says which of the two happened, because the difference decides whether the agent should try something else or tell somebody. Non-text output — an image, audio, a blob, an embedded or externally fetched resource — is withheld for the same reason, since there is no bounded media decoding or OCR on this path.

One reach beyond the endpoint is worth stating precisely, because it is where an enforced control and a detective one get confused. The model gateway evaluates tool-call rules against the tool calls a model proposes in its response, before that response is returned, so a rule about refunds binds whether or not execution is routed through the tool gateway; on a stream the frames are held per index until the arguments parse as complete JSON, governed, and only then released. That is defence in depth rather than a guarantee, and the product says so in those words: it can only refuse a proposal it is shown.