Agent Identity After MCP and A2A: Who Is Actually Authorized to Act on a User’s Behalf?

A user asks an agent to pay an invoice. An orchestrator sends a subtask to a remote A2A agent, which calls an MCP tool, and the tool calls a payment API. At the final step, the API sees a valid OAuth token—but that is not enough to answer the central question: who specifically authorized the transfer of this particular amount to this particular recipient?

A token may establish that a client is allowed to call an API. A SPIFFE ID establishes the identity of the executing process. An A2A Agent Card describes an agent’s capabilities and authentication methods. A trace ID captures the request’s technical path. None of these elements alone proves that a given agent is acting under a particular user’s limited mandate.

MCP and A2A address important but different parts of the problem. MCP formalizes OAuth-oriented access to a resource and prohibits forwarding user tokens. A2A standardizes agent discovery and task exchange. End-to-end delegation semantics across users, orchestrators, agents, and tools must be implemented by the application architecture.

Identity, authorization, and action provenance are three different questions

The term “agent identity” often conflates several independent entities. A real chain may involve the following:

For every action, three questions must be answered separately:

1. Who is authenticated? For example, a user, an OAuth client, or a workload with a particular SPIFFE ID.

2. Who is authorized to perform this specific action? This requires the target resource, operation, tenant boundary, parameters, expiration, and delegation depth.

3. What can prove this after execution? You need more than call logs: retain the authority identifier, policy decision, user approval, and a fingerprint of the actual request.

Workload identity is not a substitute for user delegation. SPIFFE IDs and SVIDs allow a process to cryptographically prove its machine identity within a trust domain. This is appropriate for mTLS, access to a token broker, and orchestrator identification, but it does not express user consent or the permitted scope of authority for a task (SPIFFE Identity).

The inverse is also true: possession of a user OAuth token does not establish which workload used it or whether that workload was authorized to delegate authority to the next agent.

What MCP actually guarantees

As of October 30, 2026, the final MCP revision is 2026-07-28. Its OAuth-oriented authorization model remains in place. Protocol sessions have been removed: each request carries the protocol version and client metadata (MCP 2026-07-28 revision overview).

An MCP server is an OAuth resource server

An HTTP MCP server is treated as a protected OAuth resource. It publishes Protected Resource Metadata, which the client uses to discover a suitable authorization server. The authorization server itself remains a separate role that issues tokens.

RFC 9728 defines a well-known URI for protected-resource metadata and makes it possible to associate a resource with permitted authorization servers. Where the set of participants is known in advance, the parties can verify the mutual consistency of their published metadata.

This matters for more than automated discovery. The association reduces the risk that a client obtains a token from the wrong issuer or presents it to an unsuitable resource.

Tokens must be bound to the resource

An MCP client must send the resource parameter in authorization and token requests. The server, in turn, must accept only tokens issued for it as the intended audience.

This leads to two mandatory architectural rules:

• A token for MCP Server A must not be accepted by MCP Server B.

• An MCP server must not forward an incoming user bearer token to an external API.

The second rule is fundamental. If a tool simply passes the original token downstream, the downstream service receives authority intended for a different resource. This creates the conditions for confused-deputy attacks, token substitution, and uncontrolled expansion of the trust boundary. Requirements for resource binding and the prohibition on token passthrough are described in the MCP authorization specification. In the dossier, this page refers to an earlier revision, so an implementation must pin the specification version it uses.

An OAuth client identifier is not an agent identity

Client ID Metadata Documents allow an HTTPS URL to serve as a client_id: the authorization server retrieves application metadata from that URL, including the redirect URI. MCP prefers pre-registration of the client, then CIMD, and only then Dynamic Client Registration.

But CIMD describes an OAuth client. It does not prove:

• the user’s identity;

• the identity of the running orchestrator instance;

• authorization for a particular action;

• the authority of a remote agent.

In addition, CIMD remained an IETF draft at the time of research. A production implementation must pin supported versions and review changes before upgrading (CIMD draft).

Baseline OAuth hygiene remains mandatory

An agent architecture does not eliminate standard OAuth security requirements. The OAuth Security BCP requires, among other things, exact redirect URI matching, PKCE for the Authorization Code flow, avoidance of implicit and password grants, and defenses against mix-up attacks. Asymmetric cryptography—for example, mTLS or private_key_jwt—is recommended for confidential-client authentication.

