Keys to the Kingdom… with a Chaperone: How Agentic JWT Grounds AI Agents in Real Intent

Access tokens are convenient little monsters. Hand one to an application and, for a while, the receiving API behaves as if the bearer of that token is a faithful representative of the user. In normal software, that assumption is often good enough. The app has deterministic code. The button does what the button was built to do. The workflow may be dull, but dullness is a security feature.

Agentic systems are less obliging. An LLM-driven client can plan, delegate, retry, call tools, and improvise its way through an API surface. The token still says “this client may do X,” but the interesting question has moved: which agent is doing X, why is it doing X, and is this still the user’s original intent or just a very confident stochastic intern with network access?

That is the problem Abhishek Goswami’s paper, “Agentic JWT: A Secure Delegation Protocol for Autonomous AI Agents,” tries to solve.¹ Its proposal, Agentic JWT, or A-JWT, is not another wrapper around prompt safety. It is a protocol design for making agentic API calls cryptographically accountable. The paper’s core move is simple enough to be dangerous in the right way: stop treating the whole AI application as one OAuth client and start treating each agent action as something that must prove identity, intent, delegation, and possession.

In other words: keep the keys to the kingdom, but send a chaperone with every door opening.

OAuth assumes the client still means what the user meant

Classical OAuth solved a real and important problem. Users should not hand permanent credentials to every third-party app that wants access to their resources. OAuth introduced an authorisation server, a client, a resource owner, scopes, and tokens. The client receives bounded authority and presents a token to the resource server. The resource server validates it and executes the request.

That model quietly assumes that the client is a stable executor of the user’s approved purpose. Not perfect, not omniscient, but basically deterministic. If the user authorised calendar access, the calendar app is presumed to be running the calendar app’s code path.

Agentic AI breaks that assumption without necessarily breaking the token. The same client may contain an orchestrator agent, a classifier agent, a planner agent, and a patcher agent. One agent may only read dependency manifests. Another may open pull requests. Another may merge code. If all of them share one client credential and one broad scope, the resource server sees a valid token but not the internal delegation story that produced the request.

This is the paper’s useful distinction: scope is not intent.

A scope says what a client is generally allowed to do. Intent says why this specific action is being performed in this specific workflow step by this specific agent. In deterministic software, those two were often close enough to blur. In agentic software, they drift apart. The model can be prompted, confused, redirected by external content, or induced into “helpful” escalation. A bearer token does not care. It is not a philosopher. It is a pass.

Agentic JWT therefore treats intent as a first-class security object rather than a vibes-based property inferred from the application.

The mechanism: every agent action carries a passport, itinerary, and handcuffs

The paper’s architecture keeps the familiar OAuth/JWT frame but adds agent-aware components. The most important are:

That is a lot of machinery, but the security logic is coherent. A-JWT is trying to convert “this application has a token” into “this registered agent, inside this registered client, at this workflow step, acting under this delegation chain, signed this request with its own key.”

The client-side shim is central. It sits inside the agentic client, computes runtime checksums, tracks workflow state, derives or manages proof-of-possession keys, injects agentic headers, and talks to the identity provider. The paper describes this shim as the place where the old OAuth world and the agentic runtime meet. Inelegant? Slightly. Necessary? Probably. Security often begins where elegance goes to file a complaint.

The identity provider also becomes more specialised. It must register agent identities, store checksums, validate workflow steps, verify delegation chains, and issue intent tokens. The resource server, or a resource-server proxy in the prototype, must understand the extra claims and enforce them. Legacy servers may ignore the new claims and treat the token like an ordinary JWT, but then they obviously do not get the agentic protections. Backward compatibility is not the same thing as magic.

The agent checksum turns prompt-and-tool configuration into identity

The most distinctive design choice is the agent checksum. The paper defines an agent’s signature from its prompt template, tools, and configuration. The shim computes a one-way hash over that signature; the identity provider compares the runtime checksum with the registered checksum before issuing an intent token.

This has a clean security intuition. If an attacker modifies an agent’s prompt, swaps a tool, or changes configuration, the checksum should change. If the checksum changes, the identity provider should refuse to mint the token. The agent cannot simply claim to be “the patcher” because the patcher’s identity is grounded in registered runtime structure.

The business interpretation is that agent deployment becomes more like workload identity management. You do not merely approve “the AI assistant.” You approve named agent roles with versioned behavioural signatures. A planner, classifier, and patcher may live in the same application, but they should not share one amorphous authorisation blob.

There is a useful governance implication here. Prompt changes become identity changes. Tool changes become identity changes. Configuration changes become identity changes. That is exactly the sort of thing enterprises usually discover after an incident and then lovingly rename “control maturity.”

