---
title: Agentic JWT (A-JWT) Protocol
url: https://www.emergentmind.com/topics/agentic-jwt-a-jwt
type: topic
---

# Agentic JWT (A-JWT) Protocol

Agentic JWT (A-JWT) is a proposed JWT/OAuth 2.0 extension protocol for autonomous AI agents in which each agent action is bound to cryptographically verifiable user intent and, optionally, to a specific workflow step. In its canonical formulation, A-JWT also carries an agent identity represented as a one-way checksum hash derived from the agent’s prompt, tools, and configuration, a chained delegation assertion describing which downstream agent may execute a task, and per-agent proof-of-possession keys intended to prevent replay and in-process impersonation [2509.13597]. Within the broader literature on AI-agent identity management, A-JWT is typically situated as an agent-aware authorization profile within the OAuth/OpenID ecosystem rather than a replacement for it, with distinct human and agent identities, delegated authority rather than impersonation, and auditable cross-domain execution as its central design commitments [2510.25819].

## 1. Emergence and conceptual scope

The intellectual lineage of A-JWT precedes the term itself. Earlier work on authenticated delegation for AI agents proposed a three-artifact model consisting of a user’s ID-token, an Agent-ID token, and a Delegation Token, with the latter explicitly authorizing an AI agent to act on a human user’s behalf under stated limits. That framework extends OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, while also proposing a process for translating flexible, natural language permissions into auditable access control configurations [2501.09674]. In that earlier model, the core questions are whether the acting entity is an AI agent, which human it acts for, and what it has been authorized to do.

A-JWT makes that agenda explicit in JWT form. The paper that introduces the term argues that OAuth 2.0 assumes deterministic clients, whereas autonomous LLM agents are stochastic planners that can expand privileges through prompt injection, multi-agent orchestration, or execution drift. Its response is not to abandon JWTs, but to reinterpret them as intent-carrying delegation artifacts rather than generic bearer credentials [2509.13597]. The OpenID Foundation whitepaper on identity management for agentic AI reaches a closely related conclusion from a different direction: agents need distinct identity artifacts, should be treated as first-class identities separate from users, and should act through delegated authority rather than impersonation [2510.25819].

This convergence defines the conceptual scope of A-JWT. It is not merely “JWTs used by agents.” It is a proposal for making agent execution legible to relying parties by preserving the distinction between human principal, acting agent, workflow context, and delegated authority. A common misconception is that such a token is just a richer access token. The literature instead presents it as an authorization artifact whose meaning depends on verifiable identity, constrained delegation, and auditability.

## 2. Token anatomy and agent identity

The paper defining A-JWT describes a “dual-faceted token design” that binds each action to user intent and, optionally, to a workflow step. Its example payload retains standard JWT claims such as `iss`, `sub`, `aud`, `exp`, `iat`, `jti`, and `scope`, but adds two agent-specific structures: an `intent` claim and an `agent_proof` claim. The `intent` object carries `workflow_id`, `workflow_step`, `executed_by`, `initiated_by`, `delegation_chain`, `step_sequence_hash`, and `execution_context`. The `agent_proof` object carries `agent_checksum`, `registration_id`, and `version` [2509.13597].

The distinguishing identity mechanism is the checksum-based agent identifier. The literature abstracts it as
$$
\text{agent\_checksum} = H(\text{Prompt} \parallel \text{Tools} \parallel \text{Configuration}),
$$
with the paper using `sha256:` examples for the resulting value [2509.13597]. This design attempts to make the agent’s operative identity more specific than an OAuth `client_id`, especially in settings where multiple agents may coexist within one client process. The associated shim computes this checksum at runtime and compares it with the registered identity before requesting or using a token.

Related identity-management work argues that this is necessary but probably not sufficient. The OpenID Foundation whitepaper states that `client_id` is not a robust stand-alone workload identity and is still insufficient as an AI agent identifier. It also suggests enriched metadata such as `agent_model`, `agent_provider`, and `agent_version`, and emphasizes on-behalf-of token patterns that preserve both the human principal and the agent actor through claims such as `sub`, `act`, and `azp` [2510.25819]. This suggests that a mature A-JWT profile may evolve from a checksum-centered design toward a richer subject model combining agent metadata, actor semantics, and issuer-governed lifecycle information.

