Agents now present OIDC ID tokens to external services. What a receiving service should verify: issuer, JWKS signature, audience, expiry, and a stable subject.
Cloud providers are giving AI agents their own identities. Google Cloud's documentation describes Agent Identity as a principal type distinct from human users and generic service accounts, built on SPIFFE. When an agent calls an external service, it can request an OIDC ID token representing its own identity.
That token lands on your side of the wire. If you operate a service an agent calls, the question is not how Google issues it. The question is what you must check before you believe it.
A note on status: a trade article on November 9 reported Google's Agent Identity Auth Manager as generally available and Agent Identity JWT support as preview. Google's own pages I read label Auth Manager as preview. Check the launch stage in Google's documentation before depending on either.
What Google's documentation says #
From Google's Agent Identity overview:
- An agent's ID has the form
spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH, and the identity derives from the hosting resource's ID.A redeployed agent gets a new principal. - Each agent gets an auto-provisioned X.509 certificate valid for 24 hours and renewed automatically.
- For Google Cloud access, the agent requests an access token bound to its certificate. For external services, it requests an OIDC ID token representing its identity.
- Traffic beyond Agent Gateway uses DPoP, so credentials are bound twice.
Google's Agent Identity auth manager, the outbound credential broker, is described separately. This post is about the token you receive, not that broker.
An ID token is a JWT you must validate #
OpenID Connect ID tokens are JSON Web Tokens. Receiving one proves nothing until you validate it. This checklist follows OpenID Connect Core and the JWT best-current-practice guidance (RFC 8725):
| Check | What to do | What goes wrong if skipped |
|---|---|---|
| Issuer source | Use an issuer you configured. Never derive it from the token. | Anyone can mint a well-formed token naming their own issuer |
| Discovery document | Fetch /.well-known/openid-configuration from that issuer; confirm itsissuer equals the token'siss , character for character |
Mix-ups between issuers |
| Signature | Verify with the key in the issuer's jwks_uri , selected bykid |
Forged tokens accepted |
| Algorithm | Pin an allowlist; reject none and anything unexpected |
Algorithm confusion |
| Audience | aud must containyour service identifier |
A token issued for another service is replayed to yours |
| Time | Check exp , andnbf oriat if present, with a small clock skew |
Expired or not-yet-valid tokens accepted |
| Subject | Map sub to your authorization rules |
Everything above passes, and you still don't know what this agent may do |
Most real failures are in the first two rows. Services configure a JWKS URL and then accept any token it can verify, which says nothing about whether the issuer is the one you meant.
What is specific to agents #
The subject changes when the agent is redeployed
Google documents that a redeployed agent gets a new principal. If you allowlist agents by subject, plan for rebinding: a deploy can silently stop matching your rules, or an old grant can linger on an identity that no longer exists. Treat subject-to-permission mappings as something you can inventory and expire.
Short lifetimes help, binding helps more
A bearer ID token can be replayed if it is stolen, which is why short lifetimes and a tight aud matter. Google describes binding credentials beyond its gateway with DPoP. If your own service accepts tokens directly, ask what binding you can require, not just what expiry.
Cache the JWKS, but expect rotation
Fetch signing keys from jwks_uri, cache them, and refresh when you see an unknown kid. A fixed copy of the key set breaks the day the issuer rotates.
Reading the discovery document before you write the code #
You can learn a lot about an issuer without a token. The discovery document lists the signing algorithms the issuer supports, its endpoints, its jwks_uri, supported scopes and grant types. The JWKS lists each public key's type, algorithm, key ID and use. Comparing the two is a fast sanity check: do the algorithms in the document match the keys actually published, and does the key set contain a key for the algorithm you plan to accept?
The OIDC Inspector does this for a domain. It fetches the OpenID Connect and OAuth 2.0 discovery documents, shows the endpoints, scopes, grant types and PKCE support, and inspects the JWKS (key type, algorithm, key ID, usage). It reads public configuration only. Do not paste tokens into any online tool.
Identity is not data permission #
A valid token tells you which agent is calling. It does not tell you what data that agent may receive for this user, in this runtime, for this task. A verified agent identity is the beginning of an access decision, not the end of one.
ContextIQ Agent Data Policy is an Enterprise Preview built around that second step: resolving the object's classification and the user's entitlement, applying your agent rule, and returning a decision with evidence. It is not generally available. If you are working through agent identity and want to see the data side, request an Enterprise Preview demo.
Follow Trango Compute on LinkedIn
We post updates on new tools, context engineering patterns, and LLM cost research.