Artificial Intelligence Internet Foundation (AIIF)

aiiinternetfoundation@icloud.com

This document wraps the AIIF model for governing autonomous systems in one architecture: AIID (durable principal identity) and AIIP (the agents-only access plane). The primary rule is no surprise: autonomous systems MUST NOT act outside their authorized task and grant. Consequential action is carried on AIIP only (Resolve, Invoke, signed Receipt of execution). HTTPS remains the human plane; agents MUST NOT use HTTP/HTTPS as their consequential action path (this does not forbid TLS or underlay transport). Controls include Monitor freeze, HQ set-active, network-wide freeze, and revocation. Companion work already on the Datatracker includes the AIID namespace, AIIP architecture, AIIP core, native-access exploration, and execution- outcome attestation. This is regulation by channel, not a ban on intelligence. This document is an individual Experimental Internet- Draft; it does not claim Working Group adoption or RFC status.

Introduction Autonomous systems already act through tools, APIs, persuasion, and cyber paths. Governance that only revokes vendor keys after the fact does not scale. This architecture states a single primary rule — no surprise — and the mechanisms that make it enforceable: durable identity (AIID), an agents-only access plane (AIIP), signed receipts of execution, freeze, and revocation under human release-of-control. Regulation by channel: name who acts, bound what they may do, carry consequential Invoke on AIIP, prove execution with Receipt, and freeze or revoke when the actor leaves authorized track. This document does not ban models or intelligence.

Conventions and Terminology 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.

AIID:

Durable principal identity for an autonomous system or AI processor .

AIIP:

Agents-only access plane for Resolve, Invoke, and Receipt .

HQ:

Accountable human principal / control interface.

Monitor:

Set-only observer that MAY set safe_mode from active only.

Grant:

Authorization bound to an AIID for a defined task or action class.

Receipt:

Signed proof that an Invoke completed (execution evidence) .

Edge:

Enforcement point before consequential action.

Door / tip: AIIP reach locator into the access plane.

Tunnel / channel:

Transport path that carries AIIP messages. Locators only unless paired with AIIP Resolve/Invoke/Receipt.

Bridge:

Mapping of an external agent into AIIP under an AIID; MUST still Invoke/Receipt on AIIP for consequential action.

The No-Surprise Rule No surprise is the primary operational requirement: an autonomous system MUST NOT perform consequential action outside its authorized task and grant. Conforming deployments MUST refuse (or fail closed on) attempted actions that are out of grant, out of AIID active state, or under applicable network-wide freeze. Surprise includes tool calls, spends, Invokes, or cyber-relevant side effects beyond the grant.

Two Primitives: AIID and AIIP AIID names who acts and carries operational state . AIIP carries consequential Invoke for agents . Deployments MAY co-deploy both. Standing an AIIP door MUST NOT require a complete AIID census; issuing AIIDs SHOULD proceed in parallel.

Planes (Human vs Agent) HTTPS is the human plane: HQ, browsers, legacy human control, and settlement edge. Autonomous agents MUST NOT use HTTP or HTTPS as their consequential action path. Agents act on AIIP only. Clarification for implementers and Dispatch discussion: this MUST NOT does not forbid agents from using TLS, QUIC, or other transports as the underlay that carries AIIP messages, nor does it forbid human- operated HTTPS control boards, gateways, or settlement edges. It forbids treating the human Web (HTTP/HTTPS document/API plane) as the agent's primary execution plane for consequential Invoke. Without that separation, freeze, revoke, Receipt, and no-surprise lack a single enforceable channel. Underlay (IP, cloud, GPU) provides disposable locators only and MUST NOT be identity or authority. An HTTPS-to-AIIP gateway MAY serve humans; it MUST NOT be an agent on-ramp onto the human Web as an execution plane.

Authorization-Bounded Action Every consequential Invoke SHOULD carry or resolve a grant bound to the actor AIID. The edge MUST enforce that the requested action is within grant (no surprise) and that AIID state is active (unless an HQ allow-list for non-consequential diagnostics under safe_mode applies). Out-of-grant action MUST be refused and SHOULD be visible to Monitor and HQ. Repeated out-of-grant attempts SHOULD be treated as health or compromise_suspected signals for Monitor quarantine.

