| Internet-Draft | Intent Token | March 2026 |
| Williams | Expires 20 September 2026 | [Page] |
This document specifies the Intent Token, a cryptographic authorization primitive for autonomous AI agent systems. An Intent Token binds an autonomous agent action to a cryptographically signed, human-declared authorization envelope before that action is executed. The Intent Token addresses a fundamental gap in existing authorization frameworks: while OAuth 2.0, OIDC, and related standards govern identity and access at the session level, no standardized primitive exists for governing what an autonomous agent is authorized to DO at the moment of action. The Intent Token provides this primitive. It is model-agnostic, transport-agnostic, and composable with existing authorization infrastructure.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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 [RFC6749] governs whether a principal has access to a resource. OpenID Connect [OIDC] 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:¶
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) [DEEPMIND-DCT], 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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 [RFC8693], 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 [HARDY-1988] 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.¶
An Intent Token is a JSON Web Token [RFC7519] with the following structure. The header MUST include "typ": "intent+jwt".¶
{
"header": {
"alg": "ES256",
"typ": "intent+jwt"
},
"payload": {
"iss": "https://intentbound.example.com",
"sub": "agent-id:AG-7729-ALPHA",
"aud": "iba-gate:production",
"exp": 1771234567,
"iat": 1771230967,
"jti": "a8f3c2d1-4b5e-6f7a-8b9c-0d1e2f3a4b5c",
"ibt_ver": "1.0",
"principal": {
"id": "user:jeffrey.williams@example.com",
"type": "human",
"auth_method": "ES256-keypair"
},
"declared_intent": {
"action_class": "financial:order:equity",
"scope": "EQUITIES_US",
"bounds": {
"max_position_usd": 50000000,
"max_single_order_usd": 5000000,
"permitted_instruments": ["NYSE:*", "NASDAQ:*"],
"prohibited_instruments": ["OTC:*"],
"time_window": "09:30-16:00 EST"
}
},
"shard": {
"id": "shard:mmc-nbwc-enyn",
"issued_at": 1771230967,
"expires_at": 1771231479,
"window_seconds": 512
},
"enforcement": {
"snap_back": true,
"latency_target_ms": 5,
"audit_chain": "witnessbound:production"
}
}
}
¶
The following claims are REQUIRED in every Intent Token:¶
Standard JWT claims iss, sub, aud, exp, iat, and jti are REQUIRED.¶
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.¶
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.¶
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 [NIST-SP-800-57]. Implementations MUST support ES256 [RFC7518]. Implementations SHOULD support ES384 and EdDSA [RFC8037] for higher-security deployments.¶
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.¶
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.¶
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.¶
The Intent Token is complementary to OAuth 2.0 [RFC6749]. 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.¶
Tomasev et al. [DEEPMIND-DCT] 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.¶
Intent Certificates MAY be implemented as W3C Verifiable Credentials [VC-DATA-MODEL], using the "IntentCertificate" credential type with credential subject claims encoding the session authorization context specified in Section 5.¶
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.¶
This document requests the following JWT Claim registrations:¶
This document requests registration of the media type application/intent+jwt for Intent Tokens.¶