Agentic JWT Protocol

• A-JWT is a cryptographic protocol that provides deterministic integrity, context, and policy guarantees for every agent action across boundary transitions.
• It employs a compact JOSE-inspired structure with signature schemes like ES256 and Ed25519, ensuring tamper-evident tokens and rigorous policy enforcement.
• Performance evaluations show sub-millisecond overhead with high throughput, making A-JWT practical for secure, auditable agentic operations in AI systems.

Agentic JWT (A-JWT) is a cryptographic protocol designed to provide deterministic integrity, context, and policy guarantees for every operation within agentic AI workflows, particularly across boundary crossings such as prompts, tools, data access, and contextual transitions. Developed as a direct response to the inadequacies of probabilistic security controls in LLM agent ecosystems, A-JWT ensures that every boundary transition is regulated by a verifiable, tamper-evident artifact, enforcing both organizational policy and cryptographic authenticity (Rajagopalan et al., 11 Feb 2026, Goswami, 16 Sep 2025, South et al., 16 Jan 2025, Dalugoda, 6 Apr 2026).

1. Protocol Goals and Security Properties

A-JWT was introduced to address the propensity of AI agents to exceed delegated authority, circumvent semantic guardrails, and bypass privilege boundaries due to stochastic reasoning or prompt injection. The protocol delivers a "complete trust layer" with the following objectives (Rajagopalan et al., 11 Feb 2026):

• Integrity: All agentic actions are cryptographically bound to principals, parameters, policy, and evolving session context (sequence number and hash chain).
• Authenticity and Non-Repudiation: Only authorized keyholders can produce or update valid tokens; signatures serve as undeniable evidence of authorship.
• Deterministic Policy Enforcement: Tokens embed a policy identifier, guaranteeing that every operation is checked for compliance with all applicable hierarchical policies.
• Context Protection: Session state is encoded as a rolling hash chain, establishing tamper-evidence and replay protection.
• Comprehensive Coverage: Each boundary crossing requires a valid token; absence leads to outright rejection by enforcement points.

These design goals ensure that operational logic and privilege are enforced at cryptographic, rather than heuristic, granularity.

2. Token Structure and Cryptographic Foundations

A-JWT adopts a compact, JOSE-inspired tripartite structure—Header, Payload, and Signature—serialized as Base64Url-encoded segments ("H.P.S"). Signature algorithms are typically ECDSA-P-256 (“ES256”) or Ed25519; RSA is supported where backward compatibility with legacy OAuth is needed (Rajagopalan et al., 11 Feb 2026, Dalugoda, 6 Apr 2026, South et al., 16 Jan 2025).

Header contains:

• "alg": Signing algorithm, e.g., "ES256" or "Ed25519"
• "typ": Always "A-JWT"
• "kid": Key identifier for the signing principal

Payload encodes:

• "iss" (issuer/agent)
• "sub" (operation or agent action)
• "aud" (intended recipient/service)
• "iat", "exp", "jti" (timestamps and nonce for replay detection)
• "pol" (policy ID for MAPL evaluation)
• "seq", "ctx" (monotonic sequence, rolling context hash)
• "res", "prm" (resource/pattern and operation arguments)
• "att" (join attestations or dependency proofs)
• Optional: delegation chain, human principal object, workflow or step hashes (South et al., 16 Jan 2025, Dalugoda, 6 Apr 2026, Goswami, 16 Sep 2025)

Signature computation:

$$\sigma = \mathrm{Sign}_{sk_{\mathrm{iss}}}(H \| "." \| P)$$

A-JWT thus takes the canonical form: $$\mathrm{A\text{-}JWT} = H \, "." \, P \, "." \, \mathrm{Base64Url}(\sigma)$$ Session context binding is ensured via hash chains, e.g., for chaining prompt turns or agent delegations: $$\mathrm{ctx}_n = \mathrm{Hash}(\mathrm{ctx}_{n-1} \| \mathrm{seq}_n \| \mathrm{jti}_n)$$ (Rajagopalan et al., 11 Feb 2026, Dalugoda, 6 Apr 2026).

3. Issuance, Verification, Refresh, and Revocation

Pseudocode formalizations specify all operational flows (Rajagopalan et al., 11 Feb 2026):