The proof-of-possession layer is equally important. A-JWT associates each agent with a per-agent key pair, stores the public key with the identity provider, and binds the corresponding JWK thumbprint to the token through `cnf`/`jkt`-style confirmation. The aim is to ensure that stolen tokens are insufficient without possession of the corresponding private key [2509.13597].

## 3. Delegation, workflows, and provenance

Delegation in A-JWT is expressed through the `executed_by`, `initiated_by`, and `delegation_chain` fields, and it is constrained by registered workflows. The identity provider verifies the requesting agent’s registration, validates the runtime checksum, checks that the claimed workflow step is authorized, and verifies delegation-chain integrity before issuing the token [2509.13597]. Workflow-step binding is therefore not ancillary metadata; it is part of the authorization decision itself.

The workflow model is step-sensitive and stateful. A-JWT tracks `workflow_id`, `workflow_step`, `step_sequence_hash`, and `execution_context`, and the paper explicitly describes Directed Acyclic Graph based workflow tracking and registration. This architecture is meant to prevent step bypass, unauthorized role switching, or API use outside the intended phase of a delegated task [2509.13597]. In effect, the token carries a compact authorization state machine snapshot.

Adjacent work on provenance sharpens this design space. Human Delegation Provenance (HDP) is a lightweight token-based scheme that cryptographically captures and verifies human authorization context in multi-agent systems through a signed human authorization root, an append-only `chain`, `session_id` binding, and optional `max_hops`, all verifiable offline from the issuer’s Ed25519 public key and current session identifier [2604.04522]. HDP is not a JWT profile, but it clarifies a major design pressure for A-JWT: delegation in agentic systems is not only about who may act next, but also about preserving a verifiable history of how authority propagated.

A second pressure comes from task-scoped authorization. PAuth argues that authorization should attach to the concrete operations implied by a user’s natural-language task rather than to broad operator scopes, using NL slices and envelopes to bind concrete operand values to symbolic provenance [2603.17170]. This suggests that future A-JWT profiles may need payloads more precise than operator-scoped OAuth scopes, especially where downstream permissions depend on upstream values or where one task should authorize only one concrete action pattern.

## 4. Enforcement architecture and security properties

A-JWT’s enforcement model is split across the client shim, the identity provider, and the resource server. The shim self-verifies code at runtime, computes the agent checksum, tracks workflow steps, derives per-agent keys, requests intent tokens, and signs outbound requests. The identity provider validates registration, runtime identity, workflow authorization, and delegation-chain integrity. The resource server verifies JWT signature, PoP binding, and agentic claims before allowing the call [2509.13597]. The threat model is STRIDE-based and includes agent identity spoofing, token replay, shim impersonation, runtime code modification, prompt injection, workflow definition tampering, cross-agent privilege escalation, workflow step bypass, scope inflation, intent origin forgery, delegation-chain manipulation, and agent configuration exposure [2509.13597].

The prototype results are functional rather than fully benchmarked, but they are specific: the paper reports blocking of scope-violating requests, replay, impersonation, and prompt-injection pathways, with sub-millisecond overhead on commodity hardware [2509.13597]. The security claim is therefore not that prompt injection disappears, but that injected reasoning should fail to produce unauthorized API effects once intent, workflow, and PoP checks are enforced at the authorization boundary.

Broader protocol analyses reinforce this boundary-based view. Comparative work on A2A, CORAL, and ACP concludes that standard security frameworks such as OAuth 2.0 and TLS do not provide sufficient granularity or contextual awareness for agent interactions, and that optional JWS enforcement leads to high-impact integrity and confidentiality flaws. It recommends combining integrated session architecture with mandatory per-message integrity guarantees [2511.03841]. This indicates that A-JWT alone is not sufficient if it is only an admission token; message-level integrity and session/channel binding remain necessary in multi-agent protocols.

Empirical evidence from mobile LLM applications provides a further caution. In a study of 444 iOS applications, 282 exposed exploitable LLM API credentials in traffic, and the most prevalent pattern was JWT-based token leakage: 136 of 282 vulnerable apps, or 48%. Persistent failures included static bearer tokens with no expiry mechanism, JWTs without an `exp` claim, servers accepting expired JWTs, JWT lifetimes from 100 to 365 days, and one token valid for 100 years [2606.12212]. These results suggest that replayable bearer-style agent tokens are brittle unless server-side validation, lifetime enforcement, and proof-of-possession are strict.

