To enforce trust boundaries across human users, autonomous workloads, and external tools without relying on service account impersonation, Agent Identity uses a three-identity delegation framework. This framework separates and coordinates three distinct identity contexts across your environment:
- User identity: The initiating end user's identity, authenticated through standard OAuth 2.0 or OpenID Connect (OIDC) with Google Identity or a federated workforce identity provider (IdP).
- Agent identity: The deployed agent's unique, cryptographically attested SPIFFE identity and auto-provisioned X.509 certificate, representing the agent acting on its own authority.
- Delegated identity: The combined authority context when the agent acts on behalf of the initiating human user using scoped 3-legged OAuth (3LO) credentials brokered by Agent Identity auth manager.
The following diagram illustrates how the user identity, agent identity, and delegated identity interact across ingress, runtime, and egress trust boundaries:
In this architecture, the user identity establishes caller context during ingress, the agent identity authenticates the workload within the runtime boundary, and the delegated identity combines both authorities when the agent accesses downstream services on behalf of the user.
How identities propagate across trust boundaries
As a request moves across these trust boundaries, the platform evaluates and propagates each identity layer:
- Client-to-Agent ingress boundary (user identity): The human user
authenticates to the client application using an OAuth 2.0 or OIDC token.
When traffic enters through Agent Gateway (in
CLIENT_TO_AGENTingress mode), the authorization policies attached to Agent Gateway verify the user identity to confirm that the user is authorized to invoke the target agent and forward the verified user context to the runtime. - Agent runtime and credential brokering (agent identity): Inside the isolated runtime environment, the agent operates under its own SPIFFE agent identity with an auto-rotated 24-hour X.509 certificate. When the agent needs credentials for downstream tools, it authenticates to Agent Identity auth manager using its agent identity.
- Autonomous egress path (agent identity): When the agent calls Google Cloud APIs or machine-to-machine endpoints on its own authority, it authenticates using certificate-bound tokens enforced by mutual TLS (mTLS) and Demonstrating Proof of Possession (DPoP), OIDC ID tokens, or 2-legged OAuth (2LO) credentials from the auth manager. IAM allow and deny policies, Principal Access Boundary (PAB) policies, and Context-Aware Access policies evaluate the request strictly against the agent identity.
- User-delegated egress path (delegated identity): When the agent calls user-scoped Model Context Protocol (MCP) servers or third-party APIs on behalf of the human user, the auth manager brokers a consented 3LO user token representing the delegated identity. Outbound calls are governed by both the agent's egress policies and the delegating user's permissions and consented OAuth scopes, and audit logs record both the agent identity and the user identity.
Identity layer comparison
The following table summarizes how the three identity layers govern access and auditability:
| Identity layer | Principal and credential type | Trust boundary and policy enforcement | Audit log attribution |
|---|---|---|---|
| User identity | Initiating end user (Google Account or workforce identity principal) authenticated with an OAuth 2.0 or OIDC token. | Client-to-Agent (ingress): Agent Gateway authorization policies verify whether the user can invoke the agent and initiate a session. | Logs the human user identity as the caller invoking the agent endpoint. |
| Agent identity | Autonomous agent workload (agent identity principal) authenticated with a SPIFFE X.509 certificate (mTLS and DPoP), OIDC ID token, or 2LO credential or API key from the auth manager. | Agent-to-Anywhere (egress): IAM allow, deny, Principal Access Boundary, and Context-Aware Access policies enforce which Google Cloud resources, auth providers, and external endpoints the agent can reach on its own authority. | Logs the agent's unique SPIFFE principal as the acting identity. |
| Delegated identity | Agent identity acting on behalf of the consenting human user (Google Account or workforce identity principal) using a scoped 3LO access token brokered by Agent Identity auth manager. | Agent-to-Anywhere (egress): Enforces least-privilege intersection—the call must satisfy both the agent's outbound governance policies and the delegating user's permissions and consented OAuth scopes. | Records dual attribution, capturing both the agent's SPIFFE identity and the delegating human user. |
What's next
Learn more about the Agent Identity overview.
Learn more about using agent identity with Agent Runtime.
Learn more about Agent Gateway.