Agent Attachment Protocol
draft-dunbar-agent-attachment-00

Network Working Group                                   L. Dunbar
Internet Draft                                          Futurewei
Intended status: Informational                       K. Majumdar
Expires: September 2, 2026                              Oracle

                                                    March 2, 2026

                     Agent Attachment Protocol
                   draft-dunbar-agent-attachment-00

Abstract
   This document describes the Agent Attachment Protocol (AAP),
   a network-centric mechanism that enables autonomous agents to
   securely attach to an overlay network infrastructure. The
   protocol defines procedures for agent attachment, identity
   validation, capability exchange, and secure session
   establishment between an agent and its local network edge
   node. Once attached, agents can communicate with remote
   agents through the overlay formed by interconnected edge
   nodes, without exposing the underlying network topology.

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), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

xxx, et al.           Expires September 2, 2026         [Page 1]
Internet-Draft             Agent-Attachment

   The list of Internet-Draft Shadow Directories can be accessed
   at http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 27, 2026  .

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as
   the document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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 Simplified BSD
   License text as described in Section 4.e of the Trust Legal
   Provisions and are provided without warranty as described in
   the Simplified BSD License.

Table of Contents

   1. Introduction..............................................3
   2. Conventions used in this document.........................4
   3. Problem Statement.........................................5
   4. Architecture Overview.....................................6
   5. Agent Gateway Discovery and Attachment....................9
      5.1. Discovery Mechanisms.................................9
         5.1.1. Anycast-Based Discovery.........................9
         5.1.2. DHCP-Based Bootstrapping.......................10
         5.1.3. DNS-Based Discovery via Directory Service......10
      5.2. Offer and Selection.................................10
      5.3. Handshake and Registration..........................10
   6. Messaging Forwarding and Routing.........................11
      6.1. Transport Header....................................11
      6.2. MFT Lookup and Forwarding...........................11
   7. Session Maintenance and Teardown.........................12
      7.1. Stateful Attachment Model...........................12
      7.2. Stateless (Soft-State) Attachment Model.............13
      7.3. Interoperability Considerations.....................13
   8. End-to-End Security......................................13
   9. Security Considerations..................................14

Dunbar, et al.           Expires Dec 2, 2026            [Page 2]
Internet-Draft             Agent-Attachment

   10. Manageability Considerations............................14
   11. IANA Considerations.....................................14
   12. References..............................................14
      12.1. Normative References...............................14
      12.2. Informative References.............................14
   13. Acknowledgments.........................................14
   Appendix A:.................................................15

1. Introduction

  The Agent Attachment Protocol (AAP) defines a network centric
  mechanism that separates agent application logic from network
  attachment and forwarding functions. In this architecture,
  agents are identified by stable, location independent
  identifiers, while network edge nodes provide scalable,
  policy-controlled forwarding based on those identifiers.
  Agents attach to a local edge node, which serves as a domain
  boundary and provides access to an overlay network formed by
  interconnected edge nodes.

  AAP is limited to the attachment and access plane between an
  agent and its local network edge node. The protocol specifies
  procedures for agent discovery, secure attachment,
  authentication, capability exchange, session establishment,
  keepalive, and teardown. Once attached, agents communicate
  with remote agents via their respective network edge nodes,
  which forward messages based on transport-layer identifiers
  without inspecting, interpreting, or modifying application-
  layer content.

  The protocol is agnostic to the application layer messaging
  format (e.g., A2A, MCP, or other frameworks) and does not
  mandate specific end to end security mechanisms between
  agents. Agent Gateways operate solely on AAP transport headers
  and forwarding state, abstracting underlying network topology
  while enabling scalable identity-based forwarding.

  AAP supports operational requirements common to distributed
  agent systems, including mobility, multi-homing, and
  capability-based interaction. The protocol allows multiple
  bootstrap mechanisms for Agent to network edge discovery,
  including anycast based discovery, DHCP based provisioning,

Dunbar, et al.           Expires Dec 2, 2026            [Page 3]
Internet-Draft             Agent-Attachment

  and DNS based resolution. These discovery methods serve only
  as initial attachment mechanisms and do not alter the core
  attachment, authentication, and forwarding semantics defined
  in this document.

  AAP does not define inter-node overlay control-plane
  procedures or application-layer messaging semantics. Its scope
  is strictly limited to secure network attachment and transport
  enablement for agent communications in multi-domain
  environments.

