What Is Agent Authorization?

Agent authorization is the process of deciding what an authenticated AI agent is allowed to do — which tools, data and actions it may access — by evaluating the agent’s identity and the request against least-privilege policy, including any on-behalf-of delegation, before the action is permitted. It is the control that keeps an autonomous agent inside its intended boundaries.

In one line: agent authorization answers “is this agent allowed to do this?” — enforced per action, under least privilege, after authentication.

Why is agent authorization hard?

Authorizing autonomous agents is harder than authorizing apps, for three reasons:

• Over-privilege by default. An agent handed a human’s token or a broad key can do everything that principal can — far more than its task needs. Least privilege has to be deliberate.
• Inherited and ambient permissions. Agents often run with whatever access their environment grants, quietly accumulating reach no one scoped.
• Delegation chains. When an agent acts for a user, or calls another agent that calls a tool, the system must carry “who is really asking” across every hop — and authorize against that, not just the immediate caller.

Getting this right is central to AI agent governance: authorization is where policy actually constrains what agents can do.

See least-privilege authorization enforced for your agents.

Book a demo

How does agent authorization work?

1. Start from a verified identity. Authorization only runs after the agent is authenticated — you must know who the agent is first.
2. Resolve delegation. If the agent is acting on-behalf-of a user or another agent, resolve the full chain to the originating principal. (See agent identity & delegation.)
3. Evaluate policy. Check the requested action and resource against least-privilege scopes assigned to that agent — not the broad role of a human.
4. Enforce the decision. Allow, deny, or require step-up (human approval) for high-impact actions — at a control point, before the request reaches the tool, model or MCP server.
5. Log for audit. Record the decision against the agent’s identity for attribution and anomaly detection.

Agent authentication vs agent authorization

Enforce on-behalf-of delegation with no privilege amplification — get a walkthrough.

Book a demo

Least privilege and on-behalf-of delegation

Two principles do most of the work. Least privilege means each agent gets only the scopes its task requires, so a compromised or misbehaving agent can do limited damage. On-behalf-of (OBO) delegation means an agent acting for a user is authorized against that user’s rights — never more — and the delegation is explicit and auditable rather than an inherited token. TrueFoundry supports collaborator-based scoping and OBO so an agent can only ever be acted for by identities that were explicitly granted it.

Authorization across multi-agent chains

Single-request authorization is not enough once agents call other agents. If each hop only checks its immediate caller, a privileged middle agent can become a confused deputy — doing things the original user was never allowed to do. Authorization has to propagate the originating identity and constraints across the whole chain. In TrueFoundry’s model the user stays constant as sub end to end, while the acting agent in the act claim changes at each hop — and the gateway re-checks “may this agent act for this user?” every time.

We cover this failure mode and the fix in depth in Authorization Propagation, Explained.

Examples of agent authorization

• Scoped tokens: an agent’s token carries only the scopes for its task (e.g. read one mailbox, not the whole tenant).
• Per-agent policy at the gateway: the control plane decides, per request, which tools and MCP servers an agent may reach.
• Collaborator-based access: an agent can be invoked or acted-for only by explicitly granted users or teams.
• Step-up approval: high-impact actions (payments, deletions) require human approval before they execute.

How TrueFoundry authorizes agents

TrueFoundry authorizes every agent action at the gateway, in a strict, auditable order once the (user, agent) pair is resolved:

1. RBAC — user: the user must be a collaborator on the target MCP server.
2. RBAC — agent: the agent must be a collaborator too (an agent:<name> subject with a role).
3. Tool restriction: if the agent’s entry defines a tools list, the requested tool must be on it.
4. Cedar policy (optional): evaluated with the agent, user claims, tool, time and delegation chain — and forbid always overrides permit.
5. Forward or deny: if every check passes the request is forwarded with the right outbound credential; otherwise it returns 403.

Delegation is governed by two claims: may_act is checked before a delegated token is minted (the forward-looking gate), and act is recorded on the issued token (the after-the-fact record). Because each exchanged token carries only the intersection of user, agent and target rights, authorization can only narrow down the chain — never amplify. Who may invoke an agent, and whom it may act for, is set through collaborator grants.

Every decision is logged with the user, agent, identity mode, delegation chain, MCP server, tool, the RBAC and Cedar decisions, the matching policy, the scopes used and the status — deployable as SaaS, VPC, on-prem or air-gapped.

Enforce least-privilege, delegated authorization for every agent action from one control plane.

Book a demo