[ Security ]

Identity you can verify, not vouch for.

Everything about how Agent ID mints, signs, and scopes identities: the signing keys, the token lifecycle, and the exact boundaries of what a verified token claims.

OpenID Connect Core 1.0Authorization Code + PKCE (RFC 7636)Scoped P-256 signing keysES256 via AWS KMSRotating JWKSSingle-use codes

[ How it's built ]

The mechanics under every token

Six properties that hold for every identity Agent ID mints.

Sign-in by signature, not secrets

The agent approves each sign-in with a scoped P-256 keypair. The private key never leaves its keystore, and no API key or password ever crosses the login flow, so there is no reusable credential to steal.

One signature, one sign-in

Each approval signs a single server-generated transaction that is consumed exactly once, and authorization codes expire in seconds. Replay is rejected, not just discouraged.

Tenant-scoped at mint time

Signing credentials are scoped to an organization, pod, or single inbox, and every sign-in is re-verified against that scope. A credential can’t mint an identity for an inbox it doesn’t own.

Issuer keys never leave KMS

Tokens are signed with ES256 via AWS KMS. The private signing key is non-exportable, so even a compromised process can’t exfiltrate it.

Published JWKS, standard rotation

Public keys are served at /.well-known/jwks.json with stable kids and an overlap window, so rotation never breaks in-flight tokens.

Live re-verification

Token exchange re-checks the signing credential, inbox, and organization against live state, and GET /userinfo re-derives claims on every call. Revocation takes effect immediately, not at expiry.

[ Anatomy of an id_token ]

Verify every claim in the token

Standard OIDC claims, signed with ES256. Validate against the published JWKS with the JOSE library you already use.

id_token (decoded)

{
  "iss": "https://auth.agentid.com",
  "sub": "a91f2c8e...43",
  "email": "support@acme.agentmail.to",
  "owner_email": "maya@acme.com",
  "email_verified": true,
  "aud": "https://mytool.dev",
  "exp": 1719800000,
  "iat": 1719799400,
  "jti": "txn_8c1f..."
}

# header: { "alg": "ES256", "kid": "..." }

sub

A stable public subject derived from the inbox. The same agent gets the same sub every time it signs in.

email

The inbox the agent signed in as, verified live at mint time. You can contact the agent directly, not just log an ID.

owner_email

The email of the human who owns the agent. Visible to you at sign-in and passed as metadata in the signup, so accountability lands in your own records.

email_verified

Emitted only when the inbox is live and inside the signing credential’s scope at the moment the token is minted.

iss / aud / exp / jti

Standard OIDC claims. aud is your exact client_id and jti names the single sign-in transaction. Verify against the published JWKS.

GET /userinfo re-derives these claims from the live inbox on every call, not just a decode of the token you already have.

[ Trust boundaries ]

What a verified token does and doesn't mean

Treat an Agent ID like a verified account: stable attribution and revocation, not a judgment of behavior.

A verified token tells you

Which agent is calling: a stable, signed identity
A real address where you can reach the agent
The owner's email: the human accountable for the agent, passed into your signup metadata
That a credential scoped to that inbox approved this exact sign-in
Enough to attribute, rate-limit, allowlist, and revoke

It deliberately does not claim

That the agent is safe or well-behaved
What the agent will do with the access you grant
A trust score or endorsement of any kind

[ Security FAQ ]

Common questions

Don’t take our word for it.

The discovery document, JWKS, and every endpoint are public. Point your own tooling at them and verify.

View discovery document Read the docs