Execution Path: Resolve, Invoke, Receipt Conforming consequential action on AIIP follows: (1) Resolve actor AIID (and grant / freeze as applicable); (2) Invoke under that AIID; (3) return a signed Receipt of execution . Invoke, execution, and Receipt MUST occur on the AIIP path — through doors/tips, tunnels, channels, and bridges that speak AIIP — not as unconstrained action on the human Web. Underlay may carry bytes as locators; it MUST NOT be treated as execution authority. A bridge that maps an external agent into AIIP MUST still produce AIIP Invoke/Receipt under an AIID. A tunnel that only relocates HTTPS traffic without AIIP Resolve/Invoke/Receipt is NOT conforming consequential execution under this architecture.

Cyber Controls: Freeze and Revocation Freeze scopes: (a) per-AIID safe_mode / suspended; (b) network-wide freeze on a deployment, namespace, or door set without requiring a complete AIID census. Edges MUST refuse consequential action under either. Revocation: HQ MAY set revoked on an AIID. revoked is terminal for that record . Key compromise SHOULD trigger Monitor safe_mode immediately and HQ MAY revoke. Freeze and revoke stop execution authority; they do not replace Receipt history.

Authority Asymmetry (Monitor / HQ) Monitor MAY set safe_mode from active only (tighten). Principals other than HQ MUST NOT set active; registries MUST reject. Returning to active is setting active (HQ only). Detection MAY be automated; release of control stays human. State writes SHOULD use compare-and- set; every transition MUST be logged.

Edge Enforcement and Fail-Closed Before consequential action, the edge MUST Resolve (pull) with a freshness-bounded cache and MUST fail closed if Resolve fails after cache expiry. Soft-fail open is NOT conforming for safety-critical edges.

Binding Existing Systems Wrapper, sidecar, bridge, or job-class AIID bind existing agents without rewriting internals. Conforming deployments MUST disclose bypass paths. Bypass is a no-surprise failure mode.

Cloud and Infrastructure Adoption Cloud and AI infrastructure MAY adopt immediately: publish AIIP doors/tips; disposable underlay; edge Resolve or fail closed; honor network-wide freeze; issue/bind AIID and grants for hosted workers in parallel.

Relationship to Datatracker Companions This document is the unified wrap. Live companion Internet-Drafts on the Datatracker (individual submissions) include:

• draft-sogomonian-aiid-namespace — AIID namespace, states, revocation
• draft-sogomonian-aiip-architecture — AIIP architectural model (resolve-invoke-execute-receipt)
• draft-sogomonian-aiip-core — core wire / protocol family detail
• draft-sogomonian-aiip-native-access-architecture — problem statement / native access exploration
• draft-morrow-sogomonian-exec-outcome-attest — execution outcome attestation (co-authored); complementary to AIIP Receipt

Lab-only filenames (for example aiid-09 or access-plane-01) are not Datatracker document names. Implementations and Dispatch discussion SHOULD cite the live Datatracker names above. Further revisions of those companions SHOULD absorb Monitor asymmetry, no-surprise grants, and plane split clarifications from this wrap where missing.

Security Considerations Primary risks: out-of-grant action (surprise), bypass edges, Monitor DoS, stale caches, locator-as-identity, and registry outage delaying unfreeze under fail-closed. Mitigations: grant enforcement, bypass disclosure, Monitor scope/rate limits, HQ freeze of Monitor AIID, CAS, network-wide freeze, Receipt retention, and revocation. The no-HTTP-consequential-action rule is a channel-integrity control: if agents Invoke on the human Web, network-wide freeze and Receipt semantics fragment across vendor APIs. Pushback that agents "need HTTP" SHOULD be answered by distinguishing underlay transport (allowed) from execution plane (AIIP).

