google agent identity: SPIFFE IDs and OIDC Tokens for AI Agents, Explained

The google agent identity stack crossed an important line at the Google Cloud Security Summit on November 4: Agent Identity JWT support entered preview, letting agents authenticate to AWS, Azure, on-premises backends, and MCP servers with standard OIDC tokens instead of static, long-lived API keys, and Auth Manager, the credential vault that brokers user-delegated access, reached general availability. Together they turn "who is this agent" from a design question into a platform primitive. Source

What Agent Identity is

Agent Identity gives each agent a strongly attested, cryptographic identity based on the SPIFFE standard. With it, an agent can authenticate to MCP servers, cloud resources, endpoints, and other agents, acting either on its own authority or on behalf of an end user. The design breaks several habits of the service account era: agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow developers to generate long-lived service account keys. Access tokens are cryptographically bound to the agent's unique X.509 certificate to make token theft harder. Source

Each agent gets a unique SPIFFE ID tied to its lifecycle and mapped to the resource URI where it is hosted, in the format spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH. When that identity appears in an IAM allow policy, it uses the parallel principal:// form. Three Google services currently support Agent Identity: Gemini Enterprise Agent Platform Runtime, Gemini Enterprise, and Cloud Run. The identity layer also slots into a wider control plane: Agent Registry catalogs the tools and destinations in your environment, and Agent Gateway enforces access policies and inspects traffic when agents call them. Source

The three-identity delegation model

The architectural idea worth understanding is delegation without impersonation. Agent Identity separates three identity contexts: the user identity, the initiating human authenticated through standard OAuth 2.0 or OIDC; the agent identity, the deployed agent's own attested SPIFFE identity and auto-provisioned X.509 certificate; and the delegated identity, the combined authority context when the agent acts for that user through scoped 3-legged OAuth credentials brokered by Auth Manager. The point is to enforce trust boundaries across humans, workloads, and external tools without service account impersonation. Source

On top of those identities sit several authentication models, chosen per target resource: 3-legged OAuth for user-delegated access to external tools, cloud-based identity for Google Cloud APIs, OIDC ID tokens for external backends and third-party clouds, 2-legged OAuth for machine-to-machine calls, API keys where a service insists on one, and HTTP basic auth, which Google's own documentation flags as not recommended. Auth Manager is where you configure and store these as auth providers. Source

What the November 4 update actually added

Two things, and they pair up. First, Auth Manager is now generally available: it centralizes credential management inside a Google-managed vault governed by IAM, automates OAuth 2.0 and PKCE flows, and refreshes user-delegated tokens to reduce consent fatigue and credential theft. Second, Agent Identity JWT support is in preview: agents can present standard OIDC tokens to external systems, covering AWS, Azure, on-premises backends, and MCP servers, which removes the need to hand agents static, long-lived API keys. Source

The mechanics, per the preview documentation: when an agent acts on its own authority, Agent Identity issues an OIDC ID token, a JWT that asserts the agent's SPIFFE identity and is signed by the issuer keys of the agent's trust domain, which is a managed workload identity pool. External systems verify these tokens without Google Cloud credentials or SDKs, using two public, unauthenticated endpoints hosted by the Google Cloud Security Token Service: an OpenID Connect Discovery endpoint that publishes provider metadata and a JWKS endpoint that serves the active public signing keys. Source

Anatomy of the token

Johannes Passing's technical walkthrough shows what an agent actually receives. When an agent on Agent Platform is assigned an agent identity instead of a service account, the metadata server stops returning a Google-issued ID token and returns a JWT-SVID instead. The decoded token carries an issuer of the form sts.googleapis.com under the organization's agent identity pool, a subject that is the agent's spiffe:// URI naming the exact Agent Runtime deployment, an audience list, standard issued-at and expiry claims, and a cnf claim holding the x5t#S256 fingerprint of the agent's certificate. Source

Two properties follow. A JWT-SVID is not issued by accounts.google.com and is not signed by the Google JWKS; it is issued by the agent identity pool and signed with a JWKS unique to that pool. And a Google Cloud organization has exactly one agent identity pool, created automatically on first use, which supplies identities to every project in the organization. Until recently the pool's JWKS could not be looked up, so JWT-SVIDs could not be verified at all; the addition of standard OIDC metadata discovery is what makes cross-cloud use possible now. Source

Using it across clouds

Passing's Azure example is the cleanest proof that this works outside Google's walls. In Entra, you create an App registration and add a federated credential with "Other issuer" pointing at the agent identity pool's issuer URL, an explicit subject identifier set to the agent's spiffe:// resource path, and a unique audience. The agent then authenticates with the Azure SDK's ClientAssertionCredential, fetching its JWT-SVID from the metadata server and exchanging it for an Azure token. His closing line is the whole thesis: no client secret and no auth manager needed. Source

Google's documentation adds the requirements on the receiving side. The external service must validate JWTs using OpenID Connect Discovery 1.0 and JWKS, must be able to reach sts.googleapis.com over HTTPS for metadata and keys, and, if it enforces certificate binding over mutual TLS, must support client certificate authentication under TLS 1.3 and validate the cnf claim per RFC 8705. By default, Google Auth client libraries bind the ID token to the agent's certificate fingerprint; Cloud Run enforces that binding on its mTLS endpoint, and there are explicit opt-outs per request or per environment when you need a plain HTTPS path. Deployment is one flag: identity_type set to AGENT_IDENTITY on Agent Runtime, or --identity-type=agent-identity on Cloud Run. Source

Our read

This section is our assessment, not Google's claims. The shift that matters is from secrets to attestation. A static API key proves possession; a short-lived, certificate-bound, SPIFFE-named token proves which workload is calling, and that is the property every agent authorization policy actually wants. It lines up with the discipline we argued for in least-privilege for AI agents: identity first, then scope, then audit. It also narrows the blast radius we described in AI agent tool permissions, because a per-agent identity lets you revoke one compromised agent without rotating a shared key used by fifty.

The caveats are real. The external-facing piece is in preview under pre-GA terms, so treat the API surface as movable. One pool per organization means your trust domain boundary is the org, which makes pool governance and issuer allow-listing a design decision, not a default. And MCP server support cuts both ways: giving agents verifiable identity fixes the anonymous-caller problem we flagged in MCP OAuth security, but every MCP server that accepts these tokens now shares the pool's verification surface.

Practical bottom line: if you run agents on Google Cloud, enable Agent Identity for new deployments now and trial the JWT federation against one non-critical external target. If you run agents elsewhere, watch the pattern, because workload-issued OIDC identity is where the whole market is heading.