Overview
Production Readiness
0.6
Novelty Score
0.7
Cost Impact Score
0.6
Citation Count
0
Why It Matters For Business
If your product runs LLM-driven multi-agent workflows, existing bearer tokens let an attacker or a compromised agent act with broad privileges. A-JWT adds per-agent intent and proof-of-possession to reduce blast radius and give cryptographic audit trails.
Summary TLDR
The paper proposes Agentic JWT (A-JWT): an extension to OAuth/JWT that issues per-agent "intent tokens" plus delegation assertions and per-agent proof-of-possession keys. A client-side shim computes a checksum identity for each agent (based on prompt, tools, config), derives short-lived keys, and asks an IDP for intent-bound tokens. A prototype blocks the modeled attacks and adds sub-millisecond verification cost, enabling stronger zero-trust guarantees for multi-agent apps while remaining backwards-compatible with OAuth.
Problem Statement
Standard OAuth/JWT treats a client process as a single principal. LLM-driven multi-agent clients break that assumption: one process can host many autonomous agents whose runtime behavior (prompts, tool calls) may diverge from the original user intent. That enables replay, impersonation, prompt-injection, privilege escalation and other attacks which existing bearer tokens cannot cryptographically distinguish.
Main Contribution
A token design (A-JWT) that adds an intent token and delegation assertion to bind each API call to a user intent and workflow step.
A client shim that computes per-agent checksums, derives per-agent PoP keys, tracks workflow state, and mints intent tokens at runtime.
IDP and resource-server verification flows that remain backward-compatible with OAuth/JWT while enforcing agent-level identity and delegation.
Security anchors and threat mitigations (checksums, PoP keys, delegation chains, workflow registration) mapped to STRIDE threats.
A Python proof-of-concept showing blocking of modeled threats and micro-benchmarks claiming sub-millisecond verification overhead.
Key Findings
A-JWT prototype prevented the modeled attacks in the micro-service experiment.
Intent and shim checks add negligible runtime cost in the prototype.
A-JWT is backward-compatible with existing OAuth/JWT deployments.
Governance and registration scale are operational bottlenecks.
Some attack scenarios remain tricky (TOCTOU with runtime prompt substitution).
Results
Threat mitigation in prototype
Verification overhead
Who Should Care
What To Try In 7 Days
Run a threat inventory of agentic flows and APIs to identify critical chokepoints.
Prototype a shim that computes a simple agent checksum and sends it as a header for sensitive API calls.
Add PoP-key verification for a high-risk API and measure token-minting latency and operational cost.
Agent Features
Memory
- Workflow state tracking in shim (short-term workflow context)
Planning
- LLM-driven plan generation (chain-of-thought style)
Tool Use
- Per-agent tool lists recorded in agent checksum
- Agent-specific API calls via shim
Frameworks
- Agent registration + workflow registration with IDP
Is Agentic
true
Architectures
- Orchestrator + delegate multi-agent app
Collaboration
- Delegation chains encoded in tokens
Reproducibility
Open Source Status
- unknown
Risks & Boundaries
Limitations
- Workflow and agent registration create operational overhead and governance complexity.
- Prototype is Python-specific; other languages need separate shim implementations.
- TOCTOU issues remain for prompt template substitutions and runtime variable content.
- Including workflow details in tokens can leak metadata unless encrypted or opaque IDs are used.
- Paper promises a fuller experimental evaluation in a future journal submission; current quantitative evidence is limited.
When Not To Use
- Single deterministic clients where existing JWT scopes are sufficient.
- Low-governance environments that cannot support per-agent registration and CI/CD integration.
- High-frequency short-lived operations where token-minting overhead would become dominant without caching.
Failure Modes
- Shim library compromise or supply-chain replacement could bypass checks if deployment integrity is broken.
- Poorly defined prompt template hashing may allow prompt-injection to evade checks (false negatives).
- Operational backlog from frequent agent re-registration when prompts/tools/configs change.
- Resource servers that ignore intent claims create mixed-trust environments and may permit policy gaps.
Core Entities
Models
- Large language models (LLMs) - generic
Metrics
- latency (sub-millisecond verification)
- attack-blocking rate (100% in prototype)
Context Entities
Metrics
- token minting latency (qualitative; may increase frequency)
- Shim integrity check (X-Shim-Checksum)