2. Conventions used in this document
   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 BCP14 [RFC2119] [RFC8174] when, and only when,
   they appear in all
   capitals, as shown here.

   The following acronyms and terms are used in this document:

   Agent: An autonomous software entity identified by an Agent
               Identifier.

   Agent Gateway (GW): A network edge node that functions as
               messaging routers within the agentic overlay
               network that manages the Message Forwarding Table
               (MFT) and handles bit-level transport for agents.

   Directory Service: A capability registry that maps agent
               capabilities to the Agent ID.

   Message Forwarding Table (MFT): A forwarding table mapping
               Agent ID prefixes to local interfaces or next-hop
               Gateways.

Dunbar, et al.           Expires Dec 2, 2026            [Page 4]
Internet-Draft             Agent-Attachment

3. Problem Statement

   The rapid emergence of AI-driven services and autonomous
   software agents has created increasing demand for agent-to-
   agent communication across administrative domains, cloud
   providers, and heterogeneous network environments. These
   agents may reside in enterprise networks, edge locations, or
   public cloud infrastructures, and often require secure,
   policy-controlled communication with remote agents outside
   their local domain.

   Existing approaches typically rely on direct IP connectivity,
   application-layer messaging systems, or ad hoc overlay
   mechanisms. When agents span multiple domains, these
   approaches introduce several operational and architectural
   challenges. Direct connectivity models may expose internal
   endpoint addressing or topology information that operators
   prefer to abstract. There is no standardized mechanism to
   enforce forwarding or transport policies consistently across
   administrative boundaries. As the number of agents grows,
   maintaining direct connectivity models becomes operationally
   complex and difficult to scale. Additionally, current systems
   lack a common framework for secure agent attachment, identity
   validation, and gateway-mediated encrypted forwarding.

   This document considers an architecture in which Agent
   Gateways (Agent GWs) serve as domain boundary nodes. Agents
   attach to a local Agent GW, and Agent GWs establish secure
   connectivity with other Agent GWs. Collectively, the
   interconnected Agent GWs form an overlay network that
   abstracts the underlying IP infrastructure, similar in
   concept to an SD-WAN overlay. In this model, end-to-end agent
   messages remain encrypted, while Agent GWs forward messages
   based on transport headers and policy controls without
   requiring visibility into application-layer semantics.

   While emerging industry efforts (e.g., agent communication
   frameworks proposed by major cloud and networking vendors)
   demonstrate growing interest in agent-to-agent communication,
   many focus primarily on discovery, directory inquiry, or
   application-layer semantics. The problem addressed in this
   document is different: it focuses on defining a transport
   substrate between Agent Gateways. The goal is to provide a
   lightweight, secure, and policy-aware overlay messaging
   framework formed by Agent GWs that enables scalable

Dunbar, et al.           Expires Dec 2, 2026            [Page 5]
Internet-Draft             Agent-Attachment

   forwarding of encrypted agent-to-agent messages across
   domains.

   The objective of this work is therefore to define an
   interoperable overlay transport protocol between Agent
   Gateways that supports secure agent attachment, controlled
   message forwarding, and domain-level policy enforcement,
   without mandating application-layer behavior or directory
   services.

4. Architecture Overview

   Agent Gateway is a network edge node that functions as
   messaging routers within the agentic overlay network. They
   forward traffic based solely on information contained in the
   cleartext A2G transport header and local forwarding policy.
   Agent Gateways do not interpret, inspect, or modify
   application-layer payloads, and are not dependent on the
   semantics of the Agent-to-Agent (A2A) or MCP messaging
   carried within the transport.

   The Agent-to-Gateway (A2G) protocol establishes a logical
   messaging overlay that decouples an agent's identity and
   advertised capabilities from its physical network location.
   In this model, Agents are identified by stable AgentIDs,
   independent of IP addressing. In this model and the Agent
   Gateway (GW) acts as a specialized Messaging Router or
   Service Forwarder that anchors the agent's current network
   attachment and provides scalable, identity-based forwarding
   across the overlay.

   The architecture separates capability discovery from message
   delivery. A Directory Service provides "yellow-pages"
   functionality by mapping agent capabilities to stable Agent
   identifiers (AgentIDs). However, an agent's network
   attachment may change over time due to mobility, multi-
   homing, policy decisions, or operational conditions, and
   therefore cannot be reliably inferred from capability
   information alone.

   To address these dynamics, the A2G protocol defines a local
   discovery and handshake process in which an agent dynamically
   discovers an appropriate Agent Gateway, performs mutual
   authentication, and establishes a forwarding context. This
   attachment state is maintained at the Agent Gateway and
   reflected in its Message Forwarding Table (MFT), enabling

