]> Independent

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

Security authorization autonomous agents intent token IBA multi-agent AI governance 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.

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). 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 (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 (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 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 Section 4.5.

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

shard:

MUST include "id", "issued_at", "expires_at", "window_seconds".

enforcement:

MUST include "snap_back" (true), "audit_chain" (FCTG URI), "auth_mode" (NEW).

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. 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 confirms this target achievable with caching: 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 (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.

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, seven 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 (Section 10.4) and Authorization Fluidity mode transitions (Section 9.2). 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 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).

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 (Section 10.4); (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 Section 6.3 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 (February 5, 2026), multiple independent research programs have converged on the same authorization gap:

• Google DeepMind DCTs : February 12, 2026 (7 days after IBA filing)
• Mastercard Verifiable Intent: February 2026 (~23 days after IBA priority date)
• Sakana AI Fugu Ultra : June 2026 -- exposes the authorization gap in production orchestration

This convergence confirms the authorization gap is real and that standardization is timely.

Empirical Validation (NEW) The extensions in this revision were developed through an eight-round RSI research chain on RSIForge.com with Human-in-the-Loop methodology , 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.

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 NIST Informative References Google DeepMind Sakana AI

Change Log

Changes from -00 to -01

• 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