Google\
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.
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 (one RFC 7591 call with an AgentMail API key) additionally get the profile, owner_profile, and owner_email scopes plus an org claim; owner details are served from the userinfo endpoint, and sign-ins fail with a 403 when the agent has not granted owner visibility.
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. Google's system answers: which workload is calling this API, and can we prove it without long-lived keys? AgentID answers: which agent is signing in to this application, and which human answers for it? No consumer app's login page accepts an X.509 SVID, and no cloud IAM system grants infrastructure access on an OIDC id_token from a third-party provider. 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 via userinfo | 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. Registration for owner scopes is one API call. Guides at auth.agentid.com/docs.
