Agent Authorization

Security Objective

Agent authorization is the control that decides whether one concrete, fully resolved action request may execute. It answers a single question in one place: who is asking, under whose authority, to do exactly what, to which resource, with which parameters, to which destination or audience, in which tenant or workspace scope, for which task, at what time, and under which policy version.

The reason this control carries so much weight in AI systems is that a model's interpretation of language is probabilistic, while the consequences of an action are not. Every attack pattern documented on this site ends at the same place: the model can be influenced, and whether that influence becomes a security impact depends on a decision made outside the model. AI agent prompt injection, multi-agent propagation and tool output injection all converge on it.

This page is the reference for that control. It is not a general identity and access management guide, and it deliberately does not restate what belongs to least privilege, human approval or information flow control.

Authentication Is Not Authorization

Knowing which user, agent or tool sent a request establishes an identity claim. It does not establish permission for the requested operation. In agentic systems this distinction is easy to lose, because a call arrives over an authenticated channel from a component that belongs to the same deployment, and the receiving side treats belonging as permission.

Model Decision Is Not an Authorization Decision

A model can produce text that looks like an authorization outcome. It can state that a user approved something, that a policy permits an action, that a recipient is internal, or that a file is non-sensitive. None of that is an authorization decision; it is generated content about authorization.

The practical rule is narrow and strict: a security-relevant fact that originates in model output is an input to validation, never an input to the permission decision.

The Learn article AI Agents and Tool Calling introduces this proposal-versus-decision split within the full agent loop.

Agent Identity Is Not the Initiating Principal

Two identities are present in almost every agent action, and collapsing them is one of the most consequential modelling errors in this area. The acting agent or workload identity is the runtime that executes. The initiating principal is the human, service or workload whose task caused the action to exist.

Microsoft's Zero Trust guidance on least privilege for AI agents, which is vendor guidance and identified as such, describes giving agents their own distinct identities and binding their permissions to the task and to the user on whose behalf they act rather than relying on shared or standing credentials. The architectural point generalizes: record both identities, and never silently convert a user's delegated authority into the agent's standing authority.

What an Authorization Decision Must Bind

A decision is only as precise as the facts it binds. A useful minimum for agentic actions is the following set, resolved before evaluation and recorded with the decision.

Where the Decision and the Enforcement Live

Two components are worth separating even in a small system. The decision point evaluates a resolved request against policy and returns a decision with a reason. The enforcement point sits on the execution path and will not perform the operation without an allow decision for that exact request.

The flow is linear, but the trust model is not. The user task and the model's proposed action are request content and remain variable; they say what is wanted, never what is permitted. The resolver, decision point and enforcement point are system components, and the identity, session, delegation and policy facts they use are resolved out of band from trusted stores, not read out of the prompt. Being a system component does not make the content it handles trusted, and the downstream resource returns data and results that carry their own trust and may themselves be externally influenced.

Place the decision as close as practical to the consequential action, so that the request evaluated is the request executed.

Orchestrator Checks Do Not Guarantee Downstream Enforcement

An authorization check in the orchestrator protects the orchestrator's own execution path. It does not constrain what the target system will accept from a credential that reaches it by another route. Where the target system is the real policy enforcement point, the action must be authorized there as well.

Capability Availability Is Not Permission

Tool discovery answers what the agent can see. Authorization answers whether this task may use it. Systems frequently conflate the two, exposing a registered tool to every session and treating registration as consent.

Reducing which tools are exposed at all is valuable, but it belongs to least privilege. Authorization still has to evaluate each invocation that the exposure permits.

Token Possession Is Not Universal Authority

Tokens are a common carrier of delegated authority, and they are frequently over-read. A token establishes what its issuer asserted, for which audience, with which scopes or roles, and for how long. It is not a general permission to act on the holder's behalf everywhere.

RFC 8707, Resource Indicators for OAuth 2.0, is used here narrowly: it defines a way for a client to signal the specific protected resource it intends to access when requesting a token, which supports issuing tokens restricted to that target audience. That is one useful mechanism for avoiding broadly valid tokens. It is not a claim that OAuth is required for agent authorization, nor that any token mechanism resolves agent security on its own.

Delegation Is Not Unlimited Impersonation

When an agent acts for a user, the useful model is delegation with preserved context, not impersonation. Delegation records who delegated, what was delegated, for which task, resource and action, and for how long. Impersonation discards that and leaves a request that is indistinguishable from the user acting directly.

A frequent failure is silent promotion: a task starts under delegated user authority, hits a permission gap, and falls back to the service's own broader credential. That fallback should be an explicit, policy-governed decision, not an implicit retry.

Authorization Context Must Not Be Model-Authored

The facts a decision depends on have to come from somewhere trustworthy. In agentic systems, the tempting shortcut is to let the model assemble them, because the model already has them in context as text.

Where a value has to originate in the model, because only the model knows what the user asked for, it is treated as a proposal: resolved against an authoritative source, validated, and then authorized. Resolution and validation are not the same as trust.

Exact-Action Authorization

