Agent Identity and Authorization in Production: Scoped Delegation, RFC 8693 Token Exchange, and Sender-Constrained DPoP Tokens

As autonomous AI agents shift from isolated experimental runtimes to multi-hop enterprise systems, identity and access management (IAM) has emerged as the primary security barrier in production engineering. Early agent architectures relied on two flawed authentication models: deploying static API keys stored in environment variables, or passing broad, long-lived user bearer tokens directly into agent execution contexts.

Both approaches break down under real-world threat models. When an agent executes untrusted code, ingests adversarial third-party data subject to indirect prompt injection, or delegates tasks across secondary subagents and Model Context Protocol (MCP) servers, broad bearer tokens expose the entire enterprise perimeter to confused deputy attacks and credential exfiltration.

Hardening production AI workflows requires shifting from static credentials to zero-trust delegated access. By combining RFC 8693 OAuth 2.0 Token Exchange, RFC 8707 Resource Indicators, and sender-constrained tokens via RFC 9449 Demonstrating Proof-of-Possession (DPoP), engineering teams can establish auditable, cryptographically bound, least-privilege agent execution pipelines.

The Failure Modes of Static Credentials and Bearer Pass-Through

Traditional web applications operate under a simple two-party or three-party authorization model: a user authenticates directly to an application, or grants an application a static OAuth token to access a specific API. Autonomous agents invalidate this paradigm because execution paths are dynamic, non-deterministic, and frequently span multiple hops across orchestrators, specialized subagents, and third-party tools.

Three common architectural antipatterns introduce severe security vulnerabilities in production:

Shared Service Accounts and Root API Keys: Assigning a single high-privilege service principal to an agent runtime obliterates identity attribution. If an agent executes a destructive database mutation or transfers funds, audit logs reflect only the service principal, making it impossible to determine which user authorized the action or which subagent initiated the prompt.
User Bearer Token Pass-Through: Passing a user's full OAuth access token (such as an enterprise Okta or Google workspace token) into an agent's memory context allows the agent to call any API the user can access. If an agent ingests malicious instructions through prompt injection, an attacker can coerce the model into calling unauthorized endpoints using the user's ambient authority.
Token Leakage in Context Traces and LLM Scratchpads: Bearer tokens present in prompt memory, tool parameter schemas, or execution logs can be captured by external logging pipelines, model training feedback loops, or unintended prompt reflections. Because standard bearer tokens are unconstrained, any entity that intercepts the string can replay it against downstream resources without restriction.

The Delegation Triad: Subject, Actor, and Resource Indicators

To resolve the confused deputy problem, an agent authorization architecture must separate the entity authorizing an action from the entity executing it. This separation is formalized across three core identity primitives:

Subject (sub): The end-user or principal who owns the underlying data and authorized the high-level workflow.
Actor (act): The autonomous agent, subagent, or execution runtime performing the immediate API invocation on behalf of the subject.
Audience / Resource (aud / resource): The specific downstream service, MCP server, or API endpoint that the resulting credential is authorized to access, strictly bounded via RFC 8707 Resource Indicators.

By encoding this relationship into cryptographically signed JSON Web Tokens (JWTs), downstream services can verify both that the user consented to the action and that the specific agent runtime is authorized to act as an intermediary.

The Mechanics of RFC 8693 Token Exchange

The IETF standard for On-Behalf-Of (OBO) identity propagation is RFC 8693 OAuth 2.0 Token Exchange. Instead of allowing an agent to hold persistent access to every tool in its environment, the agent interacts with a centralized Security Token Service (STS) or Authorization Server.

When an orchestrator agent determines that a subagent needs to call a specific tool (for example, querying a customer CRM or reading an internal repository), it initiates a token exchange request:

POST /oauth/token HTTP/1.1
Host: auth.enterprise.internal
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOiJSUzI1NiIsIn...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=eyJhbGciOiJSUzI1NiIsIn...
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://api.crm.enterprise.internal/v1/
&scope=contacts:read

Multi-Hop Delegation and Nested Actor Claims

In complex agent swarms, workflows rarely stop at a single hop. A primary planner agent may spawn a code generation subagent, which in turn invokes a continuous integration tool through an MCP server.

RFC 8693 accommodates multi-hop delegation chains by nesting the act claim within the issued JWT:

{
  "iss": "https://auth.enterprise.internal",
  "sub": "user_29d8a1e4",
  "aud": "https://api.crm.enterprise.internal/v1/",
  "exp": 1755740400,
  "nbf": 1755739500,
  "scope": "contacts:read",
  "act": {
    "sub": "agent_data_retriever_v2",
    "act": {
      "sub": "agent_primary_orchestrator"
    }
  }
}

In this structure:

sub identifies the human user whose authorization grounds the entire chain.
The top-level act.sub identifies the immediate agent invoking the API.
The nested act.act.sub records the upstream orchestrator that spawned the execution step.

Downstream resource servers enforce authorization by evaluating the top-level sub, the immediate act, and the granted scope. The nested chain provides an immutable audit trail for incident response and compliance monitoring, ensuring complete visibility into the path of delegation.

Mitigating Token Theft with Sender-Constrained DPoP Tokens

Even when tokens are scoped to narrow audiences, standard OAuth bearer tokens remain vulnerable to exfiltration: if an attacker extracts a bearer token from a sandbox environment, it can be replayed from any network location until expiration.

To eliminate bearer replay risks, modern agent platforms implement RFC 9449 Demonstrating Proof-of-Possession (DPoP) alongside OAuth 2.1 specifications:

Ephemeral Key Generation: At session initialization, the agent client runtime generates an asymmetric cryptographic key pair (typically using Ed25519 or NIST P-256 curves) stored exclusively in volatile memory or a hardware-isolated enclave.
DPoP Proof Header: When making requests to the token endpoint or downstream APIs, the agent creates a signed JWT header containing the HTTP method, the target URI, a unique timestamp (iat), and a cryptographic thumbprint (jkt) of its public key.
Cryptographic Binding: The Authorization Server issues a token whose payload is cryptographically bound to the public key thumbprint (cnf.jkt).
Validation at Resource Servers: When the agent calls a downstream tool, the resource server verifies that the signature on the DPoP HTTP header matches the public key embedded in the token's confirmation claim.

GET /v1/contacts/10492 HTTP/1.1
Host: api.crm.enterprise.internal
Authorization: DPoP eyJhbGciOiJSUzI1NiIsIn...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...

If an adversary steals the access token string through prompt reflection or memory inspection, the token cannot be used without the private signing key, neutralizing token exfiltration attacks.

DPoP vs. Mutual TLS (mTLS)

While RFC 8705 Mutual-TLS Client Authentication provides equivalent sender-constraining guarantees at the transport layer, DPoP is significantly more practical for agentic deployments:

Application-Layer Portability: DPoP operates entirely over HTTP application headers, traversing Layer 7 API gateways, reverse proxies, and serverless edge functions without requiring complex TLS termination renegotiation.
Micro-Runtime Compatibility: Ephemeral key pairs can be generated instantly inside WebAssembly sandboxes, browser extensions, or short-lived Python subprocesses without distributing root certificates.

Dynamic Scoping and Step-Up Authorization

Static permission sets fail in autonomous agent workflows because an agent cannot anticipate every required tool invocation prior to reasoning over the prompt. However, granting blanket permissions at the start of a session violates least-privilege principles.

Production implementations resolve this tension through Just-In-Time (JIT) scoping and Step-Up challenge loops:

[User Session]
       |
       v
[Planning Agent] ---> (Calculates execution graph)
       |
       v
[Token Exchange] ---> STS checks baseline policy:
       |              - Grants read-only tokens automatically (TTL: 5 min)
       |
       +------------> High-Risk Action Detected (e.g. Write / Delete / Pay):
                      - Triggers Step-Up Authentication challenge
                      - Webhook / Push notification sent to User device
                      - User approves -> Elevated token issued (TTL: 2 min, single-use)

Baseline Least Privilege: Initial token exchanges grant only read-only or low-impact scopes (such as search, document parsing, or read-only database queries) with short lifetimes (typically 5 to 15 minutes).
Granular Down-Scoping: When delegating to subagents, the primary agent explicitly strips unused scopes from the exchanged token, ensuring child processes operate in restricted sub-enclaves.
Human-in-the-Loop Step-Up Triggers: When an agent constructs a plan requiring high-consequence mutations (such as deleting data, updating payroll, or pushing code to production repositories), the STS intercepts the token exchange request and returns an insufficient_authorization challenge. The agent halts execution, dispatches an approval request to the user via out-of-band channels (such as push notifications or Slack confirmations), and resumes only after receiving a time-limited, step-up delegation token.

Implementation Blueprint: Token Exchange Payload Architecture

The following structural diagram outlines the exact field mappings required when constructing an enterprise-ready agent identity token:

+-------------------------------------------------------------------------+
|                              JWT Payload                                |
+-------------------------------------------------------------------------+
|  iss: "https://auth.enterprise.internal"   (Identity Provider)          |
|  sub: "usr_994821"                         (Human Owner / Subject)      |
|  aud: "https://mcp.github.internal"        (Downstream Tool Audience)   |
|  scope: "repo:read pull_requests:write"    (Strictly Bounded Scope)     |
|  exp: 1755739800                           (Short TTL: 300 seconds)     |
|                                                                         |
|  cnf: {                                    (RFC 9449 DPoP Binding)      |
|    "jkt": "0Z9nJ8pQr...k21L"               (Agent Public Key Hash)      |
|  }                                                                      |
|                                                                         |
|  act: {                                    (RFC 8693 Delegation Chain)  |
|    "sub": "agent_pr_reviewer",             (Immediate Executing Actor)  |
|    "act": {                                                             |
|      "sub": "agent_triage_lead"            (Upstream Orchestrator)      |
|    }                                                                    |
|  }                                                                      |
+-------------------------------------------------------------------------+

Production Hardening Checklist

Engineering teams deploying multi-agent systems and MCP tool servers should enforce the following operational safeguards:

Eliminate Ambient Authority: Ban static API keys and unconstrained service credentials from agent memory, system prompts, and configuration files.
Mandate RFC 8693 Token Exchange: Route all inter-agent and agent-to-tool communication through a dedicated Security Token Service that enforces On-Behalf-Of semantics.
Enforce RFC 8707 Resource Binding: Reject any token request that lacks a specific, fully-qualified resource or audience parameter to prevent cross-service token replay.
Deploy DPoP for Public Agent Clients: Require sender-constrained DPoP proofs on all API endpoints accessible to autonomous runtimes.
Clamp Token Lifetimes: Configure token time-to-live (TTL) between 5 and 15 minutes, with zero refresh token delegation to worker subagents.
Correlate Distributed Telemetry: Export both sub (user ID) and act.sub (agent runtime ID) as structured attributes in OpenTelemetry traces and audit logs to enable end-to-end provenance tracking.

By treating agent identity as a dynamic, cryptographically verifiable delegation problem rather than a static credential management task, organizations can safely scale autonomous agent swarms across sensitive enterprise environments.