]> Independent

Chiang Mai Thailand urls@live.com https://intentbound.com

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. Revision -01 extended 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 revision (-02) corrects the stated patent priority date and dependent date references carried over from -01, adds a fourth documented instance of independent convergence (Broadcom's AgentMinder), and revises the characterization of AI-assisted development work in for accuracy.

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 10 February 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 . The extensions address authorization at multiple scales simultaneously (), context-sensitive mode switching (), and a new normative audit trail data structure (). Independent convergence on the authorization gap was observed in Google DeepMind's Delegation Capability Tokens (February 12, 2026), Mastercard's Verifiable Intent framework (March 5, 2026), Broadcom's AgentMinder (August 31, 2026), and the authorization gap exposed by Sakana AI's Fugu Ultra orchestration system (June 2026). 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 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.

Principal:

The human or organizational entity whose declared intent authorizes the agent action. 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. Default window 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. 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.

FCTG:

Fractal Crypto-Temporal Graph. The normative audit trail data structure introduced in this revision (-01).

Authorization Fluidity:

The capacity for an IBA Gate to switch between authorization modes (STATIC, ADAPTIVE, RECURSIVE) while maintaining cryptographic continuity of the audit trail.

WitnessBound Audit Chain:

The append-only audit record defined in -00. Superseded by the FCTG. Linear audit chains are a degenerate case of the FCTG.

Problem Statement

The Authorization Gap Beyond OAuth 2.0 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.

The Delegation Depth Problem Modern autonomous agent architectures are hierarchical. Existing delegation frameworks, including OAuth 2.0 Token Exchange , 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 in Autonomous Systems The confused deputy problem 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.

The Intent Token

Token Structure An Intent Token is a JSON Web Token with "typ": "intent+jwt". The "ibt_ver" claim is "1.1" in this revision.

Required Claims

ibt_ver:

Version "1.1" for this revision.

ibt_level (NEW):

MUST be one of "agent", "cluster", "system", or "federation". See .

parent_token_jti (NEW):

The jti of the authorizing token at the next higher scale. REQUIRED for "agent" and "cluster" level tokens.

principal:

MUST include "id" (URI) and "type" ("human" or "organization").

declared_intent:

MUST include "action_class" and "scope".

Temporal Scope and Shard Binding Every Intent Token MUST be bound to a time-bounded shard. Default window 512 seconds. Expired shards MUST be rejected.

Delegation Chain Encoding 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.

Fractal Intent Token (FIT) Binding (NEW) This revision extends Intent Token binding to four scales simultaneously:

Agent Level:

Existing single-agent binding as specified in Sections 4.1-4.4.

Cluster Level:

A Cluster Intent Token (CIT) binds the collective scope of a coordinated agent group. Individual agent tokens MUST be subsets of the CIT.

System Level:

A System Intent Token (SIT) binds the global deployment policy. CITs MUST be subsets of the SIT.

Cross-System Level:

A Federation Intent Token (FedIT) enables cross- organizational authorization. OPTIONAL, requires bilateral trust establishment.

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.

Intent Certificate 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 . MUST support ES256 . SHOULD support ES384 and EdDSA .

Enforcement Binding

Pre-Action Validation 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 indicates this target is achievable with caching in the tested implementation: 2-3ms base, sub-1ms cached.

SNAP-BACK on Violation 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.

Audit Chain Requirements Every enforcement decision MUST be recorded in the FCTG (). 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 is intended to support audit requirements such as those found in the EU AI Act Article 9, MiFID II, FDA Cybersecurity 2023, and HIPAA Security Rule; conformance with any specific regulatory regime has not been independently assessed.

Interoperability

Relationship to OAuth 2.0 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.

Relationship to Delegation Capability Tokens Google DeepMind introduced DCTs on February 12, 2026, two days after the IBA patent filing. DCTs govern delegation scope; the Intent Token governs action authorization at the moment of execution. Complementary primitives.

Relationship to W3C Verifiable Credentials The Intent Certificate MAY be expressed as a W3C Verifiable Credential for interoperability with decentralized identity infrastructure.

Relationship to Multi-Agent Orchestration Systems (NEW) 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 () and Authorization Fluidity mode transitions (). The audit trail is maintained across agent substitution events.

Security Considerations 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 ); 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).

Authorization Fluidity (NEW)

Authorization Modes

STATIC:

Fixed rules. Pre-declared scope does not change during session. Default mode. MUST be used when conditions are stable.

ADAPTIVE:

Scope may be updated by principal. Each update MUST be cryptographically signed and FCTG-recorded. IBA Gate applies most recently signed scope.

RECURSIVE:

Scope recursively refined through multiple principal confirmation rounds. REQUIRED in crisis conditions.

Mode Transitions Mode transitions MUST: (a) record transition decision as signed FCTG node before new mode takes effect; (b) maintain unbroken audit trail via FCTG branching (); (c) require principal authorization for STATIC-to-RECURSIVE transitions; (d) complete within latency_target_ms.

