Network Working Group S. D. Park Internet-Draft Samsung Electronics Intended status: Informational I. Siddique Expires: 1 March 2027 Opaque 28 August 2026 Architectural Requirements for Supporting AI Agents on the Internet draft-daniel-ai-agent-internet-architecture-01 Abstract Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, long and unpredictable model-processing intervals, and cross-domain interaction create requirements that span multiple protocol families. This document describes architectural requirements for supporting AI agents on the Internet across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, transport and connection continuity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination. 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 1 March 2027. Park & Siddique Expires 1 March 2027 [Page 1] Internet-Draft AI Agent Internet Architecture August 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Architectural Principles . . . . . . . . . . . . . . . . . . 6 6. Reference Interaction Model . . . . . . . . . . . . . . . . . 7 7. Naming and Discovery Requirements . . . . . . . . . . . . . . 7 8. HTTP Requirements . . . . . . . . . . . . . . . . . . . . . . 8 9. Transport and Connection Continuity for Long-Running Agent Operations . . . . . . . . . . . . . . . . . . . . . . . 9 10. Authentication, Authorization, and Delegation . . . . . . . . 11 11. TLS, PKI, Workload Identity, and Trust . . . . . . . . . . . 12 12. Asynchronous Agent Communication . . . . . . . . . . . . . . 13 13. Capability and Intent-Based Resolution . . . . . . . . . . . 14 14. Payment and Economic Interaction . . . . . . . . . . . . . . 14 15. Provenance, Auditability, and Accountability . . . . . . . . 15 16. Revocation, Suspension, and Emergency Control . . . . . . . . 15 17. Security Considerations . . . . . . . . . . . . . . . . . . . 16 18. Relationship to Existing Agent Protocols . . . . . . . . . . 16 19. Candidate IETF Work Items . . . . . . . . . . . . . . . . . . 17 20. Current IETF Work Landscape and Coordination Gap . . . . . . 17 21. Recommendation for IETF-Wide Coordination of AI Agent Protocol Work . . . . . . . . . . . . . . . . . . . . . . . . . . 18 22. Normative References . . . . . . . . . . . . . . . . . . . . 18 23. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Park & Siddique Expires 1 March 2027 [Page 2] Internet-Draft AI Agent Internet Architecture August 2026 1. Introduction AI agents are becoming autonomous Internet participants rather than merely user-interface features. An agent can interpret a goal, discover remote services, acquire or present delegated authority, select another agent, invoke tools, initiate payments, maintain state, and continue work without a human being present for each network transaction. Application protocols and frameworks can address important agent interaction patterns, but they do not by themselves solve Internet- wide problems of naming, discovery, identity, delegated authorization, trust, payment negotiation, asynchronous delivery, provenance, and accountability across administrative domains. AI-agent-related Internet-Drafts are already emerging across authentication and authorization, discovery, agent-to-agent and agent-to-tool communication, transport, and related areas. This breadth indicates that supporting AI agents is not a single application-protocol problem. It also creates a coordination risk if common concepts such as agent identity, capability, delegation, discovery metadata, intent, and transaction context are defined independently. This document defines architectural requirements for supporting AI agents on the Internet. It does not define a separate Internet, a new network layer, or a universal agent protocol. The preferred direction is coordinated evolution of existing Internet mechanisms and new mechanisms only where demonstrated gaps remain. 2. Terminology and Conventions 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. Agent: An autonomous or semi-autonomous software entity that can take network actions based on goals, policies, delegated authority, and contextual state. Principal: A human, organization, workload, service, or agent whose identity or authority is relevant to an action. Delegation: A grant of authority from one principal to another, including scope, time, value, context, or re-delegation constraints. Park & Siddique Expires 1 March 2027 [Page 3] Internet-Draft AI Agent Internet Architecture August 2026 Capability: A machine-readable description of an operation or service that an agent can provide. Intent: The desired outcome or declared purpose associated with an agent action. Intent is not, by itself, an authorization signal. Agent Descriptor: Machine-readable metadata describing an agent's identity, capabilities, endpoints, protocols, security requirements, and related operational properties. AI Agent Internet Architecture: The set of Internet protocol mechanisms and coordinated extensions needed to support autonomous AI agents across administrative and trust boundaries. This term does not imply replacement of the existing Internet architecture. Inference-Induced Transport Idleness: A period in which an agent task remains active while little or no application data traverses an associated transport connection because a model or service is performing inference, reasoning, retrieval, tool execution, or related processing. 3. Scope and Non-Goals This document focuses on protocol-layer interoperability across independently administered Internet domains. It covers discovery, identity, authorization and delegation, trust establishment, HTTP interaction, transport behavior for long-running agent operations, payment negotiation, asynchronous communication, capability resolution, provenance, auditability, revocation, and privacy. This document does not standardize model behavior, prompt formats, reasoning traces, agent planning algorithms, model evaluation, or a universal agent runtime. It does not select a single application framework as the interaction protocol for all agents. However, characteristics of model execution that materially affect Internet protocol behavior, such as long and unpredictable processing intervals, are within scope when they create transport, connection- management, or application-protocol requirements. 4. Problem Statement Existing Internet protocols can transport agent traffic, but they do not consistently expose the semantics required when autonomous software acts as a principal. A server can authenticate a TLS peer or validate an OAuth access token without necessarily knowing which agent is acting, which human or organization delegated the action, whether re-delegation was permitted, or whether the transaction remains within a spending or operational limit. Park & Siddique Expires 1 March 2027 [Page 4] Internet-Draft AI Agent Internet Architecture August 2026 DNS can locate hosts and services, but Internet-wide agent discovery can require resolution by organization, agent name, capability, supported protocol, security profile, or intent. Long-running agent tasks can also require asynchronous delivery and correlation beyond a single synchronous request/response exchange. AI-agent interactions can exhibit timing characteristics that differ substantially from conventional Web transactions. After an agent sends a request to a remote model or agent service, the remote system can spend seconds, minutes, or potentially longer performing model inference, reasoning, retrieval, tool execution, or multi-agent coordination before producing application data in response. During this processing interval, the underlying transport connection can remain logically valid while carrying little or no application data. Application servers, HTTP intermediaries, reverse proxies, load balancers, NATs, firewalls, or other stateful middleboxes can interpret such periods of silence as inactivity and apply idle or request timeouts that terminate or discard state associated with an otherwise valid agent operation. Even when a TCP connection remains established, a long application- limited or idle interval has implications for congestion-control state. Previously measured path capacity cannot necessarily be assumed to remain valid after a long idle period. TCP congestion- control mechanisms therefore can reduce or revalidate the congestion window before transmission resumes[RFC5681] [RFC7661]. A large model response generated after a lengthy inference interval can consequently experience a renewed congestion-window growth phase even though the application regards the operation as one continuous transaction. The architecture therefore distinguishes task lifetime, application transaction lifetime, transport connection lifetime, and network state lifetime. These lifetimes cannot be assumed to be identical. An interoperable architecture therefore needs machine-processable answers to: who is acting; who operates the agent; on whose behalf it acts; what it is authorized to do; whether that authority may be delegated; what the counterparty can do; how the counterparty is discovered and authenticated; what protocol and security profile to use; what payment is required; what evidence remains after the action; and whether a long-running task remains active independently of a particular transport connection. Park & Siddique Expires 1 March 2027 [Page 5] Internet-Draft AI Agent Internet Architecture August 2026 5. Architectural Principles *Evolution Before Replacement:*Agent-related mechanismsSHOULDreuse deployed Internet protocols and registries where practical. A new protocolSHOULDbe introduced only when existing mechanisms cannot provide the required semantics, security properties, deployment model, or scale. *Separation of Concerns:*Identity, authentication, authorization, delegation, capability, intent, trust, payment, and audit are distinct concepts andMUST NOTbe implicitly conflated. *Independent Trust Signals:*Authentication establishes control of a credential associated with an agent or workload. Authorization determines whether that authenticated principal is permitted to perform an action. Remote attestation can provide additional evidence concerning the software composition, configuration, or execution state associated with that principal. Audit mechanisms can record which identity, authorization, and attestation information informed a decision. These functions are complementary andMUST NOTbe treated as interchangeable trust signals. *Cross-Domain Operation:*MechanismsMUSTassume that agents, principals, authorization services, resource servers, and discovery infrastructure can belong to different administrative domains. *Least Authority:*Delegated authoritySHOULDbe narrowly scoped by operation, audience, resource, time, value, and context. Re- delegationSHOULDbe explicit rather than assumed. *Human and Organizational Accountability:*When an agent acts for a human or organization, protocolsSHOULDpreserve sufficient verifiable evidence to identify the accountable principal without exposing unnecessary personal data. *Decentralized Deployability:*The architectureSHOULD NOTrequire a single global agent registry, identity provider, payment provider, or trust-score operator. *Processing-Time Independence:*Internet mechanisms supporting AI agentsSHOULD NOTassume that useful application data will be generated within a short or predictable interval after a request is accepted. Protocol designsSHOULDdistinguish remote computation or inference delay from network failure andSHOULDallow application task state to survive transport interruption or transport-state expiration where practical. Park & Siddique Expires 1 March 2027 [Page 6] Internet-Draft AI Agent Internet Architecture August 2026 6. Reference Interaction Model A representative transaction can involve a User Principal, a User Agent, one or more Specialist Agents, an Agent Service, an Authorization Server, a Discovery Service, and a Resource Server. These roles can be co-located or distributed across domains. A typical sequence is: the principal delegates a constrained task; the agent discovers candidate services or agents; discovery returns endpoints, capabilities, supported protocols, and security metadata; the agent authenticates and presents delegated authority; a specialist agent may receive a bounded re-delegation; a resource may advertise payment or policy requirements; the agent verifies those requirements against its authority; the action is completed; and material authorization, payment, and provenance evidence is retained for audit. An additional phase can occur between request acceptance and result delivery. After receiving and authorizing a task, an Agent Service can enter a processing state while performing inference, reasoning, retrieval, tool invocation, or delegation to other agents. During this phase, little or no application data may traverse the connection even though the task remains active. The reference interaction model therefore distinguishes request acceptance, task processing, and result delivery. Result deliveryMAYoccur over the original transport connection, a resumed or replacement connection, or an asynchronous messaging mechanism, depending on task duration and negotiated capabilities. 7. Naming and Discovery Requirements DNS is a natural component of agent discovery because it provides globally delegated naming, caching, service discovery, and security extensions. DNS for AI Discovery (DNS-AID) is one example of current IETF work in this space. REQ-DISC-1: An agent discovery mechanismMUSTsupport discovery when an organization and agent identifier are known. REQ-DISC-2: ItSHOULDsupport discovery when the organization is known but the specific agent is not, using capability or service metadata. REQ-DISC-3: The architectureSHOULDdefine how capability-only or intent-assisted discovery can be federated without requiring a mandatory centralized registry. Park & Siddique Expires 1 March 2027 [Page 7] Internet-Draft AI Agent Internet Architecture August 2026 REQ-DISC-4: Discovery resultsSHOULDbe able to express endpoint, protocol, protocol version, capability identifiers, authentication requirements, authorization metadata, payment support, and relevant trust material. REQ-DISC-5: Discovery metadataMUSThave a mechanism for authenticity and integrity protection. REQ-DISC-6: Discovery mechanismsSHOULDdefine caching, freshness, negative caching, key rotation, endpoint mobility, and downgrade behavior. 8. HTTP Requirements HTTP is expected to remain a primary substrate for agent interactions. Agent requirements should preferentially use existing HTTP extensibility mechanisms, including status codes, fields, authentication schemes, content negotiation, HTTP Message Signatures, and Well-Known URIs. *Programmatic Payment:*HTTP 402 Payment Required and x402-style flows demonstrate a machine-operable payment challenge model. Generic standardization should remain independent of a particular currency, ledger, wallet, or settlement provider. REQ-HTTP-1: A payment challengeSHOULDidentify the payment scheme, amount or pricing rule, asset or unit, recipient, expiration, replay constraints, and verification method in machine-readable form. REQ-HTTP-2: Payment authorizationSHOULDbe bindable to the agent's delegated spending authority, request target, and transaction context. REQ-HTTP-3: Payment mechanismsSHOULDsupport receipts andSHOULDdefine failure, retry, duplicate-payment, cancellation, and refund semantics. *Agent Authentication:*HTTP Message Signatures provide a relevant primitive for cryptographically authenticating selected message components. REQ-HTTP-4: An agent authentication profileSHOULDdefine how an agent identifier, signing key, operator identity, request freshness, and key-discovery mechanism are bound to a signed request. Park & Siddique Expires 1 March 2027 [Page 8] Internet-Draft AI Agent Internet Architecture August 2026 *Intent and Policy Signaling:*Any standardized intent or purpose signalMUSTbe treated as a declaration rather than proof of authorization, andSHOULDbe cryptographically bound to the authenticated request when relied upon for policy. *Capability Negotiation:*HTTP-based agent protocolsSHOULDreuse standard content negotiation and extensibility patterns rather than creating incompatible negotiation mechanisms for every framework. Long-running AI operations can exceed timeout assumptions made by HTTP clients, servers, gateways, and intermediaries. A delayed response does not necessarily indicate server failure; it can indicate that an accepted task is still undergoing inference or other computation. REQ-HTTP-5: HTTP-based agent protocolsSHOULDprovide a machine- readable means to distinguish an accepted but still-processing operation from an unavailable, failed, or abandoned operation. REQ-HTTP-6: Agent interaction profilesSHOULDdefine whether a long- running operation remains bound to the original HTTP exchange or can transition to polling, callback, event delivery, streaming, or another asynchronous result-retrieval mechanism. REQ-HTTP-7: When intermediaries are involved, agent protocolsSHOULD NOTdepend on an indefinitely open HTTP request unless expected timeout behavior and connection-liveness requirements are compatible across the path. REQ-HTTP-8: Retry semantics for long-running operationsMUSTaddress duplicate execution. A client that loses a connection while an agent task continues remotelyMUSTbe able to determine whether the original operation is still executing before blindly repeating a consequential request. 9. Transport and Connection Continuity for Long-Running Agent Operations AI-agent workloads introduce a transport pattern in which relatively short request bursts can be followed by long periods of application silence while a model performs inference, reasoning, retrieval, tool execution, or coordination. This document refers to this condition as inference-induced transport idleness. Inference-induced transport idleness does not necessarily mean that the endpoint, transport connection, or agent task has failed. It indicates that application processing time is significantly longer than the interval between ordinary network exchanges. Park & Siddique Expires 1 March 2027 [Page 9] Internet-Draft AI Agent Internet Architecture August 2026 For TCP, a connection can remain established during such an interval. However, TCP congestion-control state reflects knowledge about network conditions rather than application task state. After a sufficiently long idle period, previously measured available capacity can no longer necessarily be assumed to remain valid. TCP mechanisms can therefore restart or revalidate transmission conservatively when application traffic resumes[RFC5681] [RFC7661]. This distinction is particularly relevant when a small agent request triggers lengthy computation followed by a large response. From the application's perspective, this can be a single continuous operation. From the transport's perspective, the response can follow a substantial idle or application-limited period. The sender can consequently need to rebuild or revalidate its usable congestion window before transmitting the complete response. Connection continuity can also be affected by stateful infrastructure. NATs, firewalls, proxies, gateways, and load balancers can discard idle flow or request state before model processing completes. Application-level request timers can expire independently of TCP connection state. Conversely, a transport connection can disappear while the remote agent task remains valid and continues execution. Similar considerations apply to transports other than TCP. QUIC defines an idle timeout and permits use of ack-eliciting packets when an endpoint needs to defer an idle timeout[RFC9000]. Agent protocols thereforeSHOULD NOTassume that keeping an application task active automatically keeps the underlying transport association active. The architecture should distinguish transport liveness from task liveness. REQ-TRANS-1: Agent protocolsMUST NOTinterpret absence of application response data during a model-processing interval as sufficient evidence that the remote task has failed. REQ-TRANS-2: Agent interaction protocolsSHOULDprovide a machine- readable indication that a request has been accepted and remains in progress when processing can exceed ordinary connection or request timeout intervals. REQ-TRANS-3: Long-running agent operationsSHOULDbe recoverable across transport connection loss where the semantics of the operation permit recovery. Park & Siddique Expires 1 March 2027 [Page 10] Internet-Draft AI Agent Internet Architecture August 2026 REQ-TRANS-4: A reconnecting clientSHOULDbe able to correlate a new transport connection with an existing agent task without requiring the task to be executed again. REQ-TRANS-5: Protocols supporting long-running operationsSHOULDdefine task identifiers, expiration semantics, cancellation behavior, and result-retrieval procedures independently of the lifetime of a specific TCP or QUIC connection. REQ-TRANS-6: ImplementationsSHOULDavoid unnecessary keepalive traffic solely for preserving long-running inference operations when an asynchronous or resumable interaction model can provide equivalent semantics. REQ-TRANS-7: Where transport or application keepalive mechanisms are used, their frequencySHOULDaccount for endpoint and middlebox timeout behavior while avoiding excessive network traffic and resource consumption. REQ-TRANS-8: Agent protocolsSHOULDallow endpoints to communicate expected processing characteristics, where useful, without requiring disclosure of private reasoning traces or internal model state. REQ-TRANS-9: Transport optimizations for inference-induced idle periodsMUSTpreserve congestion-control safety. An agent protocolMUST NOTassume that previously available path capacity remains valid solely because the application-level task has remained active. REQ-TRANS-10: Architecture and implementationsSHOULDminimize the latency penalty associated with resuming large result transfers after long processing intervals while maintaining established congestion- control principles. 10. Authentication, Authorization, and Delegation Authorization is a central gap for AI-agent use cases. Current IETF work on AI Agent Authentication and Authorization applies workload identity and the OAuth 2.0 family to agent interactions and seeks to identify gaps before defining unnecessary new protocols. REQ-AUTH-1: The architectureMUSTdistinguish agent identity from the identity of the human or organization on whose behalf the agent acts. REQ-AUTH-2: Authorization evidenceMUSTbe audience-restricted andSHOULDbe narrowly scoped to resources and operations. Park & Siddique Expires 1 March 2027 [Page 11] Internet-Draft AI Agent Internet Architecture August 2026 REQ-AUTH-3: Multi-hop delegationSHOULDpreserve the original principal and each authorized delegation step in verifiable form, while allowing privacy-preserving disclosure where intermediaries do not require the full chain. REQ-AUTH-4: DelegationSHOULDexpress time limits, transaction or value limits, context constraints, and whether re-delegation is permitted. REQ-AUTH-5: A resource serverMUSTbe able to determine the effective authority applicable to the current request without trusting unauthenticated claims from an intermediary agent. REQ-AUTH-6: Delegated authorityMUSTbe revocable or naturally short- lived, and revocation semanticsSHOULDaddress active multi-agent chains. 11. TLS, PKI, Workload Identity, and Trust TLS protects channels and authenticates endpoints, but an agentic system can require additional bindings among endpoint identity, workload identity, agent identity, operator, and delegating principal. REQ-ID-1: Agent identitySHOULDbe verifiably bound to a key or workload identity that supports rotation and short lifetimes. REQ-ID-2: The architectureSHOULDsupport proof that an agent is authorized to represent a domain or organization. REQ-ID-3: Endpoint authentication and agent authenticationSHOULDbe independently verifiable where they represent different principals. REQ-ID-4: Trust decisionsMUST NOTbe inferred solely from successful authentication. REQ-ID-5: DesignsSHOULDavoid globally stable identifiers when a scoped or pairwise identifier can satisfy the use case. REQ-ID-6: When a relying party's policy depends on the software composition, configuration, or execution environment of an agent, the architectureSHOULDsupport associating the authenticated agent identity with fresh, independently verifiable Evidence or Attestation Results concerning the relevant execution environment. Such mechanismsSHOULDbe compatible with platform-neutral remote attestation architectures such as [RFC9334] andSHOULD NOTrequire a universal hardware, runtime, or attestation mechanism. Standard claims formats such as the Entity Attestation Token (EAT) [RFC9711] can be used where appropriate. Park & Siddique Expires 1 March 2027 [Page 12] Internet-Draft AI Agent Internet Architecture August 2026 12. Asynchronous Agent Communication Long-running research, procurement, orchestration, and offline workflows do not always fit synchronous HTTP request/response. Current individual proposals explore asynchronous store-and-forward semantics for agents. Long-running model execution also illustrates why asynchronous communication is an architectural requirement rather than merely an application convenience. Keeping a transport connection open throughout an unpredictable inference or reasoning interval can consume endpoint and intermediary state, can interact poorly with request and idle timeouts, and can require keepalive traffic that provides no application value. An agent protocolSHOULDtherefore be able to transition from a synchronous request/wait/response model to a request/task-accepted/ task-identifier/processing/result-notification-or-retrieval model without losing authorization, delegation, transaction, provenance, or audit context. REQ-MSG-1: An asynchronous agent messaging mechanismSHOULDsupport globally unique message identifiers, correlation identifiers, expiration, retry, delivery status, and duplicate detection. REQ-MSG-2: ItSHOULDprovide end-to-end integrity andSHOULDallow confidentiality independent of relay hops. REQ-MSG-3: Relay infrastructureMUSTbe able to apply abuse controls without requiring access to unnecessary private task content. REQ-MSG-4: The mechanismSHOULDdefine how authorization and delegation evidence is carried or referenced across delayed delivery. REQ-MSG-5: The IETF should first evaluate whether profiles of existing HTTP, messaging, event, or mail technologies can meet these requirements before defining a new transport. REQ-MSG-6: An asynchronous resultMUSTbe correlatable with the request and authorization context that initiated the task. REQ-MSG-7: Transitioning from synchronous to asynchronous operationSHOULD NOTrequire re-execution of the original task. REQ-MSG-8: The architectureSHOULDpermit a long-running task to outlive any individual transport connection used to create, observe, or retrieve the task. Park & Siddique Expires 1 March 2027 [Page 13] Internet-Draft AI Agent Internet Architecture August 2026 13. Capability and Intent-Based Resolution AI-agent systems add a resolution problem above IP routing: selecting a service or agent because it can satisfy a requested capability under policy constraints. This is service selection and resolution at a higher layer, not a replacement for IP routing. REQ-CAP-1: Capability identifiersSHOULDhave stable semantics independent of a single vendor or agent framework. REQ-CAP-2: Capability descriptionsSHOULDbe separable from endpoint location. REQ-CAP-3: Query and matching mechanismsSHOULDsupport constraints such as language, protocol, security profile, jurisdiction, price, latency, and policy. REQ-CAP-4: Ranking and reputation informationMUST NOTbe treated as authoritative identity or authorization evidence. REQ-CAP-5: Intent-based discoverySHOULDminimize disclosure because the query itself can reveal sensitive user goals. 14. Payment and Economic Interaction Autonomous agents can purchase API calls, data, compute, content, reservations, or other services. Payment must compose with discovery, authorization, spending policy, identity, and audit rather than exist as an isolated wallet operation. REQ-PAY-1: A principalMUSTbe able to constrain an agent's spending by amount, currency or asset class, recipient or category, time, and transaction type. REQ-PAY-2: A payment proofSHOULDbe bound to the resource request sufficiently to prevent replay for a different resource or amount. REQ-PAY-3: The protocol architectureSHOULDpermit multiple payment schemes andSHOULD NOTrequire a particular blockchain or settlement network. REQ-PAY-4: ServicesSHOULDprovide machine-readable receipts that can be correlated with authorization and audit records. Park & Siddique Expires 1 March 2027 [Page 14] Internet-Draft AI Agent Internet Architecture August 2026 15. Provenance, Auditability, and Accountability Agent actions can have financial, operational, legal, or security consequences. Protocols should preserve evidence of consequential actions without requiring disclosure of model chain-of-thought or unnecessary private content. REQ-AUD-1: Audit evidenceSHOULDsupport correlation of agent identity, operator or accountable principal, authorization context, request identifier, timestamp, material policy constraints, result status, and payment reference when applicable. REQ-AUD-2: Audit evidenceSHOULDbe tamper-evident andSHOULDsupport selective disclosure. REQ-AUD-3: ProtocolsMUST NOTrequire collection of private reasoning traces as a condition of accountability. REQ-AUD-4: Audit identifiersSHOULDbe scoped to reduce cross-service tracking. REQ-AUD-5: Audit evidenceSHOULDbe able to identify or reference the Attestation Results, Verifier, appraisal policy, and relevant Reference Values that informed a trust decision when such information is material to that decision. Such auditabilitySHOULD NOTrequire disclosure of private agent reasoning, sensitive Evidence, or unrelated workload data. 16. Revocation, Suspension, and Emergency Control Autonomy and machine-speed execution make revocation a first-order protocol requirement. REQ-REV-1: Credentials and delegated authoritySHOULDsupport short validity periods and explicit revocation where risk requires it. REQ-REV-2: Revocation of a parent delegationSHOULDinvalidate or constrain dependent re-delegations according to explicit semantics. REQ-REV-3: ServicesSHOULDsupport rapid suspension of compromised agents or keys without requiring deletion of historical audit evidence. REQ-REV-4: Emergency controlsSHOULDbe fail-safe andSHOULDavoid a single globally privileged kill switch. Park & Siddique Expires 1 March 2027 [Page 15] Internet-Draft AI Agent Internet Architecture August 2026 17. Security Considerations Agent security requires separating possession of an authentication credential from the integrity of the software and execution environment that uses that credential. A compromised agent workload can retain access to a legitimate key and therefore generate cryptographically valid requests, satisfy ordinary authentication checks, and emit tamper-evident audit records even when unexpected or malicious code is executing. Authentication alone therefore does not establish that the expected software composition, configuration, or execution state controlled the credential at the time of an action. Where those properties are security-relevant, relying partiesSHOULDconsider fresh, independently verifiable Evidence or Attestation Results. The Remote ATtestation procedureS (RATS) architecture [RFC9334] provides platform-neutral roles for Evidence, Verifiers, Attestation Results, appraisal policies, Reference Values, and Relying Parties. EAT [RFC9711] provides a standard claims format that can carry attestation-related information. Attestation does not replace authentication or authorization. Authentication establishes control of a credential; authorization establishes which actions are permitted; attestation can evaluate relevant properties of the executing state; and audit evidence can record which identity, authorization, and attestation information informed the decision. ImplementationsMUST NOTtreat these signals as interchangeable. Attestation evidence can itself expose sensitive information about software versions, configuration, devices, operators, or deployment environments. ArchitecturesSHOULDminimize disclosed evidence, prefer Attestation Results or selectively disclosed claims when sufficient, and avoid retaining raw Evidence when it is not required for the relying party's decision or subsequent accountability. 18. Relationship to Existing Agent Protocols Application-layer agent protocols and frameworks are complementary to the Internet mechanisms described here. They can benefit from standardized discovery, authentication, delegated authorization, payment, and trust mechanisms. Park & Siddique Expires 1 March 2027 [Page 16] Internet-Draft AI Agent Internet Architecture August 2026 The architectural objective is composability: discovery identifies a candidate endpoint; identity authenticates it; authorization determines permitted actions; an interaction protocol carries the task; payment settles economic requirements; and provenance or audit mechanisms retain evidence. No single layer should be expected to solve all of these functions. 19. Candidate IETF Work Items Candidate cross-area work includes an agent identity profile; an OAuth-compatible multi-hop delegation profile; DNS and Well-Known based agent discovery profiles; a framework-neutral capability vocabulary and discovery metadata model; an HTTP Message Signatures profile for agents; authenticated intent and policy metadata; generic HTTP payment negotiation and receipt semantics; requirements for long-running agent transactions and inference-induced transport idleness; mechanisms for decoupling task lifetime from transport- connection lifetime; resumable agent transactions and task correlation across reconnects; asynchronous agent messaging requirements; privacy-preserving provenance and audit evidence; composition with remote attestation and attestation-result references; and revocation semantics for delegation chains. Transport-area expertise is particularly relevant in determining whether existing TCP, QUIC, HTTP, connection-liveness, congestion- control, and application-layer mechanisms adequately support AI workloads characterized by long processing intervals followed by potentially bursty or large result transfers. Protocol-specific wire work should remain with established expert Working Groups where appropriate. Cross-area work is needed for common terminology, architecture, gap analysis, and composability. 20. Current IETF Work Landscape and Coordination Gap As of August 2026, AI-agent-related Internet-Drafts span several protocol domains. Examples include DNS for AI Discovery (DNS-AID); AI Agent Authentication and Authorization; Agentic AI Use Cases and Requirements; and individual proposals addressing agent discovery, invocation, transport, and authorization. This activity is evidence of a broad protocol problem, but it also exposes a coordination gap. The drafts do not necessarily share a common model for agent identity, operator identity, capability identifiers, delegation, discovery metadata, intent, transaction context, or trust. Similar functions can therefore be specified independently at different layers or by different communities. Park & Siddique Expires 1 March 2027 [Page 17] Internet-Draft AI Agent Internet Architecture August 2026 The architectural requirement is not that every proposal use the same wire protocol. It is that common concepts have clear ownership and composable semantics. Discovery should be able to reference an authorization profile without redefining authorization; payment should be bindable to delegated authority without defining a new identity system; and agent interaction protocols should be able to consume common discovery and security metadata. A cross-IETF gap analysis and terminology effort is therefore needed before multiple overlapping mechanisms become widely deployed. 21. Recommendation for IETF-Wide Coordination of AI Agent Protocol Work The requirements in this document cut across several existing IETF Areas and protocol families. Naming and discovery touch DNS and Internet-area work; authentication, authorization, delegation, and provenance touch Security and OAuth or workload-identity work; HTTP semantics and messaging touch Applications and Real-Time and transport-related communities; transport continuity and inference- induced idleness touch transport and HTTP expertise; and deployment and lifecycle management touch Operations and Management. Without explicit coordination, independently developed solutions risk duplicating functions, defining incompatible identity or capability models, creating overlapping discovery mechanisms, and placing agent- specific semantics at inconsistent layers. The IETF should therefore consider an explicit cross-area coordination activity for AI-agent- related Internet protocol work. Such coordination could begin with common terminology, architectural principles, and a gap analysis, while protocol-specific extensions remain in the existing expert Working Groups and Areas. The objective is not to create a monolithic agent protocol, but to ensure that independently developed mechanisms compose into a coherent Internet architecture for AI agents. As the number and scope of AI-agent-related proposals increase, the IETF should also consider whether a dedicated cross-area venue, or ultimately a new Area if the work becomes sufficiently broad and persistent, would improve architectural coherence, review, and coordination. Any such organizational decision is outside the scope of this document; this document records the architectural need for coordinated IETF-wide treatment of the problem. 22. Normative References Park & Siddique Expires 1 March 2027 [Page 18] Internet-Draft AI Agent Internet Architecture August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 23. Informative References [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, . [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, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . Authors' Addresses Soohong Daniel Park Samsung Electronics Open Source Group Republic of Korea Email: soohongp@gmail.com Imran Siddique Opaque Email: imransiddique@live.com Park & Siddique Expires 1 March 2027 [Page 19]