An agent needs an identity of its own, scoped below the user it serves, or every permission the user holds becomes a permission the model can spend.
ConceptWhat it is
IAM is the system that answers who this is; RBAC is the system that answers what someone in that role may do. Both predate AI by decades and neither needs reinventing. What is new is a third party in the conversation — a model that acts, and whose identity nobody specified.
The default answer, that the agent simply acts as the user, is the one that causes trouble. It hands a probabilistic process the full set of permissions a careful human accumulated, and it makes the audit trail say a person did something a model did.
How it worksThe mechanics
The agent is issued its own principal — a service identity — and the permissions it may use are the intersection of that principal's role and the role of the user on whose behalf it is acting. Delegation is explicit and time-boxed: a token minted for this task, expiring with it, carrying the narrower of the two permission sets.
In practice this means each tool an agent may call is bound to a scope, and the scope is checked at call time against the delegated token rather than against the user's session. A read tool and a write tool are different scopes even when they touch the same system, because the blast radius is what is being bounded, not the resource.
At a glanceSee it
The agent gets the intersection of two roles, never the union. The log records both principals, so an action is attributable to the model and the person.
When to use itWhere it fits
- Any agent that can call a tool with a side effect — sending, writing, paying, deleting.
- Multi-user products where the same agent serves people with different entitlements.
- Regulated settings where an auditor will ask who performed an action and will not accept a shared service account.
- Anywhere you want to revoke an agent's ability to do one thing without revoking a person's job.
When NOT to use itLimits & anti-patterns
- A single-user local tool with no shared resources, where the ceremony costs more than it protects.
- Read-only assistants over a public corpus, where there is nothing to scope.
- As a replacement for access control on retrieval — role checks on tools say nothing about which documents were read.
- When the roles in the source system are already meaningless; mirroring a broken role model gives you a precise copy of the wrong thing.
Trade-offsAdvantages & costs
Advantages
- Bounds the damage of a successful prompt injection to the scopes the agent actually holds.
- Makes revocation surgical — withdraw one scope rather than disable an account.
- Produces a truthful audit trail, with the model and the person both named.
- Reuses identity infrastructure that already exists and is already trusted.
Trade-offs & costs
- Two principals to administer where there was one, and the intersection logic is somewhere new to get wrong.
- Short-lived tokens need refresh handling inside long agent loops, which is a real source of mid-task failure.
- Fine-grained scopes multiply quickly; a catalogue of forty tools is a catalogue of forty decisions.
- Teams route around it under delivery pressure by granting the agent a broad role, which restores the original problem while looking solved.
ExampleIn the real world
A support agent can read any ticket in the queue and can post a public reply, but issuing a refund is a separate scope it does not hold. When a customer talks it into promising money back, the promise is text; the refund tool refuses the call, and the log shows the agent attempted it on that user's behalf. The control that mattered was the scope, not the prompt.
ToolsHow to implement it
- OAuth 2.0 token exchangethe standard way to mint a narrowed, delegated token for a downstream call.
- AWS IAM roles or GCP service accountsa service identity for the agent that is separate from any human's.
- SPIFFE or SPIREworkload identity when the agent is one service among many and mutual authentication matters.
- OPA or Cedarexpressing the intersection rule once, as testable policy, rather than in each tool's handler.
Cost & effortWhat it takes
No meaningful token or latency cost; this is engineering effort and operational surface. A first implementation over an existing identity provider is days rather than weeks, and the ongoing cost is the scope catalogue — one decision per tool, revisited whenever the tool's reach changes. The expensive version is retrofitting it after an agent has shipped with the user's full permissions.