MCP provides a strong foundation for tool access. It does not describe the complete history of authority before and after that tool.

What A2A 1.0 standardizes—and what it does not

A2A 1.0 defines interaction between independent agents:

• discovery through Agent Cards;

• task lifecycles;

• messages and artifacts;

• synchronous, streaming, and asynchronous exchange;

• declaration of security schemes;

• an authenticated extended card for additional information available after authentication.

Its HTTP examples use bearer tokens. Access to tasks is tied to the authenticated client: a client must see only the tasks available to it.

However, an authenticated A2A client is not necessarily the original user. It may be an orchestrator, gateway, or another agent. Successful authentication establishes who sent the current request, but does not necessarily answer the following questions:

• Which user originated the mandate?

• Which rights were delegated at the previous step?

• Was the agent allowed to pass them on?

• Is the original tenant preserved?

• Was the specific state-changing operation approved?

A2A 1.0 core does not define a single mandatory format for a multi-step user delegation chain, an actor token, or a cryptographic provenance record. This is not necessarily a flaw in the transport protocol itself. Organizations differ in their tenant models, consent requirements, legal accountability, and decision-making models. These rules may be defined in a separate profile or a tightly specified application-level scheme.

A2A’s institutional development should not be confused with a ready-made authority model, either. In August 2026, A2A was accepted as a Growth Stage project in the Agentic AI Foundation (project announcement). Governance provides a venue for further development, but does not by itself standardize end-to-end delegation.

What an end-to-end authority model should look like

A robust design does not attempt to put the entire system into one “super-token.” Instead, it records the participants separately and issues new, narrower authority at every handoff.

A minimal action model includes:

• user — the user from whom the task originates;

• OAuth client — the application or MCP host;

• workload identity — the specific orchestrator, agent, or tool;

• executing component — the model or other component that formed the decision;

• target resource — the canonical identifier of an MCP, A2A, or API resource;

• operation — the permitted action;

• authority scope — the set of permitted rights;

• tenant — the data and policy boundary;

• purpose — the purpose of the mandate, where used by policy;

• delegation depth — the permitted number of subsequent handoffs;

• expiration — when the authority ceases to be valid;

• authority or delegation identifier — a reference to the originating delegation decision.

Every handoff requires a separate token

An orchestrator must not pass a user token to an A2A agent, and an MCP server must not forward it to a downstream API. Obtain a separate short-lived token for every next resource:

User
  → token for the MCP host/server
  → token for a specific A2A endpoint
  → token for a specific MCP tool
  → token for the downstream API

Every downstream token should have:

• one narrow audience;

• a scope no broader than the incoming authority;

• explicit tenant binding;

• a short lifetime;

• a delegation-depth limit;

• where needed, binding to the recipient’s key.

RFC 8693 Token Exchange allows a new token to be requested for a particular resource, audience, and scope. The act and may_act claims can describe the current or permitted acting party.

However, token exchange does not automatically create a persistent cryptographic linkage between the incoming and outgoing tokens. It is a separate issuance event, and revocation propagation across the entire chain is not a general property of the protocol.

Nor should one token be requested for multiple audiences and scopes at once. RFC 8693 warns that such a request effectively creates a Cartesian product of resources and rights. The authorization server may reject it as invalid_target. In an agent chain, multiple narrow tokens are safer than a general-purpose bearer token for multiple audiences.

Access decisions must be made outside the LLM

A model can propose a tool call, choose parameters, or create a plan. It must not be the only component deciding whether the action is allowed.

The policy enforcement point should validate structured data:

• the subject and workload;

• issuer and audience;

• tenant;

• permitted operation;

• actual request parameters;

• expiration and delegation depth;

• presence of required approval;

• the version of the applied policy.

This is especially important for parameters that change the meaning of an operation: amount, recipient, tenant, object identifier, or target endpoint. Text in the conversation history is not a substitute for a formal policy decision.

Choosing a delegation mechanism

There is not yet a universal format for every scenario. The choice depends on trust boundaries and requirements for portable authority.

In UCAN, delegated authority must be equal to or narrower than the delegating party’s authority, while the proof chain exposes intermediaries. But secure operation still requires trusted, authenticated agents, a protected channel, and a separate revocation model.

