Propagate identity without expanding privilege

Learning objective

Propagate user and agent identity across agent, tool, and data boundaries while keeping every action within the authority granted for the task. This lesson focuses on identity continuity and least privilege, not on creating identities or configuring a specific authorization product.

Core idea

Keep the subject and actor distinct. The subject is the user on whose behalf a task runs. The actor is the agent or service that makes the current request. A downstream service often needs both identities to answer two different questions:

• May this agent call this service and operation?
• May it do so for this user and this user’s data?

For a user-mediated action, use this design invariant:

effective authority at a hop
  is no broader than
  user delegation AND current-agent policy AND destination policy AND task limits

Treat AND as an intersection, not a union. A broadly privileged agent must not give a user access that the user lacks. A privileged user must not enable an agent to call tools outside that agent’s role. If a required identity or grant cannot be verified, deny the operation or request the missing authorization. Do not silently fall back to a more privileged workload credential.

How it works

Build an identity envelope from trusted security context, not from model text or tool arguments. The envelope should identify the initiating user, current agent, delegation or consent, intended audience, permitted action or scope, lifetime, and task correlation ID. A correlation ID supports tracing; it is not a credential.

At every agent-to-agent or agent-to-tool hop:

1. Authenticate the immediate caller and validate the credential’s issuer, audience, lifetime, signature, and proof-of-possession binding when present.
2. Verify any delegated user authority independently of the agent’s identity.
3. Authorize the exact operation and resource against all applicable policies.
4. Exchange or mint a short-lived, destination-specific credential when the next hop needs one. Do not forward a general bearer token through the chain.
5. Apply authorization before retrieving data or causing a side effect, then log the user, current actor, target, decision, and task ID without logging secrets.

OAuth 2.0 Token Exchange supports exchanging an incoming token for one suitable for a downstream service. It can represent the subject and current actor separately through the sub and act claims. Earlier actors form provenance, not an accumulating set of permissions. The OAuth security best current practice recommends restricting access tokens to the minimum privilege and intended audience; see RFC 9700, section 2.3.

Google Cloud Agent Identity assigns a distinct, attested identity to an agent. Grant the agent only the IAM roles required on each Google Cloud resource. When an agent accesses an external tool for a user, three-legged OAuth provides user-delegated authority. The Agent Identity auth manager 3LO flow stores the user’s tokens in a managed vault and, with ADK, injects a token into the tool request. The agent’s permission to retrieve that credential and the user’s delegated permission at the external service remain separate checks.

An Agent2Agent (A2A) message role, contextId, task ID, or metadata does not authenticate a user. The A2A authentication and authorization specification leaves identity handling to the protocol security layer and requires the server to authorize the authenticated caller. The receiving agent must not trust a prompt such as user_id=alice as proof of Alice’s identity.

Key distinctions and trade-offs

Propagation versus forwarding: Propagation preserves verified identity and delegation semantics. Forwarding reuses the same credential. Token exchange adds infrastructure, but it can narrow audience, scope, and lifetime and avoid exposing one reusable token to every agent.

Authorization versus attribution: A full chain of users and agents helps incident response and audit. It does not grant access. Authorization uses the verified current subject, current actor, requested operation, and resource policy. Do not union permissions from earlier actors.

Tool filtering versus data enforcement: A tool schema can require a customer_id, but the model can invent or alter that value. Derive tenant and user filters from verified context, and enforce them in the tool or data access layer before the query runs. Returning all rows and asking the model to hide unauthorized rows has already exposed the data. The A2A data-access rules likewise require authorization checks before queries that could reveal even the existence of inaccessible resources.

User authority versus agent authority: Use user delegation for access to a specific user’s resources. Use the agent’s own identity for approved autonomous or service-level work. If a backend cannot consume user context, place a trusted policy-enforcement service in front of it; do not replace the missing user check with a broad agent credential.

Architecture / decision scenario

An employee asks a travel agent to attach an itinerary from a travel SaaS system to an internal expense report. The travel agent delegates document processing to a records agent, which calls a storage tool.

The travel agent authenticates with its own Agent Identity and obtains the employee’s consented, trip-read OAuth token through auth manager. It sends the records agent a destination-specific credential or verifiable delegation context, not the reusable SaaS token. The records agent authenticates the travel agent, verifies the employee context, and checks that both agents may perform the attachment workflow.

The storage tool derives the employee and report scope from verified context. It checks that the employee may update the named report and that the records agent may write only to the expense-document location. It then stores the itinerary and logs both identities. If the employee can read the itinerary but cannot edit the report, the request is denied. The records agent’s write permission does not fill that gap.

Each hop checks verified identity context; the reusable SaaS token stays with the travel agent.

Common exam traps

• Using a shared service account for all agents and calling it identity propagation.
• Treating a user ID, A2A task ID, session value, or prompt field as authenticated identity.
• Combining user and agent permissions as a union instead of enforcing both boundaries.
• Passing one bearer token through every agent without narrowing its audience, scope, or lifetime.
• Authorizing only the first agent and assuming downstream agents and tools inherit that decision.
• Fetching broad data first and relying on the model to remove unauthorized results.
• Logging only the user or only the workload, which loses dual attribution.

What to remember

• Preserve the initiating user and current agent as separate identities.
• Re-authenticate and re-authorize at every trust boundary.
• Keep effective authority within every applicable policy and task constraint.
• Prefer short-lived, audience-specific credentials over bearer-token forwarding.
• Enforce data access before retrieval, using trusted identity context.
• Record both user and agent identities for accountable decisions.

Knowledge check

References

• Google Cloud, Agent Identity overview
• Google Cloud, Authenticate using 3-legged OAuth with auth manager
• A2A Protocol, Authentication and authorization
• A2A Protocol, Data access and authorization scoping
• RFC Editor, RFC 8693: OAuth 2.0 Token Exchange
• RFC Editor, RFC 9700: Best Current Practice for OAuth 2.0 Security