## 5. Relation to OAuth, Verifiable Credentials, and portable authorization

A-JWT sits inside a larger family of efforts to make JWT-like artifacts carry portable authority rather than only bearer access. One important precursor is capability-based access control for multi-tenant systems using OAuth 2.0 and Verifiable Credentials. That work defines a new form of OAuth 2.0 access token in which a VC is embedded in a JWT, signed as JWS, bound to the client through `cnf.jwk`, and used together with DPoP for holder-bound, offline-verifiable authorization [2104.11515]. Its capability encoding is resource/action oriented and multi-tenant, which makes it a reusable substrate for A-JWT-style authority tokens, even though it does not solve agent-native delegated chains.

A more direct conceptual framework comes from portable authorization research for autonomous agents. That literature separates the credential container, the authorization payload, and the enforcement engine, and requires that every authorization credential carry four components: agent identity, issuer identity, declared permissions, and policy constraints. It further defines a typed constraint algebra with `NumericLimitConstraint`, `TemporalWindowConstraint`, `EnumeratedListConstraint`, and `StringPatternConstraint`, and requires conjunctive, total, fail-closed evaluation semantics [2605.11487]. In that model, JWT/JWS is only the container; the real standard lies in the authorization payload and its evaluation rules.

This separation is especially important for understanding A-JWT. A common misconception is that the hard problem is choosing the right claims. The literature suggests instead that the hard problem is ensuring that independent receivers interpret those claims consistently. A-JWT therefore belongs to a broader move from “scope strings in bearer tokens” toward signed, machine-evaluable authorization payloads that remain meaningful across trust boundaries [2605.11487].

## 6. Open problems and research trajectory

A-JWT remains a proposal rather than a completed standard, and the literature is explicit about unresolved gaps. The OpenID Foundation whitepaper identifies several of them directly: standardized actor-chain representation, multi-user and shared-agent authorization, cross-domain portable trust semantics, formal agent claim sets, standardized provenance and behavior metadata, and integration of workload attestation with delegated user authority [2510.25819]. The A-JWT paper itself adds operational concerns: prompt templates often contain runtime placeholders, legitimate prompt substitution is difficult to distinguish from malicious injection, re-registration is required when prompt, tools, or configuration change, and workflow governance introduces nontrivial operational burden [2509.13597].

Provenance-focused alternatives show both what is possible and what remains difficult. HDP achieves offline verification, append-only delegation history, `session_id` binding, and `max_hops`, but it also leaves active revocation unresolved beyond expiry and session binding, grows linearly with hop count, and in version 0.1 signs all hops with the issuer key rather than the actual agent runtime [2604.04522]. This suggests that any future A-JWT profile for long delegation chains will have to balance audit richness, token size, per-agent nonrepudiation, and revocation practicality.

Implementation hardness at the JWT layer itself is another open problem. Chai’s differential analysis of JWT, JOSE, and related libraries used 23 runnable JWT/JOSE harnesses and found 50 unique JWT differences, including fail-open malformed header behavior, verification-policy flaws, claim-validation bypass, algorithm confusion, and a Base64URL ambiguity that led to a downstream revocation bypass in an open-source RAG system [2606.26933]. This suggests that the success of A-JWT will depend not only on better claim design, but also on strict verifier behavior, canonicalization discipline, and continuous library auditing.

A plausible longer-range direction is to extend agent credentials beyond identity and authorization into economically backed accountability. Insured-agent proposals describe signed coverage credentials in which an insurer, rather than the agent alone, posts slashable stake and binds policy terms such as coverage amount, deductible, exclusions, admissible evidence, claim deadlines, challenge bonds, and dispute-resolution route to persistent agent identity [2512.08737]. A plausible implication is that future agent credentials may combine authorization, provenance, and liability backing, making “who may act” and “who stands behind that action” jointly verifiable.

Source: https://www.emergentmind.com/topics/agentic-jwt-a-jwt