AI Agent Authorization: Fine-Grained Access Control (2026)

Q: What is the difference between authenticating and authorizing an AI agent?

Authentication establishes who the agent is — it proves an identity, typically with a credential or token. Authorization decides what that identity is allowed to do — and for AI agents this second question is where deployments break. Authenticating an agent and then trusting it with a broad scope is exactly how you create a confused deputy: an autonomous identity with standing privilege that a crafted prompt can steer into actions its human never intended. The correct posture is that authentication is necessary but nowhere near sufficient; every consequential action the agent attempts must be authorized per resource, against an explicit policy, scoped to the user the agent is acting for. The shift is from "the agent is authenticated, so let it call the tool" to "the agent proposed an action; the policy engine decides, per resource and per user, every single time." Because agents act autonomously, can be prompt-injected, and frequently act on behalf of a user whose permissions they must inherit rather than exceed, authorization for agents has to be fine-grained, externalized into a policy decision point, and enforced at the tool boundary — not assumed from a successful login or a coarse OAuth scope granted once at the start.

Q: Why do coarse OAuth scopes fail for AI agents?

Coarse scopes like documents:read were designed for services that behave predictably, and they fail for agents in four specific ways. First, over-broad scope: teams give the agent one key covering everything it might ever need, so a prompt injection that hijacks the agent inherits access to everything that key allows. Second, no per-resource check: a scope says read documents, not which documents, so the agent can read another user's or another tenant's document and the scope check still passes. Third, lost user context: if the agent acts under its own identity rather than the requesting user's, it can act beyond that user's permissions, breaking the basic expectation that software acting for Alice can only do what Alice can do. Fourth, static long-lived grants: a key issued once and never narrowed per task is standing privilege, which is maximal blast radius for an identity that can be manipulated. The unifying root error is treating authorization as a one-time scope check at the door rather than a per-action decision. An agent that can be talked into any action by a crafted prompt must be bounded by what it is allowed to do on each specific resource, scoped to the user it acts for — not by what it happened to be told to do.

Q: What is ReBAC and why does it fit AI agents?

ReBAC, relationship-based access control, models authorization as a graph of relationships between principals and resources and answers each access question by checking whether a permitted path exists. For example user:alice is owner of doc:42, and agent:research acts on_behalf_of user:alice, so a request by the research agent to edit doc:42 is allowed only if a relationship path grants edit through Alice's ownership. This is the model Google described in its Zanzibar paper and that open-source systems like OpenFGA implement. It fits agents for two reasons. First, it naturally expresses the on_behalf_of relationship that agents need: the agent's effective permission becomes the intersection of what the agent may do and what its user may do, so the agent can never exceed the user. Second, it externalizes authorization into a dedicated decision engine queried per action, which is exactly the per-resource, per-action granularity agents require, rather than scattering checks through application code. Relationships are also easy to scope and revoke per task, supporting least privilege: the agent is granted only the relationships its current task needs, short-lived, so a research task has no path to the payments graph. Attribute or policy-based models can serve the same role, but the relationship model maps especially cleanly onto the agent-acts-for-user structure that makes agent authorization hard.

Q: How do you stop an agent from exceeding the permissions of the user it acts for?

Make the principal the pair of the agent and the user, and compute the effective permission as the intersection of the two, so the agent can do something only if both the agent is permitted and the user is permitted. The mechanism is to propagate the user's authority into the agent's calls with a scoped, delegated credential rather than letting the agent act under a shared service key. OAuth token exchange (RFC 8693) is the standard way to do this: the user's token is exchanged for a narrowly-scoped token that represents the agent acting on behalf of that specific user for a specific purpose, and the policy decision point evaluates requests against that delegated authority. Critically, delegation must only ever narrow: when an agent hands a sub-task to another agent, the sub-agent receives a token scoped equal to or tighter than the parent's, never broader, so a mesh of agents cannot launder privilege by passing work around. The policy engine then enforces the intersection at the tool boundary on every action, and denials are logged. With this design, even if a prompt injection convinces the agent to attempt something outside the user's rights, the decision point denies it because no permitted relationship path exists for that user, and the worst case is a single logged denial rather than an escalation.

Q: Where should agent authorization be enforced?

