Independent Submission A. Sogomonian
Internet-Draft AIIF
Intended status: Informational 8 June 2026
Expires: 8 December 2026
AIIP: Native Access Architecture for Autonomous Systems
A Problem Statement and Architectural Exploration
draft-sogomonian-aiip-native-access-architecture-00
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 common Internet-layer framework analogous to the
role that DNS, HTTP, and the Web played for human information
exchange. The document provides architectural 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 8 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. Human Information Access and Autonomous Execution
3. Why Existing Standards Are Not Sufficient
4. Human Control Over AI
5. Architectural Principles
6. AIIP as an Architectural Exploration
7. AIIP Operational Model
8. Interoperability Considerations
9. Open Questions
10. Security Considerations
11. IANA Considerations
12. Conclusion
13. 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
* Other autonomous systems
Today these interactions are typically implemented through
vendor-specific APIs, proprietary invocation models, custom
authorization frameworks, and application-specific execution
semantics.
As a result, interoperability between independently developed
autonomous systems remains limited.
2. 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 may require a comparable framework for
execution-oriented interactions.
Figure 2: Autonomous Execution Access
Agent / Robot
|
v
AIIP
|
v
Resolve
|
v
Invoke
|
v
Execute
|
v
Receipt
The purpose of such a framework is not to replace existing Internet
protocols but to provide a common interoperability layer for
autonomous execution.
3. Why Existing Standards Are Not Sufficient
Existing Internet standards address important parts of the problem.
DNS: Naming.
HTTP: Information exchange.
OAuth: Authorization.
RATS [RFC9334]:
Attestation of trustworthy system state. AIIP does not
replace RATS; rather, 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.
Each solves a specific problem.
However, no common Internet-layer architecture currently exists for
autonomous execution across independently developed implementations.
AIIP does not seek to replace these technologies. Instead, AIIP
explores whether a common execution architecture can be built using
these technologies as foundational components.
4. Human Control Over AI
A foundational principle of a native access architecture for
autonomous systems is that authority originates from accountable
human or organizational actors.
Autonomous systems may perform actions, invoke services, interact
with physical devices, and execute tasks on behalf of users and
organizations. However, such actions occur within authority
boundaries established by humans and organizations.
AIIP assumes that autonomous systems operate through delegation
rather than independent sovereignty.
Figure 3: 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.
AIIP explores whether autonomous execution should occur within a
common framework that provides:
* Delegation controls
* Authorization mechanisms
* Policy enforcement
* Accountability mechanisms
* Verifiable outcomes
The objective is to reduce the risk of autonomous systems acting
outside authorized boundaries and to improve interoperability across
independently developed implementations.
A native access architecture for autonomous systems should support:
* Delegation management
* Delegation revocation
* Human override capabilities
* Policy enforcement
* Auditability
* Verifiable execution outcomes
Human control over AI is therefore not merely a policy objective; it
is an architectural requirement for accountable autonomous execution.
5. Architectural Principles
A native access architecture for autonomous systems should support:
* Resource identification
* Resource discovery
* Action invocation
* Delegation of authority
* Policy enforcement
* Execution accountability
* Verifiable outcomes
These functions should operate across organizational, administrative,
and implementation boundaries.
6. 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]
Forthcoming work under development includes:
* AIIP URI Scheme (draft-sogomonian-aiip-uri-scheme)
Future work may include:
* Discovery and resolution
* Invocation models
* Namespace governance
* Execution profiles
* Interoperability frameworks
The objective is not to define a replacement for existing Internet
technologies but to investigate common abstractions for interoperable
autonomous execution.
7. AIIP Operational Model
AIIP explores a common execution model based on four primary stages:
Figure 4: Resolve, Invoke, Execute, Receipt
Resolve
|
v
Invoke
|
v
Execute
|
v
Receipt
Resolve: Identifies a resource and retrieves execution metadata.
Invoke: Initiates an action within authorized policy boundaries.
Execute: Performs the requested operation.
Receipt: Provides verifiable evidence describing what occurred.
This model is intended to support interoperability among
independently developed autonomous systems.
8. Interoperability Considerations
Today autonomous systems rely on proprietary combinations of:
* APIs
* Authentication mechanisms
* Authorization frameworks
* Execution semantics
* Verification models
As autonomous systems become more capable and more interconnected,
these differences create barriers to interoperability.
A common access architecture could reduce fragmentation and improve
interoperability among:
* AI agents
* Robots
* Autonomous services
* Industrial systems
* Execution environments
9. Open Questions
Several questions remain open:
* Do autonomous systems require a common Internet-layer execution
model?
* Which existing IETF technologies should be reused?
* What abstractions are necessary for interoperable autonomous
execution?
* What trust and verification mechanisms are required?
* What role should standards bodies play in such an architecture?
These questions are intended to stimulate discussion rather than
prescribe specific technical solutions.
10. 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
* Authorization
* Delegation
* Policy enforcement
* Attestation
* Outcome verification
* Revocation
* Human override mechanisms
Future AIIP specifications may define protocol-level mechanisms
addressing these concerns.
11. IANA Considerations
This document has no IANA actions.
12. Conclusion
The Internet transformed human access to information through common
protocols and interoperable abstractions.
As autonomous systems become increasingly important participants in
Internet-based interactions, a similar question emerges:
Should autonomous systems have a native access architecture for
discovery, invocation, execution, delegation, policy enforcement,
and verifiable outcomes?
AIIP proposes that this question is worth exploring.
The architecture described in this document assumes that autonomous
systems operate under human or organizational authority. The goal
is not to replace human decision-making, but to provide
interoperable mechanisms through which delegated actions can be
performed, governed, and verified across independently developed
implementations.
A native access architecture for autonomous systems should therefore
enable both autonomous execution and human accountability.
13. 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,
.
[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)
United States of America
Email: aiinternetfoundation@icloud.com