W3C Verifiable Credentials Data Model 2.0 makes it possible to express verifiable issuer assertions about a subject and includes credentialStatus for detecting suspension or revocation. However, the specific status mechanism, trust in the issuer, and business validation rules remain outside the data model. Validating a VC on every tool invocation may be unnecessarily expensive and complex.

OpenA2A Agent Authorization Protocol should not be treated as an established production standard. As of October 2026, the project labels version 0.5.1 as a proposed draft open to co-authors. It can be studied and tested, but stable interoperability or proven adoption should not be assumed without separate verification.

Within a single enterprise trust domain, a complex chain of delegated authority may not be necessary. OAuth, workload identity, short-lived tokens, centralized PDPs/PEPs, and unified auditing often provide a simpler and sufficiently strong model. The OpenID Foundation likewise considers OAuth 2.1 suitable for many synchronous single-domain scenarios, identifying the main gaps in cross-domain, highly autonomous, asynchronous, and multi-user delegation (Identity Management for Agentic AI).

Primary attack paths

Confused deputy and audience substitution

A typical scenario is that an agent legitimately has access to two resources but uses one user’s or tenant’s authority when accessing the other resource.

At every policy enforcement point, validate:

• issuer and signature, or the introspection result;

• expiration;

• the exact audience/resource value;

• the canonical endpoint identifier;

• the tenant in the authority and the tenant of the target object;

• scope and operation;

• the prohibition on forwarding the incoming token downstream.

Host, path, and resource-identifier normalization require particular attention. A path or hostname variation must not cause the server to process a tenant A request as a tenant B request.

Token theft and replay

DPoP binds an OAuth token to the holder’s key. The proof is bound to the HTTP method, target URI, and access-token hash through the htm, htu, and ath parameters (RFC 9449). An intercepted bearer token without the corresponding key is therefore insufficient.

But DPoP does not eliminate replay automatically. Reuse of the same proof at the same endpoint requires a short acceptance window and, for strict protection, one of the following mechanisms:

• shared jti replay detection;

• a server nonce;

• a coordinated combination of both approaches.

In a horizontally scaled system, an instance-local cache is insufficient. Otherwise, a proof already accepted by node A can be replayed to node B. Shared replay storage increases processing cost and complexity, so its impact must be measured rather than assumed.

Cross-tenant escalation

Tenant binding must be checked at every handoff, not only in the initial user token. A token for the downstream service without tenant-bound authority creates a gap: the downstream service can see an allowed scope but cannot determine the allowed data boundary.

For a particularly sensitive chain, a practical starting policy is:

• audience: one specific endpoint;

• scope: a subset of the incoming rights;

• delegation depth: no more than one handoff;

• tenant: an explicit mandatory field;

• further delegation: only through a new token exchange.

User approval and long-running tasks

In MCP 2026-07-28, multi-round-trip requests allow a tool or server to request user input or confirmation and receive it when the original call is retried. This is a useful human-in-the-loop mechanism, but the protocol itself does not determine which actions require approval or how approval is bound to the operation.

Approval should be retained as a separate decision linked, at minimum, to:

• the risk class;

• the user or other approving party;

• the target resource;

• the canonical action parameters or their hash;

• the tenant;

• the delegation identifier;

• the expiration time.

If the amount, recipient, tenant, or purpose of the call changes after approval, the previous approval must not apply. Reuse is possible only for the identical action and only within explicitly defined policy limits.

This is especially important for asynchronous A2A tasks. Tokens may expire, policy may change, or the originating mandate may be revoked between task submission and the actual state change. Before an irreversible step, the executor must revalidate current authority rather than rely on the fact that the task was once accepted.

Revocation does not automatically propagate through the chain

If the original grant is revoked, previously issued downstream tokens may remain valid until exp. Token Exchange does not guarantee cascading revocation.

The architecture must choose a combination of controls:

• short TTLs;

• introspection before sensitive actions;

• deny lists for grant or token identifiers;

• revocation events;

• reauthorization at critical stages.

Every combination leaves a risk window. It must be measured and documented—for example, how quickly revocation reaches every policy enforcement point and how long an already issued token can be used without contacting the authorization server.

Provenance and auditing: a trace ID is not enough