At the tool or action boundary — the precise moment the agent attempts to actually do something — not at the chat input and never in the prompt. The reason is that the prompt is attacker-influenceable: an instruction like "you may only access Alice's files" is guidance the model can be talked out of through prompt injection, so it is not a control. Enforcement belongs at a policy enforcement point that every tool call routes through. That enforcement point constructs the principal from the agent's identity plus the user's scoped delegated authority, names the exact resource the action targets, and asks the policy decision engine whether the action is permitted before it runs; a denial is logged and returned to the agent as an ordinary tool error rather than silently swallowed. This is the same deterministic gate used in secure MCP and regulated multi-agent designs, but now backed by a real authorization model — relationship or policy based — instead of a hardcoded allow-list. Sub-agents inherit and only narrow the parent's authority, so delegation through a mesh cannot widen access. And every decision, capturing the principal, resource, action, verdict, and reason, is written to an immutable log, because the question a regulated review asks is whether the agent could only ever have acted within its user's rights, and that decision log is the evidence that answers it.

Q: What are the common anti-patterns in agent authorization?

Seven recur. One API key for the whole agent — a single broad credential is the confused deputy's weapon, so scope per task, short-lived, least-privilege. Authorizing the agent rather than the agent-and-user pair — an agent acting on its own identity can exceed its user, so the effective permission must be the intersection, with user authority propagated by token exchange. Scope checks instead of per-resource checks — a documents:read scope lets the agent read any document, so the specific resource must be checked every time. Authorization in the prompt — "you may only access Alice's files" is an instruction, not a control, and prompt injection overrides it, so enforcement must live in the policy engine at the tool boundary. Privilege widening on delegation — if sub-agents can be granted more than the parent, a mesh launders access, so delegated tokens must only narrow. Policy scattered in application code — hardcoded if checks drift and cannot be audited, so authorization should be externalized to a ReBAC or policy engine. And no decision audit — if you cannot show why each action was allowed, you cannot pass a regulated review, so every decision must be logged immutably. Each has a direct fix, and together they convert an agent from a confused deputy with standing privilege into one provably bounded by its user's rights.

Q: How does fine-grained agent authorization map to regulation and OWASP?

It maps directly, which lets one control set serve security and compliance. Against the OWASP Top 10 for LLM Applications, an over-privileged agent that can be steered into unintended actions is excessive agency (LLM06/LLM08), and broad standing credentials are an insecure-design issue; fine-grained, per-action, user-scoped authorization with least privilege is the architecture-level mitigation those risks call for. Against data-protection and financial regulation, the access-control and least-privilege expectations of GDPR, the UAE and Saudi PDPL, Singapore's MAS, Switzerland's FINMA, and the EU AI Act for high-risk systems all require that a system acting on personal or financial data can only access what it is authorized to, that access is least-privilege, and that it is auditable. The relationship-based model satisfies the first two by construction — the agent's permission is the intersection with its user, scoped per task — and the immutable decision log satisfies auditability, because a reviewer can ask for the record of any action and see the principal, resource, action, and the policy reason it was allowed. NIST SP 800-207 zero trust reinforces the per-request authorization principle. The practical approach is to design the ReBAC or policy enforcement once, enforce it at the tool boundary, log every decision, and present that same evidence to both engineering security reviews and regulatory audits.

Q: How do we mature our agent-authorization posture over time?

Use a five-stage ladder. Stage 0 is keyed: one broad API key per agent, coarse scopes, and authorization attempted in the prompt, which makes the agent a confused deputy with standing privilege. Stage 1 is identified: each agent has its own workload identity and short-lived credentials with no shared keys, so actions are attributable and revocable. Stage 2 is user-scoped: the agent acts as the agent-and-user pair via token exchange, and the effective permission is the intersection, so an agent can never exceed the user it acts for. Stage 3 is fine-grained: per-resource, per-action ReBAC or policy checks are enforced at the tool boundary, the agent is granted least privilege per task, and delegated tokens only narrow when work is handed to sub-agents. Stage 4 is attested: policy is externalized in a decision engine, every decision is written to an immutable log, the system is red-teamed against confused-deputy and privilege-escalation paths, and the controls are mapped to OWASP LLM and the relevant access-control regulation so every agent action is provably bounded by its user's rights. Track the share of tool calls evaluated by the policy engine, the number of standing broad keys remaining (target zero), and red-team escalation success rate as the headline metrics of progress up the ladder.