Agentic JWT (A-JWT) Protocol

• Agentic JWT (A-JWT) is a protocol extension to OAuth 2.0 that links each AI agent action with cryptographically verifiable user intent and workflow context.
• It employs a checksum-based agent identifier and per-agent proof-of-possession keys to securely authenticate agents and prevent token misuse.
• The design enforces delegation, workflow, and provenance controls, enabling granular, auditable authorization for autonomous AI systems.

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 (Goswami, 16 Sep 2025). 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 (South et al., 29 Oct 2025).

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 (South et al., 16 Jan 2025). 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 (Goswami, 16 Sep 2025). 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 (South et al., 29 Oct 2025).

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 (Goswami, 16 Sep 2025).

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 (Goswami, 16 Sep 2025). 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 (South et al., 29 Oct 2025). 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 (Goswami, 16 Sep 2025).

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 (Goswami, 16 Sep 2025). 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 (Goswami, 16 Sep 2025). 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 (Dalugoda, 6 Apr 2026). 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 (Sharma et al., 17 Mar 2026). 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 (Goswami, 16 Sep 2025). 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 (Goswami, 16 Sep 2025).

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 (Goswami, 16 Sep 2025). 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 (Louck et al., 5 Nov 2025). 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 (Gao et al., 10 Jun 2026). 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 (Fotiou et al., 2021). 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 (Madhira, 12 May 2026). 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 (Madhira, 12 May 2026).

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 (South et al., 29 Oct 2025). 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 (Goswami, 16 Sep 2025).

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 (Dalugoda, 6 Apr 2026). 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 (Villa et al., 25 Jun 2026). 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 (Hu et al., 9 Dec 2025). 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.