| Internet-Draft | AIPF | June 2026 |
| Sarker, et al. | Expires 25 December 2026 | [Page] |
The current generation of AI agent communication protocols enables basic tool access and inter-agent messaging, but lacks the architectural and protocol foundations required for open, interoperable, and resilient Internet-scale deployments. This document presents the AI Agent Interoperable Protocol Framework (AIPF), a layered framework that identifies the key building blocks and the protocol suite required for interoperable Agent-to-agent/Agent-to-tool communication.¶
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 25 December 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. 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.¶
The emergence of autonomous AI agents that communicate, collaborate, and delegate tasks across the Internet introduces a new class of networked entity with requirements that existing protocol frameworks were not designed to address. A number of drafts have identified a cluster of open problems for which the IETF has a responsibility to provide standards-based solutions: inter-domain agent discovery, fine-grained delegated authorization across domain boundaries, multi-modal low-latency transport with session continuity, and secure transfer of accumulated task context across agent lifetimes.¶
This document specifies the AI Agent Interoperable Protocol Framework (AIPF), an architectural framework. AIPF addresses the complete lifecycle of an inter-domain AI agent-to-agent and agent-to-tools interaction: how agents advertise capabilities and discover peers (the Discovery module), how agents establish verifiable identities, authenticate to each other, and authorize delegation chains (the Security module), and how agents establish low-latency multi-modal communication sessions that survive network interruptions and agent migrations (the Transport Sessions module). The protocol requirements that AIPF is designed to satisfy are defined in [I-D.agentic-ai-usecases-requirements]. This document specifies the architectural framework and building blocks necessary to satisfy those requirements, and identifies applicable existing IETF protocols and areas requiring new protocol work. This document serves both as an architectural reference and as input to the IETF standardization effort for AI agent communication protocols.¶
MCP [MCP] and A2A [A2A] are application-layer protocols that rely on IETF standards, including HTTP, JSON, OAuth 2.0, and TLS, for their transport and security foundations. These protocols are complementary rather than competing: MCP focuses on vertical integration between an agent and its tools, while A2A focuses on horizontal agent-to-agent communication. While open-source and broadly adopted, they do not define the infrastructure-level building blocks such as cross-domain discovery, cryptographically verifiable delegation chains, session continuity, and multi-modal transport semantics that Internet-scale agent deployments require. This document analyzes these gaps and identifies protocol work appropriate for IETF standardization.¶
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.¶
Several industry-developed protocols address subsets of the agent communication problem:¶
MCP defines a standardized interface for AI agents to access tools, resources, and APIs. It is primarily an agent-to-tool (A2T) protocol operating within a single administrative domain, with manual pre-configuration of tool endpoints. MCP does not define agent discovery, cross-domain authentication, or session resumption.¶
A2A defines agent-to-agent communication using HTTP and Server-Sent Events (SSE). It introduces the "Agent Card" for capability advertisement and a "Task" object for session state. A2A's discovery depends on knowledge of the target agent's URL and does not define cross-domain federation. Session resumption after network disconnection is implementation-specific. Authorization uses OAuth 2.0 scopes without a defined delegation chain model.¶
ACP uses REST/HTTP for local, synchronous and asynchronous agent communication. It does not define Internet-scale discovery or cross-domain security.¶
As documented in [I-D.yao-catalist-problem-space], the specific gaps that the IETF should address are:¶
No standardized mechanism for resolving agent identifiers to network locations across domains.¶
No standardized cross-domain directory or federation mechanism for capability-based agent discovery.¶
No defined delegation chain model for multi-hop cross-domain agent authorization with cryptographic verifiability.¶
No session state management with explicit resumption, timeout, and migration semantics.¶
No multi-modal transport with per-stream reliability, ordering, and latency semantics appropriate for real-time audio and video alongside bulk data.¶
No standardized agent context document format or protocol for secure context transfer during agent migration.¶
The use cases and protocol requirements that motivate this framework are defined in [I-D.agentic-ai-usecases-requirements]. This document takes those requirements as input and specifies the architectural framework and building blocks necessary to satisfy them.¶
The gaps enumerated in Section 3 fall into four areas, each addressed by a separate section in the document:¶
Inter-domain discovery and capability advertisement (Section 7)¶
Verifiable identity, authorization, and delegation (Section 8)¶
Long-lived session continuity (Section 10)¶
Without standards-based solutions, long-running and cross-domain agent workflows cannot interoperate.¶
AIPF is designed around four commitments that should govern all companion protocol specifications:¶
New protocol work is warranted only when existing mechanisms cannot satisfy agent communication requirements without violating their specification or breaking backward compatibility. The analysis in this document shows that the majority of AIPF can be realized by composing, extending, or profiling existing IETF protocols.¶
Every AIPF interaction MUST be authenticated, encrypted, and authorized. There is no defined fallback to cleartext or unauthenticated operation. This is not a "security layer" applied on top; it is built into the connection establishment procedure itself.¶
Agent communication is inherently long-lived and stateful. Every protocol element is designed with the assumption that the logical session outlives any individual network connection, and that the transport layer exists to serve the session, not the reverse.¶
A minimal AIPF deployment (two agents, same domain, bilateral session, text-only modality) must interoperate with a full deployment (N agents, cross-domain, multi-party group key, multi-modal streams, session migration). Protocol elements that are not needed in a given interaction are negotiated away, not required.¶
Discovery establishes trust anchors.¶
Security binds identity and authorization.¶
Transport provides multiplexed streams.¶
Sessions bind execution continuity.¶
AIPF defines a vocabulary and interaction model ensuring these layers evolve coherently.¶
The use case for orchestrator-driven agent collaboration, including task delegation, result reporting, and session continuity, is described in Section 4.2 of [I-D.agentic-ai-usecases-requirements]. The operational flow for a complete interaction within this use case proceeds as follows:¶
Task Initiation: A user provides a goal to e.g. an Orchestrator Agent.¶
Agent Selection: The Orchestrator Agent uses discovery protocols to discover candidate Sub-agents that have the capabilities required for sub-tasks.¶
Identity Establishment: Before connecting, the Orchestrator Agent obtains verifiable credentials for itself and verifies the identity of the target Sub-agent.¶
Authorization: The Orchestrator Agent obtains an OAuth 2.0 delegation token scoped to the sub-task, derived from the original user authorization.¶
Connection Establishment: The Orchestrator Agent initiates transport layer protocol connection ( e.g a QUIC connection ) to the Sub-agent endpoint. TLS 1.3 cryptographic layer ([RFC9001]) or MLS group key agreement ([RFC9420], [RFC9750]) is established for multi-party sessions as part of this connection establishment phase.¶
Session Creation: Over the established transport protocol connection, the Orchestrator Agent creates an Agent Session, negotiating modalities, stream types, and session parameters.¶
Task Execution: The agents exchange messages using application-layer protocols (e.g., MCP, A2A) and Multi-modal data (text, audio, video) is carried over the transport layer protocol with appropriate priority and reliability settings.¶
Session Resumption or Migration: If the underlying transport layer connection is interrupted, the session could be resumed a pre-shared session ticket (e.g., QUIC session resumption) when the connection is recovered. If the Sub-agent migrates to a new compute node, and session will be created. In that case, the application need to retain the session information to be reused in the new connection.¶
Task Completion: The Orchestrator Agent receives results from Sub-agents, synthesizes the final response, and delivers it to the user. Sessions are gracefully terminated.¶
TODO: describe each of the blocks in details.¶
AIPF is organized as a layered protocol stack. Each layer provides guarantees that the layer above depends on. The stack is shared by both communicating agents, with agent-to-agent interaction occurring at the agent layer and the protocol layers beneath providing the necessary security, authorization, session, and transport foundations.¶
+--------------------+ +-------------------+
| User / App | | User / App |
+---------+----------+ +----------+--------+
| |
v v
+-----------------+ +-----------------+ +---------------+
| Agent (A) |<--->| Discovery |<---> | Agent (B) |
+---------+-------+ +-----------------+ +-------+-------+
| |
+----------------------+-----------------------+
|
v
+---------------------------------------------------------------+
| Session Management |
| - Session ID |
| - Resumption Tokens |
| - Context Integrity Digest |
| - Protocol : |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| Authorization and Delegation |
| - Protocol : AUTH2.0 |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| Identity Management |
| - Workload Identity Tokens (WIT) |
| - WIMSE Proof Tokens (WPT) |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| Transport |
| - Multiplexed Streams |
| - Per-stream Semantics |
| - Protocol : QUIC, MoQT |
+---------------------------------------------------------------+
|
v
+---------------------------------------------------------------+
| Security |
| - Channel Protection |
| - Mutual Authentication |
| - Protocol: TLS 1.3 |
+---------------------------------------------------------------+
TLS 1.3 provides channel protection and mutual authentication for all agent communication. When agents communicate directly over QUIC, TLS 1.3 is integrated into the QUIC handshake [RFC9001] and does not occupy a discrete layer above or below the transport. In architectures involving intermediaries where TLS is terminated at a proxy, application-layer authentication is required to maintain identity continuity across TLS termination points, as described in Section 8.2.¶
QUIC provides multiplexed streams with per-stream semantics suitable for the heterogeneous communication patterns of agent interactions. MoQT (Media over QUIC Transport) adds a publish/subscribe layer over QUIC for the one-to-many and many-to-many group communication that point-to-point QUIC streams cannot provide.¶
OAuth 2.0 provides the authorization and delegation framework, enabling agents to obtain and present access tokens scoped to specific tasks. WIMSE provides workload identity for agents through a URI embedded in X.509 certificates at the TLS layer, and through Workload Identity Tokens (WIT) and WIMSE Proof Tokens (WPT) at the application layer. The Agent Session Protocol (ASP) maintains session continuity, resumption tokens, and context integrity across network interruptions. Agents interact at the top of the stack, each acting on behalf of a user or system.¶
Attestation, as being defined in the SEAT WG, introduces mechanisms to bind attestation evidence to agent communications. The evidence may be carried during the TLS handshake or at the application layer. Attestation is not represented as a discrete layer in the diagram because it does not occupy a single position in the stack. Depending on the approach, attestation evidence may be conveyed during the TLS handshake or conveyed at the application layer by extending [RFC9261]. Its placement in the stack is therefore solution-specific and outside the scope of this framework document.¶
Discovery in open environments requires resolving an agent identifier to current network locations and advertised capabilities across administrative domains. Existing mechanisms do not support capability-aware, federated resolution without pre-established trust relationships. A2A introduces the Agent Card, a JSON document available at a well-known URI (/.well-known/agent.json) that advertises agent capabilities. While useful, this mechanism assumes prior knowledge of the agent's domain. A scalable discovery system requires:¶
Globally unique agent identifiers ( e.g DNS-rooted)¶
Signed Agent Capability Documents¶
Federation protocols with provenance tagging and hop limits¶
Concrete mechanisms for agent resolution and capability-based discovery are the subject of ongoing, early-stage work in the IETF and are not yet settled. AIPF treats the discovery requirements above as in scope and will reference specific mechanisms once that work matures.¶
Security for agent communication spans four interdependent concerns: verifiable agent identity, channel protection, binding of authorized intent to agent execution, and delegation chain integrity. The use cases and protocol requirements that motivate this architecture are discussed in [I-D.agentic-ai-usecases-requirements]. Some of the mechanisms for satisfying these requirements using existing IETF standards are described in [I-D.klrc-aiagent-auth].¶
Agent identity encompasses two concerns: a stable unique identifier and cryptographic credentials bound to that identifier.¶
Every agent is required to be assigned a unique, stable identifier that remains consistent across network reconnections and session resumptions. Credentials are required to be bound to the agent's identity. The credential lifecycle, including provisioning, rotation, and revocation, is required to be supported without manual intervention.¶
All agent communication is required to be encrypted and mutually authenticated. AIPF does not define a fallback to cleartext or unauthenticated operation. Authentication may operate at the transport layer, the application layer, or both. Transport-layer authentication works well when TLS connections are not terminated by intermediaries. In architectures involving proxies, application-layer authentication is required to maintain identity continuity across TLS termination points. The channel protection mechanism is required to be negotiated during session establishment, with both endpoints authenticating before any task state or authorization token is exchanged.¶
Autonomous agents dynamically generate execution plans and issue sub-requests based on their own reasoning, which may diverge from the scope of the original user authorization. AIPF requires that authorization tokens be bound to the scope and context of the delegated task and be non-transferable to a different task context without re-authorization.¶
When one agent delegates a sub-task to another, the receiving agent is authorized only to the extent explicitly permitted by the delegating agent. In multi-hop scenarios, the delegation chain may span several agents before reaching the resource or tool ultimately invoked. At each hop, the receiving party is required to verify that the authority presented was derived from the human or system that originally authorized the task, has not been expanded beyond what was originally granted, and has not been forged or modified in transit. A delegating agent is not permitted to grant authority that exceeds its own authorization at the time of delegation.¶
Agents act on behalf of users or other agents across multiple hops and administrative domains. Audit requires that each action be traceable to the principal that authorized it and the agent that executed it. For Non-repudiation, this traceability is required to be cryptographically verifiable, so that no party can later deny its role. The mechanism for recording and verifying it is outside the scope of this framework.¶
Transport for agent-to-agent communication spans several interdependent concerns: session continuity across long-running tasks, heterogeneous delivery semantics, explicit task and stream correlation, efficient movement of large context and data objects, signaling for priority and cancellation, structured error propagation, and negotiation of modalities and group communication topologies. The use cases and protocol requirements that motivate these transport properties are discussed in [I-D.agentic-ai-usecases-requirements]. The transport substrate is not required merely to deliver bytes between endpoints; it is required to preserve the correctness, efficiency, and recoverability of delegated agent execution across administrative domains and under changing network conditions.¶
Agent communication requires heterogeneous transport semantics rather than a single uniform model.¶
Agent communication patterns fall into three broad delivery semantic classes, each with distinct transport properties:¶
Reliable ordered delivery: : Used for control messages, workflow state updates, authorization checkpoints, and structured results. The transport substrate is required to guarantee in-order, lossless delivery for these message classes, and is required to isolate them from other traffic classes to avoid head-of-line blocking.¶
Low-latency, loss-tolerant delivery: Used for real-time audio, video, and high-frequency sensor or telemetry streams. The transport substrate is required to minimize latency for these streams and is not required to guarantee delivery or ordering.¶
High-throughput reliable delivery: Used for large context payloads and model inputs and outputs. The transport substrate is required to support high-throughput reliable transfer with flow-control isolation from other traffic classes. Where in-band transfer is impractical, a secure, integrity-protected out-of-band transfer mechanism is required to be supported.¶
Agent tasks are not limited to simple request-response exchange. An agent may delegate work asynchronously, receive an acknowledgement before completion, stream partial results, emit progress updates, request additional authorization, and later return a final result or cancellation status. The transport is required to take these patterns explicitly into account, including correlation of messages to the relevant task, subtask, and session. Multiplexing is required so that multiple delegated tasks or tool invocations can proceed concurrently without unrelated head-of-line blocking. The transport is also required to permit out-of-order completion of concurrent subtasks while preserving per-task ordering for incremental output and terminal states.¶
Delegated agent work varies in urgency and consequence. Some exchanges are on the critical path of a user-visible task, while others are background enrichment, speculative reasoning, or deferred synchronization. The protocol is required to signal task priority and delivery urgency so that transport and scheduling layers can differentiate service. Such signaling is required to be advisory and policy-controlled; a sender is not permitted to raise priority beyond the authority or policy of the delegated task. Priority signaling is also required for coordination messages such as authorization responses, cancellation acknowledgements, and error notifications, because delaying them can break an otherwise correct workflow.¶
Agents may exchange text, structured objects, images, audio, video, and sensor data within a session. The transport protocol is required to support negotiation of modalities and formats during session establishment or capability discovery. The negotiated set is binding unless explicitly updated; an endpoint is not permitted to send an unsupported modality. Transport-relevant modality properties, including reliability, latency sensitivity, and expected size, are required to inform stream selection, flow-control allocation, and framing. Modality negotiation therefore constrains both content and transport behavior.¶
The transport is required to carry more than final results. It is required to also convey incremental output, progress updates, checkpoint states, cancellation states, and structured errors usable by an orchestrating peer. Error signaling is required to distinguish transport failure from application failure, authorization failure, policy rejection, timeout, validation failure, and interoperability problems. Progress and liveness notifications are required to be representable independently of final completion so that a peer can tell whether an agent is active, blocked on external input, or waiting in a recoverable state. It is required to ensure that terminal error or cancellation signals are not silently lost if an ordinary data stream fails.¶
Agent execution may be interrupted by user action, policy enforcement, higher-priority work, loss of authorization, or dependent-subtask failure. The protocol is required to define explicit application-layer cancellation and interruption signaling, rather than rely on connection teardown. Cancellation is required to identify the affected scope, including a single invocation, delegated subtree, or session. Receiving agents are required to treat cancellation as idempotent and report whether execution stopped, had already completed, or could not be fully rolled back due to an irreversible action. In multi-hop deployments, interruption semantics are required to propagate predictably so that dependent subtasks do not continue after withdrawal of the parent task.¶
Some agent interactions may use one-to-many or many-to-many communication among a group of agents whose membership may change during an exchange. The transport is required to support these delivery patterns and to handle agents joining or leaving the group while the exchange is active. An agent's authorization to participate is required to be verified when it joins, and the keying material is required to be updated whenever an agent joins or leaves, so that an agent can decrypt group traffic only while it is a member.¶
Agent interactions are often long-lived, interruption-prone, and delegated across multiple hops. Each session is required to have a stable application-layer identifier that survives reconnection, endpoint migration, and resumption. The transport mapping is required to let an authorized peer re-attach to an interrupted session and restore enough task context to continue without redoing completed work. Session continuity is thus defined above any TCP connection, QUIC connection, or TLS association. QUIC migration and TLS resumption help, but they preserve transport or cryptographic state, not the higher-layer task, delegation, and execution state autonomous agents require.¶
Session continuity is required to provide persistent session identifiers, single-use resumption tokens, acknowledgment of the last received message, and context integrity verification.¶
## Reuse As-Is¶
TLS 1.3 [RFC8446] provides mutual authentication and channel protection. Agents are required to negotiate TLS 1.3 or higher.¶
QUIC [RFC9000] and QUIC-TLS [RFC9001] provide multiplexed streams and 0-RTT session resumption.¶
OAuth 2.0 Token Exchange [RFC8693] provides the base token exchange mechanism.¶
WIMSE Workload Credentials [I-D.ietf-wimse-workload-creds] for agent identity, Workload Identity Tokens (WIT) at the application layer and Workload Identity Certificates (WIC) at the transport layer.¶
The following existing protocols may require profiling or extension; this list is expected to evolve as new IETF and OAuth WG specifications emerge:¶
The OAuth WG is actively discussing how existing and new mechanisms apply to AI agent authorization. [I-D.ietf-oauth-identity-chaining] addresses cross-domain authorization, and [I-D.ietf-oauth-transaction-tokens] addresses intra-domain token exchange between workloads. New proposals such as [I-D.hardt-aauth-protocol] are also under discussion. AIPF will track this work and profile the relevant outcomes once the OAuth WG reaches consensus.¶
More TBD..¶
The authors thank Kehan Yao for the discussion and comments.¶