The catch is that this only works cleanly when the organisation can define and register stable agent templates. Real agents have dynamic prompt variables, user inputs, retrieved context, and tool outputs. The paper recognises this as a time-of-check/time-of-use problem: the registered prompt template can be checked, but runtime substitutions may be legitimate or malicious. A-JWT can validate structure and whitelist substitutions, but it does not make prompt injection disappear. It narrows what injected behaviour can successfully execute at protected APIs.

That distinction matters. This is not “prompt injection solved.” It is “even if the agent is manipulated, the resulting API action must still fit a registered identity and intent envelope.” Much less glamorous. Much more useful.

Intent tokens make the workflow visible to the API

The paper’s intent token extends a normal JWT with additional claims such as workflow_id, workflow_step, executed_by, initiated_by, delegation_chain, step_sequence_hash, and execution context such as repository, branch, or commit. The exact fields in production would vary by system, but the principle is stable: the token carries enough context for the resource server to judge whether the action belongs to the approved workflow.

This is the protocol’s real centre of gravity. Without workflow context, a broad scope such as repo:write is a blunt instrument. With workflow context, a patcher may be allowed to create a pull request only as part of a vulnerability remediation workflow, after the planner and classifier steps have occurred, for a particular repository and branch.

The paper frames this as restoring Zero Trust semantics for agentic workflows. That framing is reasonable, provided one reads “restoring” as an architectural aspiration rather than an experimental verdict. Zero Trust asks systems to continuously verify subjects, context, and policy. A-JWT gives APIs more material to verify at each call.

For business teams, the important shift is from permission assignment to action provenance. The question is no longer only:

Did this client have write access?

It becomes:

Was this write action executed by the registered patcher agent, during the approved patching step, under the correct delegation chain, for the correct repository context, using the agent’s own proof-of-possession key?

That is a much better audit question. It is also a much harder engineering question. Progress, as usual, arrives with paperwork.

Delegation chains stop multi-agent systems becoming accountability soup

Multi-agent systems are useful partly because they divide labour. The orchestrator routes. The planner analyses. The classifier narrows. The patcher changes things. But division of labour creates a security question: when a downstream agent acts, who authorised it?

A-JWT encodes the delegation chain in the token. The resource server can see that the orchestrator initiated a workflow, delegated a step to the planner, which led to a patcher action. The identity provider can validate whether that chain is registered and allowed. The paper maps this to repudiation and delegation-chain manipulation threats: without cryptographic provenance, agents can become very good at producing side effects that nobody can reconstruct later.

This is where the design becomes operationally interesting. Enterprises already struggle to explain why a human changed something in production. With agents, the answer “the AI did it” will age about as well as “the intern had root access.” A delegation chain gives security teams a basis for post-incident reconstruction and, more importantly, pre-incident policy enforcement.

A simple way to read the design is:

User intent
   ↓
Orchestrator agent
   ↓
Registered workflow step
   ↓
Delegate agent
   ↓
Intent token + delegation chain + PoP signature
   ↓
Resource-server enforcement

The resource server is the choke point. That is sensible. Agent reasoning may be messy, but APIs are where the mess becomes real. If an agent can only hallucinate in a chat window, the risk is reputational. If it can merge code, send money, revoke access, or delete records, the risk becomes operational. A-JWT focuses on the moment where agency becomes action.

The threat model is the paper’s scaffolding, not decoration

The paper uses STRIDE to enumerate threats across spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It maps these to agentic security problems such as agent identity spoofing, token replay, shim impersonation, runtime code modification, prompt injection, scope inflation, intent origin forgery, delegation-chain manipulation, and agent configuration exposure.

This section is not merely a ceremonial threat table. It explains why the protocol has so many moving parts.

The important pattern is that A-JWT does not try to make LLMs reliable by staring harder at their outputs. It constrains the execution channel. That is the right layer for many enterprise controls. Models will remain probabilistic; resource servers do not have to be.

The prototype is illustrative, not yet a benchmark-grade evaluation

The paper describes a Python proof-of-concept built around a multi-agent vulnerability patching system. The workflow monitors a Git repository, scans manifests, classifies ecosystems, generates a software bill of materials, queries vulnerabilities from OSV, triages and groups them, then patches code, creates pull requests, and merges them.

The agent roles are deliberately different in privilege:

This is a good demonstration scenario because it contains exactly the kind of privilege gradient that makes agentic systems dangerous. Reading a manifest is one thing. Auto-merging a patch is quite another. If those agents share a broad client credential, the system relies on internal behavioural discipline. A-JWT tries to replace discipline with enforceable boundaries.

The experimental methodology is a before-and-after comparison. The “before” phase uses ordinary OAuth 2.0 JWTs with a client_credentials grant. The “after” phase uses A-JWT intent tokens with an agent_checksum grant. The authors reproduce the threat scenarios and observe that the A-JWT version mitigates them through token-minting denial, resource-server denial, or other enforcement.

