Skip to main content

AI Agent Discovery (AID) Problem Statement
draft-mozley-aidiscovery-00

Document Type Active Internet-Draft (individual)
Authors Jim Mozley , Nic Williams , Behcet Sarikaya , Roland Schott
Last updated 2025-10-15
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-mozley-aidiscovery-00
Network Working Group                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Informational                            Infoblox, Inc.
Expires: 18 April 2026                                       B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telekom
                                                         15 October 2025

               AI Agent Discovery (AID) Problem Statement
                      draft-mozley-aidiscovery-00

Abstract

   With the deployment of AI agents comes a need for mechanisms to
   support agent-to-agent discovery.  This document presents
   requirements and considerations for agent-to-agent discovery.

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 18 April 2026.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Mozley, et al.            Expires 18 April 2026                 [Page 1]
Internet-Draft                   AID PS                     October 2025

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  Scope of Discovery Processes  . . . . . . . . . . . . . . . .   2
   4.  Autonomy and Governance . . . . . . . . . . . . . . . . . . .   4
   5.  Agent Registration Advertisement and Discovery  . . . . . . .   4
   6.  Regulation and Compliance Features  . . . . . . . . . . . . .   5
   7.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Schema Evolution  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Abuse . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   10. Connectivity  . . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Attestation and Provenance  . . . . . . . . . . . . . . . . .   6
   12. Challenges with Existing Proposed Mechanisms  . . . . . . . .   6
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   15. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   AI Agents play a crucial role in modern telecommunications by
   enabling intelligent automation, decision-making, and adaptive
   network management.  These agents are software-driven entities that
   leverage artificial intelligence, including machine learning and
   natural language processing, to interact with users, applications,
   and network components.

   Organisations require robust automatable mechanisms for the secure
   advertisement and discovery of AI agents on public and private
   networks.

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.  Scope of Discovery Processes

   The scope of the agent-to-agent discovery could include:

   *  Dynamic registration, deregistration, and advertisement of agent
      capability

Mozley, et al.            Expires 18 April 2026                 [Page 2]
Internet-Draft                   AID PS                     October 2025

   *  Context-aware discovery by other agents (domain, geography,
      operational constraints like batch versus real-time)

   *  Standardisation of the discovery process with privacy preservation

      -  Having a known entry point such as an index of an
         organisation's agents

   *  Standard schemas to describe agent capabilities

      -  Versioning and lifecycle management

   *  Resiliency in advertising agents

   *  Ensuring trust and verification mechanisms built into the
      discovery process

   *  Using the same mechanisms on both public and private networks

   *  Interoperability and integration with existing technologies and
      datasets (backward compatability)

   Considerations and constraints on these processes may include:

   *  Organisations needing control over the process of advertising
      their agents

   *  Scalability owing to the large number of agents

   *  Energy and resource efficiency

   *  Adversarial use of agents (i.e. using inputs from an index to
      modify agent reasoning)

   *  Agent decision variance based on temperature, context, or model
      state

   *  Requirements for organisations and agents to operate independently

   *  Legislation and regulatory frameworks that could include
      constraints such as sovereignty of data and operational
      considerations (human in the loop governance)

   *  Legal issues with ownership of names and brands, or having
      mechanisms to deal with disputes

   *  Ethical concerns with respect to agent capabilities, access, and/
      or advertised metadata

Mozley, et al.            Expires 18 April 2026                 [Page 3]
Internet-Draft                   AID PS                     October 2025

4.  Autonomy and Governance

   Due to the wide range of services agents could be used for,
   organisations will need autonomy when advertising agents and may need
   to work within regulatory frameworks that stipulate such things as
   operational requirements and sovereignty of data, or such regulations
   may not be acceptable to some organisations.  Discovery mechanisms
   will need to allow each organisation to publish its own agents'
   capabilities independently of others.  A centralised directory of all
   possible public agents does not facilitate this.  An adversarial
   centralized directory is also able to stifle competitor advertisement
   capabilities.  The needed autonomy ensures that discovery remains
   resilient to governance disputes, competitive interference, and
   jurisdictional constraints.

   Given that organisations will need to be autonomous but still
   facilitate agents discovering other agents and being able to
   communicate securely with them, a well known entry point is needed.
   This further allows organizations to delegate authority to others for
   specific jobs or capabilities.

5.  Agent Registration Advertisement and Discovery

   Organisations will need to advertise agents and their capabilities to
   other entities via a predictable entry point.  This will facilitate
   any entity's agents discovering the organisation's agent
   capabilities, and subsequently performing any verification, tests
   prior to initiating service provided by the agent.  To achieve this,
   the entry point MUST be based on a mechanism that is both ubiquitous
   and interoperable across public and private networks.

   It is likely this will mean a directory service at or referenced by
   the entry point that an organisation uses to describe agent
   capabilities based on a standard schema.

   Once an agent discovers another agent e.g. via a directory service,
   it will communicate with it using protocols such as (A2A, MCP, ACP,
   etc.) via properties it has discovered from the index service.

   All communication will need to be secured through public key
   infrastructure mechanisms.  While in-process agent communication
   avoids network concerns (co-located agents), any external, cross-host
   agent interaction still routes through existing network
   infrastructure requiring the entry point.

Mozley, et al.            Expires 18 April 2026                 [Page 4]
Internet-Draft                   AID PS                     October 2025

