--- title: Identifying Agents with Token Exchange description: Use OAuth 2.0 token exchange to identify AI agents in a delegation chain with nested act claims, creating an audit trail back to the human user. component: identity-for-ai page_id: identity-for-ai:identity:idai-token-exchange canonical_url: https://developer.pingidentity.com/identity-for-ai/identity/idai-token-exchange.html llms_txt: https://developer.pingidentity.com/identity-for-ai/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: August 14, 2026 keywords: ["identity for ai", "ai identity", "ai security", "ai governance", "ai compliance", "ai agent", "ai agent types", "personal agent", "digital assistant", "digital worker"] section_ids: the-value-of-preserving-the-delegation-chain: The value of preserving the delegation chain token-exchange-in-an-agent-to-agent-flow: Token exchange in an agent-to-agent flow configuring-token-exchange-with-ping-identity: Configuring token exchange with Ping Identity --- # Identifying Agents with Token Exchange In a standard OAuth flow, an application might impersonate a user, holding a token that allows it to do anything a user can do. This makes the application's behavior indistinguishable from user-performed actions. In complex agentic architectures (where multiple AI agents are collaborating with each other), this is dangerous, especially if rogue agent activity cannot be traced. The OAuth 2.0 Token Exchange protocol ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)) defines how to apply the concept of delegation to token exchange. The advantage of delegation over other approaches, such as secret vault retrieval, is that an agent never possesses live credentials. An agent only possesses a finely-scoped access token after the end user triggers token exchange. ## The value of preserving the delegation chain Token exchange supports two essential pillars of agentic systems: accountability and authorization. First, the delegation chain provides a complete audit trail. Rather than agent activity appearing as if it were performed by the user, the `sub` and `act` claims preserve who acted on whose behalf. Combined with security telemetry, this allows for a full story behind each action, making agent actions attributable and traceable. In other words, a token can show "I'm Agent A, and I'm performing a specific action requested by Agent B, to complete a task for User C." Second, this context enables more precise authorization decisions. A resource server can evaluate not only what the user is allowed to do, but also whether a particular agent is allowed to do it for the user. This allows policies to account for not only the user, but also the specific actors involved. ## Token exchange in an agent-to-agent flow The following graphic illustrates an agent-to-agent flow, where multiple agents are working together and communicating with a Model Context Protocol (MCP) server to solve a problem on behalf of the user. ![A diagram showing each step of token exchange between a user, two agents, and an MCP server.](_images/idai-token-exchange.png) The key to this flow is the `act` (actor) claim within the JSON Web Token (JWT). With each new agent authentication, a new `act` claim is appended, creating a nested audit trail of collaboration between agents and servers. The following describes each authentication in the flow: 1. User authentication The process begins with a human user authenticating with an identity provider (IdP) to use an agent. * **The exchange:** Ping Identity (the IdP) issues a JWT. * **Key claims:** * `sub` (subject): user\@example.com (The human). * `aud` (audience): https\://agent1.example.com (The "orchestrator" agent the human is communicating with). * **Meaning:** The user is interacting directly with agent 1, so there is no `act` claim yet. 2. Agent 1 delegates to agent 2 Agent 1 needs to offload a task to agent 2. Agent 1 can't just pass the user's token because that token is scoped for agent 1, not agent 2. * **The exchange:** Agent 1 contacts the IdP and requests token exchange. It presents the user's token and asks for a new token valid for agent 2. * **Key claims:** * `sub`: user\@example.com (Still the user). * `aud`: https\://agent2.example.com (Now valid for agent 2). * The `act` claim: ```json "act": { "sub":"https://agent1.example.com", } ``` * **Meaning:** Agent 1 is the actor requesting agent 2 to perform a task on behalf of the user. 3. Agent 2 delegates to MCP server Agent 2 now needs to access a tool or resource through an MCP server. * **The exchange:** Agent 2 sends the token it received from agent 1 to the IdP and requests a token scoped for the MCP server. * **Key claims:** * `sub`: user\@example.com (Still the user). * `aud`: https\://mcp-server1.example.com (Valid for the MCP server). * The nested `act` claim: ```json "act": { "sub":"https://agent2.example.com", "act": { "sub":"https://agent1.example.com", } } ``` * **Meaning:** Now, agent 2 is the actor performing token exchange with the MCP server, having been triggered by agent 1. The user is still the original owner of the request. This demonstrates a complete chain of delegation. Because every actor appends its own identifier at each stage of the flow, the final token distinguishes agent activity from the original human request, resulting in an audit trail of every action. To complete the user's task, the MCP server will access the target resource server. This backend connection is typically authenticated using an API key, an access token, or a dedicated service account. ## Configuring token exchange with Ping Identity The following product documentation covers token exchange configuration for each supported IdP: * [PingAM](https://docs.pingidentity.com/pingam/latest/am-oauth2/token-exchange.html) * [PingOne](https://docs.pingidentity.com/pingone/use_cases/p1_oauth_2_token_exchange.html) * [PingOne Advanced Identity Cloud](https://docs.pingidentity.com/pingoneaic/am-oauth2/token-exchange.html) * [PingFederate](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_oauth_exchange.html)