The boundary is important: the paper states that full experimental results and performance analysis are deferred to a forthcoming journal publication. The abstract and contribution list refer to functional blocking and low overhead, but the current arXiv text does not provide the kind of detailed measurement tables, ablations, latency distributions, or adversarial test matrix one would want before treating those claims as settled engineering evidence.

So the fair reading is this:

This does not weaken the paper’s conceptual contribution. It just locates it properly. A-JWT is most valuable as a protocol proposal and architectural pattern. It is not yet a mature standard, a reference implementation blessed by the ecosystem, or a complete empirical security evaluation.

The enterprise takeaway: agent access should look like workload identity plus intent provenance

For CIOs, CISOs, and product teams building agentic systems, the paper’s lesson is not “adopt this exact protocol tomorrow.” The more useful takeaway is that agentic access control needs four properties that ordinary client-level OAuth often does not provide.

First, agents need separate identities. A single client ID for a multi-agent application is too coarse when the internal agents have different tools, prompts, and privilege levels.

Second, workflows need to be registered or otherwise governed. If an agent can invent new action paths at runtime and still obtain broad tokens, the security model is mostly theatre with a JSON payload.

Third, API calls need intent provenance. The protected resource should know not only who called, but why this call is part of an authorised task.

Fourth, high-impact actions need proof-of-possession or equivalent binding. Bearer tokens are convenient because possession is enough. That is also their defect. For agentic systems, especially co-resident agents inside the same process, possession alone is too weak.

A-JWT packages those properties into a token-based design. An enterprise implementation might not copy every field. It might use service mesh identity, SPIFFE-like workload IDs, policy engines, signed workflow manifests, or custom gateway enforcement. Fine. The architectural requirement remains: the API must be able to reject a valid-looking request whose agent, intent, delegation, or workflow context is wrong.

That is the part many agent demos skip. They show the agent doing the thing. They do not show the API saying, “No, not like that.”

The cost is governance, not just cryptography

A-JWT’s biggest deployment challenge is not the cryptographic idea. It is the organisational machinery required to make the cryptography meaningful.

Agents must be registered. Their prompt templates, tools, and configurations must be versioned. Workflows must be described. Delegation paths must be approved. Identity providers must support new claims and grant types. Resource servers must enforce them. Shim libraries must be integrated into agent runtimes. CI/CD pipelines may need to update registrations whenever an agent changes. MCP-style tool and prompt management would need to coordinate with identity registration.

That is not a small lift. It is also not optional if agents are going to touch production systems.

The paper is refreshingly direct about several trade-offs. Short-lived or one-time tokens may increase minting frequency. Workflow introspection may add latency, even if in-memory overhead is expected to be modest. Workflow registration creates scale and governance issues. The Python reference implementation would need language-specific equivalents. Workflow metadata inside tokens can disclose operational structure unless encrypted or replaced with opaque identifiers. Standardisation through IETF-style processes would take time.

The most delicate limitation is runtime prompt evaluation. A checksum over prompt templates, tools, and configuration can detect certain changes, but runtime substitutions are inevitable. The protocol can whitelist substitution patterns and validate structure, but distinguishing legitimate dynamic content from injection remains hard. This is exactly where model security and access-control security meet, look at each other suspiciously, and agree to escalate to architecture review.

Where A-JWT fits first

The strongest early use cases are not casual assistants. They are agentic systems with clear workflows, meaningful API side effects, and privilege separation across agents.

Good candidates include:

Weak candidates are open-ended consumer agents whose workflows are fluid, low-risk, or mostly conversational. If the system cannot define approved workflows, A-JWT’s workflow-binding benefits become harder to realise. One can still use agent identity and proof-of-possession, but the full intent model depends on a degree of process structure.

This is not a flaw. It is a targeting rule. Controls work best where the work has shape.

The paper’s quiet challenge to agent builders

The popular story of agent safety often begins with better prompting, better evaluation, better model behaviour, and better refusal policies. Those matter. But Agentic JWT asks a more infrastructure-flavoured question: what if the model behaves badly and still has a valid token?

That question is where enterprise AI becomes real. The moment an agent can act through APIs, security cannot live only in the prompt, the model wrapper, or the dashboard. It must live at the boundary where requests reach systems of record.

The paper’s answer is to bind every meaningful action to a registered agent identity, a user intent, a workflow step, a delegation chain, and a proof-of-possession key. The result is not a silver bullet. It is a narrower blast radius, a better audit trail, and a policy surface that reflects how agentic systems actually behave.

That may sound less exciting than autonomous intelligence. Good. The history of enterprise technology suggests that “less exciting” is often where the durable controls are hiding.

Agentic JWT’s most important contribution is not a new claim field. It is the insistence that an AI agent’s authority should be explainable at the moment of execution, not reconstructed later from logs, vibes, and a regretful Slack thread.

Cognaptus: Automate the Present, Incubate the Future.