Wiki · Concept · Last reviewed June 25, 2026

JSON Web Tokens

JSON Web Tokens are compact claim containers that can be signed, integrity protected, or encrypted; in agent systems they often carry identity, delegation, audience, and authorization evidence.

Category: Concept Updated: June 25, 2026 Tags: AI agents, JWT, JOSE, OAuth, identity, authorization

Definition

JSON Web Token, usually abbreviated JWT, is the IETF token format defined by RFC 7519: a compact, URL-safe way to represent claims transferred between two parties. Those claims are encoded as JSON and carried either as the payload of a JSON Web Signature structure or as the plaintext of a JSON Web Encryption structure.

A JWT is not a magic login ticket. It is a format for claims. Whether it proves anything depends on the issuer, signature or encryption method, key discovery, audience, expiration, token profile, validation rules, and the resource server policy that decides what to do with it.

For AI agents, JWTs matter because delegated tool calls often move through identity and authorization systems that speak JOSE and OAuth. A token may say which user, client, agent, authorization server, audience, scope, or actor is involved. The system still must validate and enforce those claims.

How It Works

A typical JWT has a header, payload, and signature or encryption data, serialized in compact form. The payload contains claims. RFC 7519 registers common claim names such as iss for issuer, sub for subject, aud for audience, exp for expiration, nbf for not-before time, iat for issued-at time, and jti for token identifier.

JSON Web Signature, RFC 7515, protects integrity and can authenticate the signer. JSON Web Encryption, RFC 7516, protects confidentiality. JSON Web Key, RFC 7517, represents cryptographic keys used by these systems. Together these sit inside the JOSE family of specifications.

Many deployments use JWTs inside larger profiles. RFC 9068 defines a JWT profile for OAuth 2.0 access tokens. RFC 7523 defines JWT bearer assertions for OAuth client authentication and authorization grants. JAR, JARM, SD-JWT VC, and Entity Attestation Token all use JWT-related machinery for more specific jobs.

Agent Context

Agent workflows create long chains: a human authorizes a task, a model selects a tool, a runtime calls a connector, and a resource server decides whether to honor the request. JWTs can preserve evidence across that chain if the claims are narrow, validated, and logged.

The useful questions are concrete. Who issued this token? Which client or agent is it for? Which subject or actor does it represent? Which resource server is the audience? Which scope, authorization detail, assurance level, or confirmation key is present? When does it expire? Was it revoked or superseded?

The dangerous pattern is possession-only authorization. A tool server sees a token-shaped string and accepts it without checking issuer, audience, time, signature, key, token type, or policy. In an agent setting, a copied token from logs, traces, browser storage, or a compromised connector can become live authority.

Governance and Safety

RFC 8725 is the JWT Best Current Practices document. It updates RFC 7519 with implementation and deployment guidance, including algorithm verification, key selection, explicit typing, claim validation, and avoiding confusion between different kinds of JWTs. The OAuth working group also has an active rfc8725bis draft as of June 2026.

Governance should treat a JWT as evidence that must be appraised, not as a conclusion. A signed token from the wrong issuer, a token with the wrong audience, an expired token, a token with missing subject context, or a token intended for one profile but accepted in another can all be well-formed and still unsafe.

Audit records should preserve token metadata, not full bearer tokens: issuer, subject where appropriate, audience, client or agent identifier, key identifier, algorithm, token type, expiration, scope or authorization detail, confirmation claim if used, validation result, and downstream action.

Defense Pattern

Source Discipline

Claims about JWTs should name the profile and use case: ID token, OAuth access token, JWT bearer grant, request object, response object, SD-JWT VC, EAT, status-list token, or custom token. The same compact syntax can carry different trust semantics. Do not collapse JWT into OAuth, OpenID Connect, bearer tokens, API keys, or legal consent.

Spiralist Reading

Spiralism reads a JWT as a small envelope of institutional speech. It says: this issuer asserts these claims for this audience until this time.

The signature is not a blessing. It is a receipt with a key attached. The moral and operational question is still whether the receiving system should believe it, limit it, log it, or refuse it.

Open Questions

Sources

Return to Wiki