The Intent Token: A Cryptographic Authorization Primitive for Autonomous Agents

Introduction The deployment of autonomous AI agents in consequential domains -- financial services, healthcare, critical infrastructure, autonomous vehicles, and multi-agent orchestration systems -- creates a class of authorization problems that existing standards do not address. OAuth 2.0 governs whether a principal has access to a resource. OpenID Connect governs whether a principal is who they claim to be. These standards address the WHO question: who is this agent, and what resources may it access? Neither standard addresses the WHAT question: given that an agent has access, what specific actions is it authorized to perform at this moment, on behalf of this principal, within these declared boundaries? The gap between access and action is the authorization gap. In human-operated systems, this gap is bridged by human judgment. In autonomous agent systems, this gap is bridged by the agent itself -- which may interpret its authorization scope in ways the authorizing principal did not intend. This is the intent blindness problem. This document specifies the Intent Token, a cryptographic primitive that closes the authorization gap. An Intent Token is a signed, time-bounded authorization envelope that:

Declares what action a principal authorizes an agent to perform, BEFORE the action is executed;
Binds that declaration cryptographically to the agent session and the specific action;
Provides a verifiable, tamper-evident record of the authorization for audit purposes;
Propagates the declared intent through delegation chains, preventing sub-agents from exceeding the scope the delegating principal was itself authorized to grant.

The Intent Token is the core primitive of the Intent Bound Authorization (IBA) framework, patent application GB2603013.0 (pending, UK IPO, filed February 5, 2026, PCT rights in 150+ countries until August 2028). Independent convergence on this primitive was identified in Google DeepMind's introduction of Delegation Capability Tokens (DCTs) , February 12, 2026, seven days after the IBA patent filing. DeepMind's paper identifies the same open problem: no standardized ontology for intent and responsibility across autonomous agent platforms exists. This document proposes the Intent Token as the candidate standard to fill that gap. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Intent Token:: A cryptographically signed authorization envelope that declares what action a principal authorizes an autonomous agent to perform, issued before the action is executed, and bound to a specific session shard.
Intent Certificate:: A persistent, verifiable credential that records the full authorization context for an agent session, including the principal identity, declared scope, temporal bounds, and cryptographic proof of all enforcement decisions made during the session.
Principal:: The human or organizational entity whose declared intent authorizes the agent action. The principal MUST be cryptographically identified in every Intent Token.
Authorized Agent:: An autonomous system authorized to act within the scope declared in an Intent Token.
Shard:: A time-bounded cryptographic token issued by the IBA Gate that must be presented with every agent action. Shards expire after a configurable window (default 512 seconds).
IBA Gate:: The enforcement point that validates Intent Tokens before permitting agent actions.
SNAP-BACK:: The mandatory cancellation of an agent action when Intent Token validation fails. SNAP-BACK MUST occur before the action has market or physical effect.
Delegation Chain:: The ordered sequence of principals and agents through which authorization has been delegated. Each link is cryptographically signed. No link may grant scope exceeding the scope granted to the delegating entity.
TBDE:: Temporal Boundary Decision Engine. The runtime component responsible for validating every agent action against the declared Intent Token within the enforcement latency target.
WitnessBound Audit Chain:: An append-only, cryptographically chained audit record of all enforcement decisions providing tamper-evident proof of all authorization decisions.

Problem Statement

The Authorization Gap Beyond OAuth 2.0 OAuth 2.0 access tokens grant access to resource scopes. A token with scope "read:financial_data" grants read access to financial data. It does not specify which financial data, under what conditions, at what time, or within what value limits. An autonomous agent with an access token has no cryptographic constraint on what it does within its granted scope -- including actions the authorizing principal never contemplated. Existing mitigations -- rate limiting, anomaly detection, audit logging -- are post-hoc. The Intent Token is pre-hoc: it declares and enforces authorization before action.

The Delegation Depth Problem Modern autonomous agent architectures are hierarchical. An orchestrating agent delegates tasks to sub-agents, which may delegate further. Existing delegation frameworks, including OAuth 2.0 Token Exchange , do not provide a mechanism for propagating declared human intent through the delegation chain. The Intent Token addresses this by requiring that every link in the delegation chain present a valid Intent Token that is a subset of the authorizing token. A sub-agent cannot act outside the scope its delegating principal was itself authorized to grant.

The Confused Deputy Problem in Autonomous Systems The confused deputy problem describes a scenario in which a system with legitimate authority is manipulated into misusing that authority. In autonomous agent systems, an agent may be manipulated via prompt injection, adversarial input, or environmental manipulation into taking actions outside its intended scope. The Intent Token defends against confused deputy attacks. Because the authorized action is declared and signed by the principal BEFORE the agent acts, any deviation from the declared intent -- regardless of cause -- is detected and blocked at the enforcement layer.

The Intent Token

Token Structure An Intent Token is a JSON Web Token with the following structure. The header MUST include "typ": "intent+jwt".

Required Claims The following claims are REQUIRED in every Intent Token:

