{"slug": "agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery", "title": "Agent Identity Tokens: What to Check in the JWT Claims, Issuer, and OIDC Discovery Document (Google Cloud, SPIFFE, JWKS)", "summary": "Services that accept OIDC ID tokens from Google Cloud AI agents must verify the issuer against a pre-configured value, fetch the issuer's /.well-known/openid-configuration document, check the JWKS signature by kid, pin an algorithm allowlist, confirm aud contains their own service identifier, validate exp/nbf/iat, and map sub to authorization rules, according to a technical guide citing Google Cloud's Agent Identity documentation. Google Cloud's Agent Identity, built on SPIFFE, gives each agent an ID of the form spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH with an auto-provisioned X.509 certificate valid for 24 hours, and a redeployed agent receives a new principal, so services that allowlist agents by subject must plan for rebinding. The guide notes a November 9 trade article reported Google's Agent Identity Auth Manager as generally available and Agent Identity JWT support as preview, while Google's own pages label Auth Manager as preview.", "body_md": "# Agent Identity Tokens: What to Check in the JWT Claims, Issuer, and OIDC Discovery Document (Google Cloud, SPIFFE, JWKS)\n\nAgents now present OIDC ID tokens to external services. What a receiving service should verify: issuer, JWKS signature, audience, expiry, and a stable subject.\n\nCloud 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.\n\nThat 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.\n\nA 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.\n\n## What Google's documentation says\n\nFrom Google's [Agent Identity overview](https://docs.cloud.google.com/iam/docs/agent-identity-overview):\n\n- 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.**\n- Each agent gets an auto-provisioned X.509 certificate valid for 24 hours and renewed automatically.\n- 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.\n- Traffic beyond Agent Gateway uses DPoP, so credentials are bound twice.\n\nGoogle's Agent Identity auth manager, the outbound credential broker, is described separately. This post is about the token you receive, not that broker.\n\n## An ID token is a JWT you must validate\n\nOpenID 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):\n\n| Check | What to do | What goes wrong if skipped | \n|---|---|---|\n| **Issuer source** | Use an issuer you configured. Never derive it from the token. | Anyone can mint a well-formed token naming their own issuer | \n| **Discovery document** | Fetch `/.well-known/openid-configuration` from that issuer; confirm its`issuer` equals the token's`iss` , character for character | Mix-ups between issuers | \n| **Signature** | Verify with the key in the issuer's `jwks_uri` , selected by`kid` | Forged tokens accepted | \n| **Algorithm** | Pin an allowlist; reject `none` and anything unexpected | Algorithm confusion | \n| **Audience** | `aud` must contain**your** service identifier | A token issued for another service is replayed to yours | \n| **Time** | Check `exp` , and`nbf` or`iat` if present, with a small clock skew | Expired or not-yet-valid tokens accepted | \n| **Subject** | Map `sub` to your authorization rules | Everything above passes, and you still don't know what this agent may do | \n\nMost 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.\n\n## What is specific to agents\n\n### The subject changes when the agent is redeployed\n\nGoogle 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.\n\n### Short lifetimes help, binding helps more\n\nA 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.\n\n### Cache the JWKS, but expect rotation\n\nFetch 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.\n\n## Reading the discovery document before you write the code\n\nYou 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?\n\nThe [OIDC Inspector](https://contextiq.trango-compute.com/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.\n\n## Identity is not data permission\n\nA 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.\n\n**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](https://contextiq.trango-compute.com/agent-data-policy).\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery", "canonical_source": "https://contextiq.trango-compute.com/blog/agent-identity-tokens-what-to-check-jwt-claims-issuer-discovery", "published_at": "2026-11-10 00:00:00+00:00", "updated_at": "2026-11-10 17:52:07.791661+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "artificial-intelligence"], "entities": ["Google Cloud", "SPIFFE", "OpenID Connect", "Agent Identity Auth Manager", "Agent Gateway", "DPoP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery", "markdown": "https://wpnews.pro/news/agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery.md", "text": "https://wpnews.pro/news/agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery.txt", "jsonld": "https://wpnews.pro/news/agent-identity-tokens-what-to-check-in-the-jwt-claims-issuer-and-oidc-discovery.jsonld"}}