Why agents need different controls

The point of listing these together is that each failure is quiet. None of them produces an error, an alert or an anomaly in the tooling you already have; each produces a control that reports normal while the thing it was protecting against happens.

The caller’s repertoire is fixed at build time. This is the assumption behind every route-level policy, every schema validation and every integration review, and it is the one that breaks hardest. An agent decides which tool to call, and with what arguments, from text it has just read — some of which was written by somebody outside your organisation. The set of calls it can make is its grant list, not its code, and a code review of the agent tells you almost nothing about what it will do.

Volume bounds cost. A request quota bounds requests. What you pay depends on tokens in and tokens out, on which model actually served the call after routing and failover, and on how that provider counts cached input — a distinction that runs to a large fraction of the bill on agent traffic specifically, since agent turns repeat the same system prompt and retrieved context. A quota of ten thousand requests a day is compatible with almost any invoice you care to name.

The credential identifies the principal. An application key names an application. An agent key names a process that may be acting for any of a thousand people, on a task delegated by another agent, which was itself delegated by a third. Authorising on the credential alone authorises the widest thing that credential ever needs to do.

The response is data. Everything in an API stack treats a response as a payload to be parsed, validated and handed onward. A tool result is read by a model as text, and models do not reliably maintain the boundary between data and instruction — so a row in a table populated from a public form is a channel into your agent’s decision-making.

A retry is free. Idempotency and at-least-once delivery are the load-bearing assumptions of every resilient API client. For an agent, a retry after an ambiguous timeout can bill a second time for the same work, because a timeout cannot prove the vendor did not complete and charge for the call, and it can commit an external effect a second time if the downstream system was not given a key it honours.

Three changes, and each is a direct consequence of one of the assumptions above.

Authorise the action rather than the integration, because the caller’s repertoire is not fixed. Granting an agent the order database hands it the refund endpoint sitting beside it, and the injected instruction that eventually reaches it will name the refund endpoint. Deny by default is what makes this hold without an exhaustive list of prohibitions.

Authorise the chain rather than the last hop, because the credential names a process. If the effective permissions of a delegation chain are the union of its members, a low-privileged agent escalates simply by asking a higher-privileged one to do the work it was just refused; intersecting per hop is what makes composition safe by construction. Where a named human is on the request, treat that as another set to intersect rather than as a source of authority, because the header carrying them is a string the caller chose.

Authorise the arguments rather than only the endpoint, because the arguments are model-proposed and therefore as attacker-influenceable as the prompt. A rule that says refunds over a threshold need a human is a statement about an argument value, and expressing it needs matchers over the argument tree rather than an endpoint-level allow or deny.

Then, for the small set of actions where being wrong is permanent, add a human bound to the exact payload. The binding is the whole design: an approval that authorises a refund rather than this refund of this amount on this order is a standing licence for every refund the agent proposes afterwards, and the agent proposing them is precisely the component most likely to have been talked into it. Bind it to a hash of the canonical action plus its execution context, make it single-use and give it an expiry — and keep the gated set small enough that the queue is actually read, because an approval queue nobody reads is worse than no gate at all.

Most organisations arrive at this problem already holding four things that each cover part of it, and the sensible position is to keep all four.

An identity platform issues and governs the agent’s identity, its ownership and its lifecycle. It is the authoritative upstream for who owns this and should it still exist, and a governance layer should read from it rather than maintain a competing inventory. Where it can issue workload assertions, it becomes the strongest available answer to who is calling: an issuer-signed composite identity exchanged for a short-lived, audience-bound, single-use capability beats a long-lived bearer token in every respect except integration effort.

A security stack inspects traffic and applies data-loss rules. It reads the payload, which is necessary and is blind to authority — the same prompt is legitimate from one agent and an incident from another, and the difference is not in the bytes. Keep it, and stop expecting it to know that the refund in that payload is above the threshold a human was supposed to see.

Network and egress control decides where the process may connect at all, which is one of the few controls that binds an agent whose traffic does not route through your governance layer. Narrowing it is the cheapest way to make bypassing the gateway hard rather than merely discouraged.

And the gateway itself carries the request, applies quotas and caches responses. Carrying a request is not deciding it, but a gateway is the natural place to put the decision, which is why almost every serious implementation converges on the same shape regardless of vendor.

The narrow layer left over is the one that binds: the exact delegated authority at the moment of the call, the business effect that resulted, and a record of both that survives the person who could edit it. Everything else on a governance feature list — a registry, provider routing, quotas, cost dashboards, prompt data-loss controls, trace trees, tool access lists — is table stakes. You need them, they are not hard to find, and a vendor whose lead story is one of them is describing a category rather than a position.