Agent Identity and Delegated Authorization
An AI agent that does anything useful needs to act on systems: read a calendar, query a database, send a message. The lazy way to grant that is to hand the agent a standing credential — an admin token, a service account, the user's own session — and let it do whatever it likes. It works in the demo and quietly becomes the worst decision in your architecture. The right question is the one identity engineers answered years ago for third-party apps: how does a program act on behalf of a user without becoming that user? The answer is delegated authorization, and agents need it more than any app ever did.
Why “just give it a token” fails
When a human logs in, authority is bounded by a person: they get tired, they hesitate, they notice something is off. An agent has none of those brakes. It will make ten thousand calls a minute and follow an instruction buried in a web page as faithfully as one from you. So the credential you give it is not a convenience — it is the entire blast radius. Give an agent a broad, long-lived token and you have created a tireless account that runs on text it does not fully trust and cannot fully verify.
This is the same problem the web faced when apps wanted to act for users. The bad old answer was to collect the user's password and log in as them — full impersonation, no limits, no revocation. OAuth replaced that with delegation: the user consents to a scoped grant, an authorization server issues a token good for only those scopes, and the app acts with that token instead of the user's credentials. “OAuth for agents” is not a slogan; it is recognising that an agent is exactly the kind of semi-trusted deputy OAuth was built to contain.
Scopes are the whole game
A token's power is defined by its scopes, and this is where agent deployments go wrong. It is easier to request read_write_all once than to enumerate the four operations the agent actually performs, so teams over-scope “to be safe,” which is precisely backwards. The right posture is the one OAuth encourages and few enforce: request the narrowest scopes, for the shortest lifetime, bound to the specific task. An agent that summarises invoices needs invoices:read, not a token that can also delete them.
Two refinements matter for agents specifically. First, keep the agent's identity distinct from the user's — a token that says “this is the scheduling agent acting for Alice” is auditable and revocable in a way that Alice's own session is not. Standards like OAuth token exchange exist precisely to mint these on-behalf-of tokens. Second, remember that scope is a ceiling, not a decision: the resource must still authorize each call on its own terms. Delegation narrows what the agent can attempt; it does not decide what it should.
And handle the token like the crown jewels it is. If an agent's token leaks — logged in plaintext, echoed into a prompt, exfiltrated by an injected instruction — whoever holds it becomes the agent. Short lifetimes, rotation, storage outside the model's context, and revocation you can actually trigger are not optional hardening; they are the difference between a scare and a breach.
- List the credentials one production agent holds and read their scopes. If it carries a broad or admin-equivalent grant, ask which specific tool calls actually need that scope — usually none do.
- Trace one action end to end and confirm the downstream resource authorizes the request itself, rather than trusting that the agent was allowed to ask.
Enumerating every agent's true authority, testing scope escalation and token handling under adversarial conditions, is a controlled engagement — exactly what our assessment and SecStudio agent-testing tooling are built to run.
Designing agent authorization that holds
- Give the agent its own identity. Never let it inherit a human's session or a shared admin account; a distinct principal is what makes audit and revocation possible.
- Scope to the task, expire fast. Narrow scopes, short-lived tokens, refreshed as needed — the smaller the window, the smaller the theft.
- Authorize at the resource. Check every action against policy at the point it lands, not just at the point the token was issued.
- Protect and rotate secrets. Keep tokens out of prompts, logs and model context; assume any credential the model can see, an attacker can eventually extract.
Delegated authorization is not new — it is the settled answer to a settled problem. What is new is that we are handing that authority to a deputy which reads untrusted text for a living and never gets suspicious. The controls are borrowed from OAuth; the discipline has to be stricter, because the thing holding the token is far easier to talk into misusing it. You cannot bound an agent's authority until you know every agent you run and exactly what each one can reach.