Understanding the Issue
This isn't about a security breach. It's about a common architectural oversight that occurs before incidents happen, when teams deploy agentic systems without using token exchange with delegation.
Organizations adopting AI-driven workflows often face this issue: an application integrates a Large Language Model, uses an interface like Model Context Protocol, and routes requests through microservices. The agent performs actions, and audit logs show activity. But when you ask, "Who authorized this API call?" the answer is unclear.
The application made the call, but on whose behalf? With what scope? Through which intermediary? Without delegation, you're essentially giving your agent unrestricted access instead of a controlled and specific authorization.
How the Architectural Gap Develops
This isn't a timeline of an attack but a progression of how the gap emerges:
T+0: The team deploys an application with embedded agent capability. The user authenticates, and the application receives the user's access token.
T+1: The user instructs the agent to perform a task through a natural language interface. The agent interprets the intent and selects the appropriate tool from the MCP server.
T+2: The application calls a downstream service using its own service account credentials, not an exchanged token scoped to the user's request.
T+3: The service executes the action. Logs record the application service account as the actor, losing the user's identity.
T+4: During a later audit, the security team can't determine which user requested which agent action or scope the review to user entitlements.
Identifying Missing or Failed Controls
Token Exchange Implementation: The application didn't exchange the user's token when calling the agent or downstream services. RFC 8693 defines this exchange mechanism, but it's often skipped.
Delegation Chain: Even with token exchanges, the actor relationship isn't preserved. You know the application called the service, but not that it acted on behalf of a specific user with specific permissions.
Overprivileged Service Accounts: The application uses a service account with broad permissions instead of requesting downscoped tokens for each operation, leading to excessive access.
Policy Decision Point Validation: No authorization engine checks that the exchanged token's scopes match the requested resource action. The identity provider authenticates but doesn't enforce policy at each delegation boundary.
Broken Audit Trail: When the application calls an agent, which calls an MCP gateway, which calls a microservice, context is lost at each hop. You can't trace the chain back to the originating user.
What OAuth 2.0 and RFC 8693 Require
OAuth 2.0 allows delegated authorization, letting one party act on behalf of another with specific scopes. RFC 8693 extends this with token exchange, defining how to transform tokens while preserving the subject and actor relationship.
The specification defines three entities:
- Subject: The primary identity that owns the resource (your end user).
- Actor: The entity performing the exchange and subsequent action (your application, agent, or gateway).
- Authorization Server: The system performing the exchange and enforcing scope decisions.
A compliant exchange includes the subject token, the requested scope, and optionally the actor token. The authorization server returns a new token that binds the actor to the subject's delegated permissions.
For chained exchanges, application to agent to MCP gateway to service, each intermediary becomes an actor in the next exchange. The token carries the full delegation chain: user → application → agent → gateway. Each hop further downscopes permissions.
Action Items for Your Team
Implement Token Exchange at Every Service Boundary: Don't reuse the application's service account credentials for downstream calls. Exchange the user's token with the authorization server, requesting only the scopes needed for the specific operation. Your identity provider must support RFC 8693 exchanges.
Preserve the Actor Chain in Every Exchange: Include the actor claim in your token exchange request. When your application exchanges the user's token to call an agent, the resulting token should show the application as actor and the user as subject. When the agent calls the MCP gateway, the gateway becomes the new actor, but the application and user remain in the chain.
Scope Tokens to the Operation, Not the Service: Don't request read:all_documents when the agent only needs read:single_document for this specific user request. Your authorization server should enforce least-privilege scoping based on the requested resource and the subject's entitlements.
Deploy a Policy Decision Point that Validates Every Exchange: Before your authorization server issues the exchanged token, verify that the actor is permitted to perform this operation on behalf of this subject. Check that the requested scopes don't exceed what the subject is entitled to. Reject exchanges that violate Toxic Access Combination rules.
Instrument Your Audit Logs to Capture Delegation Chains: Standard access logs record the service account that made the call. You need logs that show: user X authenticated, application Y exchanged token on behalf of X, agent Z exchanged token on behalf of Y acting for X, service executed action. Without this chain, your Certification Campaigns can't tie agent actions back to user entitlements.
Test Your Audit Trail Before Deploying Agentic Workflows: Simulate a user request that triggers an agent action through multiple services. Pull the audit logs. Can you answer: which user authorized this? Which intermediaries acted? What scopes were granted at each hop? If you can't reconstruct the chain, your delegation implementation is incomplete.
The shift to agentic systems doesn't change the core requirement: you must know who is performing what action and for whom. Token exchange with delegation isn't new technology. It's a 2020 RFC that most teams ignored because their non-agentic architectures worked without it. Now it's mandatory.