Trace context helps correlate the technical execution path. MCP 2026-07-28 supports propagation of W3C trace context through _meta, while OpenTelemetry defines context propagation as the transfer of execution-related values across process boundaries (OpenTelemetry Context Propagation).

But a trace ID does not prove authority. Its presence does not mean that a user approved the action, that policy permitted the specific parameters, or that an intermediate agent did not expand the scope.

A minimal action record should include:

• the user subject;

• the OAuth client_id;

• workload identities of the orchestrator and executor;

• A2A agent and MCP tool identifiers;

• the identifier and version of the executing component, if required by the control model;

• the canonical target resource;

• the grant/delegation ID;

• jti or a secure token hash;

• the policy decision and its version;

• user-approval information;

• a hash of the canonical request;

• trace_id;

• the downstream call result.

Such a record ties together identities, authority, decision, and the actual request. Requirements for tamper protection, retention periods, privacy, and legal evidentiary value depend on the industry and jurisdiction; ordinary JWT claims, conversation logs, or trace IDs must not automatically be treated as proof of non-repudiation.

The NIST concept paper specifically distinguishes human and agent identities, least privilege under unpredictable behavior, proof of authority for a specific action, delegation, and accountability. It is a concept paper and request for public comment, not a completed standards profile.

How to validate the architecture before production rollout

Compatibility among specific MCP hosts, A2A SDKs, and authorization servers cannot be inferred from specification text. It should be validated experimentally. The following scenarios are a validation methodology, not published measurement results.

1. Baseline flow

Deploy an authorization server, MCP host, MCP resource server, and test API.

1. The user completes Authorization Code + PKCE.

2. The host requests a token with resource set to the specific MCP endpoint.

3. The MCP server validates the issuer, signature or introspection result, exp, audience, scope, and tenant.

4. For the API, the server obtains a separate short-lived token through Token Exchange.

5. The audit record includes the user, client_id, the orchestrator’s SPIFFE ID, tool, resource, jti or token hash, policy decision, trace_id, and result.

The critical invariant: the original user bearer token never reaches the downstream API.

2. Confused deputy and token substitution

Create two MCP servers and two tenant APIs.

• Send a token for Server A to Server B.

• Attempt to make an MCP tool forward the incoming token to an external API.

• Substitute a path, host, or resource identifier so that a tenant A request appears to be a tenant B request.

A protected system must reject the wrong audience, prohibit token forwarding, and preserve tenant binding after address canonicalization.

3. Replay and delegation of authority to an agent

Issue an A2A Agent B downstream token bound with DPoP.

Validate:

• use of the token without the private key;

• replay of the same proof for the same method and URI;

• replay of the proof against another endpoint;

• validation of cnf, htm, htu, ath, iat, nonce, and jti;

• the difference in behavior on one node and in a horizontally scaled system.

If replay succeeds through another service instance, replay protection is effectively limited to the node boundary.

4. Cross-tenant delegation and approval

A tenant A user delegates a task to an orchestrator, which delegates a subtask to agent B.

Verify that B cannot:

• call a privileged tool belonging to another tenant;

• expand the scope;

• exceed the permitted delegation depth;

• replace the target endpoint;

• use an approval after changing the amount, recipient, or tenant.

Then revoke the originating grant and measure how long already issued tokens continue to work without introspection or a deny list.

Readiness criteria

An architecture can be considered ready for production operation only after the following invariants have been verified:

• an upstream token is not accepted by a resource with a different audience;

• a user bearer token is not forwarded along the chain;

• authority only narrows during delegation;

• every workload is cryptographically identified separately from the user;

• the tenant is checked at every policy enforcement point;

• access decisions are made outside the LLM;

• approval is bound to exact parameters and cannot be reused after they change;

• DPoP replay protection works across the entire cluster, not only on one node;

• the audit trail links the action to the user, workload, grant, policy, and actual request;

• the window between grant revocation and the point at which downstream tokens cease to be valid has been measured and accepted by the risk owner.

MCP and A2A should not be evaluated as competing answers to the same question. MCP constrains client access to a tool. A2A organizes task exchange between agents. End-to-end authority exists only when the architecture links the human subject, OAuth client, executing workload, target resource, and specific action—and issues a new, narrow, verifiable authorization at every handoff rather than forwarding the original token downstream.