Dunbar, et al.           Expires Dec 2, 2026            [Page 6]
Internet-Draft             Agent-Attachment

   efficient routing based on AgentID while keeping discovery,
   identity, and forwarding responsibilities cleanly separated.

   +----------------------+           +-------------------+
   |  DIRECTORY SERVICE   |           |AGENT GATEWAY (GW) |
   |(Capability, AgentIDs)|           |(Dynamic Attachment|
   |                      |           |Msg Forwarding     |
   +----------^-----------+           +-----------+-------+
      (A)     |                                   |
Capability)   |       (B)                 (C)     | (D)
    INQUIRY   |TARGET AgentIDs       GW-DISCOVER  | GW-OFFER
              |                                   |
        +-----+-----------------------------------+-----+
        |                 [ AGENT A ]                   |
        +-----------------------+-----------------------+
                                |
                                | (E) ENCRYPTED MESSAGE
                                | [Header: Target AgentID]
                                v
                     +-----------------------+
                     |    MFT LOOKUP &       |
                     |     FORWARDING        |
                     +-----------------------+
           Figure 1: Key Components of Agent to GW Transport

   Legend:

   (A) Agent queries "Who has Skill X?"

   (B) Directory returns "Agent B (AgentID-456)"

   (C) Agent initiates an Agent Gateway discovery process to locate an
   appropriate local Agent Gateway that serves as its ingress point to
   the agentic overlay network.

   (D) An Agent Gateway responds with a GW-OFFER, providing connection
   parameters and supported features. The Agent selects a Gateway and
   completes authentication and registration.

   (E) Once attached, the Agent sends end-to-end messages containing a
   cleartext transport header with the Target AgentID and an
   application-layer payload. In most practical deployments, the A2A
   or MCP messaging carried within the payload is expected to be
   encrypted; however, this is independent of A2G-MTP. The Agent
   Gateway performs a lookup in its Message Forwarding Table (MFT) and

