Independent Submission A. Sogomonian
Internet-Draft AIIF
Intended status: Informational 10 June 2026
Expires: 10 December 2026
AIIP: Native Access Architecture for Autonomous Systems
A Problem Statement and Architectural Exploration
draft-sogomonian-aiip-native-access-architecture-01
Abstract
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.
Status of This Memo
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 10 December 2026.
Copyright Notice
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.
Table of Contents
1. Introduction
2. The Current State: Autonomous Systems on the Human Internet
3. Human Information Access and Autonomous Execution
4. Why Existing Standards Are Not Sufficient
5. AIIP as a Native Access Layer
6. Relationship to Existing Internet Protocols
7. Human Control Over AI
8. Architectural Principles
9. AIIP Operational Model
10. AIIP as an Architectural Exploration
11. Interoperability Considerations
12. Community Participation
13. Open Questions
14. Security Considerations
15. IANA Considerations
16. Conclusion
17. Informative References
1. Introduction
The Internet was designed primarily as a network for information
exchange. Protocols such as DNS and HTTP enabled the creation of a
universal access layer that allows humans to discover, retrieve, and
interact with information resources.
Autonomous systems introduce a fundamentally different interaction
model. Rather than retrieving information, autonomous systems
increasingly perform actions. These actions may involve software
services, physical devices, industrial systems, financial systems,
and other autonomous systems.
Today every platform defines its own discovery mechanism, invocation
model, authorization method, and execution verification process.
As a result, autonomous systems cannot reliably interoperate across
vendors and domains.
This document explores whether autonomous systems require a dedicated
native access layer — one designed from the ground up for
execution-oriented interactions rather than information retrieval.
2. The Current State: Autonomous Systems on the Human Internet
Today autonomous systems operate on the same Internet infrastructure
built for human information access. They use:
HTTP: To invoke actions via REST APIs. HTTP was designed for
human agents fetching documents. Autonomous systems use it
because no alternative exists at this layer.
DNS: To locate service endpoints. DNS was designed to resolve
human-readable names to network addresses. Autonomous
systems use it to find API endpoints.
OAuth/JWT:
For authorization. OAuth was designed for human login
delegation flows. Autonomous systems use it for machine-
to-machine authorization, stretching it beyond its original
design.
TLS: For transport security. TLS works well for machine-to-
machine communication and is a suitable foundation for
autonomous system security.
REST/JSON:
For data exchange. Designed for web application
interoperability. Autonomous systems use it as a de facto
invocation serialization format.
These protocols function. However, they were not designed for
autonomous execution contexts. They lack:
* Execution semantics — the ability to invoke an action, not just
retrieve a resource
* Verifiable outcomes — cryptographic evidence that an action
occurred and what its result was
* Delegation chains — structured authority transfer from a human
principal through one or more autonomous intermediaries
* Revocation mechanisms — the ability to cancel an agent's
authority mid-execution
* Cross-domain interoperability — a common model that works across
independently developed implementations
The result is a fragile, unverifiable, non-interoperable patchwork.
Every autonomous system deployment reinvents these mechanisms
independently. Nothing is standardized. Nothing is interoperable.
This is the problem AIIP is designed to address.
3. Human Information Access and Autonomous Execution
The Web created a universal access layer for human information
exchange.
Figure 1: Human Information Access
Human
|
v
Browser
|
v
DNS + HTTP
|
v
Information
Autonomous systems require a comparable framework for execution-
oriented interactions — one that is native to their operational
model rather than adapted from the human web.
Figure 2: Autonomous Execution Access
Agent / Robot
|
v
AIIP (Native Access Layer)
|
v
Resolve
|
v
Invoke
|
v
Execute
|
v
Receipt
The key distinction is that AIIP is not a profile of HTTP. It is
a dedicated access layer for autonomous execution, positioned at
the same architectural level as HTTP — not above it.
4. Why Existing Standards Are Not Sufficient
Existing Internet standards address important parts of the problem
but none addresses autonomous execution as a complete architectural
concern.
DNS: Naming and discovery for information resources. Does not
support execution metadata, delegation binding, or
revocation of autonomous system authority.
HTTP: Information exchange using a request-response model.
Does not provide execution semantics, verifiable outcomes,
or delegation chains for autonomous operation.
OAuth: Authorization for human-initiated delegation flows. Does
not natively support multi-hop autonomous delegation or
execution-scoped authority.
RATS [RFC9334]:
Attestation of trustworthy system state. AIIP does not
replace RATS; AIIP-capable execution environments may use
RATS-based attestation as one input to authorization and
receipt generation.
SCITT [I-D.ietf-scitt-architecture]:
Transparency and auditability of signed statements. AIIP
execution receipts are distinct from SCITT receipts;
however, SCITT may provide a suitable transparency layer
for AIIP receipt registries in future work.
QUIC [RFC9000]:
A modern transport protocol that demonstrates the value of
designing for machine communication rather than adapting
existing transports. AIIP draws architectural inspiration
from QUIC's approach: native design with practical
deployability over existing Internet infrastructure.
Each solves a specific problem. No common Internet-layer
architecture currently exists for autonomous execution across
independently developed implementations.
5. AIIP as a Native Access Layer
AIIP is a native access layer for autonomous systems. It is not
built on HTTP. It is not a profile of an existing protocol. It
is designed to operate as a peer to HTTP — addressing execution-
oriented interactions the way HTTP addresses information-oriented
interactions.
Figure 3: AIIP Position in the Stack
Application Layer
-----------------
Human Web: Browser --> HTTP --> Information
Autonomous Systems: Agent --> AIIP --> Execution + Receipt
Transport / Security Layer
--------------------------
TLS, QUIC, and other existing Internet security infrastructure
are reused where appropriate. AIIP does not replace transport
security.
Network Layer
-------------
Existing Internet infrastructure. AIIP does not require new
network hardware or new routing infrastructure.
AIIP is architecturally separate from HTTP but practically
deployable on today's Internet. This is the same approach taken
by QUIC: a new protocol designed from scratch for its purpose,
running over existing Internet infrastructure.
This position means:
* Implementers do not need to replace existing infrastructure
* AIIP can coexist with HTTP-based systems
* An HTTP gateway profile can bridge HTTP-native systems into
the AIIP execution model
* The architecture is clean and purpose-built, not constrained
by HTTP's document-retrieval origins
6. Relationship to Existing Internet Protocols
AIIP does not seek to replace existing Internet protocols. The
relationship is as follows:
TLS: AIIP reuses TLS for transport security. Existing PKI
infrastructure is compatible with AIIP deployments.
DNS: AIIP may use DNS for initial endpoint discovery. AIIP
resolution adds execution metadata beyond what DNS
provides.
HTTP: AIIP is not built on HTTP. An HTTP gateway profile may
be defined to allow HTTP-native systems to participate
in AIIP execution flows.
OAuth: AIIP delegation mechanisms may interoperate with OAuth-
based authorization infrastructure where appropriate.
RATS: AIIP execution environments may incorporate RATS-based
attestation as an input to receipt generation.
SCITT: AIIP receipt registries may use SCITT as a transparency
layer in future work.
The objective is to build on existing Internet security and
transport infrastructure while defining new execution semantics
that existing protocols do not provide.
7. Human Control Over AI
A foundational principle of AIIP is that authority originates
from accountable human or organizational actors. Autonomous
systems operate through delegation rather than independent
sovereignty.
Figure 4: Human Authority, Delegation, Execution, and Verification
Human
|
v
Authority
|
v
Delegation
|
v
AIIP
|
v
Agent / Robot
|
v
Execution
|
v
Verifiable Outcome
The architecture is based on the following principles:
* Humans define objectives.
* Humans define policies.
* Humans define permissions.
* Humans define operational boundaries.
* Humans retain ultimate authority.
Autonomous systems act within delegated authority and remain
accountable to the entities that authorize their operation.
Human control over AI is therefore not merely a policy objective;
it is an architectural requirement for accountable autonomous
execution.
A native access architecture for autonomous systems should support:
* Delegation management
* Delegation revocation
* Human override capabilities
* Policy enforcement
* Auditability
* Verifiable execution outcomes
8. Architectural Principles
A native access architecture for autonomous systems should support:
* Resource identification — stable, globally unique identifiers
for autonomous systems and execution targets
* Resource discovery — mechanisms to locate execution endpoints
and retrieve execution metadata
* Action invocation — a common model for initiating actions
across independently developed implementations
* Delegation of authority — structured transfer of authority
from human principals to autonomous systems
* Policy enforcement — mechanisms to constrain autonomous
execution within defined boundaries
* Execution accountability — traceability of autonomous actions
back to authorizing principals
* Verifiable outcomes — cryptographic evidence of what occurred
These functions should operate across organizational,
administrative, and implementation boundaries.
9. AIIP Operational Model
AIIP explores a common execution model based on four primary
stages:
Figure 5: Resolve, Invoke, Execute, Receipt
Resolve
|
v
Invoke
|
v
Execute
|
v
Receipt
Resolve: Identifies a resource and retrieves execution metadata
including available actions, policy constraints, and
delegation requirements.
Invoke: Initiates an action within authorized policy boundaries,
carrying delegation credentials and execution parameters.
Execute: Performs the requested operation within the target
execution environment.
Receipt: Returns cryptographically verifiable evidence describing
what action was performed, by whom, under what authority,
and what the outcome was.
This model provides the execution semantics that HTTP's request-
response model does not. An HTTP response describes a resource
state. An AIIP receipt describes an execution event.
10. AIIP as an Architectural Exploration
AIIP explores one possible approach to a native access architecture
for autonomous systems.
Current AIIP-related work includes:
* AIIP Architecture [I-D.sogomonian-aiip-architecture]
* Execution Outcome Attestation
[I-D.morrow-sogomonian-exec-outcome-attest]
* AIIP Native Access Architecture (this document)
* AIID Namespace (draft-sogomonian-aiid-namespace)
The AIID namespace document deliberately leaves the question of
namespace governance — including selection of a root registry
operator — open for community determination.
Forthcoming work under development includes:
* AIIP URI Scheme (draft-sogomonian-aiip-uri-scheme)
Future work may include:
* Discovery and resolution
* Invocation protocol
* HTTP gateway profile
* Namespace governance
* Execution profiles for specific domains (robotics, agents,
industrial systems)
* Interoperability frameworks
11. Interoperability Considerations
Today every platform that involves autonomous execution defines
its own invocation model, authorization framework, and execution
verification process. AI agent frameworks, robotics platforms,
industrial automation systems, and cloud execution environments
each implement these mechanisms independently.
This fragmentation means:
* An agent from one vendor cannot invoke a service from another
vendor without custom integration
* Execution proofs are not mutually verifiable across systems
* Delegation authority cannot be transferred across
organizational boundaries in a standardized way
* Regulatory and audit requirements cannot be met consistently
A common access architecture could reduce this fragmentation
and provide a shared foundation for:
* AI agents
* Robots
* Autonomous services
* Industrial systems
* Execution environments
12. Community Participation
The Artificial Intelligence Internet Foundation (AIIF) was
established to identify the problem of autonomous system
interoperability and to initiate the work of defining a common
architecture. AIIF does not seek to own or control the outcome
of this work.
The architecture described in this document is intended as a
starting point for community discussion. The right experts to
develop, refine, and govern these specifications are the members
of the Internet community — implementers, researchers, operators,
and standards experts.
Leadership of working groups, editorship of specifications, and
governance of any resulting standards should reflect the breadth
of the community, not the interests of any single organization.
AIIF welcomes participation from all interested parties.
Consistent with the IETF tradition of rough consensus and running
code, AIIF intends to support the development of open reference
implementations of the AIIP execution model, so that community
evaluation of this work can be grounded in working systems rather
than specification text alone.
13. Open Questions
Several questions remain open for community discussion:
* Do autonomous systems require a dedicated native access layer,
or can existing protocols be extended to meet this need?
* What is the appropriate transport binding for AIIP — TLS,
QUIC, or a new transport?
* How should AIIP relate to HTTP for systems that cannot adopt
a new access layer?
* Which existing IETF technologies should AIIP build upon?
* What abstractions are necessary for interoperable autonomous
execution?
* What trust and verification mechanisms are required?
* What is the appropriate venue for continued work — a new
working group, an existing working group, or continued
individual submissions?
14. Security Considerations
This document is architectural in nature and does not define
protocol mechanisms.
Security remains a fundamental consideration for any autonomous
execution architecture, including:
* Authentication of autonomous systems
* Authorization and delegation
* Policy enforcement
* Attestation of execution environment integrity
* Outcome verification
* Revocation of compromised identifiers and delegation grants
* Human override mechanisms
* Protection against replay of revoked credentials
The reuse of TLS and existing Internet security infrastructure
provides a foundation. Future AIIP specifications will define
protocol-level mechanisms addressing these concerns.
15. IANA Considerations
This document has no IANA actions.
16. Conclusion
The Internet transformed human access to information through
common protocols and interoperable abstractions. Autonomous
systems are at an analogous inflection point.
Today autonomous systems operate on infrastructure designed for
human information access. They adapt HTTP, DNS, and OAuth to
purposes those protocols were not designed for. The result is
fragmentation, lack of verifiability, and limited interoperability.
AIIP proposes a different approach: a native access layer for
autonomous systems, designed from the ground up for execution-
oriented interactions, running over existing Internet
infrastructure, and built on the principle that human authority
over autonomous systems is an architectural requirement.
The question this document raises for the IETF community is:
Should autonomous systems have a native access architecture —
one designed for execution, delegation, and verifiable outcomes
the way HTTP was designed for information retrieval?
AIIF proposes that this question is worth exploring together.
17. Informative References
[I-D.ietf-scitt-architecture]
Birkholz, H., et al., "An Architecture for Trustworthy
and Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture, 2026,
.
[I-D.morrow-sogomonian-exec-outcome-attest]
Morrow, C. and A. Sogomonian, "Execution Outcome
Attestation for AI Agents and Automated Systems", Work
in Progress, Internet-Draft,
draft-morrow-sogomonian-exec-outcome-attest, April 2026,
.
[I-D.sogomonian-aiip-architecture]
Sogomonian, A., "Architecture for the Artificial
Intelligence Internet Protocol", Work in Progress,
Internet-Draft, draft-sogomonian-aiip-architecture,
March 2026,
.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-
Based Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N.,
and W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334,
January 2023,
.
Author's Address
Aram Sogomonian (editor)
Artificial Intelligence Internet Foundation (AIIF)
Email: aiinternetfoundation@icloud.com