AI Agent Interoperable Protocol Framework (AIPF)
draft-zahed-agent-comm-framework-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zaheduzzaman Sarker , Tirumaleswar Reddy.K , Kehan Yao , Dapeng Liu , Suresh Krishnan | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zahed-agent-comm-framework-01
individual submission Z. Sarker
Internet-Draft T. Reddy
Intended status: Informational Nokia
Expires: 20 January 2027 K. Yao
China Mobile
D. Liu
Alibaba Cloud
S. Krishnan
Cisco
19 July 2026
AI Agent Interoperable Protocol Framework (AIPF)
draft-zahed-agent-comm-framework-01
Abstract
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.
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 20 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarker, et al. Expires 20 January 2027 [Page 1]
Internet-Draft AIPF July 2026
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Current Protocol Landscape . . . . . . . . . . . . . . . . . 4
4. Framework Scope . . . . . . . . . . . . . . . . . . . . . . . 5
5. Design Philosophy . . . . . . . . . . . . . . . . . . . . . . 5
6. Framework Composition . . . . . . . . . . . . . . . . . . . . 6
6.1. Operational Flow . . . . . . . . . . . . . . . . . . . . 6
6.2. Framework Overview . . . . . . . . . . . . . . . . . . . 7
7. Discovery Aspects . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Aspects . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Agent Identity . . . . . . . . . . . . . . . . . . . . . 10
8.2. Channel Protection . . . . . . . . . . . . . . . . . . . 10
8.3. Intent-Execution Separation . . . . . . . . . . . . . . . 11
8.4. Delegation Chain Integrity . . . . . . . . . . . . . . . 11
8.5. Audit and Non-Repudiation . . . . . . . . . . . . . . . . 11
9. Transport protocols Aspects . . . . . . . . . . . . . . . . . 11
9.1. Delivery Semantics . . . . . . . . . . . . . . . . . . . 12
9.2. Message Exchange Patterns . . . . . . . . . . . . . . . . 12
9.3. Priority and Scheduling . . . . . . . . . . . . . . . . . 13
9.4. Multimodal Negotiation . . . . . . . . . . . . . . . . . 13
9.5. Structured Error and Progress Signaling . . . . . . . . . 13
9.6. Cancellation and Interruption . . . . . . . . . . . . . . 14
9.7. Multiple Communication topologies . . . . . . . . . . . . 14
10. Session Continuity . . . . . . . . . . . . . . . . . . . . . 14
11. Applicability of Existing IETF Work . . . . . . . . . . . . . 14
11.1. Profile or Extend . . . . . . . . . . . . . . . . . . . 15
11.2. New Protocol Work . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Sarker, et al. Expires 20 January 2027 [Page 2]
Internet-Draft AIPF July 2026
1. 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
[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 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.
Sarker, et al. Expires 20 January 2027 [Page 3]
Internet-Draft AIPF July 2026
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Current Protocol Landscape
Several industry-developed protocols address subsets of the agent
communication problem:
Model Context Protocol (MCP) [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]: 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]: 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:
1. No standardized mechanism for resolving agent identifiers to
network locations across domains.
2. No standardized cross-domain directory or federation mechanism
for capability-based agent discovery.
3. No defined delegation chain model for multi-hop cross-domain
agent authorization with cryptographic verifiability and fine
grained authorization.
4. No session state management with explicit resumption, timeout,
and migration semantics.
Sarker, et al. Expires 20 January 2027 [Page 4]
Internet-Draft AIPF July 2026
5. No multi-modal transport with per-stream reliability, ordering,
and latency semantics appropriate for real-time audio and video
alongside bulk data.
6. No standardized agent context document format or protocol for
secure context transfer during agent migration.
4. Framework Scope
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)
* Heterogeneous, multi-modal transport (Section 9)
* Long-lived session continuity (Section 10)
Without standards-based solutions, long-running and cross-domain
agent workflows cannot interoperate.
5. 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
Sarker, et al. Expires 20 January 2027 [Page 5]
Internet-Draft AIPF July 2026
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.
6. 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.
6.1. 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 [I-D.agentic-ai-usecases-requirements].
The operational flow for a complete interaction within this use case
proceeds as follows:
1. *Task Initiation*: A user provides a goal to e.g. an Orchestrator
Agent.
2. *Agent Selection*: The Orchestrator Agent uses discovery
protocols to discover candidate Sub-agents that have the
capabilities required for sub-tasks.
3. *Identity Establishment*: Before connecting, the Orchestrator
Agent obtains verifiable credentials for itself and verifies the
identity of the target Sub-agent.
4. *Authorization*: The Orchestrator Agent obtains an OAuth 2.0
delegation token scoped to the sub-task, derived from the
original user authorization.
Sarker, et al. Expires 20 January 2027 [Page 6]
Internet-Draft AIPF July 2026
5. *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.
6. *Session Creation*: Over the established transport protocol
connection, the Orchestrator Agent creates an Agent Session,
negotiating modalities, stream types, and session parameters.
7. *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.
8. *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.
9. *Task Completion*: The Orchestrator Agent receives results from
Sub-agents, synthesizes the final response, and delivers it to
the user. Sessions are gracefully terminated.
6.2. 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.
+--------------------+ +-------------------+
| User / App | | User / App |
+---------+----------+ +----------+--------+
| |
v v
+-----------------+ +-----------------+ +---------------+
| Agent (A) |<--->| Discovery |<---> | Agent (B) |
+---------+-------+ +-----------------+ +-------+-------+
| |
Sarker, et al. Expires 20 January 2027 [Page 7]
Internet-Draft AIPF July 2026
+----------------------+-----------------------+
|
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 |
+---------------------------------------------------------------+
Figure 1: Reference architecture
Sarker, et al. Expires 20 January 2027 [Page 8]
Internet-Draft AIPF July 2026
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.
7. 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)
Sarker, et al. Expires 20 January 2027 [Page 9]
Internet-Draft AIPF July 2026
* 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.
8. 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 [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].
8.1. 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. [I-D.klrc-aiagent-auth] 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.
8.2. 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.
Sarker, et al. Expires 20 January 2027 [Page 10]
Internet-Draft AIPF July 2026
8.3. 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.
8.4. 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.
8.5. 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.
9. 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
[I-D.agentic-ai-usecases-requirements]. The transport substrate is
Sarker, et al. Expires 20 January 2027 [Page 11]
Internet-Draft AIPF July 2026
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.
9.1. 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.
9.2. 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.
Sarker, et al. Expires 20 January 2027 [Page 12]
Internet-Draft AIPF July 2026
9.3. 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.
9.4. 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.
9.5. 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.
Sarker, et al. Expires 20 January 2027 [Page 13]
Internet-Draft AIPF July 2026
9.6. 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.
9.7. 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.
10. 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.
11. Applicability of Existing IETF Work
## Reuse As-Is
Sarker, et al. Expires 20 January 2027 [Page 14]
Internet-Draft AIPF July 2026
* 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.
11.1. 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.
[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.
* 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..
11.2. New Protocol Work
TBD
Sarker, et al. Expires 20 January 2027 [Page 15]
Internet-Draft AIPF July 2026
12. 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
Section 8.3 and Section 8.4, 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.
13. IANA Considerations
TBD
Acknowledgments
The authors thank Kehan Yao for the discussion and comments.
References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Sarker, et al. Expires 20 January 2027 [Page 16]
Internet-Draft AIPF July 2026
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
Informative References
[A2A] Google, "Agent2Agent Protocol Specification", 2025,
<https://a2a-protocol.org/v0.2.5/specification/>.
[ACP] BeeAI, "Agent Communication Protocol", 2025,
<https://agentcommunicationprotocol.dev/>.
[I-D.agentic-ai-usecases-requirements]
Reddy.K, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases
and Requirements", Work in Progress, Internet-Draft,
draft-agentic-ai-usecases-requirements-00, 22 May 2026,
<https://datatracker.ietf.org/doc/html/draft-agentic-ai-
usecases-requirements-00>.
[I-D.hardt-aauth-protocol]
Hardt, D., "AAuth Protocol", Work in Progress, Internet-
Draft, draft-hardt-aauth-protocol-02, 28 April 2026,
<https://datatracker.ietf.org/doc/html/draft-hardt-aauth-
protocol-02>.
[I-D.ietf-oauth-identity-chaining]
Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
M. J., Campbell, B., and A. Parecki, "OAuth Identity and
Authorization Chaining Across Domains", Work in Progress,
Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-identity-chaining-16>.
Sarker, et al. Expires 20 January 2027 [Page 17]
Internet-Draft AIPF July 2026
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-09, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-09>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J. A., Schwenkschuster, A.,
Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
Credentials", Work in Progress, Internet-Draft, draft-
ietf-wimse-workload-creds-02, 2 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[I-D.klrc-aiagent-auth]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
klrc-aiagent-auth-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
auth-03>.
[I-D.yao-catalist-problem-space]
Yao, K. and Z. Sarker, "Problem Space Analysis of AI Agent
Protocols in IETF", Work in Progress, Internet-Draft,
draft-yao-catalist-problem-space-analysis-01, March 2026,
<https://datatracker.ietf.org/doc/html/draft-yao-catalist-
problem-space-analysis-01>.
[MCP] Anthropic, "Model Context Protocol", 2024,
<https://modelcontextprotocol.io/specification>.
[RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/rfc/rfc9261>.
[RFC9750] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and
A. Duric, "The Messaging Layer Security (MLS)
Architecture", RFC 9750, DOI 10.17487/RFC9750, April 2025,
<https://www.rfc-editor.org/rfc/rfc9750>.
Authors' Addresses
Zaheduzzaman Sarker
Nokia
Email: zaheduzzaman.sarker@nokia.com
Sarker, et al. Expires 20 January 2027 [Page 18]
Internet-Draft AIPF July 2026
Tirumaleswar Reddy
Nokia
Email: k.tirumaleswar_reddy@nokia.com
Kehan Yao
China Mobile
Email: yaokehan@chinamobile.com
Dapeng Liu
Alibaba Cloud
Email: max.ldp@alibaba-inc.
Suresh Krishnan
Cisco
Email: suresh.krishnan@gmail.com
Sarker, et al. Expires 20 January 2027 [Page 19]