Protocol flows

Token minting

This is the sequence that runs on every governed call. The agent is about to touch a resource; between the intent and the request, the runtime mints an intent token and the Authority decides whether to grant it. It’s the hot path, and it adds a handful of milliseconds to a step that already takes an LLM hundreds.

Clientagent + embedAuthorization Serverauth51 authorityResource Serverthe APIC · request intent token (agent_checksum grant)D · intent token — short-lived, DPoP-boundE · call resource, present intent tokenF · protected resource
Figure 1. The request-time flow. The client asks the Authority to mint (control plane); the Authority returns a short-lived, DPoP-bound intent token; the client presents it to the resource, which verifies it (data plane).

The request

When the agent is about to call a resource, the runtime pauses the egress and assembles a mint request against the agent_checksum grant: the agent id, the checksum it just computed from the live agent, the requested scope and audience, and (if the run is following a plan) the workflow, step, and delegation context. This request is itself authenticated with the client’s ordinary OAuth token; minting an intent token is a privileged operation.

The validation

The Authority runs a decision, in order: the grant type must be agent_checksum; the agent must be registered; the submitted checksum must match the registered one (recomputed, not trusted); the requested scope must fall inside the grant; and, if a workflow is in play, the step, its prerequisites, and the delegation chain must all check out. Any failure returns a specific error and no token.

Note

The checksum comparison here is the runtime identity check. Because the Authority recomputes it, a mint request from an agent whose prompt or tools changed since registration fails at this step. The same request that worked before the change is now denied.

The mint and the attach

On success the Authority issues an intent token: an ordinary JWT carrying the identity, the single scope and audience, a tight expiry, the cnf.jkt key binding, and the intent and agent_proof claims. The runtime attaches it to the outbound request, adds the DPoP proof signed with the agent’s private key, and lets the call proceed. At the resource, the verifier checks the signature and the binding before doing any work.

What it costs, and why the total can go down

The security work here is small: token minting adds on the order of ~18 ms, and the checksum computation is a fraction of a millisecond, negligible against an LLM reasoning step that runs hundreds to thousands of milliseconds.

Counter-intuitively, end-to-end workflow time can drop: because a mint is denied before a disallowed action runs, the system skips the wasted LLM and tool calls that a bad path would otherwise have spent. Blocking early saves more than verification costs. arXiv 2509.13597