How OAuth Token Exchange Enables AI Agent Identity Delegation

AI agents often need to act on behalf of end users, but traditional authentication frameworks struggle to enable such delegation without compromising security. Recent advancements in identity delegation—particularly through RFC 8693 (OAuth 2.0 Token Exchange)—are changing how AI systems manage user permissions. By integrating this protocol with the Agent2Agent (A2A) framework and IBM Vault as an identity provider, organizations can streamline delegation while maintaining robust security controls.

The Challenge of Identity Delegation in AI Systems

Modern AI agents frequently require access to user-specific resources, whether to execute tasks, retrieve data, or perform actions on a user’s behalf. Traditional OAuth 2.0 flows authenticate the agent directly, but they lack a built-in mechanism for the agent to inherit the user’s identity or permissions. This limitation forces end users to manually approve each action, creating friction and reducing scalability.

Industry leaders like Microsoft’s Entra Agent ID and independent experts such as Christian Posta have highlighted this gap, advocating for solutions that align with RFC 8693. This specification introduces a standardized way to exchange tokens, enabling an agent to obtain a delegated access token that reflects the user’s identity and permissions. By implementing this flow, organizations can delegate authority securely while preserving auditability and fine-grained control.

Step 1: Generating a Subject Token with Delegation Claims

The first step in the delegation workflow involves authenticating the end user to the AI agent’s client, typically through an OpenID Connect (OIDC) provider. Here, IBM Vault serves as the OIDC provider, issuing a subject token enriched with a may_act claim. This claim explicitly defines which client agents are authorized to act on the user’s behalf, ensuring only pre-approved entities can request delegated access.

To configure this in Vault, administrators define an OIDC scope named may-act and attach it to the user’s identity token. The scope includes a list of client agents, each paired with a unique Vault entity ID. For example:

locals {
  may_act_scope_name = "may-act"
  may_act_claim      = jsonencode([
    for agent, info in var.client_agents : {
      client_id = agent,
      sub       = vault_identity_entity.client_agents[agent].id
    }
  ])
}

resource "vault_identity_oidc_scope" "may_act" {
  name        = local.may_act_scope_name
  template    = <<EOT
{
  "client_id": "${vault_identity_oidc_client.agent.client_id}",
  "may_act": ${local.may_act_claim}
}
EOT
  description = "Claim enabling agent delegation for OIDC tokens"
}

The resulting subject token includes critical fields such as client_id, sub, and the may_act array. These fields ensure the token’s authenticity and specify which agents are permitted to act on the user’s behalf. For instance:

{
  "iss": "$VAULT_ADDR/v1/identity/oidc/provider/agent",
  "sub": "50099deb-d0cf-911b-4310-64a173c542a6",
  "may_act": [
    {
      "client_id": "test-client",
      "sub": "83b1d088-c7d5-b8a4-dd7b-99baca521f8d"
    }
  ]
}

Administrators can configure multiple scopes to support different delegation scenarios, allowing end users to dynamically adjust which agents can act on their behalf.

Step 2: Requesting an Actor Token for Delegated Access

With the subject token in hand, the client agent requests an actor token from Vault’s identity secrets engine. This token is bound to the agent’s identity and includes claims that reflect the user’s delegated permissions. For example:

{
  "iss": "$VAULT_ADDR/v1/identity/oidc",
  "sub": "83b1d088-c7d5-b8a4-dd7b-99baca521f8d",
  "client_id": "test-client",
  "aud": "test-client",
  "scope": "helloworld:read"
}

The sub claim in the actor token corresponds to the Vault entity ID associated with the agent’s authentication method, such as Kubernetes or AppRole. This ensures the token’s lineage is traceable and tied to a specific role and authentication path. For example:

vault read identity/entity/id/83b1d088-c7d5-b8a4-dd7b-99baca521f8d

This command returns metadata about the entity, including its aliases and authentication methods, which helps administrators verify the token’s origin and scope.

Step 3: Exchanging Tokens to Obtain Delegated Access

The final step involves exchanging the subject token for a delegated access token using Vault’s custom secrets engine. This engine implements RFC 8693, enabling the exchange of tokens while preserving the user’s identity and permissions. The process involves validating the subject token’s may_act claim and ensuring the agent’s identity matches the authorized delegation.

A proof-of-concept implementation of this secrets engine is available on GitHub, though it remains unofficial and intended for educational purposes. Organizations interested in adopting this approach should evaluate its suitability for production environments and consider contributing to its development.

The Future of Agent Identity and Delegation

As AI agents become more integrated into enterprise workflows, the need for secure and scalable identity delegation will only grow. Protocols like RFC 8693, combined with robust identity providers such as IBM Vault, offer a promising path forward. By enabling agents to act on behalf of users without compromising security or usability, these solutions pave the way for more autonomous and intelligent systems.

For organizations exploring AI-driven automation, experimenting with identity delegation today could yield significant advantages in flexibility, compliance, and user experience tomorrow.