Authentication proves who. Authorization decides what.
Most agent security starts and stops at authentication: the agent gets a token, the token proves it is who it claims to be, and the door opens. That is necessary and nowhere near sufficient. A valid token says an agent is allowed in. It says nothing about whether this agent, right now, should read the production database, call the payments API, or spawn ten sub-agents that each try the same.
For a human, login-time access control mostly works. A person authenticates once, gets a session, and acts inside it for an hour. An agent breaks every assumption in that sentence. It has no session in any human sense, it runs continuously, it calls tools thousands of times, and it hands work to other agents that inherit a slice of its authority. Grant access once at the front door and you have no control over the thousand actions that follow.
Authorization models, compared
Three models get used to make that decision. They are not equivalent.
| Model | How it decides | Where it breaks for agents |
|---|---|---|
| Role-based (RBAC) | Static roles map to fixed permission sets | An agent’s needs shift per task and per delegation, so static roles are either too broad or multiply into hundreds nobody maintains |
| Scoped tokens (OAuth scopes) | The token carries a fixed list of scopes granted when it was issued | Scopes are frozen at issue time, so they cannot reflect what the agent is doing at the moment it acts, or narrow as work is delegated |
| Policy-as-code (ABAC) | A policy evaluates attributes of the request (identity, scopes, trust tier, delegation depth, the action, the target) when the action happens | Needs an enforcement point in the action path, but it is the only model that decides on live context instead of a grant made earlier |
RBAC and scoped tokens both decide before the action, from information fixed earlier. Policy-as-code decides at the action, from attributes of the real request. For agents, whose context changes with every step, that difference is the whole game.
Request-time authorization vs pre-grant admission
It helps to separate two decisions that often get conflated.
Admission is pre-grant: which servers, tools, or systems is this agent allowed to connect to at all? Standards like MCP Enterprise Managed Authorization handle this well, letting your identity provider decide which MCP servers an agent may reach through corporate SSO.
Request-time authorization is what happens after admission: for each individual action the connected agent attempts, is this action allowed given this context? Admission gets the agent through the door. Request-time authorization governs everything it does once inside, and that is where most real damage happens.
You need both. Admission without request-time control is a guard who checks IDs at the entrance and then never looks again.
Delegation and scope ceilings
Agents delegate. A planning agent spawns a research agent, which spawns three workers. Each hop passes down some authority, and that is exactly where authority tends to leak.
The rule that keeps it safe is scope attenuation: permissions narrow at every hop, and a sub-agent can never hold more than the agent that delegated to it. Authority only shrinks as it descends, it never grows. This is the mechanism behind RFC 8693 token exchange, and it is what prevents the classic confused-deputy problem, where a low-privilege agent tricks a high-privilege one into acting for it.
Delegation depth belongs in the policy too. An agent that is allowed to delegate two levels deep should not be able to spawn a chain ten deep, and the authorization layer should treat that depth as a first-class attribute it can check, not an afterthought.
Revocation
Authorization is not only about granting. When an agent is compromised or a person leaves, the decision has to reverse, fast and completely.
Token expiry is not revocation. A leaked token stays valid until it expires, which can be an hour of damage at machine speed. Real revocation cuts the identity now: revoke a parent agent and the whole delegation tree beneath it should fail its next check, because each descendant revalidates per request rather than coasting on a token it already holds. Done at the identity layer, this is a scalpel: you cut the compromised agent and the chain it spawned, without disabling the shared service accounts other applications depend on. Continuous Access Evaluation and Shared Signals are the standards that carry the revocation event across boundaries in seconds.
A sequence for implementing agent authorization
- Give every agent its own identity. Shared keys make per-agent authorization impossible before you start.
- Define least-privilege scopes for what each agent actually needs, not the superset that is convenient.
- Put an enforcement point in the action path: a gateway, or hooks in the agent’s runtime, so decisions are made in-line rather than trusted to the agent.
- Write policy as code, once, and enforce it across every surface (model calls, tool calls, agent-to-agent) so behavior does not drift between products.
- Attenuate scope at each delegation hop and cap delegation depth.
- Set a fail posture per surface: deny unless permitted, and decide where unmatched traffic fails open versus closed.
- Wire cascade revocation so cutting one identity stops everything beneath it.
- Log every decision, with the identity and context behind it, so the audit trail is a byproduct rather than a separate project.
How Highflame handles authorization
Highflame enforces one Cedar policy, authored once and evaluated at every boundary an agent crosses: model traffic, the IDE, the tool gateway, and agent-to-agent hops. The policy runs in-process in about a millisecond per call, forbid overrides permit, and the model never sees the policy, only the decision. Authorization is zero-trust by default: the engine denies unless a policy permits, with a per-surface switch for whether unmatched traffic fails open or closed.
Scope attenuation and delegation depth are first-class inputs, so a sub-agent always holds strictly less authority than the principal that authorized it. Trust tier (first-party, verified third-party, or unverified) is a verified input to each decision, never a bypass. And revocation cascades fleet-wide in under three seconds through CAE/SSF, so a compromised agent and its whole chain go inert without touching anything else. You can see the model on the platform page or in the code-agent controls.