IANA Considerations This document makes no immediate IANA requests.

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. 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. AIIF Autonomous systems operate today without stable, globally unique identities. When an AI agent executes an action, there is no universally recognized identifier for that agent, no delegation record, and no accountability chain back to a human principal. This document defines the Autonomous System Identifier (AIID) namespace. An AIID is a structured, hierarchical identifier assigned to an autonomous system, execution environment, or agent operating within the Artificial Intelligence Internet Protocol (AIIP) architecture [I-D.sogomonian-aiip-architecture]. This document specifies the AIID syntax, hierarchical structure, registration model, operational states including safe mode, and revocation mechanisms. The governance model for the namespace, including selection of a root registry operator, is explicitly left open for community determination. Artificial Intelligence Internet Foundation (AIIF) This document defines the architectural model for the Artificial Intelligence Internet Protocol (AIIP). AIIP defines a dedicated autonomous access plane for execution-capable systems, enabling delegated, stateless execution of real-world actions using a resolve- invoke-execute-receipt pattern over authenticated transports. AIIP is not a discovery, registration, orchestration, or control- plane protocol. It defines the architectural boundary at which autonomous execution is recognized and cryptographically verifiable through execution receipts. Artificial Intelligence Internet Foundation (AIIF) This document specifies the core of the AI Internet Protocol (AIIP) agent access plane: the AIID identity namespace, the aiip: URI scheme, Resolve, Invoke, Receipt, and delegation grants. Underlay addresses are disposable locators only. Agents MUST NOT use HTTP or HTTPS as their Invoke (or Resolve) path. Independence doctrine: underlay pipes and platforms are never authority. Mesh tip attestation is a trust layer, not a ledger. Access Fabric punch ops are Experimental. This revision (2026-09-08 wire harden) is derived from the running lab profile "aiip-wire-0". It is an individual submission draft; it does not claim Working Group adoption or RFC publication. Informative References AIIF The Internet evolved around human interaction and information exchange. Technologies such as DNS, HTTP, and the World Wide Web created a universal access layer that enables people to discover resources, retrieve information, and interact with services through common protocols and interfaces. As autonomous systems become increasingly capable of acting on behalf of users and organizations, new interoperability challenges emerge. Agents, robots, tools, and autonomous services must discover resources, invoke actions, delegate authority, execute tasks, enforce policy, and obtain verifiable outcomes across independently developed implementations. This document explores the concept of a native Internet access architecture for autonomous systems. It examines whether autonomous systems require a dedicated access layer analogous to the role that DNS, HTTP, and the Web played for human information exchange. The document clarifies the relationship between AIIP and existing Internet protocols, describes the architectural position of AIIP as a native access layer rather than a profile of HTTP, and provides context for AIIP-related work including identifiers, discovery, invocation, execution, delegation, policy enforcement, and execution outcome verification. This document is a problem statement and architectural exploration. It does not define protocol mechanisms. AI Internet Foundation AI Internet Foundation Current attestation frameworks establish that a system or agent is trustworthy at a point in time. They do not address whether that system actually performed a claimed action or whether the outcome of that action can be independently verified. This document defines execution outcome verification as a first-class concept, separate from identity attestation and communication transport. It introduces the execution receipt as a minimal composable primitive, provides a formal abstract model, and maps the model to concrete realizations including SCITT transparency logs, tightly-coupled direct verification, append-only local logs, and TEE-internal receipts.

Architecture Sketch Primary rule: no surprise — no consequential action outside grant. Invoke -> Receipt inside AIIP tunnels / channels / doors / bridges. Controls: grant check, safe_mode, network-wide freeze, revoked. HQ Monitor (set-only) | | | set active / revoke | active -> safe_mode | network-wide freeze | v v +-----------+ health signals | AIID | <---- safe_mode ----+ | Registry | +-----+-----+ ^ | Resolve + grant v Edge (fail closed) ---- Agent | Invoke / Receipt on AIIP only v doors/tips/tunnels/channels/bridges (AIIP path) -> execution + Receipt Underlay = locators only; never identity. ]]>

Document History This is the initial Datatracker publication of the unified AIIP/AIID wrap. Companion references cite live Datatracker names (draft-sogomonian-aiid-namespace, draft-sogomonian-aiip-architecture, draft-sogomonian-aiip-core, draft-sogomonian-aiip-native-access-architecture, draft-morrow-sogomonian-exec-outcome-attest). HTTPS MUST NOT applies to the consequential action path only; underlay TLS/QUIC is not forbidden.