• Issuance ("SignA-JWT"): An agent or issuer computes all required fields, serializes header/payload, signs the result, and returns the tripartite artifact.
• Verification ("VerifyA-JWT"): The recipient verifies the cryptographic signature, checks timestamps, enforces monotonicity and replay, validates the hash chain, and executes the policy binding by intersecting all policies referenced in the "pol" claim.
• Refresh: Tokens expiring or rolling over context are re-minted with updated sequence and hash state.
• Revocation: Each token carries a unique "jti"; issuers or registries maintain a revocation list. Verification includes a registry lookup to check for revocations.
• For chained-delegation models (see (Dalugoda, 6 Apr 2026)), each delegation "hop" is appended as an entry in an append-only, signed context.

Tokens not satisfying any step are deterministically rejected, and all policy enforcement decisions are derived from effective intersections specified by policy composition theorems in MAPL (Rajagopalan et al., 11 Feb 2026).

4. Integration with Policy Engines and Delegation Chains

A-JWT integrates directly with AI-native policy languages such as MAPL, where each token specifies a "pol" (policy_id), binding the operation to dynamically composable, hierarchical constraints. Policy intersection is executed as follows:

• Fetch policy referenced by "pol" (resource-centric)
• Fetch all relevant organizational policies (e.g., principal’s org-tree)
• Intersect constraints in $O(\log M + N)$ time ($M$ principals, $N$ resources), due to hierarchical composition with attestations (Rajagopalan et al., 11 Feb 2026).
• Attestations or delegation chains are verified recursively according to session or workflow context

In multi-hop delegation and provenance (as in (Dalugoda, 6 Apr 2026)), A-JWT tokens maintain an append-only array of "hops", with each hop cryptographically bound via SHA-256 chain hashes and per-hop signatures. A table summarizing protocol variants:

Capability	Standard JWT	OAuth RFC 8693	HDP/A-JWT (Ed25519)
Multi-hop Provenance	No	No	Yes
Offline Verifiability	Yes	No	Yes (self-contained)
Human Principal Binding	No	Yes (act claim)	Yes
Scope/Policy Lineage	No	No	Yes
Infra Footprint	Low	High	Minimal (JSON+Ed25519)

(Dalugoda, 6 Apr 2026)

5. Workflow Enforcement and Boundary Crossing

A-JWT enforcement points (PEPs) are designed to intercept every transition across the four agentic boundaries: prompts (LLM calls), tool invocations, data fetches, and session/context advances. A canonical boundary workflow proceeds as (Rajagopalan et al., 11 Feb 2026):

1. Arguments and "pol" are assembled for the outgoing operation.
2. The A-JWT is minted and attached.
3. The recipient verifies cryptography, time, replay protection, and hash chain.
4. MAPL policies are fetched and constraints are intersected with resource- and organizational policies.
5. On acceptance, the tool executes; otherwise, the operation is rejected with a deterministic audit log.

This flow delivers deterministic, complete, and sound rejection or acceptance, as established by formal proofs.

6. Performance and Empirical Results

Evaluation on commodity x86-64 platforms (8-core, 16 GB RAM) shows:

• ECDSA-P-256 sign: ≈102 μs
• ECDSA-P-256 verify: ≈89 μs
• SHA-256 hash chain: ≈15 μs
• Policy fetch/intersection (depth 3–5): 50–100 μs in-memory, 100–300 μs via Redis
• Local tool call overhead: <1 ms (excluding LLM/network)
• Achieved 100% recall, 0% false positives across 174 diverse test cases (11 attack patterns × 9 frameworks)
• Protects against 9/10 OWASP Top 10 attack classes and mitigates high-impact CVEs observed in production
• Throughput ≥5,000 operations/sec per PEP; cryptographic overhead is negligible compared to network/LLM latency

(Rajagopalan et al., 11 Feb 2026).

7. Practical Implications and Comparisons

A-JWT operates as a minimal and universal trust substrate, requiring no protocol modifications to underlying AI frameworks or OAuth. Implementations exist in major Python frameworks for autonomous agents and LLM orchestration, supporting drop-in deployment.

Distinctive from conventional JWT or OAuth2, A-JWT's bearers cryptographically encode (a) active policy intersection, (b) agent/delegation context, (c) rolling and session-bound hash provenance, (d) formal intent tokens, and (e) append-only delegation chains. This ensures that agentic decision surfaces are auditable, non-repudiable, and enforce least-privilege at every step, resolving well-documented gaps in previous authorization models (Dalugoda, 6 Apr 2026, Goswami, 16 Sep 2025, South et al., 16 Jan 2025).

A full-featured A-JWT protocol instance provides deterministic, system-wide guarantees for agentic AI operations with sub-millisecond operational overhead and provable security against replay, forgery, escalation, and privilege boundary bypass.