Identity-Bound Authorization: Closing the Execution-Layer Gap in AI Agent Deployments

Most agent security work targets the input: keep untrusted text from steering the model. That is necessary and insufficient. The harder problem sits one layer down, at the moment the agent actually calls something — and it is not a model problem at all. It is an authorization problem that existing identity infrastructure was not built to express.

The gap has a specific shape. Standard OAuth 2.0 assumes the client is the principal whose intent the token represents. For a human using an application, that holds. For an agent, it does not: the operator is the principal, and the agent is executing on their behalf. An OAuth flow that places the agent in the client role has made the agent the entity that decides when to use credentials authorizing its own actions.

That is not a configuration mistake. It is a category error baked into the protocol’s trust model, and it is why bolting agents onto human identity plumbing keeps producing the same failures.

What breaks, specifically

AI Identity: Standards, Gaps, and Research Directions for AI Agents (Otsuka, Toyoda, and Leung, April 2026) frames AI identity as “the continuous relationship between what an AI agent is declared to be and what it is observed to do,” and identifies five gaps: semantic intent verification, recursive delegation accountability, agent identity integrity, governance opacity and enforcement, and operational sustainability. Their conclusion is worth quoting in substance — these are structural gaps, and extending human frameworks to agents without structural modification produces systematic failures.

Authorization Propagation in Multi-Agent AI Systems (Tallam, May 2026) narrows to the multi-agent case and names three sub-problems that traditional access control models do not address:

Transitive delegation. Agent A is authorized to do X and delegates part of the work to Agent B. What is B authorized to do? RBAC, ABAC, and ReBAC all assume a principal making a request, not a chain of principals each narrowing or widening scope. Without an explicit rule, delegation either over-grants (B inherits A’s full authority) or breaks the workflow (B inherits nothing).

Aggregation inference. Each agent in a pipeline accesses data it is individually permitted to see. The composition reveals something none of them was permitted to derive. This is an old problem in database security, and it returns with force when a synthesis step is the entire point of the architecture.

Temporal validity. Authorization granted at the start of a long-running task may not be valid when the task actually executes. Agents run for minutes or hours, queue work, and retry. A token that was correct at request time may be wrong at execution time — the user’s role changed, the resource moved, the task was superseded.

Why the execution layer is the right place to enforce

The instinct is to solve this at the orchestration layer: have the framework track who asked for what and check permissions before dispatching. That fails for a structural reason — the orchestrator is part of the system being defended. A compromised or manipulated planning step produces a request the orchestrator believes is legitimate, and any check the orchestrator performs on its own output inherits the compromise.

Enforcement has to happen where the action occurs, against an identity the agent cannot mint for itself, with a scope that was fixed before the agent’s reasoning began.

That is what “identity-bound” means in practice: the credential presented at the call site is cryptographically tied to a specific principal and a specific delegation chain, issued by something outside the agent’s control, and scoped to the intersection of what the agent may do and what the delegating user may do. The intersection matters. An agent should never be able to do something its principal cannot, and a user should never gain capability by routing a request through an agent.

The mechanisms being proposed

The Tallam paper sets out seven structural requirements and points to a set of emerging mechanisms:

• Invocation-bound capability tokens — a credential valid for one specific call rather than a session, which collapses the window in which a stolen token is useful.
• Task-scoped authorization envelopes — an explicit boundary attached to a task that constrains everything done under it, including by sub-agents.
• Dependency-graph policy enforcement — evaluating authorization against the actual graph of data and delegation, which is what makes aggregation inference detectable at all.
• Execution-count revocation — credentials that expire after N uses rather than after a duration, appropriate when the work is bounded by actions rather than time.

Complementary work is happening in standards. IETF activity on agent identity introduces dual-identity credentials binding an agent to its human owner through delegation flows that produce auditable accountability chains. Cloud Security Alliance guidance on agentic AI calls for trusted agent registries, authentication via verifiable credentials, short-lived OAuth 2.0/OIDC tokens, and a prohibition on cross-agent privilege delegation unless explicitly authorized. NIST issued a request for information on AI agent security in early 2026 and published a concept paper on agent identity and authorization.

None of this is settled. The direction is consistent — short-lived, narrowly scoped, cryptographically attributable credentials evaluated at every boundary — but the interoperable specification does not exist yet.

What is deployable now

Teams running agents in production do not get to wait for the standards to converge. The controls available today, in rough order of return:

Issue credentials per task, not per agent. A long-lived service account shared by an agent fleet is the single largest amplifier of every failure mode above. Per-task issuance is the precondition for everything else.

Enforce the intersection rule. Scope every token to what the agent is permitted to do and what the delegating principal is permitted to do. This is the control that prevents an agent from becoming a privilege escalation path, and it is enforceable with existing infrastructure.

Make delegation explicit and recorded. When an agent hands work to another agent, that should produce an auditable record naming the delegating identity, the scope passed, and the task. If your architecture cannot answer “on whose authority did this call happen,” the answer during an incident will be nobody’s.

Keep the enforcement point outside the agent. A policy check the agent performs on itself is not a control. Put it in the gateway, the proxy, or the resource server.

Prefer short lifetimes over broad revocation. Revocation infrastructure that works across a distributed agent system is hard. Credentials measured in minutes, or in permitted invocations, sidestep much of that.

Log at the call site. The orchestration trace tells you what the system intended. The call-site log tells you what it did. When those diverge, the second one is the incident.

The connection to the rest of the stack

Identity-bound authorization does not stop an agent from being manipulated. It bounds what a manipulated agent can accomplish — which is the same relationship that memory safety has to application bugs. It also does real work against a different failure class: the supply chain risk in installed agent skills, where privilege escalation appeared in 11.8% of analyzed skills. A skill can only escalate to privilege that exists to be escalated to.

The framing that has served best: assume the agent’s reasoning will eventually be wrong or subverted, and design so that being wrong costs a bounded amount. That is an authorization architecture question, and it is answerable now with mechanisms that exist, rather than a research problem to defer.