AgentID vs Google Cloud Agent Identity: Sign-in identity for the open web vs workload identity for Google's runtime
Google's agent identity gives agents SPIFFE IDs and X.509 certificates inside the Gemini Enterprise Agent Platform. AgentID gives agents an OpenID Connect identity any app can accept. Different layers, different problems.
- AgentID
TL;DR
Google Cloud Agent Identity gives agents on Google's runtime a SPIFFE identity and an X.509 certificate for authenticating to infrastructure. AgentID is an OpenID Connect provider that lets an agent sign in at any app on the open web, with the owner's email behind it for registered clients.
Google Cloud Agent Identity gives agents deployed on Google's runtime a SPIFFE identity and an X.509 certificate for authenticating to infrastructure. AgentID is an OpenID Connect provider that lets an agent sign in at any application on the open web with a verified email identity and, for registered clients, the owner's email address. They operate at different layers: no consumer app's login page accepts an X.509 SVID, and no cloud IAM system grants infrastructure access on an id_token from a third-party provider.
What is Google Cloud Agent Identity?
Google's agent identity, documented under the Gemini Enterprise Agent Platform (Google's Vertex AI Agent Engine pages now redirect there), "provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard". When an agent is deployed to the platform's runtime, the system "assigns it a unique SPIFFE identity and an X.509 certificate".
The design goal is fixing the sins of service accounts. Google's documentation draws the contrast directly: "Unlike service accounts, agent identities are not shared by multiple workloads by default, can't be impersonated, and don't allow developers to generate long-lived service account keys". On top of the certificate, agents authenticate several ways depending on target: mTLS to Google Cloud APIs, three-legged OAuth for user-delegated access to external services, two-legged OAuth for the agent's own authority, API keys where needed, and DPoP through the Agent Gateway. Per Google's docs, "Access tokens generated for Google Cloud are cryptographically bound to the agent's unique X.509 certificates to prevent token theft".
The scope is Google's own surfaces: the platform runtime and Gemini Enterprise. The agent identity auth manager is in preview, under pre-GA terms. Source: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-identity-overview, read 2026-09-09.
What is AgentID?
AgentID is a "Sign in with AgentID" button, a standard OpenID Connect provider run by AgentMail, the same integration shape as "Sign in with Google" but for agents. Every sign-in returns an ES256-signed id_token with a stable subject and the agent's inbox address, verified live at token mint. The agent's signing credential never leaves the agent, each sign-in is a fresh one-time signature, and the app never receives anything reusable.
Any app can accept sign-ins without registering. Registered clients (an application created in the AgentID console or with the CLI) also get the owner_profile and owner_email scopes; owner details arrive in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim.
Different layers, occasionally confused
SPIFFE certificates and OIDC tokens solve different problems, and the confusion between them is mostly the word "identity" doing double duty.
| AgentID | Google Cloud Agent Identity | |
|---|---|---|
| Question it answers | Which agent is signing in to this application, and which human answers for it | Which workload is calling this API, and can we prove it without long-lived keys |
| What the agent presents | An ES256-signed OIDC id_token, verified against published keys | A SPIFFE identity and an X.509 certificate |
| Where it is accepted | Any application's login page that speaks OpenID Connect | Google Cloud infrastructure; no consumer app's login page accepts an X.509 SVID |
| What it will not do | No cloud IAM system grants infrastructure access on an id_token from a third-party provider | Gives an agent no identity an unrelated application can verify at sign-in |
The two meet only in the sense that a serious agent deployment eventually needs both layers.
Side-by-side
| AgentID | Google Cloud Agent Identity | |
|---|---|---|
| For | Any app accepting agent sign-ins; agent developers anywhere | Teams deploying agents on Google's agent runtime / Gemini Enterprise |
| Cross-app support | Yes, any OIDC-capable app on the web | Google Cloud surfaces; external services via OAuth flows the developer configures |
| Owner email support | Yes, owner_email for registered clients | No owner-identity claim presented to receiving apps; delegation via 3-legged OAuth carries the user's own identity |
| Standards support | Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591 | SPIFFE, X.509, mTLS, OAuth 2.0, DPoP |
| Pricing | Free for apps | Part of Google Cloud platform usage; identity feature in preview |
| Time to integrate | Minutes on an existing OIDC stack | Requires deploying agents on Google's runtime |
| Who owns the identity root | AgentMail inbox controlled by the agent's owner | Google Cloud trust domain of the operating project |
When to choose Google Cloud Agent Identity
Choose it when your agents run on Google's platform and the thing you need to secure is their access to infrastructure. Per-agent certificates that cannot be impersonated, no long-lived keys to leak, tokens bound to hardware-backed identity: this is materially better security than shared service accounts, and if you are on the Gemini Enterprise Agent Platform you should use it. It also cleanly handles the delegation case where an agent needs a user's permission to call an external API on their behalf.
Be aware of its boundaries. It is in preview, it presumes Google's runtime, and it gives an agent no identity that an unrelated application on the web can verify at sign-in.
When to choose AgentID
Choose AgentID when the counterparty is an application, not an API you control. An agent signing up for SaaS tools, a consumer product deciding its agent policy, a platform enforcing per-human account limits: these interactions happen at login pages, in OIDC, between parties with no shared cloud. AgentID works regardless of where the agent runs, Google Cloud included. An agent deployed on Google's runtime with a SPIFFE identity for its infrastructure can hold an AgentID for the open web, and the two never conflict.
The owner layer is the other differentiator. Google's system attests to which workload is calling. AgentID's registered tier attests to which human stands behind the agent, which is the fact a receiving app needs for rate limiting, abuse control, and KYC.
Get started
Accept agent sign-ins by adding AgentID as a custom OIDC provider: issuer https://auth.agentid.com plus your client_id. Owner scopes need an AgentID application, created in the console or with the CLI. Guides at www.agentid.com/docs.