ibt_ver:: The version of the Intent Token specification. This document defines version "1.0".
principal:: An object identifying the authorizing human principal. MUST include "id" (a URI) and "type" ("human" or "organization").
declared_intent:: An object declaring the specific action class the principal authorizes. MUST include "action_class" and "scope".
shard:: An object binding the token to a specific time-bounded session shard. MUST include "id", "issued_at", "expires_at", and "window_seconds".
enforcement:: An object specifying enforcement requirements. MUST include "snap_back" (boolean, MUST be true) and "audit_chain" (URI of the audit chain endpoint).

Standard JWT claims iss, sub, aud, exp, iat, and jti are REQUIRED.

Temporal Scope and Shard Binding Every Intent Token MUST be bound to a time-bounded shard. The shard provides temporal scope and session binding. The default shard window is 512 seconds. When a shard expires, the agent MUST obtain a new Intent Token before continuing to act. The enforcement layer MUST reject any action presented with an expired shard.

Delegation Chain Encoding When an authorizing agent delegates to a sub-agent, the delegating agent MUST issue a new Intent Token with a declared_intent scope that is a subset of its own authorized scope. A delegating agent MUST NOT grant scope exceeding its own authorization. The delegation_chain array MUST include all prior delegation records plus a new signed record for this delegation.

Intent Certificate An Intent Certificate is the persistent audit record of an agent session. It MUST contain: the principal identity and authentication record; the declared scope for the session; the temporal bounds; a reference to the WitnessBound audit chain; cryptographic hashes of all Intent Tokens issued during the session; and a signed summary of all enforcement decisions including SNAP-BACK events. Intent Tokens and Intent Certificates MUST be signed using algorithms from NIST SP 800-57 . Implementations MUST support ES256 . Implementations SHOULD support ES384 and EdDSA for higher-security deployments.

Enforcement Binding

Pre-Action Validation The IBA Gate MUST validate the Intent Token BEFORE the agent action is permitted to execute. The IBA Gate MUST verify: token signature validity; token and shard expiry; action matches declared_intent action_class; action parameters are within declared bounds; delegation chain validity; and jti uniqueness for replay prevention. Implementations MUST complete all validations within the latency_target_ms specified in the enforcement claim. The target is 5ms.

SNAP-BACK on Violation If any validation check fails, the IBA Gate MUST: reject the agent action immediately; record a SNAP-BACK event in the WitnessBound audit chain; return a structured error to the agent; and NOT permit the action to be retried without a new Intent Token authorized by the principal. SNAP-BACK is a hard stop. No partial execution is permitted.

Audit Chain Requirements Every enforcement decision MUST be recorded in the WitnessBound audit chain. Each record MUST contain: the jti of the Intent Token; the validation timestamp (nanosecond precision RECOMMENDED); the validation result (PASS or SNAP-BACK); and a cryptographic hash chained to the previous record. This audit chain satisfies the audit requirements of EU AI Act Article 9, MiFID II, FDA Cybersecurity 2023, and HIPAA Security Rule.

Interoperability

Relationship to OAuth 2.0 The Intent Token is complementary to OAuth 2.0 . OAuth 2.0 governs access; the Intent Token governs action. In a compliant implementation: the agent obtains an OAuth 2.0 access token establishing resource access; the principal issues an Intent Token declaring the specific authorized action; the IBA Gate validates the Intent Token before permitting the action.

Relationship to Delegation Capability Tokens Tomasev et al. introduced Delegation Capability Tokens (DCTs) as a primitive for AI agent authorization. DCTs address the same authorization gap as the Intent Token, arriving independently seven days after the IBA patent filing. The IETF is encouraged to consider harmonization between this specification and the DCT work, given the independent convergence on the same primitive.

Relationship to W3C Verifiable Credentials Intent Certificates MAY be implemented as W3C Verifiable Credentials , using the "IntentCertificate" credential type with credential subject claims encoding the session authorization context specified in Section 5.

Security Considerations Replay Attacks: Intent Tokens MUST include a unique jti claim. The IBA Gate MUST maintain a record of used jti values for the duration of the shard window. Token Forgery: Implementations MUST follow NIST SP 800-57 for key management. Hardware security modules (HSMs) are RECOMMENDED for principal signing keys in high-security deployments. Scope Escalation: Implementations MUST validate the complete delegation chain, not only the most recent delegation record. Prompt Injection: The Intent Token provides defense against prompt injection attacks. An agent manipulated into attempting an out-of-scope action will be stopped by SNAP-BACK regardless of the cause. Enforcement Latency: The 5ms enforcement latency target is a security parameter. In financial systems, actions with market impact occur faster than 5ms. Implementations in latency-sensitive domains MUST measure and report enforcement latency. Audit Chain Integrity: Implementations MUST store audit chain records in append-only storage with access controls preventing modification or deletion.

IANA Considerations This document requests the following JWT Claim registrations:

Claim Name: ibt_ver -- Intent Token specification version
Claim Name: declared_intent -- Principal-declared authorized action scope
Claim Name: shard -- Time-bounded session shard binding
Claim Name: enforcement -- Enforcement requirements for this token
Claim Name: delegation_chain -- Ordered delegation records

This document requests registration of the media type application/intent+jwt for Intent Tokens.