AI Agent Interoperable Protocol Framework (AIPF)

Introduction 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 . 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 and A2A are application-layer protocols that are built on top of IETF standards, including HTTP, JSON, OAuth 2.0, and TLS, for their transport and security foundations. These protocols are intended to be complementary rather than competing: MCP focuses on interactions between an agent and its tools, while A2A focuses on horizontal agent-to-agent communication. While both of these protocols are open-source and are 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 existing IETF protocols that are suitable for use, as well as identifying new IETF protocol work that is needed.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Current Protocol Landscape Several industry-developed protocols address subsets of the agent communication problem:

Model Context Protocol (MCP) :: 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.
Agent2Agent Protocol (A2A) :: 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.
Agent Communication Protocol (ACP) :: 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 , 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 and fine grained authorization.
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.

Framework Scope The use cases and protocol requirements that motivate this framework are defined in . This document takes those requirements as input and specifies the architectural framework and building blocks necessary to satisfy them. The gaps enumerated in fall into four areas, each addressed by a separate section in the document:

Inter-domain discovery and capability advertisement ()
Verifiable identity, authorization, and delegation ()
Heterogeneous, multi-modal transport ()
Long-lived session continuity ()

Without standards-based solutions, long-running and cross-domain agent workflows cannot interoperate.

Design Philosophy AIPF is designed around four commitments that should be taken into account in all companion protocol specifications:

Maximize reuse of existing IETF standards:: 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.
End-to-end security as a baseline, not an option:: 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.
Session-oriented, not request-response-oriented:: 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.
Composability and incremental deployment:: 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 can be negotiated away, and are not required.

Framework Composition

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.

Operational Flow The use case for orchestrator-driven agent collaboration, including task delegation, result reporting, and session continuity, is described in Section 4.2 of . 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 () or MLS group key agreement (, ) 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.

Framework Overview 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.

Reference architecture | 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 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 . 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 . Its placement in the stack is therefore solution-specific and outside the scope of this framework document.

Discovery Aspects 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 Aspects 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 . Some of the mechanisms for satisfying these requirements using existing IETF standards are described in .

Agent Identity 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. defines an Agent Identity Management System (AIMS) that is a conceptual model describing the set of functions required to establish, maintain, and evaluate the identity and permissions of an agent workload.

Channel Protection 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.

Intent-Execution Separation 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 granted to an agent be limited to the scope of the delegated task, so that an agent cannot use it to authorize actions outside that scope. This depends on delegation mechanics in which an agent acts on behalf of the original user and the authority passed at each hop is narrowed to the delegated task rather than broadened. Standardizing these delegation mechanics for AI agents is an active area of work in the OAuth WG; AIPF will profile the relevant outcomes as this work matures.

Delegation Chain Integrity 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.

Audit and Non-Repudiation 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 protocols Aspects 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 . 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.

Delivery Semantics 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.

Message Exchange Patterns 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.

Priority and Scheduling 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.

Multimodal Negotiation 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.

Structured Error and Progress Signaling 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.

Cancellation and Interruption 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.

Multiple Communication topologies 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.

Session Continuity 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.

Applicability of Existing IETF Work ## Reuse As-Is

TLS 1.3 provides mutual authentication and channel protection. Agents are required to negotiate TLS 1.3 or higher.
QUIC and QUIC-TLS provide multiplexed streams and 0-RTT session resumption.
OAuth 2.0 Token Exchange provides the base token exchange mechanism.
WIMSE Workload Credentials for agent identity, Workload Identity Tokens (WIT) at the application layer and Workload Identity Certificates (WIC) at the transport layer.

Profile or Extend 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. addresses cross-domain authorization, and addresses intra-domain token exchange between workloads. New proposals such as are also under discussion. AIPF will track this work and profile the relevant outcomes once the OAuth WG reaches consensus.
MoQT (Media over QUIC Transport): acts as a unified transport substrate for distributed agent state synchronization and real-time multimodal communications. Work needs to happen to provide a common mapping of request-response and streaming patterns onto the pub/sub model of MoQT in order to enable interoperability across diverse agent ecosystems.
More TBD..

New Protocol Work TBD

Security Considerations AI agents enlarge the attack surface: they act autonomously, delegate across administrative domains, and operate over long-lived sessions that accumulate sensitive task context and rely on long-standing delegated authority. This section highlights threats specific to the building blocks in this document; detailed mitigations are expected in the companion specifications. Delegated authority is the primary risk. A rogue or compromised agent may attempt to use delegated authority beyond the task it was granted, or to broaden it as it delegates onward. As required in and , authority granted to an agent is scoped to the delegated task and cannot be broadened along the chain, and the delegation chain is verifiable at each hop so an intermediary cannot forge or escalate it. Because agents exchange rich, potentially sensitive multimodal context, both message content and metadata require protection. Even with content encrypted, analysis of message sizes, timing, and stream patterns can leak the nature of an agent's tasks; mitigations such as padding may be warranted where that exposure matters.

IANA Considerations TBD

Acknowledgments The authors thank Kehan Yao for the discussion and comments.