Crisis Detection 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.

Fractal Crypto-Temporal Graph (FCTG) (NEW) 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.

Node Structure Each FCTG node MUST contain:

event_id:

UUID uniquely identifying this authorization event. REQUIRED.

agent_id:

Agent identifier. REQUIRED. MUST match "sub" claim of associated Intent Token.

action:

Action class being authorized. REQUIRED. MUST match declared_intent.action_class.

timestamp:

Nanosecond-precision timestamp. REQUIRED. MUST be recorded before agent action executes.

cryptographic_signature:

ES256 signature over concatenation of event_id, agent_id, action, and timestamp. REQUIRED. MUST be computed and verified before agent action executes. This constitutes the cryptographic before-action binding.

parent_id:

event_id of immediately preceding node. REQUIRED except for root nodes.

ibt_level: Authorization scale of this node. REQUIRED. mode: Authorization mode active at time of this event. REQUIRED.

Before-Action Binding in Continuous Flow 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.

Query Performance 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.

Mode Transition Handling 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.

Relationship to WitnessBound Audit Chain WitnessBound Audit Chain from -00 is superseded. "audit_chain" MAY reference either endpoint. "ibt_ver" "1.0" implies WitnessBound; "1.1" implies FCTG.

Convergent Independent Development (NEW) Since GB2603013.0 (10 February 2026), multiple independent research programs and commercial platforms have converged on the same authorization gap:

• Google DeepMind DCTs : February 12, 2026 (2 days after IBA filing)
• Mastercard Verifiable Intent : March 5, 2026 (~23 days after IBA priority date)
• Sakana AI Fugu Ultra : June 2026 -- exposes the authorization gap in production orchestration
• Broadcom AgentMinder: August 31, 2026 -- requires every agent to declare intent, not just identity, before it can act on enterprise systems, binding that declared intent to permitted tools and authorized resources at runtime

This convergence is offered as evidence that the underlying authorization gap is real and independently recognized across research and industry; it is not offered as evidence of technical equivalence between these systems and the Intent Token specification.

Empirical Validation (NEW) The extensions in this revision were developed through an eight-round research process on RSIForge.com using a Human-in-the-Loop methodology , with iterative feedback from Grok (xAI) obtained across all eight rounds. This feedback was conversational in nature and does not constitute formal peer review; no independent, credentialed review of these extensions has been conducted to date. Key findings from this process: Authorization Fluidity (no single mode wins all regimes); Meta-Agent (emergent oversight appeared unprompted); FCTG (emerged from audit trail continuity analysis); sub-5ms latency indicated as achievable with caching in the tested implementation. Two empirical gaps remain requiring production data: novelty rate of authorization transitions, and FCTG long-term coherence at scale.

IANA Considerations 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".

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. NIST Informative References Google DeepMind Mastercard This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Sakana AI

Log -01 to -02 revisions:

• Corrected patent priority date throughout from "February 5, 2026" to "10 February 2026" (Sections 1, 11), matching the official UK IPO Electronic Filing Receipt for GB2603013.0
• Corrected Mastercard Verifiable Intent announcement date from "February 2026" to "March 5, 2026" (Sections 1, 11); the previously stated "~23 days after IBA priority date" figure was independently correct and is unchanged
• Corrected the DeepMind DCT gap from "seven days after the IBA patent filing" to "two days after" (Sections 1, 7.2, 11), consistent with the corrected priority date
• Added Broadcom AgentMinder (August 31, 2026) as a fourth documented instance of independent convergence (Sections 1, 11)
• Added entry to Informative References, resolving a reference cited in the -01 Change Log but not previously defined in the bibliography
• Revised to describe Grok (xAI) involvement as iterative conversational feedback rather than "peer review," and added an explicit statement that no independent, credentialed review has been conducted
• Softened 's regulatory-compliance claim from stating the audit chain "satisfies" named regulatory requirements to stating it is "intended to support" them, noting conformance has not been independently assessed
• Softened and 12 latency claims from "confirmed achievable" to "indicated as achievable... in the tested implementation"
• Resolved an internal inconsistency between two different expiry dates stated in -01

-00 to -01 revisions:

• Added "ibt_level" claim (REQUIRED) for fractal scale identification
• Added "parent_token_jti" claim for cross-scale chain verification
• Added "auth_mode" field to enforcement object
• Updated "ibt_ver" from "1.0" to "1.1"
• Added Section 4.5: Fractal Intent Token (FIT) Binding
• Added Section 7.4: Relationship to Multi-Agent Orchestration Systems
• Added Section 9: Authorization Fluidity
• Added Section 10: Fractal Crypto-Temporal Graph (FCTG)
• Added Section 11: Convergent Independent Development
• Added Section 12: Empirical Validation
• Updated Sections 6.1, 6.2, 6.3 to reference FCTG
• Added references: WILLIAMS-2026, SAKANA-FUGU, MASTERCARD-VI