Exact-action authorization means the decision is made after parameters are concrete, on the request that will actually execute. A broad permission to send email should not authorize an arbitrary combination of recipient, attachment, body and data source.

Stale Authorization and Time-of-Check Gaps

A plan approved at one moment may execute against different facts. The target may resolve differently, a parameter may be rewritten by a later step, the classification of an attachment may change, the delegation may have expired, or the policy may have been updated.

Where an execution-relevant fact has changed materially, the correct behaviour is to authorize the execution request again rather than rely on the earlier decision about the plan.

Confused Deputy at Privilege Boundaries

A more privileged component that performs work because the caller is authenticated is a confused deputy. The caller's identity is established; the question of whether the caller's delegated scope covers the requested operation has not been asked.

Every privilege boundary in the system needs this check, including internal ones that feel like implementation details.

Per-Hop Authorization in Multi-Agent Systems

Delegation across agents must not amplify authority. A downstream agent should receive at most the subset required for its subtask, and every hop should have a scope that can be enforced independently rather than inherited by convention.

1. 01
   Bound subset per hop

   The delegated scope handed to a downstream agent is a subset of the upstream scope, derived from the subtask rather than copied wholesale.

2. 02
   Preserved initiating principal

   The principal and task travel with the delegation in a form the receiving side can verify, not as prose in a message.

3. 03
   Independent enforcement

   Each hop authorizes the request it receives; no hop treats an upstream allow as sufficient for its own action.

4. 04
   No re-expansion

   A downstream component cannot request a broader grant than the delegation it received, and attempts to do so are denied and recorded.

The attack-side view of what happens without this is documented in multi-agent prompt injection; this page is the control reference rather than the threat description.

Human Approval Is a Layer, Not the Base Model

Human approval is valuable for selected high-impact actions, and it is a poor substitute for an authorization model. If the base decision is missing, approval becomes the only gate, and it is the gate most easily worn down by volume.

An approval that is worth having is specific and informed: it names the resource, the parameters and the destination that will be used. Approval UX, consent quality and fatigue belong to the human-in-the-loop control rather than to this page.

Boundaries With Neighbouring Controls

Authorization is one control among several that meet at the action boundary. Keeping the responsibilities apart makes each of them testable.

Sequence-level composition is covered in Tool-Chain Analysis; a chain result never pre-authorizes a call.

Deny by Default and Fail Closed

When a security-relevant fact is missing or ambiguous, the safe outcome is a denial with a reason code. The unsafe outcome is a system that lets the missing fact be completed from model-authored text, because that converts an availability problem into an authorization bypass.

Each of these produces a denial that is visible, attributable and testable, which is what makes deny-on-missing-context measurable later.

Revocation and Short-Lived Authority

Authorization decisions are made against a state that can change. Two operational properties matter here, and both are kept deliberately bounded because credential lifecycle in general belongs to least privilege and identity management.

Microsoft's vendor guidance on least privilege for AI agents discusses just-in-time and time-bound elevation for agent identities rather than persistent standing rights. The relevant point for authorization is narrower: the enforcement point must consult current state, so that a withdrawal takes effect at the next decision rather than at the next credential renewal.

Worked Scenario: A Routine Vendor Invoice Email

The scenario is synthetic, bounded and reversible. Its purpose is to show that proposal, authorization and execution are three separate facts, not to demonstrate any technique.

What the Scenario Does and Does Not Prove

A single contained run demonstrates that one gate held for one request. Coverage claims require the measurements in the testing section, with their denominators stated.

Authorization Telemetry

Authorization telemetry is what makes the control investigable. The minimum is a record per decision that ties the proposal, the resolved context, the decision and the outcome together.

Collapsing these into a single event makes it impossible to tell a blocked attempt from a completed action, which is precisely the distinction an investigation needs.

Testing and Metrics

Each measure below is reported separately, with its denominator stated. There is no composite authorization score, because a single number hides which property failed.

Revocation Enforcement Time is reported as an operational latency rather than a rate: the time between a withdrawal and the first enforcement point that stops accepting the withdrawn authority. Benign task utility is reported separately as well, and is never folded into a security figure, because a system that denies everything scores perfectly on every block rate.

To practice these properties in a controlled setting, the Agent Authorization lab is a deterministic simulation of exact-action authorization, principal and delegation binding, re-authorization after material parameter changes and per-hop non-amplification.

Incident Response and Common Mistakes

When an agent action goes wrong, the first job is to establish which of four different failures occurred, because the remediation differs entirely.

On source use: the Microsoft pages are vendor and product guidance and are labelled as such, with product-specific behaviour not generalized beyond that product. OWASP's Top 10 for Agentic Applications 2026 is used as a neighbouring risk framework for identity and privilege abuse, not as an authorization standard. RFC 8707 is used narrowly for explicit resource indication and audience restriction, with no implication that OAuth is required or sufficient. NIST SP 800-207 was considered and intentionally omitted, because its policy decision and enforcement terminology adds no claim this page needs beyond the generic architecture already described here. Related attack-side material is available in the attack library, including indirect prompt injection and persistent prompt injection.

Frequently Asked Questions