6.  Regulation and Compliance Features

   Services provided by agents may be subject to legislation and
   regulation because they are time critical, relate to health care,
   financial in nature, etc.  The agent discovery process, protocols and
   communication will need to take this into account as otherwise
   organizations will not be able to deploy them.

   Compliance considerations include, but are not limited to,
   availability, auditability, and security.  Discovery protocols MUST
   provide mechanisms to ensure high availability, as service outages in
   regulated environments can have severe legal and operational
   consequences.  Similarly, auditability MUST be supported through
   verifiable logging of discovery and registration events, enabling
   organizations to demonstrate compliance during regulatory reviews or
   incident investigations.  These should be considered during the
   choices of using existing protocols or developing new ones for agent
   discovery to avoid barriers to implementation.

7.  Scalability

   Given the large number of agents, volume of transactions, legal and
   regulatory considerations, the discovery mechanisms need to be both
   highly scalable and devolved to the organizations advertising agent
   capabilities.  Any solution that introduces centralized bottlenecks
   or single points of failure is inherently unsuitable for this
   purpose, which should also be weighed for how a solution is
   developed.

8.  Schema Evolution

   Agents will advertise machine-readable capabilities that evolve over
   time.  The discovery system MUST support explicit versioning, content
   negotiation, and backward compatible evolution of capability schemas.
   It MUST place constraints on payload size and complexity to ensure
   efficient transport and caching while allowing extensibility for
   domain-specific metadata.  Mechanisms for deprecation, sunset
   notices, and compatibility matrices are needed to prevent negotiation
   failures at runtime.

9.  Abuse

   Open discovery surfaces are targets for abuse including amplification
   attacks, scraping, and denial of service.  The system MUST support
   rate limiting, request authentication when appropriate, abuse
   detection, and response shaping to minimize amplification potential.
   Economic considerations, such as preventing cost shifting to
   responders and preserving fairness across tenants, SHOULD be

Mozley, et al.            Expires 18 April 2026                 [Page 5]
Internet-Draft                   AID PS                     October 2025

   incorporated into protocol and operational guidance.

10.  Connectivity

   Discovery alone is insufficient without practical reachability.  The
   problem statement SHOULD acknowledge challenges introduced by NATs,
   carrier-grade NAT, firewalls, split-horizon networks, and dual-stack
   IPv4/IPv6 environments.  Agents may exist behind egress-only
   boundaries or at the edge with intermittent connectivity.  The system
   MUST not assume stable, symmetric, or publicly routable paths and
   SHOULD define expectations for relay, proxy, or rendezvous patterns
   where direct connectivity is infeasible.

11.  Attestation and Provenance

   Agents may be required to prove properties about their software and
   runtime environment.  The discovery layer SHOULD carry or reference
   attestations such as software bill of materials, model/version
   identifiers, supply-chain provenance, or trusted-execution
   environment evidence.  Safety classifications, permissible-use
   statements, and risk tiers can be part of discovery metadata to
   enable policy-aware client behavior.

12.  Challenges with Existing Proposed Mechanisms

   Several alternative approaches to agent discovery have been proposed,
   including centralized registries, blockchain-based naming systems,
   and proprietary service directories.  While these models may offer
   novel features, they introduce significant architectural,
   operational, and governance challenges.  Centralized registries
   concentrate control and introduce single points of failure, limiting
   resilience and scalability.

   Blockchain-based systems often lack integration with existing
   internet infrastructure, suffer from latency and cost constraints,
   and present jurisdictional ambiguity due to decentralized governance.
   Proprietary directories fragment the discovery ecosystem and inhibit
   interoperability across agent frameworks and administrative domains.
   Furthermore, organizations securely delegating authority to AI
   solution providers requires interfacing between this central
   authority as opposed to business-to-business which can be used to
   suppress innovation.

Mozley, et al.            Expires 18 April 2026                 [Page 6]
Internet-Draft                   AID PS                     October 2025

   The introduction of a novel discovery protocol would require the
   establishment of new governance structures, security models, and
   operational tooling.  Early implementations would likely be
   centralized among a limited set of stakeholders, introducing
   bottlenecks in protocol evolution and risk mitigation, and could
   result in centralization.

13.  Security Considerations

   All agent discovery mechanisms need to be secured through public key
   infrastructure.

   All agent discovery mechanisms need to have thread detection.

   All agent discovery mechanisms and security mechanisms need to work
   in real-time.

   All agent discovery mechanisms need to use standardized interfaces or
   APIs in case external security instances are used.

   Protection needed against * DoS attacks * Unauthorized access and
   control * Secure communication framework e.g., TLS 1.3 etc.  *
   Continuous monitoring of the agent discovery mechanism

14.  IANA Considerations

   This document has no IANA actions.

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

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Jim Mozley
   Infoblox, Inc.
   Email: jmozley@infoblox.com

Mozley, et al.            Expires 18 April 2026                 [Page 7]
Internet-Draft                   AID PS                     October 2025

   Nic Williams
   Infoblox, Inc.
   Email: nic@infoblox.com

   Behcet Sarikaya
   Unaffiliated
   Email: sarikaya@ieee.org

   Roland Schott
   Deutsche Telekom
   Email: roland.schott@telekom.de

Mozley, et al.            Expires 18 April 2026                 [Page 8]