| Internet-Draft | AIIP Architecture | March 2026 |
| Sogomonian | Expires 27 September 2026 | [Page] |
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.¶
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 27 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 Internet has historically been optimized for human interaction, document retrieval, and request-response semantics. Autonomous systems, however, require a different access model, one focused on delegated execution, safety boundaries, and post-execution accountability.¶
AIIP provides a uniform architectural model for invoking and executing actions by autonomous systems with verifiable outcomes. The architecture follows a resolve-invoke-execute-receipt pattern.¶
Native AIIP communication is designed for machine-to-machine operation and does not assume HTTP semantics, browser compatibility, or synchronous request-response behavior. HTTPS gateways are optional and non-authoritative.¶
From the perspective of autonomous systems, AIIP functions as a native entry point to Internet capabilities, separate from the human-oriented Web access model.¶
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.¶
AIIP defines:¶
AIIP explicitly does NOT define:¶
AIIP defines a distinct autonomous access plane for execution-capable systems. This access plane is separate from the human-oriented Web and independent of control-plane or discovery mechanisms.¶
An AIIP access point is a network-visible execution interface that accepts invocation requests, validates authorization, performs or brokers execution, and produces verifiable execution receipts.¶
AIIP provides a distinct network access model for autonomous systems. In this model, autonomous systems interact through AIIP-native invocation and execution semantics rather than through HTTP-based interfaces designed primarily for human users.¶
The AIIP autonomous access plane begins at invocation and ends at execution receipt generation. Any function operating entirely outside this boundary is outside the scope of AIIP.¶
AIIP does not extend HTTP. It defines a native, machine-oriented execution plane that may be carried over authenticated transports such as TLS [RFC8446] or QUIC [RFC9000].¶
AIIP is designed to coexist with discovery, registration, policy, and orchestration mechanisms, which may provide inputs to AIIP without constraining its execution semantics.¶
AIIP occupies a distinct architectural layer between higher-level autonomous decision logic and authenticated transport. This can be expressed conceptually as follows:¶
Discovery and registration mechanisms may provide identifiers, endpoints, or trust material consumed by AIIP, but AIIP does not depend on their semantics.¶
AIIP follows a resolve-invoke-execute-receipt pattern.¶
Prior to invocation, an autonomous system may obtain an execution target, access point identifier, trust material, or delegation grant by means outside the scope of this specification.¶
The invoking system submits a cryptographically authenticated request to attempt an action under a delegation grant.¶
AIIP assumes that execution attempts occur under delegated authority. A delegation grant authorizes an autonomous system to attempt specific actions against a defined scope under stated constraints.¶
Delegation grants SHOULD be narrowly scoped, time-limited, and bound to an identified subject. Implementations MAY include additional constraints such as maximum executions, time windows, geographic restrictions, or environmental preconditions.¶
Grant encoding and distribution are out of scope for this document. However, the architecture assumes that the executing environment is able to verify grant authenticity and applicability before execution.¶
An invocation is a cryptographically authenticated request to attempt an action under a delegation grant.¶
An invocation message typically includes a target identifier, an action, input parameters, a delegation grant or reference to one, and cryptographic metadata such as timestamps, nonces, or signatures. The exact encoding is out of scope for this document.¶
Execution is the successful completion of a state-changing operation by the target environment.¶
AIIP defines the sole architectural boundary at which autonomous execution is recognized. An action lacking a valid AIIP execution receipt MUST NOT be treated as executed for protocol purposes.¶
Each successful execution MUST produce an execution receipt. A failed execution attempt MAY also produce a signed receipt or equivalent verifiable outcome record.¶
Receipts provide cryptographic evidence that an execution occurred, together with the execution outcome as determined by the executing environment.¶
A receipt typically includes an invocation reference, execution status, result commitment such as a hash, timestamp, identity of the executing environment, and a cryptographic signature.¶
Receipts enable auditability, compliance, dispute resolution, and post hoc verification.¶
Receipt encoding is out of scope for this document. Semantic validity is independent of serialization format.¶
Receipt validity MUST NOT depend on field ordering, whitespace, presentation details, or other serialization artifacts.¶
AIIP messages MUST be carried over an authenticated transport or protected by equivalent cryptographic mechanisms that provide peer authentication, integrity protection, and confidentiality appropriate to the deployment environment.¶
This document does not define a mandatory single transport binding. Example transports include TLS [RFC8446] and QUIC [RFC9000]. Future specifications may define concrete bindings and negotiation behavior.¶
Transport success alone does not constitute execution. Protocol-level recognition of execution depends on receipt generation and validation.¶
AIIP supports authorized execution in the absence of continuous connectivity. Offline operation represents execution under pre-authorized constraints, not deferred transmission or request caching.¶
Implementations supporting offline execution SHOULD bound that capability using explicit validity intervals, execution limits, environmental constraints, or comparable controls.¶
Execution receipts generated during offline operation MUST remain verifiable once connectivity is restored.¶
AIIP gateways MAY translate between AIIP and non-AIIP systems, including HTTP-based systems.¶
Gateways are non-authoritative with respect to execution. A gateway MUST NOT alter the semantic content of a receipt and MUST NOT claim that transport delivery alone is equivalent to execution.¶
Unless explicitly acting as the execution environment itself, a gateway MUST NOT generate an authoritative execution receipt on behalf of a different execution environment.¶
Future work may define concrete transport bindings, receipt encodings, deployment profiles, registries, media types, URI schemes, or other operational extensions needed to support interoperable AIIP deployments.¶
Such extensions require separate specification and community review.¶
AIIP relies on authenticated transports and cryptographic mechanisms to provide integrity, authenticity, and non-repudiation properties for invocations and execution receipts.¶
Implementations MUST consider threats including replay of invocation messages, forgery or misuse of delegation grants, impersonation of invoking agents or execution environments, tampering with receipts or result commitments, abuse of offline execution authority beyond its intended scope, and unauthorized modification or observation by intermediary systems.¶
Implementations SHOULD use nonces, timestamps, audience restriction, narrow grant scope, expiration controls, and cryptographic signatures to mitigate replay and forgery risks.¶
Execution environments MUST verify that the presented authorization is applicable to the requested action and target before execution.¶
Because gateways are non-authoritative, trust decisions MUST be bound to the actual execution environment and its receipt rather than to an intermediary that merely relays or translates requests.¶
AIIP deployments can expose information about agent identity, delegated authority, execution timing, execution targets, and action outcomes. Correlation of receipts or invocation metadata across contexts can reveal behavior patterns even when payload content is protected.¶
Implementations SHOULD minimize unnecessary disclosure, limit retained metadata, and apply data minimization principles to both invocations and receipts. Deployments MAY use privacy-enhancing techniques such as selective disclosure, compartmentalized identifiers, or zero-knowledge mechanisms where suitable.¶
This document has no IANA actions.¶