| Internet-Draft | Intent Token | June 2026 |
| Williams | Expires 24 December 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 revision (-01) extends the specification with Fractal Intent Token (FIT) binding for multi-scale agent systems, Authorization Fluidity for context-sensitive mode switching, and the Fractal Crypto-Temporal Graph (FCTG) as the normative audit trail data structure for continuous adaptive authorization.¶
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 3 December 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).¶
This revision (-01) extends the -00 specification in response to developments in multi-agent orchestration systems and findings from empirical research conducted via the RSIForge recursive self-improvement research platform [WILLIAMS-2026]. The extensions address authorization at multiple scales simultaneously (Section 4.5), context-sensitive mode switching (Section 9), and a new normative audit trail data structure (Section 10).¶
Independent convergence on the authorization gap was observed in Google DeepMind's Delegation Capability Tokens [DEEPMIND-DCT] (February 12, 2026), Mastercard's Verifiable Intent framework (February 2026), and the authorization gap exposed by Sakana AI's Fugu Ultra orchestration system (June 2026). Section 11 documents this convergence.¶
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 but do not constrain what an autonomous agent does within that scope. Existing mitigations are post-hoc. The Intent Token is pre-hoc: it declares and enforces authorization before action.¶
Modern autonomous agent architectures are hierarchical. Existing delegation frameworks, including OAuth 2.0 Token Exchange [RFC8693], do not propagate declared human intent through the delegation chain. The Intent Token requires that every link present a valid Intent Token that is a subset of the authorizing token.¶
The confused deputy problem [HARDY-1988] describes a system with legitimate authority being manipulated into misusing that authority. The Intent Token defends against this: because the authorized action is declared and signed by the principal BEFORE the agent acts, any deviation is detected and blocked at the enforcement layer.¶
An Intent Token is a JSON Web Token [RFC7519] with "typ": "intent+jwt". The "ibt_ver" claim is "1.1" in this revision.¶
{
"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.1",
"ibt_level": "agent",
"parent_token_jti": "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f",
"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": "fctg:production",
"auth_mode": "static"
}
}
}
¶
Standard JWT claims iss, sub, aud, exp, iat, and jti are REQUIRED.¶
Every Intent Token MUST be bound to a time-bounded shard. Default window 512 seconds. Expired shards MUST be rejected.¶
Delegating agents MUST issue sub-tokens with scope that is a strict subset of their own. The delegation_chain array MUST include all prior delegation records.¶
This revision extends Intent Token binding to four scales simultaneously:¶
The fractal structure is self-similar: the same token schema, cryptographic requirements, and enforcement rules apply at every scale. An IBA Gate at any level MUST reject tokens whose scope exceeds the authorizing token at the next level up.¶
An Intent Certificate is the persistent audit record of an agent session. MUST contain: principal identity; declared scope; temporal bounds; FCTG endpoint reference; cryptographic hashes of all Intent Tokens; signed summary of all enforcement decisions including SNAP-BACK events.¶
MUST use algorithms from NIST SP 800-57 [NIST-SP-800-57]. MUST support ES256 [RFC7518]. SHOULD support ES384 and EdDSA [RFC8037].¶
The IBA Gate MUST validate the Intent Token BEFORE permitting agent action. Validations MUST include: token signature; token and shard expiry; action matches declared_intent; parameters within bounds; delegation chain validity; jti uniqueness; and ibt_level chain validity (NEW). All validations MUST complete within latency_target_ms (target: 5ms). Empirical analysis [WILLIAMS-2026] confirms this target achievable with caching: 2-3ms base, sub-1ms cached.¶
Validation failure MUST result in: immediate action rejection; SNAP-BACK event recorded in FCTG; structured error returned to agent; no retry without new principal-authorized Intent Token. No partial execution permitted.¶
Every enforcement decision MUST be recorded in the FCTG (Section 10). Each record MUST contain: the Intent Token jti; validation timestamp (nanosecond precision RECOMMENDED); validation result (PASS or SNAP-BACK); cryptographic hash chained to previous record. This satisfies EU AI Act Article 9, MiFID II, FDA Cybersecurity 2023, and HIPAA Security Rule audit requirements.¶
Complementary, not competing. OAuth 2.0 governs access; the Intent Token governs action. Compliant implementation: agent obtains OAuth 2.0 access token; principal issues Intent Token; IBA Gate validates Intent Token before action.¶
Google DeepMind introduced DCTs [DEEPMIND-DCT] on February 12, 2026, seven days after the IBA patent filing. DCTs govern delegation scope; the Intent Token governs action authorization at the moment of execution. Complementary primitives.¶
The Intent Certificate MAY be expressed as a W3C Verifiable Credential [W3C-VC] for interoperability with decentralized identity infrastructure.¶
Orchestration systems route tasks to agents. The Intent Token governs what those agents are authorized to do. These are orthogonal functions. A compliant deployment provides: (a) dynamic routing to the best available model, and (b) cryptographic enforcement of action authorization regardless of which model was selected.¶
When the orchestrating system substitutes one agent for another, the Intent Token framework handles this via FCTG branching (Section 10.4) and Authorization Fluidity mode transitions (Section 9.2). The audit trail is maintained across agent substitution events.¶
Intent Token implementations MUST defend against: replay attacks (jti uniqueness cache); token forgery (key verification and rotation); scope inflation (delegation chain verification at each link, extended to cross-scale in Section 4.5); prompt injection (before-action binding blocks out-of-scope actions regardless of manipulation source); mode manipulation (all mode transitions MUST be principal-authorized and FCTG-recorded); FCTG integrity (append-only, Merkle roots provide tamper evidence).¶
Mode transitions MUST: (a) record transition decision as signed FCTG node before new mode takes effect; (b) maintain unbroken audit trail via FCTG branching (Section 10.4); (c) require principal authorization for STATIC-to-RECURSIVE transitions; (d) complete within latency_target_ms.¶
The IBA Gate MUST implement: a Classifier monitoring agent action patterns and system state; Human-in-the-Loop Validation suspending action and requesting principal confirmation under ambiguous or novel conditions; and optionally a Meta-Agent monitoring classifier performance across multiple IBA Gates. Crisis classification latency MUST be within latency_target_ms. Classification decisions MUST be FCTG-recorded.¶
The FCTG replaces the WitnessBound Audit Chain as the normative audit data structure. It is backward-compatible: a linear WitnessBound chain is a degenerate FCTG with no branching.¶
Each FCTG node MUST contain:¶
The before-action binding invariant MUST be maintained at every FCTG node regardless of authorization mode. Continuous flow increases the frequency of discrete binding events; it does not eliminate them.¶
FCTG implementations MUST support historical audit queries at all four authorization scales. Implementations MAY use Merkle tree indexing for O(log n) complexity. When Merkle indexing is used: roots MUST be anchored at agent and cluster levels; proofs MUST be available for cross-scale queries; roots MUST be updated at mode transition boundaries; storage overhead is O(k log n). Localized skip-list augmentation within FCTG subtrees is permitted. A global skip-list is NOT RECOMMENDED due to the non-linear fractal graph structure.¶
On mode transition, the FCTG MUST: (a) create new branch at transition boundary; (b) seal previous branch with terminal signature over branch root Merkle hash; (c) link new branch via parent_id; (d) record transition as signed node with action "mode_transition". A verifier MUST traverse complete history across all transitions via parent_id links.¶
WitnessBound Audit Chain from -00 Section 6.3 is superseded. "audit_chain" MAY reference either endpoint. "ibt_ver" "1.0" implies WitnessBound; "1.1" implies FCTG.¶
Since GB2603013.0 (February 5, 2026), multiple independent research programs have converged on the same authorization gap:¶
This convergence confirms the authorization gap is real and that standardization is timely.¶
The extensions in this revision were developed through an eight-round RSI research chain on RSIForge.com with Human-in-the-Loop methodology [WILLIAMS-2026], peer-reviewed by Grok (xAI) across all eight rounds. Key findings: Authorization Fluidity (no single mode wins all regimes); Meta-Agent (emergent oversight appeared unprompted); FCTG (emerged from audit trail continuity analysis); sub-5ms latency confirmed achievable with caching.¶
Two empirical gaps remain requiring production data: novelty rate of authorization transitions, and FCTG long-term coherence at scale.¶
This document requests registration of the "intent+jwt" media type and the following JWT claims: "ibt_ver", "ibt_level", "parent_token_jti", "principal", "declared_intent", "shard", "enforcement".¶