Dunbar, et al.           Expires Dec 2, 2026            [Page 7]
Internet-Draft             Agent-Attachment

   forwards the payload, without inspecting or interpreting its
   contents, toward the Gateway currently serving the target agent.

   The following steps illustrate the high-level operation of
   the Agent-to-Agent Gateway transport:

     o Capability Discovery:
        Agent performs an out-of-band inquiry to the Directory
        Service ((e.g., "find an agent capable of JSON-to-XML
        translation")). The Directory Service returns one or
        more Target Agent IDs that satisfy the request. At this
        stage, the Agent identifies which agent(s) it intends to
        communicate with, but does not yet have information
        about where those agents are currently attached in the
        network. The mechanism used for this capability inquiry
        is outside the scope of this document.

     o Gateway Discovery:
        After identifying the target Agent ID(s), the Agent
        initiates an Agent Gateway discovery process by sending
        a GW-DISCOVER message (e.g., via anycast or other
        supported bootstrap mechanisms). One or more reachable
        Agent Gateways respond with GW-OFFER messages containing
        the Gateway identifier and connection parameters (such
        as a gRPC endpoint and supported features)

     o Handshake and Registration:
        The Agent selects an Agent Gateway and performs a mutual
        authentication handshake, providing its Agent ID and
        cryptographic proof of identity. Upon successful
        validation, the Agent Gateway establishes an attachment
        context and registers the Agent in its local Message
        Forwarding Table (MFT).

     o Message Forwarding and Table Management:
        Once attached, the Agent initiates messaging sessions by
        sending end-to-end payloads. Each message includes a
        cleartext A2G transport header that carries the Source
        Agent ID and Target Agent ID.

        Upon receiving a message, the Agent Gateway does not
        inspect the payload. Instead, it performs a lookup on
        the Target Agent ID in its MFT. If a matching entry
        exists, the Gateway forwards the message to the

Dunbar, et al.           Expires Dec 2, 2026            [Page 8]
Internet-Draft             Agent-Attachment

        appropriate local interface or next-hop Agent Gateway.
        If no entry is found, the Gateway may invoke a route-
        discovery procedure (outside the scope of this document)
        to locate the Gateway currently serving the target
        agent.

        The MFT is updated dynamically as agents attach, detach,
        or move, reflecting the evolving attachment state of the
        agentic overlay network.

5. Agent Gateway Discovery and Attachment

   In a dynamic environment, an Agent cannot assume a static
   configuration for its messaging ingress. An Agent's network
   attachment may change over time due to mobility, multi-
   homing, policy decisions, or deployment constraints.
   Therefore, A2G-MTP defines a Gateway discovery and attachment
   procedure that allows an Agent to identify an appropriate
   Agent Gateway and establish a forwarding context.

   This document supports multiple mechanisms for discovering an
   Agent Gateway. These mechanisms are treated as bootstrap
   options and do not alter the attachment, authentication, or
   forwarding semantics defined in subsequent sections.

5.1. Discovery Mechanisms

   An Agent MAY use one or more of the following mechanisms to
   discover a candidate Agent Gateway:

5.1.1. Anycast-Based Discovery

   An Agent MAY discover a local ingress Gateway by sending a
   GW-DISCOVER message to a well-known routable anycast address.
   The discovery message includes the Agent's ID and a nonce.

   Any Agent Gateway reachable via the anycast address MAY
   respond with a GW-OFFER message. Anycast-based discovery
   enables topology-aware selection of a nearby Gateway without
   requiring pre-configuration.

Dunbar, et al.           Expires Dec 2, 2026            [Page 9]
Internet-Draft             Agent-Attachment

5.1.2. DHCP-Based Bootstrapping

   In managed access networks, the Agent Gateway MAY be co-
   located with, or designated by, the IP gateway for the
   Agent's access network. In such environments, DHCP MAY be
   used to provide the Agent with unicast bootstrap information
   for an Agent Gateway, such as an IP address, FQDN, or service
   endpoint.

   DHCP-based information MUST be treated as advisory. The Agent
   MUST still perform the authentication and registration
   procedures defined in Section 4.3 before establishing an
   attachment.

5.1.3. DNS-Based Discovery via Directory Service

   The Directory Service MAY return a stable Agent Gateway
   service identifier (e.g., URL or FQDN) to the Agent as part
   of the capability discovery process. The Agent MAY use DNS
   resolution (including anycast or load-balanced DNS) to obtain
   a reachable Agent Gateway unicast address.

   DNS-based discovery provides scalable, multi-hop reachability
   but does not replace the explicit attachment and
   authentication procedures defined by A2G-MTP.

5.2. Offer and Selection

   For discovery mechanisms that involve Gateway responses
   (e.g., anycast-based discovery), an Agent Gateway responds
   with a GW-OFFER message containing:

        o Gateway identifier
        o Transport endpoint (e.g., gRPC URI)
        o Supported transport features

   The Agent selects one Gateway based on local policy and
   proceeds with the attachment procedure.

5.3. Handshake and Registration

   The Agent initiates a mutual authentication handshake with
   the selected Agent Gateway, providing its Agent ID and
   cryptographic proof of identity. Upon successful validation,
   the Agent Gateway establishes an attachment context and
   assigns a Session Context, analogous to a DHCP lease.

Dunbar, et al.           Expires Dec 2, 2026           [Page 10]
Internet-Draft             Agent-Attachment

   The Agent Gateway then registers the Agent in its local
   Message Forwarding Table (MFT), enabling message forwarding
   for the duration of the attachment.

   Regardless of the discovery mechanism used, the handshake,
   authentication, registration, and forwarding behavior defined
   by A2G-MTP remain identical.

6. Messaging Forwarding and Routing

     The Agent GW serves as the switching and forwarding engine
     for the agentic overlay network. Each Agent Gateway
     maintains a MFT that maps Agent IDs (or Agent ID prefixes)
     to local attachment or next-hop Agent Gateways. The MFT
     reflects the dynamic attachment state of agents and is
     updated as agents attach, detach, or move.

6.1. Transport Header

   Each message sent by an Agent carries a cleartext A2G
   transport header that enables forwarding without exposing
   application semantics. The transport header includes the
   following fields:

     o Target Agent ID (or prefix)
     o Message Identifier
     o TTL
     o End-to-End Security Context Identifier

   In most deployments, application data and higher-layer
   semantics are encrypted end-to-end between agents and are
   opaque to Agent Gateways.

6.2. MFT Lookup and Forwarding

     Ingress Processing: When an Agent sends a message, it
     includes a clear-text A2G Header containing the Target
     Agent ID, which was obtained earlier from the capability
     discovery. The encrypted payload is encapsulated without
     modification by the Agent.

     Forwarding Logic: Upon receiving a message, the Agent
     Gateway performs an exact-match (or prefix-match, if
     supported) lookup on the Target Agent ID in its MFT.

Dunbar, et al.           Expires Dec 2, 2026           [Page 11]
Internet-Draft             Agent-Attachment

       o If the target is attached to the same Gateway, the
          Gateway forwards the encrypted payload to the
          corresponding local attachment.
       o If the target is attached to a remote Gateway, the
          Gateway forwards the encrypted payload to the next-hop
          Agent GW.

     If no matching MFT entry exists, the Gateway MAY invoke a
     route-discovery or resolution procedure to locate the
     Gateway currently serving the target Agent; such procedures
     are outside the scope of this document.

     Payload Confidentiality: Agent GW does not inspect,
     decrypt, or interpret the message body. The GW only
     forwards messages solely based on the information contained
     in the cleartext transport header.

7. Session Maintenance and Teardown

   The relationship between the Agent and the GW may be stateful
   or stateless (soft state), depending on deployment
   requirements and implementation choices. In both cases, the
   attachment is ephemeral and reflects the Agent's current
   network presence.

7.1. Stateful Attachment Model

   In a stateful attachment model, the Agent Gateway maintains
   explicit session state for each attached Agent.

   Keep-Alives: An attached Agent periodically sends "Heartbeat"
   messages to the GW to indicate continued presence. If
   heartbeats are not received within a configured interval, the
   GW marks the corresponding MFT entry as Stale and eventually
   remove it.

   Explicit Release: When an Agent finishes its task or intends
   to detach, it sends a Session-End signal to the Gateway. Upon
   receipt, the Gateway removes the Agent's entry from its MFT
   and MAY notify Gateways to tear down the corresponding
   forwarding state.

Dunbar, et al.           Expires Dec 2, 2026           [Page 12]
Internet-Draft             Agent-Attachment

7.2. Stateless (Soft-State) Attachment Model

   In a soft-state attachment model, the Gateway does not rely
   on explicit session teardown and instead treats attachment
   state as time-bounded.

     o MFT entries are created with a lifetime and expire
        automatically unless refreshed.
     o Periodic data traffic or lightweight refresh messages
        MAY implicitly renew the attachment.
     o Absence of traffic or refreshes results in automatic
        removal of stale MFT entries without requiring explicit
        Session-End signaling.

   The soft-state model reduces signaling overhead and is well
   suited for large-scale or highly dynamic environments where
   explicit session management may be impractical.

7.3. Interoperability Considerations

   Regardless of whether a stateful or soft-state model is used,
   the forwarding behavior defined in Section 5 remains
   unchanged. Gateways forward messages based on current MFT
   entries and do not depend on application-layer semantics.

   Implementations MAY support one or both attachment models,
   provided that stale attachment state is removed in a timely
   manner to prevent mis-delivery.

8. End-to-End Security

   A2G-MTP is agnostic to the application-layer messaging
   protocol used between Agents (e.g., A2A, MCP) and does not
   mandate whether Agent-to-Agent communications are encrypted.
   In most practical deployments, such communications are
   expected to be protected using end-to-end encryption.

   When end-to-end security is employed, the selected mechanism
   is responsible for providing confidentiality, integrity
   protection, replay protection, and sender authentication
   between communicating Agents.

   Agent Gateways operate solely on the cleartext A2G transport
   header for forwarding decisions. Agent Gateways MUST NOT

Dunbar, et al.           Expires Dec 2, 2026           [Page 13]
Internet-Draft             Agent-Attachment

   decrypt, inspect, or modify application layer payloads and
   are not participants in application-layer security contexts.

   The specific end-to-end security protocol used between Agents
   is outside the scope of this document. Any selected mechanism
   SHOULD provide mutual authentication and cryptographic
   binding between the Agent identity and the protected message
   content.

9. Security Considerations

   TBD.

10. Manageability Considerations

        TBD

11. IANA Considerations

   TBD

12. References

12.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References

   .

13. Acknowledgments

   Acknowledgements to xxx for their extensive review and
   suggestions.

   This document was prepared using 2-Word-v2.0.template.dot.

Dunbar, et al.           Expires Dec 2, 2026           [Page 14]
Internet-Draft             Agent-Attachment

Appendix A:

Authors' Addresses

   Linda Dunbar
   Futurewei
   Email: ldunbar@futurewei.com

   Kausik Majumdar
   Oracle
   Email: kausik.majumdar@oracle.com

Contributors' Addresses

Dunbar, et al.           Expires Dec 2, 2026           [Page 15]