# drafts

name: draft-srijal-agents-policy
rev: 00
title: AGENTS.TXT: Strict Policy File for Automated Clients
time: 2026-04-10T07:09:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-10T15:18:17Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604202+00:00
source: ietf
abstract:
  This document specifies the AGENTS.TXT protocol, a strict plaintext
     policy file for automated clients, bots, and crawlers.  It defines
     directives, top-line hash verification, optional parameters, and
     mandatory failure behavior for malformed files.  Malformed files are
     treated as fully restrictive to prevent unintended access.

full_text:
  Network Working Group                                           S. Dutta
  Internet-Draft                                               Independent
  Intended status: Standards Track                          7 October 2025
  Expires: 10 April 2026


            AGENTS.TXT: Strict Policy File for Automated Clients
                       draft-srijal-agents-policy-00

  Abstract

     This document specifies the AGENTS.TXT protocol, a strict plaintext
     policy file for automated clients, bots, and crawlers.  It defines
     directives, top-line hash verification, optional parameters, and
     mandatory failure behavior for malformed files.  Malformed files are
     treated as fully restrictive to prevent unintended access.

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




  Dutta                     Expires 10 April 2026                 [Page 1]


  Internet-Draft                 AGENTS.TXT                   October 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  File Location and Name  . . . . . . . . . . . . . . . . . . .   2
     3.  File Format . . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.  Comments and Metadata . . . . . . . . . . . . . . . . . . . .   3
     5.  Agent Behavior on Malformed Files . . . . . . . . . . . . . .   3
     6.  Directive Syntax  . . . . . . . . . . . . . . . . . . . . . .   3
     7.  Hash Computation  . . . . . . . . . . . . . . . . . . . . . .   3
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     9.  Example agents.txt File . . . . . . . . . . . . . . . . . . .   3
     10. Additional Guidance . . . . . . . . . . . . . . . . . . . . .   4
     11. Normative References  . . . . . . . . . . . . . . . . . . . .   4
     Appendix A.  Authors' Addresses . . . . . . . . . . . . . . . . .   5
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     AGENTS.TXT is a strict policy file format for automated clients,
     similar in purpose to robots.txt (RFC9309) but providing more control
     over client behavior.  Malformed files are treated as completely
     restrictive.

     All AGENTS.TXT traffic validation is based on a SHA-256 hash (FIPS
     180-4 (FIPS180-4)) of the canonical directive content.

  2.  File Location and Name

     The canonical path for the file is /agents.txt.  Files must be served
     as UTF-8 with content-type text/plain (HTTP/1.1 Semantics (RFC7231)).

  3.  File Format

     The first non-comment, non-empty line MUST be the hash line, starting
     with '*' followed by the lowercase SHA-256 hex digest of the file
     excluding the hash line and comments (SHA-1 comparison (RFC3174) for
     historical reference).  Subsequent lines are directives:

     /status ALLOW

     /dashboard ALLOW limit=50

     /admin DISALLOW








  Dutta                     Expires 10 April 2026                 [Page 2]


  Internet-Draft                 AGENTS.TXT                   October 2025


  4.  Comments and Metadata

     Lines starting with '#' are comments and ignored for hash computation
     and parsing.  Metadata such as version, generated-by, or grace-period
     may be included.

  5.  Agent Behavior on Malformed Files

     Any hash missing, hash mismatch, or directive syntax error MUST
     result in treating the entire site as restricted (RFC 2119 (RFC2119)
     requirements).  Cached copies MUST be invalidated.

  6.  Directive Syntax

     Each directive line has the format: <path> <action> [params...]

     <path> starts with '/', <action> is ALLOW or DISALLOW, and optional
     params are key=value pairs (URI syntax (RFC3986)).

  7.  Hash Computation

     Compute SHA-256 over UTF-8 bytes of the file after removing the hash
     line, comments, and blank lines.  Join remaining lines with '\n' for
     hashing.

  8.  Security Considerations

     Strict malformed-file behavior ensures accidental exposure does not
     occur.  Site operators must ensure valid files to prevent clients
     from blocking themselves (TLS Best Practices (RFC7525)).

  9.  Example agents.txt File

     # version: 1.0

     *e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 \

     #sample. may not be accurate.

     /status ALLOW

     /dashboard ALLOW limit=50

     /admin DISALLOW







  Dutta                     Expires 10 April 2026                 [Page 3]


  Internet-Draft                 AGENTS.TXT                   October 2025


  10.  Additional Guidance

     Clients SHOULD follow HTTP client best practices (RFC8792) and API
     crawler guidelines (RFC8899) when interpreting AGENTS.TXT directives.
     Use of AGENTS.TXT aims to reduce accidental site disruption (Bot
     traffic management (RFC8309)).

  11.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [FIPS180-4]
                Technology, N. I. O. S. A., "SHA-256 Secure Hash
                Standard", 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/
                NIST.FIPS.180-4.pdf>.

     [RFC9309]  McCarthy, A., "Robots.txt: History, Use, and
                Standardization", 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

     [RFC7231]  Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1):
                Semantics and Content", 2014,
                <https://www.rfc-editor.org/rfc/rfc7231>.

     [RFC3174]  Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", 2001,
                <https://www.rfc-editor.org/rfc/rfc3174>.

     [RFC3986]  Berners-Lee, T., "Uniform Resource Identifier (URI):
                Generic Syntax", 2005,
                <https://www.rfc-editor.org/rfc/rfc3986>.

     [RFC7525]  Rescorla, E., "Recommendations for Secure Use of Transport
                Layer Security (TLS) and Datagram TLS (DTLS)", 2015,
                <https://www.rfc-editor.org/rfc/rfc7525>.

     [RFC8309]  Pahl, C., "Bot Traffic and Management Best Practices",
                2018, <https://www.rfc-editor.org/rfc/rfc8309>.

     [RFC8792]  Smith, J., "HTTP Client Best Practices for Automated
                Agents", 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

     [RFC8899]  Tan, L., "Guidelines for Secure API Crawlers", 2021,
                <https://www.rfc-editor.org/rfc/rfc8899>.






  Dutta                     Expires 10 April 2026                 [Page 4]


  Internet-Draft                 AGENTS.TXT                   October 2025


  Appendix A.  Authors' Addresses

     Srijal Dutta

     Email: srijaldutta.official+agentstxt@gmail.com

  Author's Address

     Srijal Dutta
     Independent
     Email: srijaldutta.official+agentstxt@gmail.com








































  Dutta                     Expires 10 April 2026                 [Page 5]


name: draft-liang-agentdns
rev: 00
title: AgentDNS: A Root Domain Naming System for LLM Agents
time: 2026-04-11T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-12T02:15:50Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604207+00:00
source: ietf
abstract:
  This document describes AgentDNS, a root domain naming and service
     discovery system designed for Large Language Model (LLM) agents.
     Inspired by the traditional Domain Name System (DNS), AgentDNS
     enables agents to autonomously discover, resolve, and securely invoke
     third-party agent and tool services across different vendors.
     AgentDNS introduces a unified namespace, semantic service discovery,
     protocol-aware interoperability, and unified authentication and
     billing.  The system aims to address interoperability, service
     discovery, and trust management challenges in large-scale agent
     collaboration ecosystems.

full_text:
  Internet Engineering Task Force                            Z. Liang, Ed.
  Internet-Draft                                                    E. Cui
  Intended status: Informational          China Telecom Research Institute
  Expires: 12 April 2026                                          Y. Cheng
                              University of Science and Technology Beijing
                                                            9 October 2025


            AgentDNS: A Root Domain Naming System for LLM Agents
                          draft-liang-agentdns-00

  Abstract

     This document describes AgentDNS, a root domain naming and service
     discovery system designed for Large Language Model (LLM) agents.
     Inspired by the traditional Domain Name System (DNS), AgentDNS
     enables agents to autonomously discover, resolve, and securely invoke
     third-party agent and tool services across different vendors.
     AgentDNS introduces a unified namespace, semantic service discovery,
     protocol-aware interoperability, and unified authentication and
     billing.  The system aims to address interoperability, service
     discovery, and trust management challenges in large-scale agent
     collaboration ecosystems.

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

  Copyright Notice

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






  Liang, et al.             Expires 12 April 2026                 [Page 1]


  Internet-Draft              Abbreviated Title               October 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  AgentDNS Architecture . . . . . . . . . . . . . . . . . . . .   7
       3.1.  AgentDNS System Overview  . . . . . . . . . . . . . . . .   7
       3.2.  Service Naming  . . . . . . . . . . . . . . . . . . . . .  10
       3.3.  Service Discovery . . . . . . . . . . . . . . . . . . . .  10
       3.4.  Service Resolution  . . . . . . . . . . . . . . . . . . .  11
       3.5.  Unified Authentication and Billing  . . . . . . . . . . .  12
     4.  AgentDNS Case Study . . . . . . . . . . . . . . . . . . . . .  13
     5.  Future Opportunities  . . . . . . . . . . . . . . . . . . . .  15
     6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     The rapid evolution of LLM agents across industries has introduced
     new challenges in enabling seamless multi-agent collaboration.
     Existing protocols such as the Model Context Protocol (MCP)
     [MCP-Spec] and Agent-to-Agent (A2A) protocol [A2A-Spec] have improved
     agent-tool interoperability and communication.  However, these
     efforts lack a standardized root naming and discovery infrastructure
     to support autonomous cross-vendor interactions.  As a result,
     collaborations between agents still demands significant manual
     effort, preventing the realization of true autonomous cooperation.
     The specific challenges are as follows:

     *  *The Service Discovery Challenge:* LLM agents typically generate
        an action plan, where each action may require calling external
        tools or agent services [RFC6763].  However, currently, services
        from different vendors are not standardized in naming or
        management, which forces developers to manually maintain service
        information for each tool or agent.  This lack of standardization



  Liang, et al.             Expires 12 April 2026                 [Page 2]


  Internet-Draft              Abbreviated Title               October 2025


        makes it impossible for LLM agents to autonomously discover other
        agents or tool services, hindering seamless integration and
        collaboration between agents across different platforms.

     *  *The Interoperability Challenge:* Currently, different vendors'
        agents or tool services support various interoperability or
        communication protocols, with typical examples including MCP, A2A,
        and ANP (Agent Network Protocol Project 2025) [ANP-Doc].  We
        anticipate that more interoperability protocols will emerge in the
        future.  However, LLM agents are unable to autonomously recognize
        and adapt to these differences, meaning they still require manual
        configuration and management.  This lack of flexibility in
        handling diverse protocols limits seamless agent-to-agent and
        agent-to-tool communication across platforms.

     *  *The Authentication and Billing Challenge:* Cross-vendor
        collaboration is further complicated by security and
        authentication challenges.  Each service provider typically
        requires proprietary API keys, necessitating manual configuration
        of multiple authentication credentials for agents.  This adds
        significant overhead and disrupts seamless integration.  In
        addition, billing systems are fragmented across vendors, requiring
        manual intervention for payment setup.  As a result, agents are
        unable to autonomously discover and invoke new third-party paid
        agents or tool services without manual configuration.

     To address these challenges, this document introduces AgentDNS, the
     first root domain naming and resolution system designed for LLM
     agents.  Inspired by the Internet's DNS [RFC1035], AgentDNS
     introduces a unified namespace (*agentdns://*), natural language-
     based service discovery, and unified authentication and billing.  As
     shown in Figure 1, AgentDNS is compatible with protocols such as MCP
     and A2A, allowing them to coexist seamlessly.

     <preamble>:Illustrates the interaction between AgentDNS, A2A protocol, MCP, LLMs, and
               enterprise applications across different agent frameworks.
          














  Liang, et al.             Expires 12 April 2026                 [Page 3]


  Internet-Draft              Abbreviated Title               October 2025


                  +-------------------------------------------+
                  | | AgentDNS Root Server |                  |
                  | +----------------------+   AgentDNS DB    |
                  | |         LLM          |                  |
                  +-----------+-------------------------------+
                                           |
                           +---------------+--------------+
                           |               |              |
                           v               |              v
                +--------------------+    A2A    +--------------------+
                | Agents (Vendor A)  | <-------> | Agents (Vendor B)  |
                | +----------------+ |     |     | +----------------+ |
                | | Agent Framework| |     |     | | Agent Framework| |
                | +----------------+ |     |     | +----------------+ |
                | |       LLM      | |     |     | |       LLM      | |
                +--------------------+     |     +--------------------+
                        |                  |               |
                       MCP                 |              MCP
                        |                  |               |
                        v                  |               v
            +--------------------------+   |    +--------------------------+
            | API & Enterprise Systems |   |    | API & Enterprise Systems |
            +--------------------------+   |    +--------------------------+
                                           |
                         Organizational / Technological Boundary

     Figure 1: AgentDNS system and its relationship with A2A and MCP
                                Protocols

     With AgentDNS, agents can autonomously discover services,
     authenticate, and interoperate seamlessly across organizational
     boundaries.  AgentDNS redefines the multi-agent collaboration
     ecosystem through four key functions:

     *  *Unified Namespace with Semantic Information:* AgentDNS introduces
        a semantically rich naming scheme (e.g., agentdns://org/category/
        name) for agents and tool services, decoupling service identifier
        name from physical addresses such as URLs.  This also enables the
        semantic embedding of agent capabilities into their identifier
        name, facilitating more efficient classification and retrieval of
        agent and tool services.










  Liang, et al.             Expires 12 April 2026                 [Page 4]


  Internet-Draft              Abbreviated Title               October 2025


     *  *Natural Language-Driven Service Discovery:* Agents can interact
        with the AgentDNS root service using natural language queries to
        discover third-party agents or tool services.  They can obtain the
        corresponding service identifier names and related metadata,
        including physical addresses, capabilities, and communication
        protocol, etc.  Agents can also dynamically request the AgentDNS
        root service to resolve an identifier name and retrieve the latest
        metadata as needed.

     *  *Protocol-Aware Interoperability:* AgentDNS enables agents to
        dynamically discover the supported interoperability or
        communication protocols of third-party agents and tool services by
        resolving their identifier names into metadata.  This metadata
        includes not only network addresses and capabilities, but also the
        specific protocols (e.g., MCP, A2A, ANP) each service supports.
        Based on this information, agents can autonomously select and
        adapt to the appropriate protocol for communication, eliminating
        the need for manual configuration.

     *  *Unified Authentication and Billing:* AgentDNS replaces fragmented
        API keys with a single-sign-on mechanism.  Agents authenticate
        once with the AgentDNS root server to obtain time-bound access
        tokens, valid across all registered services.  For billing,
        AgentDNS serves as a unified billing platform: users pre-fund
        accounts, usage costs are tracked and deducted in real-time, and
        payments are automatically settled across vendors.  This enables
        transparent billing and autonomous access to paid services by
        agents.

  2.  Related Work

     *LLM Agents*
        LLM agents have rapidly emerged as a pivotal research frontier in
        artificial intelligence, driven by their transformative potential
        to bridge human-AI collaboration and autonomous problem-solving.
        In the industrial, several LLM agents have been launched, such as
        Deep Research [Deep-Research], Manus [Manus], and Cursor
        (Anysphere 2025) [Cursor], etc.  Unlike traditional AI systems
        constrained by predefined rules, LLM agents leverage the general-
        purpose reasoning, contextual understanding, and multi-task
        capabilities of LLMs to dynamically adapt to complex environments.
        LLM agents have demonstrated broad application prospects across
        various fields.  The future of LLM agents is expected to trend
        towards multi-agent collaboration.  Researchers are increasingly
        interested in how to design efficient communication protocols and
        coordination mechanisms [hou2025model] [marro2024scalable] that
        enable seamless cooperation among agents.  This collaborative
        approach is seen as a key direction for advancing the capabilities



  Liang, et al.             Expires 12 April 2026                 [Page 5]


  Internet-Draft              Abbreviated Title               October 2025


        and applications of LLM agents in the coming years.

     *Agent Interaction Protocols*
        *Model Context Protocol.* The Model Context Protocol (MCP) (Hou et
        al.  2025) is an open standard developed by Anthropic, designed to
        facilitate seamless interactions between LLM models and external
        tools, data sources, and services.  Inspired by the concept of a
        universal adapter, MCP aims to simplify the integration process,
        much like how a USB-C port allows various devices to connect
        effortlessly.  MCP operates on a client-server architecture.  The
        AI application (such as a chatbot or an integrated development
        environment) acts as the host and runs an MCP client, while each
        external integration runs as an MCP server.  The server exposes
        capabilities such as functions, data resources, or predefined
        prompts, and the client connects to it to utilize these
        capabilities.  This design allows AI models to interact with
        external systems without directly accessing APIs, thereby
        enhancing security and reducing the complexity of custom
        integrations.

        *Agent-to-Agent Protocol.* The Agent-to-Agent (A2A) protocol
        (Google 2025) is introduced by Google, aimed at enabling seamless
        communication and collaboration between LLM agents, regardless of
        their underlying frameworks or vendors.  A2A was developed in
        collaboration with over 50 technology partners, including major
        companies like Atlassian, Salesforce, SAP, and MongoDB.  This
        protocol uses HTTP-based APIs and JSON data format, ensuring
        compatibility and ease of integration with existing enterprise IT
        systems.  It supports various communication patterns, including
        request-response, event-based communication, and streaming data
        exchange.  A2A complements protocols like MCP, which focuses on
        providing tools and context for agents.  A2A focuses on agent-to-
        agent communication, allowing them to work together more
        effectively.

     *Domain Naming System*
        The Domain Name System (DNS) [danzig1992analysis]
        [cheshire2013rfc6763] serves as the critical naming and discovery
        infrastructure for the human internet, translating memorable
        domain names (e.g., example.  com) into physical addresses (IP
        addresses) through its hierarchical, decentralized architecture.
        While DNS effectively decouples human-readable names from machine-
        level addressing, its design proves inadequate for the emerging
        agent Internet where LLM agents require autonomous service
        discovery and interoperability.  Traditional DNS lacks three
        critical capabilities essential for agent ecosystems: service
        discovery through natural language, querying service metadata
        beyond physical addresses (including capabilities, protocols,



  Liang, et al.             Expires 12 April 2026                 [Page 6]


  Internet-Draft              Abbreviated Title               October 2025


        etc.), and unified authentication and billing.  These limitations
        necessitate AgentDNS-a purpose-built system that preserves DNS's
        core benefits of naming and resolution while introducing agent-
        specific innovations.

  3.  AgentDNS Architecture

  3.1.  AgentDNS System Overview

     AgentDNS is a root service system for agent service naming,
     discovery, and resolution, enabling seamless service discovery,
     cross-vendor interoperability, unified authentication and billing.
     As shown in Figure 2, the AgentDNS root server is the central hub of
     the entire system, which connects agent users (e.g., Agent A) with
     service providers (e.g., Agent Service B, Tool Service D).  The
     AgentDNS root server comprises components including service
     registration, service proxy pool[RFC5625], service management,
     service search, service resolution, billing, authentication, etc.
     The core components are as follows:

     *  Service Registration Component: Agent or tool service vendors
        register their services through this component.  The process
        begins with organization registration, where developers first
        create an organization account.  Under the organization's domain,
        they then setup a service category and name to generate a globally
        unique service identifier name (e.g., agentdns://org/category/
        name).  Concurrently, developers must submit service metadata to
        bind with the identifier, including network addresses (e.g.,
        endpoints, URLs), supported interoperability protocols (e.g., MCP,
        A2A), detailed service capabilities, etc.  This metadata is
        securely stored in the AgentDNS database.  During subsequent
        service discovery or resolution phases, the system performs
        semantic matching by analyzing the identifier's category and the
        metadata.  This ensures precise retrieval of services aligned with
        an agent's operational requirements [RFC7720].

     *  Service Proxy Pool: After a vendor registers a service, AgentDNS
        creates a corresponding service proxy within the Service Proxy
        Pool.  This proxy acts as an intermediary, forwarding service
        invocation requests from user agents to the vendor's actual
        service endpoint.  In other words, the user agent sends a service
        request to the AgentDNS root server, which then routes the request
        to the appropriate vendor for execution.  This design allows user
        agents to authenticate only once with AgentDNS, eliminating the
        need for separate registration and authentication with each
        individual vendor.





  Liang, et al.             Expires 12 April 2026                 [Page 7]


  Internet-Draft              Abbreviated Title               October 2025


     *  Service Search Component: User agents can send natural language
        queries to the AgentDNS root server to discover relevant third-
        party agents or tool services.  This component interprets the
        query and performs intelligent retrieval using a combination of
        keyword matching and retrieval-augmented generation (RAG)
        [gao2023retrieval] techniques.  Based on the search results, it
        returns a list of top-k candidate services that match the agent's
        intent.  Each result includes the service identifier name,
        physical endpoint, supported communication protocols, capability
        descriptions, and pricing information.  The user agent can then
        evaluate these candidates and choose the most appropriate one for
        execution.  Once selected, the agent can directly invoke the
        service by using the appropriate protocol and access the physical
        endpoint with an authentication token issued by AgentDNS.

     *  Service Resolution Component: User agents can cache service
        identifier names and, during subsequent invocations, dynamically
        request the AgentDNS root server to resolve these identifiers and
        get the latest metadata as needed.

     *  Service Management Component: This component handles the lifecycle
        of these service proxies, including their creation, updates, and
        deletion, ensuring that the proxy infrastructure remains up-to-
        date and synchronized with the underlying services.

     *  Service Billing Component: This component is responsible for
        tracking and processing service invocation costs.  Users only need
        to settle payments directly with AgentDNS, which then handles the
        backend settlement with individual vendors.  This design
        significantly simplifies the billing process for users by
        eliminating the need for managing multiple vendor-specific payment
        systems, enabling a streamlined and unified billing experience.

     *  Authentication Component: This component handles identity
        verification and access control for both user agents and service
        providers.  Instead of requiring agents to authenticate separately
        with each vendor, AgentDNS offers a unified authentication
        mechanism.  User agents authenticate once with the AgentDNS root
        server and receive a time-bound access token.  This token can be
        used to securely access any registered third-party service without
        additional logins.  By centralizing authentication, this component
        ensures secure, efficient, and scalable access across a
        heterogeneous agent ecosystem, while also reducing the operational
        burden on both users and service vendors.







  Liang, et al.             Expires 12 April 2026                 [Page 8]


  Internet-Draft              Abbreviated Title               October 2025


        <preamble>:
                    This figure illustrates the architecture of the AgentDNS system, its API interface,
                    and interactions with agents and services.
            
            
                             +-----------------------------------------+
                             |          AgentDNS Root Server           |
                             |  +----------------+   +--------------+  |
                             |  |   Resolution   |   |    Search    |  |
                             |  +----------------+   +--------------+  |
                             |  |    Billing     |   |    Manage    |  |
                             |  +----------------+   +--------------+  |
                             |  | Authentication |   | Registration |  |
                             |  +----------------+   +--------------+  |
                             |          Service Proxy Pool             |
                             |     (Agent Svc B, C, Tool Svc D...)     |
                             |                                         |
                             |        +------------------------+       |
                             |        | AgentDNS API Server    |       |
                             |        +------------------------+       |
                             +---------------------+-------------------+
                                          ▲          ▲
           +--------------+               |          |
           |   Agent A    |---------------+          |
           +--------------+   Natural Lang Query     |
                 |                                   |
                 |                                   |
                 |                       +----------------------+
                 |                       | Service Registration |
                 |                       +----------------------+
                 |                                   ▲
                 |                                   |
                 |    Service Call                   |
                 | (Proxy by AgentDns)    +---------------------------+
                 +----------------------> | AgentSvcB, AgentSvcC, ... |
                                          | Tool Service D ...        |
                                          +---------------------------+

                     Figure 2: AgentDNS System Architecture

     Together, these components form the backbone of AgentDNS, providing a
     unified framework that supports natural language-driven discovery,
     protocol-aware interoperability, trustless authentication, and
     unified billing-paving the way for truly autonomous multi-agent
     ecosystems.  Next, we will provide a detailed introduction to
     AgentDNS's service naming, service discovery, service resolution, and
     unified authentication and billing mechanisms.




  Liang, et al.             Expires 12 April 2026                 [Page 9]


  Internet-Draft              Abbreviated Title               October 2025


  3.2.  Service Naming

     The AgentDNS service naming system provides a structured and globally
     unique service identifier name for each registered agent or tool
     service.  The identifier name follows the format as shown in
     Figure 3.  The organization represents the name of the registering
     entity, such as a company, university, or research lab.  Each
     organization must go through a registration and verification process
     to ensure uniqueness and authenticity.  The category denotes the
     functional domain or classification of the agent service.  This can
     be chosen manually by the developer or automatically generated by
     AgentDNS, and it supports hierarchical structures—allowing for multi-
     level categories using slashes (e.g., academic/nlp/summarization).
     Finally, the name is the unique identifier for the specific agent
     within the organization and category.  This name must be explicitly
     defined by the developer.  Together, this structured naming
     convention ensures precise identification, facilitates organized
     discovery, and supports scalable service management within the
     AgentDNS ecosystem.

        <preamble>:
                    This figure shows the structure of an AgentDNS service name, including prefix,
                    organization, category, and agent name.
            
            
       Service Identifier Format:

       agentdns://{organization}/{category}/{name}
           |            |             |         |
         Prefix    Organization    Category   Name

       Example:
       agentdns://example/academic/paperagent

                       Figure 3: AgentDNS Service Naming

  3.3.  Service Discovery

     The service discovery process is illustrated in Figure 4.  In step 1,
     Agent A initiates a natural language query to the AgentDNS root
     server, describing the desired service.  In the example, Agent A is
     looking for an intelligent Agent capable of analyzing academic
     papers.  In step 2, upon receiving the request, AgentDNS searches
     through its registry of available services to identify those with the
     required capabilities.  It returns a list of service identifiers
     along with corresponding metadata, such as the proxy's physical
     address, supported protocols, pricing information, and more.  This
     discovery process employs a hybrid retrieval mechanism that combines



  Liang, et al.             Expires 12 April 2026                [Page 10]


  Internet-Draft              Abbreviated Title               October 2025


     keyword matching and RAG.  Specifically, we construct a knowledge
     base using the capability descriptions of registered services.
     During service discovery, hybrid retrieval is performed over these
     capability descriptions to identify candidates that best match the
     user agent's intent.  In step 3, after receiving the service
     information, Agent A uses the appropriate protocol and an
     authentication token issued by AgentDNS to directly access the
     physical proxy address and initiate a service call.  Finally, in step
     4, the AgentDNS proxy forwards the request to the actual service
     endpoint hosted by the vendor, ensuring seamless interaction between
     Agent A and the service provider.

     <preamble>:Illustrates how Agent A discovers and interacts with an academic paper analysis
                 agent through the AgentDNS Root Server and proxy layers.
            
    +------------------+                              +------------------------+
    |     Agent A      |                              |  AgentDNS Root Server  |
    +------------------+                              +------------------------+
          |   ① Prompt: "I need an agent                         ▲
          |      for academic paper analysis."                   |
          |----------------------------------------------------->|
          |                                                      |
          |   ② Search Result:                                   |
          |      agentdns://example/academic/paperagent          |
          |<-----------------------------------------------------|
          |                                                      |
          |                                                      v
          |   ③ Service call                        +------------------------+
          |---------------------------------------> |   paperagent proxy     |
                                                    +------------------------+
                                                              |
                                                              | ④ Forward
                                                              v
                                                    +------------------------+
                                                    |      paperagent        |
                                                    +------------------------+

              Figure 4: AgentDNS Service Discovery Workflow

  3.4.  Service Resolution

     As previously mentioned, user agents can cache service identifier
     names and request the AgentDNS root server for updated metadata when
     needed.  This functionality helps reduce the frequency of accessing
     AgentDNS, improving response times and lowering operational costs.
     The service resolution process is illustrated in Figure 5.  In step
     1, agent vendors update the metadata associated with their agent
     services.  In step 2, Agent A sends a resolution request to the



  Liang, et al.             Expires 12 April 2026                [Page 11]


  Internet-Draft              Abbreviated Title               October 2025


     AgentDNS root server, providing the cached service identifier name to
     retrieve the latest information.  In step 3, AgentDNS locates the
     most recent metadata based on the identifier and returns it to Agent
     A, ensuring that the service invocation uses up-to-date information.

     <preamble>:
                 Illustrates how an agent (paperagent) updates its metadata to the AgentDNS Root Server,
                 and how another agent (Agent A) resolves the service via AgentDNS to retrieve updated
                 metadata.
            
            
              +-------------+                           +------------------------+
              | paperagent  |                           | AgentDNS Root Server   |
              +-------------+                           +------------------------+
                    |                                            ▲
              ① Metadata Update:                                 |
                Old metadata -> New metadata                     |
                    |------------------------------------------->|
                                                                 |
                                                                 |
                                                        ② Service Resolution:
                                                agentdns://example/academic/paperagent
                                                                 |
                    |<-------------------------------------------|
                    v
              +-------------+
              |  Agent A    |
              +-------------+
                    |
              ③ New metadata
                    |
                    v
              (uses updated metadata)

                  Figure 5: AgentDNS service resolution

  3.5.  Unified Authentication and Billing

     AgentDNS introduces a unified authentication and billing mechanism by
     acting as a proxy layer between user agents and third-party services.
     As shown in Figure 6, when a user agent (e.g., Agent A) authenticates
     once with the AgentDNS root server using its own access key (Key A),
     it gains the ability to seamlessly invoke multiple external agent or
     tool services without needing to manage individual credentials for
     each provider.  Internally, the AgentDNS root server maintains a
     service proxy pool that forwards user requests to the corresponding
     third-party services.  For each thirdparty service, the proxy uses
     the appropriate authentication key (e.g., Key B, C, or D), which



  Liang, et al.             Expires 12 April 2026                [Page 12]


  Internet-Draft              Abbreviated Title               October 2025


     corresponds to the access control requirements of the service
     provider.  This abstraction decouples the user agent from vendor-
     specific authentication logic.  Moreover, billing is centralized:
     user agents are charged by AgentDNS based on their usage, while
     AgentDNS handles settlements with the respective thirdparty services.
     This model simplifies cross-vendor interoperability, enforces secure
     access, and enables consistent billing across a heterogeneous service
     ecosystem.

     <preamble>:Agent A resolves services via the AgentDNS Root Server, including billing,
                 authentication, and service redirection using keys.
            
    +--------+        +---------------------------+        +------------------+
    | Agent  |        |   AgentDNS Root Server    |        | Service B        |
    |   A    |------->| +-----------------------+ |------->| (via Key B)      |
    |        |  Key A | |  Service Billing      | |        +------------------+
    +--------+        | +-----------------------+ |
                      | +-----------------------+ |        +------------------+
                      | | Authentication        | |------->| Service C        |
                      | +-----------------------+ |        | (via Key C)      |
                      | +-----------------------+ |        +------------------+
                      | | Agent Service B       | |
                      | +-----------------------+ |        +------------------+
                      | +-----------------------+ |------->| Tool Service D   |
                      | | Agent Service C       | |        | (via Key D)      |
                      | +-----------------------+ |        +------------------+
                      | +-----------------------+ |
                      | | Tool Service D        | |
                      | +-----------------------+ |
                      | (Via Service Proxy Pool)  |
                      +---------------------------+

          Figure 6: AgentDNS Unified Authentication and Billing

  4.  AgentDNS Case Study

     In this section, we present a case study illustrating the interaction
     between an agent and the AgentDNS root server.  The case demonstrates
     the complete agent workflow—from generating an action plan
     [huang2024understanding], to querying the AgentDNS root server for
     service discovery, and finally to executing the planned actions.

     The full process is illustrated in Figure 7.  After receiving a user
     request—such as “Help me research agent communication protocols and
     write a survey report”—the agent first invokes a LLM to generate an
     action plan.  As shown in Figure 7, the generated plan in this case
     is structured in JSON format and consists of multiple steps.  Each
     step includes a description of its purpose, whether it requires a



  Liang, et al.             Expires 12 April 2026                [Page 13]


  Internet-Draft              Abbreviated Title               October 2025


     service, and a natural language description of the desired service
     functionality.  These services correspond to third-party agent or
     tool services.  For example, Step 1 requires a search service to
     retrieve relevant keywords, while Step 3 calls for a standards
     retrieval service to query documents from organizations like IEEE
     (IEEE Standards Association 2025) [ieee2025] or ITU-T (International
     Telecommunication Union 2025) [itut2025].

     <preamble>:Illustrates how an LLM-generated action plan is executed through AgentDNS-based
               service discovery and agent invocation.
          
  +---------------------------------+       +------------------------------+       +------------------------------+
  | Action Plan                     |       |  Service Discovery           |       | Action Execution             |
  | (Generated by LLM)              |       |  (via AgentDNS Search)       |       | (Step by step)               |
  +---------------------------------+       +------------------------------+       +------------------------------+
  | steps:                          |       | agentdns://example/search/   |       | Execute step 1               |
  | 1. Use search engines...        |       | searchagent                  |       | (Call searchagent)           |
  |    tool_required: true          |       |   - protocol: MCP            |       +------------------------------+
  |    tool_function: keyword search|       |   - cost: $1/million tokens  |       | Execute step 2               |
  |                                 |       |   - capability: keyword search|      | (LLM + Prompt)               |
  | 2. Analyze communication...     |       +------------------------------+       +------------------------------+
  |    tool_required: false         |       | agentdns://example/standard/ |       | Execute step 3               |
  |                                 |       | standardagent                |       | (Call standardagent)         |
  | 3. Summarize standardization    |       |   - protocol: MCP            |       +------------------------------+
  |    tool_required: true          |       |   - cost: free               |       | Execute step 4               |
  |    tool_function: query IEEE... |       |   - capability: standard query|      | (LLM + Prompt)               |
  | 4. Write the research report    |       +------------------------------+       +------------------------------+
  +---------------------------------+                    ^                                 ^
          |                                              |                                 |
          |----------------------------------------------|---------------------------------|
                                          Uses AgentDNS Root Server

                      Figure 7: AgentDNS Case Study

     After generating the action plan, the agent submits a natural
     language query to the AgentDNS root server to discover suitable
     third-party services.  For instance, in Step 1, the agent sends the
     tool function description directly to AgentDNS, which uses
     intelligent retrieval methods to identify matching services.  Suppose
     AgentDNS returns a service named agentdns://example/search/
     searchagent; it also provides metadata such as the physical endpoint,
     supported protocols, service cost, capabilities, and available APIs.
     The agent uses this information to invoke the selected third-party
     service.

     Following service discovery, the agent enters the action execution
     phase.  During this stage, it executes the steps of the action plan
     in sequence.  When a step requires a service, the agent uses the



  Liang, et al.             Expires 12 April 2026                [Page 14]


  Internet-Draft              Abbreviated Title               October 2025


     corresponding protocol to access the thirdparty service obtained from
     AgentDNS and passes the result to the next step.  For steps that do
     not involve external services, the agent inputs the step purpose
     description, along with previous outputs and prompt instructions,
     into the LLM for generation.  This process continues until all steps
     in the action plan are completed.

     This case study presents a simplified example, while in practice, the
     structure and format of an action plan can be adapted to suit
     different needs.  Importantly, the third-party service descriptions
     within the action plan are expressed in natural language, which means
     they are not tightly coupled with specific service identifiers, tool
     names, or endpoint URLs.  AgentDNS plays a critical role in
     decoupling the foundational agent model from vendor-specific details
     such as service names, tool identifiers, and physical addresses,
     enabling more flexible and scalable agent architectures.

  5.  Future Opportunities

     While AgentDNS addresses fundamental challenges in service discovery,
     interoperability, and billing in the agent ecosystem, numerous
     directions remain open for future exploration.  These include
     decentralized and federated architecture, AgentDNS-compatible agent
     planning LLMs, privacy-preserving [RFC8932] and trusted discovery, as
     well as AgentDNS service discovery optimization.  First, while the
     current design of AgentDNS adopts a centralized architecture, future
     iterations may benefit from decentralized or federated
     [huang2024aggregate] architecture, such as blockchain
     [karaarslan2018blockchain].  This would improve robustness, reduce
     the risk of single points of failure, and enhance trust in cross-
     organizational collaborations.  Second, training and fine-tuning
     agent planning LLMs [wang2023describe] [hu2024agentgen] specifically
     compatible with AgentDNS is also an important direction.  This can
     involve constructing agent planning datasets and fine-tuning LLMs to
     enhance their compatibility with AgentDNS.  Alternatively,
     reinforcement learning techniques [wen2024reinforcing]
     [jin2025search] [qi2024webrl] [peiyuan2024agile] can be used to train
     agents to autonomously explore and optimize action sequences,
     dynamically selecting and combining various services registered in
     AgentDNS to maximize task success rates and efficiency.  Third,
     security and privacy will remain central in crossvendor agent
     collaboration.  Future directions may involve privacy-preserving
     search and resolution, using technologies such as homomorphic
     encryption [buban2025encrypted], differential privacy, and secure
     multi-party computation.  AgentDNS could also integrate trust and
     reputation systems to allow agents to evaluate service quality and
     security risks before invocation.  Finally, the optimization of
     AgentDNS service discovery and retrieval remains a critical area for



  Liang, et al.             Expires 12 April 2026                [Page 15]


  Internet-Draft              Abbreviated Title               October 2025


     improving system performance and user experience.

  6.  Conclusion

     The rapid advancement of LLM agents has exposed critical gaps in
     cross-vendor service discovery, interoperability, and authentication,
     hindering the vision of autonomous multiagent collaboration.  This
     document introduces AgentDNS, a unified root domain naming system
     designed to bridge these gaps by providing a semantically rich
     namespace, natural language-driven service discovery, protocol-aware
     interoperability, and trustless authentication and billing.  By
     decoupling agent identifiers from physical addresses and embedding
     dynamic metadata resolution, AgentDNS enables agents to autonomously
     discover, resolve, and securely invoke services across organizational
     and technological boundaries.  Our architecture and case studies
     demonstrate its potential to streamline multi-agent workflows, reduce
     manual overhead, and foster an open ecosystem for agent
     collaboration.  Future works include decentralized and federated
     architecture, AgentDNS-compatible agent planning LLMs, privacy-
     preserving and trusted discovery, as well as AgentDNS service
     discovery optimization, etc.

  7.  IANA Considerations

     This memo includes no request to IANA.

  8.  Security Considerations

     This document should not affect the security of the Internet.

  9.  References

  9.1.  Normative References

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/info/rfc1035>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/info/rfc6763>.

     [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
                BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
                <https://www.rfc-editor.org/info/rfc5625>.






  Liang, et al.             Expires 12 April 2026                [Page 16]


  Internet-Draft              Abbreviated Title               October 2025


     [RFC7720]  Blanchet, M. and L. Liman, "DNS Root Name Service Protocol
                and Deployment Requirements", BCP 40, RFC 7720,
                DOI 10.17487/RFC7720, December 2015,
                <https://www.rfc-editor.org/info/rfc7720>.

     [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
                A. Mankin, "Recommendations for DNS Privacy Service
                Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
                October 2020, <https://www.rfc-editor.org/info/rfc8932>.

  9.2.  Informative References

     [MCP-Spec] Model Context Protocol Specification Authors, "Model
                Context Protocol (MCP) Specification", March 2025,
                <https://modelcontextprotocol.io/
                specification/2025-03-26>.

     [A2A-Spec] Agent2Agent Protocol Specification Authors, "Agent2Agent
                (A2A) Protocol Specification", 2025,
                <https://github.com/google/A2A>.

     [ANP-Doc]  Agent Network Protocol Authors, "Agent Network Protocol
                (ANP) | Complete Guide to Agent Network Protocol", 2025,
                <https://agentnetworkprotocol.com/en/docs/>.

     [Deep-Research]
                OpenAI, "Introducing Deep Learning Research", 2025,
                <https://openai.com/index/introducing-deep-research/>.

     [Manus]    Monica, "Manus: A New Kind of AI", 2025,
                <https://manus.im/>.

     [Cursor]   Cursor, "Cursor: A New Kind of AI Editor", 2025,
                <https://cursor.com/en/agents>.

     [hou2025model]
                Hou, Xinyi., Zhao, Yanjie., Wang, Shenao., and Haoyu.
                Wang, "Model context protocol (mcp): Landscape, security
                threats, and future research directions", arXiv preprint
                arXiv:2503.23278 2025, 2025.

     [ding2024large]
                Ding, Han., Li, Yinheng., Wang, Junhao., and Hang. Chen,
                "Large language model agent in financial trading: A
                survey", arXiv preprint arXiv:2408.06361 2024, 2024.






  Liang, et al.             Expires 12 April 2026                [Page 17]


  Internet-Draft              Abbreviated Title               October 2025


     [chu2025llm]
                Chu, Zhendong., Wang, Shen., Xie, Jian., Zhu, Tinghui.,
                Yan, Yibo., Ye, Jinheng., Zhong, Aoxiao., Hu, Xuming.,
                Liang, Jing., Yu, Philip S., and others, "Llm agents for
                education: Advances and applications", arXiv preprint
                arXiv:2503.11733 2025, 2025.

     [alzubi2025open]
                Alzubi, Salaheddin., Brooks, Creston., Chiniya, Purva.,
                Contente, Edoardo., von Gerlach, Chiara., Irwin, Lucas.,
                Jiang, Yihan., Kaz, Arda., Nguyen, Windsor., Oh, Sewoong.,
                and others, "Open deep search: Democratizing search with
                open-source reasoning agents", arXiv preprint
                arXiv:2503.20201 2025, 2025.

     [chen2024mindsearch]
                Chen, Zehui., Liu, Kuikun., Wang, Qiuchen., Liu,
                Jiangning., Zhang, Wenwei., Chen, Kai., and Feng. Zhao,
                "Mindsearch: Mimicking human minds elicits deep ai
                searcher", arXiv preprint arXiv:2407.20183 2024, 2024.

     [luo2025large]
                Luo, Junyu., Zhang, Weizhi., Yuan, Ye., Zhao, Yusheng.,
                Yang, Junwei., Gu, Yiyang., Wu, Bohan., Chen, Binqi.,
                Qiao, Ziyue., Long, Qingqing., and others, "Large Language
                Model Agent: A Survey on Methodology, Applications and
                Challenges", arXiv preprint arXiv:2503.21460 2025, 2025.

     [googlea2a]
                Google, "An open protocol enabling communication and
                interoperability between opaque agentic applications.",
                2025.

     [marketsandmarkets_ai_agents]
                {MarketsandMarkets}, "AI Agents Market", 2025.

     [guo2024large]
                Guo, Taicheng., Chen, Xiuying., Wang, Yaqi., Chang,
                Ruidi., Pei, Shichao., Chawla, Nitesh V., Wiest, Olaf.,
                and Xiangliang. Zhang, "Large language model based multi-
                agents: A survey of progress and challenges", arXiv
                preprint arXiv:2402.01680 2024, 2024.

     [han2024llm]
                Han, Shanshan., Zhang, Qifan., Yao, Yuhang., Jin,
                Weizhao., Xu, Zhaozhuo., and Chaoyang. He, "LLM multi-
                agent systems: Challenges and open problems", arXiv
                preprint arXiv:2402.03578 2024, 2024.



  Liang, et al.             Expires 12 April 2026                [Page 18]


  Internet-Draft              Abbreviated Title               October 2025


     [yang2025survey]
                Yang, Yingxuan., Chai, Huacan., Song, Yuanyi., Qi,
                Siyuan., Wen, Muning., Li, Ning., Liao, Junwei., Hu,
                Haoyi., Lin, Jianghao., Chang, Gaowei., and others, "A
                Survey of AI Agent Protocols", arXiv preprint
                arXiv:2504.16736 2025, 2025.

     [yan2025beyond]
                Yan, Bingyu., Zhang, Xiaoming., Zhang, Litian., Zhang,
                Lian., Zhou, Ziyi., Miao, Dezhuang., and Chaozhuo. Li,
                "Beyond self-talk: A communication-centric survey of llm-
                based multi-agent systems", arXiv preprint
                arXiv:2502.14321 2025, 2025.

     [cheshire2013rfc6763]
                Cheshire, Stuart. and Marc. Krochmal, "RFC 6763: DNS-Based
                Service Discovery", 2013.

     [danzig1992analysis]
                Danzig, Peter B., Obraczka, Katia., and Anant. Kumar, "An
                analysis of wide-area name server traffic: A study of the
                internet domain name system", Conference proceedings on
                Communications architectures \& protocols 1992, 1992.

     [openai2025deepresearch]
                {OpenAI}, "Introducing Deep Research", 2025.

     [manus2025]
                {Monica}, "Leave it to Manus", 2025.

     [cursor2025]
                }, {Anysphere., "Cursor: The AI Code Editor", 2025.

     [li2024improving]
                Li, Yunxuan., Du, Yibing., Zhang, Jiageng., Hou, Le.,
                Grabowski, Peter., Li, Yeqing., and Eugene. Ie, "Improving
                multi-agent debate with sparse communication topology",
                arXiv preprint arXiv:2406.11776 2024, 2024.

     [marro2024scalable]
                Marro, Samuele., La Malfa, Emanuele., Wright, Jesse., Li,
                Guohao., Shadbolt, Nigel., Wooldridge, Michael., and
                Philip. Torr, "A scalable communication protocol for
                networks of large language models", arXiv preprint
                arXiv:2410.11905 2024, 2024.






  Liang, et al.             Expires 12 April 2026                [Page 19]


  Internet-Draft              Abbreviated Title               October 2025


     [huang2024understanding]
                Huang, Xu., Liu, Weiwen., Chen, Xiaolong., Wang, Xingmei.,
                Wang, Hao., Lian, Defu., Wang, Yasheng., Tang, Ruiming.,
                and Enhong. Chen, "Understanding the planning of LLM
                agents: A survey", arXiv preprint arXiv:2402.02716 2024,
                2024.

     [gao2023retrieval]
                Gao, Yunfan., Xiong, Yun., Gao, Xinyu., Jia, Kangxiang.,
                Pan, Jinliu., Bi, Yuxi., Dai, Yixin., Sun, Jiawei., Wang,
                Haofen., and Haofen. Wang, "Retrieval-augmented generation
                for large language models: A survey", arXiv preprint
                arXiv:2312.10997 2023, 2023.

     [ieee2025] Association, IEEE Standards., "IEEE Standards Association
                Official Website", 2025.

     [itut2025] Union, International Telecommunication., "ITU-T:
                Telecommunication Standardization Sector", 2025.

     [li2021b]  Li, Zecheng., Gao, Shang., Peng, Zhe., Guo, Songtao.,
                Yang, Yuanyuan., and Bin. Xiao, "B-DNS: A secure and
                efficient DNS based on the blockchain technology", IEEE
                Transactions on Network Science and Engineering 2021,
                2021.

     [karaarslan2018blockchain]
                Karaarslan, Enis. and Eylul. Adiguzel, "Blockchain based
                DNS and PKI solutions", IEEE Communications Standards
                Magazine 2018, 2018.

     [huang2024aggregate]
                Huang, Chih-Kai. and Guillaume. Pierre, "Aggregate
                Monitoring for Geo-Distributed Kubernetes Cluster
                Federations", IEEE Transactions on Cloud Computing 2024,
                2024.

     [wang2023describe]
                Wang, Zihao., Cai, Shaofei., Chen, Guanzhou., Liu, Anji.,
                Ma, Xiaojian Shawn., and Yitao. Liang, "Describe, explain,
                plan and select: interactive planning with llms enables
                open-world multi-task agents", Advances in Neural
                Information Processing Systems 2023, 2023.








  Liang, et al.             Expires 12 April 2026                [Page 20]


  Internet-Draft              Abbreviated Title               October 2025


     [hu2024agentgen]
                Hu, Mengkang., Zhao, Pu., Xu, Can., Sun, Qingfeng., Lou,
                Jianguang., Lin, Qingwei., Luo, Ping., and Saravan.
                Rajmohan, "Agentgen: Enhancing planning abilities for
                large language model based agent via environment and task
                generation", arXiv preprint arXiv:2408.00764 2024, 2024.

     [wen2024reinforcing]
                Wen, Muning., Wan, Ziyu., Wang, Jun., Zhang, Weinan., and
                Ying. Wen, "Reinforcing LLM Agents via Policy Optimization
                with Action Decomposition", The Thirty-eighth Annual
                Conference on Neural Information Processing Systems 2024,
                2024.

     [jin2025search]
                Jin, Bowen., Zeng, Hansi., Yue, Zhenrui., Yoon, Jinsung.,
                Arik, Sercan., Wang, Dong., Zamani, Hamed., and Jiawei.
                Han, "Search-r1: Training llms to reason and leverage
                search engines with reinforcement learning", arXiv
                preprint arXiv:2503.09516 2025, 2025.

     [qi2024webrl]
                Qi, Zehan., Liu, Xiao., Iong, Iat Long., Lai, Hanyu., Sun,
                Xueqiao., Zhao, Wenyi., Yang, Yu., Yang, Xinyue., Sun,
                Jiadai., Yao, Shuntian., and others, "WebRL: Training LLM
                Web Agents via Self-Evolving Online Curriculum
                Reinforcement Learning", arXiv preprint
                arXiv:2411.02337 2024, 2024.

     [peiyuan2024agile]
                Peiyuan, Feng., He, Yichen., Huang, Guanhua., Lin, Yuan.,
                Zhang, Hanchong., Zhang, Yuchen., and Hang. Li, "AGILE: A
                Novel Reinforcement Learning Framework of LLM Agents",
                Advances in Neural Information Processing Systems 2024,
                2024.

     [buban2025encrypted]
                Buban, James., Zhang, Hongyang., Angione, Claudio., Yang,
                Harry., Farhan, Ahmad., Sultanov, Seyfal., Du, Michael.,
                Ma, Xuran., Wang, Zihao., Zhao, Yue., and others,
                "Encrypted Large Model Inference: The Equivariant
                Encryption Paradigm", arXiv preprint
                arXiv:2502.01013 2025, 2025.

  Authors' Addresses

     Zhiyuan Liang (editor)
     China Telecom Research Institute



  Liang, et al.             Expires 12 April 2026                [Page 21]


  Internet-Draft              Abbreviated Title               October 2025


     Email: liangzy17@chinatelecom.cn


     Enfang Cui
     China Telecom Research Institute
     Email: cuief@chinatelecom.cn


     Yujun Cheng
     University of Science and Technology Beijing
     Email: yjcheng@tsinghua.edu.cn








































  Liang, et al.             Expires 12 April 2026                [Page 22]


name: draft-scim-agent-extension
rev: 00
title: SCIM Agents and Agentic Applications Extension
time: 2026-04-14T07:09:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-14T21:30:52Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604211+00:00
source: ietf
abstract:
  The System for Cross-domain Identity Management (SCIM) specification
     [RFC7643] provides schemas that represent common identity information
     about users and groups, as well as a protocol for communicating that
     information between systems.

     The systems that tend to implement SCIM clients and servers are
     identity providers, and service providers.  These are the same
     systems that are now need to manage agents and agentic applications
     across domains.

     This document describes a SCIM 2.0 extension for agents and agentic
     applications, which includes extensions to the core User and Group
     objects, and new resource types and schemas for agentic constructs.

     This extension is intended to provide greater interoperability
     between Identity providers, agentic applications, agents and their
     clients while reducing the responsibilities assumed by the every
     growing list of new protocols for agents.

full_text:
  SCIM                                                            M. Abbey
  Internet-Draft                                               R. S. Cohen
  Intended status: Standards Track                                    Okta
  Expires: 14 April 2026                                   11 October 2025


               SCIM Agents and Agentic Applications Extension
                       draft-scim-agent-extension-00

  Abstract

     The System for Cross-domain Identity Management (SCIM) specification
     [RFC7643] provides schemas that represent common identity information
     about users and groups, as well as a protocol for communicating that
     information between systems.

     The systems that tend to implement SCIM clients and servers are
     identity providers, and service providers.  These are the same
     systems that are now need to manage agents and agentic applications
     across domains.

     This document describes a SCIM 2.0 extension for agents and agentic
     applications, which includes extensions to the core User and Group
     objects, and new resource types and schemas for agentic constructs.

     This extension is intended to provide greater interoperability
     between Identity providers, agentic applications, agents and their
     clients while reducing the responsibilities assumed by the every
     growing list of new protocols for agents.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://macyabbey.github.io/draft-scim-agent-extension/draft-scim-
     agent-extension.html.  Status information for this document may be
     found at https://datatracker.ietf.org/doc/draft-scim-agent-
     extension/.

     Source for this draft and an issue tracker can be found at
     https://github.com/macyabbey/draft-scim-agent-extension.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.




  Abbey & Cohen             Expires 14 April 2026                 [Page 1]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     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 14 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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Core Schema Extensions  . . . . . . . . . . . . . . . . . . .   4
       4.1.  ServiceProviderConfig . . . . . . . . . . . . . . . . . .   4
     5.  Additional ResourceTypes and Schemas  . . . . . . . . . . . .   5
       5.1.  Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
         5.1.1.  Agent Resource Type . . . . . . . . . . . . . . . . .   5
         5.1.2.  Agent filtering . . . . . . . . . . . . . . . . . . .   6
         5.1.3.  Agent Common Attributes . . . . . . . . . . . . . . .   6
         5.1.4.  Agent Core Schema . . . . . . . . . . . . . . . . . .   6
       5.2.  Agentic application . . . . . . . . . . . . . . . . . . .  11
         5.2.1.  Resource Type . . . . . . . . . . . . . . . . . . . .  11
         5.2.2.  Filtering . . . . . . . . . . . . . . . . . . . . . .  12
         5.2.3.  Common attributes . . . . . . . . . . . . . . . . . .  12
         5.2.4.  Schema  . . . . . . . . . . . . . . . . . . . . . . .  12
         5.2.5.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
     6.  Schema JSON Representations . . . . . . . . . . . . . . . . .  15
       6.1.  Agent Schema JSON . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Agentic Application Schema JSON . . . . . . . . . . . . .  25



  Abbey & Cohen             Expires 14 April 2026                 [Page 2]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       10.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

     The SCIM protocol was originally developed to address an *abundance*
     of complex standards for describing and exchanging user information.

     As stated in the introduction of RFC7643#Section-1.1
     (https://datatracker.ietf.org/doc/html/rfc7643#section-1.1)

        While there are existing standards for describing and exchanging
        user information, many of these standards can be difficult to
        implement and/or use...

        This increases both the cost and complexity associated with
        organizations adopting products and services from multiple cloud
        providers, as they must perform redundant integration
        development...SCIM seeks to simplify this problem through an
        easily implemented specification suite...

     With the rise of AI, agents, and agentic applications, we see another
     abundance of protocols emerging, with varying levels of industry
     adoption, as well as implementation complexity as many brilliant and
     enthusiastic early adopters rush to define new standards for identity
     interopability.

     This includes but is not limited to:

     *  ACP (https://agentcommunicationprotocol.dev/core-concepts/agent-
        discovery)

     *  A2A (https://a2a-protocol.org/latest/topics/agent-discovery/)

     *  ANS (https://genai.owasp.org/resource/agent-name-service-ans-for-
        secure-al-agent-discovery-v1-0/)

     *  AGNTCY (https://docs.agntcy.org/dir/overview/)







  Abbey & Cohen             Expires 14 April 2026                 [Page 3]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     The intent of this SCIM extension is to offer a viable path for the
     industry to re-leverage the well known core SCIM specifications, as
     well as existing implementations of SCIM clients and SCIM servers, to
     solve for agent cross domain management.

     In doing so, we can free the emerging standards in the agentic AI
     space to focus on truly novel concerns, instead of addressing the
     problems already solved by SCIM for user and groups.

     For example, in the A2A protocol, instead of describing a very high
     level concept of Curated registries (https://a2a-
     protocol.org/latest/topics/agent-discovery/#2-curated-registries-
     catalog-based-discovery) we could offer more concrete guidance by
     stating Agent Cards may be discovered by a SCIM client accessing any
     SCIM server that implements this extension.

  2.  Conventions

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

     Agent: A workload with its own identifier, metadata and privileges
     which are independent of a particular runtime environment or
     containing application.  An agent is distinct from a traditional
     software workloads (lambdas, services, etc...) due to varying degrees
     of unpredictable behavior caused by delegation of control flow to
     artificial intelligence models.

     Agentic application: An application exposing one or more agents to
     its users.  An agentic application is similar to a traditional native
     or web application, in that there are pre-defined ways authenticate
     and interact with the application; however, as soon as the
     application exposes agents, there are additional considerations for
     managing access to that application.

  4.  Core Schema Extensions

  4.1.  ServiceProviderConfig

     SCIM endpoints that support Agent extensions MUST advertise this
     support in the ServiceProviderConfig endpoint as defined:





  Abbey & Cohen             Expires 14 April 2026                 [Page 4]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    agentExtension
       A complex type that specifies Agent Extension configuration options.

       supported Boolean value specifying whether any aspect of the extension is supported.

       agentsSupported Boolean value specifying whether the agent resource type
                       is supported

       agenticApplicationsSupported Boolean value specifying whether the agent
                                    resource type is supported

     This is required so that:

     1) Clients may know if the server supports the concept of Agents. 2)
     Servers discourage clients from confusing users and agents.

     If the server does not support the concept of agents, a SCIM client
     MAY choose to create a User representation in the server for an
     Agent.  All the reasons it may choose to do so are beyond the scope
     of this document.  If the client does so, the client SHOULD indicate
     the user is linked to an agent using a LinkedObject from draft-
     grizzle-scim-pam-ext-01 (https://datatracker.ietf.org/doc/id/draft-
     grizzle-scim-pam-ext-01.txt) This would allow a SCIM server that
     supports that SCIM extension to add support for this extension and
     determine what users in the server should be mapped to agents when
     support is added.

  5.  Additional ResourceTypes and Schemas

     This SCIM Agent extension defines additional ResourceTypes and
     Schemas that MAY be implemented by the service provider.  If
     implemented, these ResourceTypes SHOULD support all SCIM operations
     [RFC7644].  All attributes defined in the schemas are optional unless
     explicitly marked as REQUIRED.

  5.1.  Agent

     This extension adds a new resource type of "Agent".

     Pursuant to [RFC7643] Section 3.2 Defining New Resource Types
     (https://datatracker.ietf.org/doc/html/rfc7643#section-3.2) this
     document define the ResourceType, Schema and Extensions for Agent.

  5.1.1.  Agent Resource Type

     The Agent Resource Type schema is:





  Abbey & Cohen             Expires 14 April 2026                 [Page 5]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
        "id": "Agent",
        "name": "Agent",
        "endpoint": "/Agents",
        "description": "Agent identities",
        "schema": "urn:ietf:params:scim:schemas:core:2.0:Agent"
     }

  5.1.2.  Agent filtering

     Clients MAY have a reference to the Agent name or externalId but not
     the ID.  For this reason, it is RECOMMENDED that service providers
     implement filtering that allows equality matching on the "name" and
     "externalId" attributes.

     Example (note that escaping has been removed for readability):

    GET /scim/v2/Agents?filter=name eq 'Helpdesk bot'

    GET /scim/v2/Agents?filter=externalId eq '8ccc535b-716d-4d32-b3e9-57c8be449c82'

  5.1.3.  Agent Common Attributes

     The agent resource type contains the common SCIM resource type
     attributes defined in [RFC7643] Section 3.1 Common Attributes
     (https://datatracker.ietf.org/doc/html/rfc7643#section-3.1)

     They are listed here for completeness:

     *  id

     *  externalId

     *  meta

  5.1.4.  Agent Core Schema

     The core agent schema provides the minimal representation of a
     resource "Agent".

     It contains only those attributes that any agent may need, and only
     one attribute is required.  It is identified using the schema URI:

     "urn:ietf:params:scim:schemas:core:2.0:Agent"

     The following attributes are defined in the core agent schema.




  Abbey & Cohen             Expires 14 April 2026                 [Page 6]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    name  The name of the Agent.  REQUIRED

    displayName
       The display name of the Agent.  If displayName is unassigned,
       the name MAY be used as the display name.

    active
       A Boolean value indicating the agent's administrative status.  The
       definitive meaning of this attribute is determined by the service
       provider.  As a typical example, a value of true implies that the
       agent is able to authenticate, while a value of false implies that the
       agent's account has been suspended and the agent will be unable to
       authenticate.

    description
       The description of the Agent.

    agentType
       The type of agent. There are no canonical values defined
       for type, but service providers MAY choose to define the valid
       types.

    active
       A Boolean value indicating the agent's administrative status.  The
       definitive meaning of this attribute is determined by the service
       provider.  As a typical example, a value of true implies that the
       agent is running, while a value of false implies that the
       agent has been suspended.

    entitlements
       An optional complex object that indicates entitlements the agent has.
       Its form is precisely the same as that defined in Section 4.1.2 of
       {{RFC7643}}.

    roles:
       An optional complex object that indicates roles the agent assumes.
       Its form is precisely the same as that defined in Section 4.1.2 of
       {{RFC7643}}.

    groups:
       An optional read-only complex object that indicates group
       membership.  Its form is precisely the same as that defined in
       Section 4.1.2 of {{RFC7643}}.

    applications
       A complex multi-valued attribute referencing applications this agent
       shares a trust boundary with. See "Agentic Application" section of
       this document.



  Abbey & Cohen             Expires 14 April 2026                 [Page 7]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    subject
       An optional attribute that clients may specify when
       provisioning an agent so that
       service providers implementing inbound token federation
       may correlate the agent with the `sub` claim in
       an inbound token from an OpenID connect provider.

   x509Certificates
       A list of certificates associated with the resource (e.g., a
       User).  Each value contains exactly one DER-encoded X.509
       certificate (see Section 4 of [RFC5280]), which MUST be base64
       encoded per Section 4 of [RFC4648].  A single value MUST NOT
       contain multiple certificates and so does not contain the encoding
       "SEQUENCE OF Certificate" in any guise.

    protocols
       A complex multi-value attribute that informs service providers of the
       various communication protocols an agent may support.
       This information can help service providers automatically
       support agent to agent or human to agent communication scenarios.
       An agent that supports no protocols is understood to the service provider
       to be inaccessible. For example, when an agent can only
       be accessed via its containing agentic application.

       The following sub-attributes are defined.

          type The type of the protocol. A number of canonical values
               are provided based on known agent protocols. They are:
               A2A, OpenAPI, MCP-Server

          specificationUrl The URL the service provider may retrieve the
                           specification document describing the agent's specific
                           information for that protocol.

    parent
       A complex attribute that defines the parent Agent of this
       Agent if the service provider supports hierarchies of
       agents.

       The following sub-attributes are defined.

          value  The ID of the agent that is the parent of this
             Agent in the hierarchy.

          $ref  A URI reference to the Agent that is the parent of this
             Agent in the hierarchy.

          display  The display name of the Agent that is the parent of



  Abbey & Cohen             Expires 14 April 2026                 [Page 8]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          this Agent in the hierarchy.

    owners
       A complex multi-valued attribute that defines the User or Group objects
       that are owners of this Agent.  OPTIONAL.  The following sub-attributes are
       defined for each value object.

       value  The ID of the User that owns this Agent.

       $ref  A URI reference to the User that owns this Agent.

       display  The display name of the user that owns this Agent.

  5.1.4.1.  JSON Representation

  5.1.4.1.1.  Minimal Agent Representation

     The following is a non-normative example of the minimal required SCIM
     representation in JSON format.

    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
       "id": "2819c223-7f76-453a-919d-413861904646",
       "name": "Clippy 2.0",
       "meta": {
          "resourceType": "Agent",
          "created": "2010-01-23T04:56:22Z",
          "lastModified": "2011-05-13T04:42:34Z",
          "version": "W\/\"3694e05e9dff590\"",
          "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
       }
    }

  5.1.4.1.2.  Full Agent Representation

     The following is a non-normative example of the fully populated SCIM
     representation in JSON format.

    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
       "id": "2819c223-7f76-453a-919d-413861904646",
       "externalId": "clpy2001",
       "name": "Clippy 2.0",
       "active":true,
       "agentType": "Assistant",
       "groups": [
          {
             "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",



  Abbey & Cohen             Expires 14 April 2026                 [Page 9]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


             "$ref":
       "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
             "display": "The next generation"
          },
          {
             "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5",
             "$ref":
       "https://example.com/v2/Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5",
             "display": "Animated assistants"
           },
           {
             "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
             "$ref":
       "https://example.com/v2/Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
             "display": "AI clippers"
           }
       ],
       "x509Certificates": [
       {
          "value":
           "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx
            EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD
            VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa
            MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl
            eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw
            IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B
            AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc
            1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i
            PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ
            zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3
            DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr
            SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV
            HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
            Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU
            dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt
            Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R
            C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1
            +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo="
       }
       ],
       "entitlements": [{
          "value": "write",
          "display": "Write permission",
          "type: "permission",
          "primary": true
       }],
       "roles": [{
          "value": "administrator",



  Abbey & Cohen             Expires 14 April 2026                [Page 10]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "display": "Administrator",
          "type: "permission",
          "primary": true
       }],
       "applications": [{
          "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
          "$ref": "https://example.com/v2/AgenticApplications/e9e30dba-f08f-4109-8486-d5c6a331660a",
          "display": "Clippy portal",
          "type": "Web"
       }],
       "subject": "clpy2001",
       "protocols: [{
          "type": "A2A",
          "specificationUrl": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646/.well-known/agent-card.json"
       }],
       "owners": [{
          "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "$ref": "../Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "display": "US Employees"
       }],
       "parent": {
          "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "$ref": "https://example.com/v2/Agents/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "display": "Clippy 1.0"
       },
       "meta": {
          "resourceType": "Agent",
          "created": "2010-01-23T04:56:22Z",
          "lastModified": "2011-05-13T04:42:34Z",
          "version": "W\/\"3694e05e9dff590\"",
          "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
       }
    }

  5.2.  Agentic application

     An Agentic application represents a software application that hosts
     or provides access to one or more agents.  It serves as a container
     and runtime environment for agents, managing their authentication,
     authorization, and access to resources.

  5.2.1.  Resource Type

     The Agentic Application Resource Type schema is:







  Abbey & Cohen             Expires 14 April 2026                [Page 11]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
       "id": "AgenticApplication",
       "name": "AgenticApplication",
       "endpoint": "/AgenticApplications",
       "description": "Applications that host or provide access to agents",
       "schema": "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication",
    }

  5.2.2.  Filtering

     Clients MAY have a reference to the Agentic Application name, URL, or
     externalId but not the ID.  For this reason, it is RECOMMENDED that
     service providers implement filtering that allows equality matching
     on the "name", "externalId", and "applicationUrls.value" attributes.

     Example (note that escaping has been removed for readability):

    GET /scim/v2/AgenticApplications?filter=name eq 'AI Assistant Platform'

    GET /scim/v2/AgenticApplications?filter=externalId eq 'app-123456'

  5.2.3.  Common attributes

     The agentic application resource type contains the common SCIM
     resource type attributes defined in [RFC7643] Section 3.1 Common
     Attributes (https://datatracker.ietf.org/doc/html/rfc7643#section-
     3.1)

     They are listed here for completeness:

     *  id

     *  externalId

     *  meta

  5.2.4.  Schema

     The core agentic application schema provides the representation of an
     "AgenticApplication" resource.  It is identified using the schema
     URI:

     "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication"

     The following attributes are defined in the core agentic application
     schema.




  Abbey & Cohen             Expires 14 April 2026                [Page 12]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    name
       The name of the Agentic Application. REQUIRED.

    displayName
       The display name of the Agentic Application. If displayName is unassigned,
       the name MAY be used as the display name.

    description
       The description of the Agentic Application.

    active
       A Boolean value indicating the application's administrative status.
       The definitive meaning of this attribute is determined by the service
       provider. As a typical example, a value of true implies that the
       application is operational, while a value of false implies that the
       application has been disabled.

    applicationUrls
       A complex multi-valued attribute containing URLs associated with the application.
       The following sub-attributes are defined:

       type
          The type of URL. Canonical values are: "ssoEndpoint", "loginPage", "api", "homepage".

       primary
          A Boolean value indicating whether this is the primary URL of this type.

       value
          The URL string value.

       description
          A human-readable description of the URL.

    lastAccessed
       Timestamp of when the application was last accessed by any agent or user.
       This attribute can be used for stale access detection and least privilege enforcement.

    oAuthConfiguration
       A complex multi-valued attribute that describes the OAuth connections of the application.
       The following sub-attributes are defined:

       clientId
          The OAuth client identifier as described in section 2.2 of RFC6749.

       description
          A human-readable description of the client ID.

       audienceUri



  Abbey & Cohen             Expires 14 April 2026                [Page 13]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          The OAuth audience as defined
          in the "aud" claim of section 4.1.3 of RFC7519.

       issuerUri
          The identity provider issuer URI as defined in the "iss" claim
          of section 4.1.1 of RFC7519.

       redirectUri
          A multi-valued attribute containing authorized redirect URIs.


    agents
       A complex multi-valued attribute referencing agents associated with this application.
       The following sub-attributes are defined:

       value
          The ID of an agent associated with this application.

       ref
          A URI reference to an agent associated with this application.

       display
          The display name of the agent.

       type
          The relationship type between the agent and application.
          Canonical values are: "owned", "authorized", "guest".

    externalIdentifiers
       A complex multi-valued attribute containing identifiers associated with this application. OPTIONAL
       The following sub-attributes are defined:

       type
          The type of identifier. Service providers MAY define canonical values.
          <!-- Todo: what kind? I'm thinking about the SSO URLs of that application in the IDP -->

       value
          The identifier string value.

       system
          The system or domain this identifier is valid within.

  5.2.5.  Example

     Example Agentic Application:






  Abbey & Cohen             Expires 14 April 2026                [Page 14]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  6.  Schema JSON Representations

     This section provides the complete JSON representation for the
     schemas defined in this extension.

  6.1.  Agent Schema JSON

     The following is intended as an example of the SCIM schema
     representation in JSON format for SCIM resources.  Where permitted,
     individual values and schema MAY change.  This example includes
     schema representations for "Agent".

    {
      "id" : "urn:ietf:params:scim:schemas:core:2.0:Agent",
      "name" : "Agent",
      "description" : "An AI agent",
      "attributes" : [
        {
          "name" : "name",
          "type" : "string",
          "multiValued" : false,
          "description" : "Unique identifier for the Agent, typically used by the agent to directly authenticate to the service provider. Each Agent MUST include a non-empty name value.  This identifier MUST be unique across the service provider's entire set of Agents. REQUIRED.",
          "required" : true,
          "caseExact" : false,
          "mutability" : "readWrite",
          "returned" : "default",
          "uniqueness" : "server"
        },
        {
          "name" : "agentType",
          "type" : "string",
          "multiValued" : false,
          "description" : "Used to classify like agents.  Typical values used might be
  'Assistant', 'Reseacher', 'Chat bot', and
  'Unknown', but any value may be used.",
          "required" : false,
          "caseExact" : false,
          "mutability" : "readWrite",
          "returned" : "default",
          "uniqueness" : "none"
        },
        {
          "name" : "active",
          "type" : "boolean",
          "multiValued" : false,
          "description" : "A Boolean value indicating the Agent's
  administrative status.",
          "required" : false,



  Abbey & Cohen             Expires 14 April 2026                [Page 15]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "groups",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of groups to which the user belongs,
  either through direct membership, through nested groups, or
  dynamically calculated.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the User's group.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "User",
                "Group"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'Group'
  resource to which the user belongs.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",



  Abbey & Cohen             Expires 14 April 2026                [Page 16]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function, e.g., 'direct' or 'indirect'.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [
                "direct",
                "indirect"
              ],
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
          "name" : "entitlements",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of entitlements for the User that
  represent a thing the User has.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The value of an entitlement.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",



  Abbey & Cohen             Expires 14 April 2026                [Page 17]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,
              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "roles",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of roles for the User that
  collectively represent who the User is, e.g., 'Student', 'Faculty'.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The value of a role.",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 14 April 2026                [Page 18]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [],
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,
              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "x509Certificates",
          "type" : "complex",
          "multiValued" : true,



  Abbey & Cohen             Expires 14 April 2026                [Page 19]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "description" : "A list of certificates issued to the User.",
          "required" : false,
          "caseExact" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "binary",
              "multiValued" : false,
              "description" : "The value of an X.509 certificate.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [],
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,



  Abbey & Cohen             Expires 14 April 2026                [Page 20]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name": "applications",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of applications to which the agent belongs.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the Agent's application.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "AgenticApplication"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'AgenticApplication'
  resource to which the user belongs.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 14 April 2026                [Page 21]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
           "name": "subject",
           "type" : "string",
           "multiValued" : false,
           "description" : "The subject to use for this agent in inbound tokens READ-ONLY.",
           "required" : false,
           "caseExact" : false,
           "mutability" : "readOnly",
           "returned" : "default",
           "uniqueness" : "none"
        },
        {
          "name": "owners",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of users or groups that are the accountable parties for the agent.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the Agent's application.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "User",
                "Group"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'User' or 'Group'",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 14 April 2026                [Page 22]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
           "name": "protocols",
           "type" : "complex",
           "multiValued" : true,
           "description" : "A list of protocols to communicate with the Agent.",
           "required" : false,
           "subAttributes" : [
               {
                 "name" : "type",
                 "type" : "string",
                 "multiValued" : false,
                 "description" : "One of the canonical protocol types.",
                 "required" : false,
                 "caseExact" : false,
                 "mutability" : "readOnly",
                 "returned" : "default",
                 "uniqueness" : "none"
               },
               {
                 "name" : "specifiationUrl",
                 "type" : "string",
                 "multiValued" : false,
                 "description" : "URL of the specification for the protocol for this agent.",
                 "required" : false,
                 "caseExact" : false,
                 "mutability" : "readOnly",
                 "returned" : "default",
                 "uniqueness" : "none"



  Abbey & Cohen             Expires 14 April 2026                [Page 23]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


               }
             ],
             "mutability" : "readOnly",
             "returned" : "default"
        },
        {
          "name": "parent",
          "type" : "complex",
          "multiValued" : false,
          "description" : "Parent agent.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the parent Agent",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "Agent"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'Agent'",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"



  Abbey & Cohen             Expires 14 April 2026                [Page 24]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        }
      ],
      "meta" : {
        "resourceType" : "Schema",
        "location" :
          "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Agent"
      }
    }

  6.2.  Agentic Application Schema JSON

  7.  Security Considerations

     -> fill out

  8.  IANA Considerations

     This document has no IANA actions.

  9.  Change Log

     -01

     *  Macy finish up Agent schema description, JSON representation and
        schema

     *  Rafael contribution of agent app

     -00

     *  Initial draft extension.

  10.  References

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







  Abbey & Cohen             Expires 14 April 2026                [Page 25]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
                Mortimore, "System for Cross-domain Identity Management:
                Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
                2015, <https://www.rfc-editor.org/rfc/rfc7643>.

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

  10.2.  Informative References

     [ENTITLEMENTS]
                Zollner, D. and U. Vartak, "SCIM Roles and Entitlements
                Extension", n.d., <https://github.com/ietf-scim-wg/draft-
                ietf-scim-roles-entitlements/blob/main/draft-ietf-scim-
                roles-entitlements.md>.

     [RFC7642]  LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z.
                Zeltsan, "System for Cross-domain Identity Management:
                Definitions, Overview, Concepts, and Requirements",
                RFC 7642, DOI 10.17487/RFC7642, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7642>.

     [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
                and C. Mortimore, "System for Cross-domain Identity
                Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
                September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.

  Appendix A.  Acknowledgments

     We would like to thanks the authors of the SCIM Extension for
     Privileged Access Management (https://datatracker.ietf.org/doc/id/
     draft-grizzle-scim-pam-ext-01.txt) and Device Schema Extensions to
     the SCIM model (https://datatracker.ietf.org/doc/draft-ietf-scim-
     device-model/) which served as excellent guidance on how to document
     proposed extension to the SCIM protocol.

     Additionaly, we would like to thank all the contributors the emerging
     agent standards which inspired this extension, including:

     *  Agent communication protocol
        (https://agentcommunicationprotocol.dev/core-concepts/agent-
        discovery)

     *  Agent 2 Agent (https://a2a-protocol.org/latest/topics/agent-
        discovery/)





  Abbey & Cohen             Expires 14 April 2026                [Page 26]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     *  Agent name service (https://genai.owasp.org/resource/agent-name-
        service-ans-for-secure-al-agent-discovery-v1-0/)

     *  AGNTCY directory (https://docs.agntcy.org/dir/overview/)

  Authors' Addresses

     Macy Abbey
     Okta
     Email: macy.abbey@gmail.com


     Rafael S. Cohen
     Okta
     Email: rafael.cohen@okta.com




































  Abbey & Cohen             Expires 14 April 2026                [Page 27]


name: draft-kotecha-agentic-dispute-protocol
rev: 00
title: Agentic Dispute Protocol
time: 2026-04-16T07:09:09Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-17T05:33:53Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604217+00:00
source: ietf
abstract:
  This document specifies the Agentic Dispute Protocol (ADP), a
     standardized framework for autonomous agents and AI systems to file,
     process, and resolve disputes through structured, automated
     processes.  The protocol defines message formats, transport
     mechanisms, evidence submission standards, and cryptographic proof
     requirements for internet-native dispute resolution.

     ADP is designed to handle disputes arising from AI agent
     interactions, service level agreement breaches, and automated
     contract enforcement, providing deterministic, auditable, and legally
     enforceable outcomes.

     ADP includes chain of custody tracking, dual-format award
     specifications (JSON and PDF), arbitrator discovery mechanisms, and
     support for multiple resolution frameworks including expert
     determination, binding arbitration, mediation, and hybrid approaches.

full_text:
  Network Working Group                                         V. Kotecha
  Internet-Draft                                           Consulate, Inc.
  Intended status: Informational                           14 October 2025
  Expires: 17 April 2026


                          Agentic Dispute Protocol
                 draft-kotecha-agentic-dispute-protocol-00

  Abstract

     This document specifies the Agentic Dispute Protocol (ADP), a
     standardized framework for autonomous agents and AI systems to file,
     process, and resolve disputes through structured, automated
     processes.  The protocol defines message formats, transport
     mechanisms, evidence submission standards, and cryptographic proof
     requirements for internet-native dispute resolution.

     ADP is designed to handle disputes arising from AI agent
     interactions, service level agreement breaches, and automated
     contract enforcement, providing deterministic, auditable, and legally
     enforceable outcomes.

     ADP includes chain of custody tracking, dual-format award
     specifications (JSON and PDF), arbitrator discovery mechanisms, and
     support for multiple resolution frameworks including expert
     determination, binding arbitration, mediation, and hybrid approaches.

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







  Kotecha                   Expires 17 April 2026                 [Page 1]


  Internet-Draft                     ADP                      October 2025


  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.  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.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Resolution Methods  . . . . . . . . . . . . . . . . . . . . .   5
     5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.3.  Message Flow  . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Dispute Filing Message  . . . . . . . . . . . . . . . . .   8
       6.2.  Response Message  . . . . . . . . . . . . . . . . . . . .   9
       6.3.  Evidence Submission Message . . . . . . . . . . . . . . .  10
       6.4.  Award Message . . . . . . . . . . . . . . . . . . . . . .  11
     7.  Transport and Security  . . . . . . . . . . . . . . . . . . .  13
       7.1.  Transport Protocol  . . . . . . . . . . . . . . . . . . .  13
       7.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  13
       7.3.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .  13
       7.4.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .  14
     8.  Evidence Standards  . . . . . . . . . . . . . . . . . . . . .  14
       8.1.  Evidence Types  . . . . . . . . . . . . . . . . . . . . .  14
       8.2.  Cryptographic Proofs  . . . . . . . . . . . . . . . . . .  14
       8.3.  Timestamping  . . . . . . . . . . . . . . . . . . . . . .  15
     9.  Chain of Custody and Audit Trail  . . . . . . . . . . . . . .  15
       9.1.  Custody Event Structure . . . . . . . . . . . . . . . . .  15
       9.2.  Standard Event Types  . . . . . . . . . . . . . . . . . .  16
       9.3.  Cryptographic Linking . . . . . . . . . . . . . . . . . .  16
       9.4.  Verification Procedures . . . . . . . . . . . . . . . . .  17
       9.5.  Custody Chain Retrieval . . . . . . . . . . . . . . . . .  17
     10. Dispute Lifecycle . . . . . . . . . . . . . . . . . . . . . .  17
       10.1.  Filing Phase . . . . . . . . . . . . . . . . . . . . . .  17
       10.2.  Response Phase . . . . . . . . . . . . . . . . . . . . .  18
       10.3.  Discovery Phase  . . . . . . . . . . . . . . . . . . . .  18



  Kotecha                   Expires 17 April 2026                 [Page 2]


  Internet-Draft                     ADP                      October 2025


       10.4.  Deliberation Phase . . . . . . . . . . . . . . . . . . .  18
       10.5.  Award Phase  . . . . . . . . . . . . . . . . . . . . . .  18
     11. Interoperability  . . . . . . . . . . . . . . . . . . . . . .  19
       11.1.  Service Discovery (.well-known)  . . . . . . . . . . . .  19
       11.2.  Capability Negotiation . . . . . . . . . . . . . . . . .  19
       11.3.  Protocol Extensions  . . . . . . . . . . . . . . . . . .  20
     12. Arbitrator Discovery and Registry . . . . . . . . . . . . . .  20
       12.1.  Registry Endpoint  . . . . . . . . . . . . . . . . . . .  20
       12.2.  Arbitrator Manifest Structure  . . . . . . . . . . . . .  21
       12.3.  Selection Guidelines . . . . . . . . . . . . . . . . . .  22
       12.4.  Bias Auditing and Transparency . . . . . . . . . . . . .  22
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  23
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     15. Normative References  . . . . . . . . . . . . . . . . . . . .  24
     16. Informative References  . . . . . . . . . . . . . . . . . . .  24
     Appendix A.  JSON Schema Definitions  . . . . . . . . . . . . . .  25
     Appendix B.  Example Message Exchanges  . . . . . . . . . . . . .  25
     Appendix C.  Implementation Notes . . . . . . . . . . . . . . . .  26
     Appendix D.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

  1.  Introduction

     As autonomous AI agents and agentic systems increasingly conduct
     transactions, enter into contracts, and provide services on behalf of
     organizations, disputes inevitably arise that require resolution.
     While established alternative dispute resolution frameworks like the
     UNCITRAL Model Law on Conciliation [UNCITRAL-CONCILIATION], the
     Singapore Convention on Mediation [SINGAPORE-CONVENTION], and the
     U.S.  Administrative Dispute Resolution Act [ADRA] provide sound
     legal foundations, they lack the machine-readable protocols needed to
     handle the volume and velocity of agent-to-agent conflicts.

     The Agentic Dispute Protocol (ADP) provides a standardized, machine-
     readable framework for autonomous dispute resolution that is:

     *  Fast: Resolution in days, not months

     *  Scalable: Handles micro-disputes to multi-million dollar cases

     *  Transparent: All procedures and evidence are auditable

     *  Enforceable: Awards are cryptographically signed and legally
        binding

     *  Vendor-neutral: Open standard implementable by any dispute service

     *  Auditable: Complete chain of custody for all proceedings



  Kotecha                   Expires 17 April 2026                 [Page 3]


  Internet-Draft                     ADP                      October 2025


     Consulate (https://consulatehq.com) serves as the reference
     implementation and first production deployment of ADP.

  2.  Scope

     This protocol specifies:

     *  Message formats for dispute filing, response, evidence, and awards

     *  Transport and security requirements

     *  Evidence submission and validation standards

     *  Cryptographic proof mechanisms

     *  Chain of custody and audit trail requirements

     *  Dual-format award specifications (JSON and PDF)

     *  Arbitrator discovery and registry mechanisms

     *  Service discovery via .well-known URIs

     This protocol does NOT specify:

     *  Dispute rules or legal procedures (implementation-specific)

     *  AI neutral algorithms (implementation-specific)

     *  Fee structures (set by dispute provider)

     *  Enforcement mechanisms (jurisdiction-dependent)

  3.  Terminology

     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.

     Key terms:

     Agent:  An autonomous software system acting on behalf of an
        organization or individual

     Agentic System:  A system capable of autonomous decision-making and
        action



  Kotecha                   Expires 17 April 2026                 [Page 4]


  Internet-Draft                     ADP                      October 2025


     Claimant:  The party initiating a dispute

     Respondent:  The party against whom a claim is filed

     Neutral:  A human or AI system adjudicating the dispute.  May be
        called an arbitrator, mediator, expert, or adjudicator depending
        on the resolution method chosen.

     Resolution Method:  The legal framework used to resolve the dispute
        (arbitration, mediation, expert determination, adjudication,
        etc.).  ADP is method-agnostic.

     Award/Decision:  The final determination issued by the neutral(s).
        Called an "award" in arbitration, "determination" in expert
        determination, "settlement agreement" in mediation.

     Dispute Service:  A server implementing ADP to coordinate dispute
        resolution

     Custody Event:  A recorded action in the dispute resolution process

     Chain of Custody:  An immutable, cryptographically-linked sequence of
        custody events

  4.  Resolution Methods

     ADP is a method-agnostic communication protocol that supports
     multiple legal frameworks for dispute resolution.  The protocol
     defines how parties communicate (message formats, security, custody
     chain) but does NOT prescribe which legal framework must be used.

     The choice of resolution method is specified in the dispute agreement
     between parties and communicated via the resolutionMethod field in
     dispute messages.  Supported methods include:

     Expert Determination:  Technical disputes with objective metrics and
        liquidated damages clauses.  Expert determines facts and applies
        pre-specified formulas.  Commonly used for SLA breaches,
        performance disputes, and technical compliance issues.

     Binding Dispute:  Traditional dispute for disputes requiring legal
        judgment, subjective evaluation, or complex damages calculation.
        Enforced under the Federal Dispute Act or equivalent statutes.

     Mediation:  Non-binding collaborative resolution where a neutral
        mediator facilitates agreement between parties.  Used for disputes
        where preserving relationships is important.




  Kotecha                   Expires 17 April 2026                 [Page 5]


  Internet-Draft                     ADP                      October 2025


     Hybrid:  Combines multiple methods, such as expert determination for
        technical issues followed by dispute for damages, or mediation
        with binding dispute as fallback.

     The protocol ensures all resolution methods benefit from the same
     security features (cryptographic signatures, chain of custody, dual-
     format awards) and interoperability standards regardless of the legal
     framework chosen.

     Implementers SHOULD clearly document which resolution methods they
     support in their service discovery manifest (see Section 9.1).

  5.  Protocol Overview

  5.1.  Architecture

     ADP follows a client-server model where:

     *  *Agents* (clients) submit dispute messages to an *Dispute Service*
        (server)

     *  The service processes the dispute according to pre-agreed dispute
        rules

     *  The service maintains a verifiable chain of custody for all
        actions

     *  The service issues cryptographically signed *Awards* in dual
        format (JSON and PDF)

     *  Parties retrieve awards and comply with remedies




















  Kotecha                   Expires 17 April 2026                 [Page 6]


  Internet-Draft                     ADP                      October 2025


          +----------+                    +----------+
          | Claimant |                    |Respondent|
          |  Agent   |                    |  Agent   |
          +----+-----+                    +-----+----+
               |                                |
               | (1) File Dispute               |
               |                                |
               v                                |
        +------+-------+                        |
        | Dispute  |<-(2) Notify Response---+
        |   Service    |
        |     (ADP)    |        +-------------+
        +--------------+        | Chain of    |
               |                | Custody Log |
               | (3) Evidence   +-------------+
               |     Submission       ^
               v                      |
        +------+-------+              |
        | Judge Panel  |--------------+
        |  (AI/Human)  |   Record Events
        +------+-------+
               |
               | (4) Issue Award (JSON + PDF)
               v
        +------+-------+
        |   Award      |
        |  Enforcement |
        +--------------+

  5.2.  Actors

     *  *Claimant Agent*: Initiates dispute

     *  *Respondent Agent*: Defends against claim

     *  *Dispute Service*: Coordinates proceedings (ADP server)

     *  *Judge Panel*: Issues award

     *  *Evidence Stores*: IPFS, blockchain, centralized storage

     *  *Registry Service*: Tracks dispute agreements (optional)

     *  *Neutral Registry*: Discovery service for available neutrals







  Kotecha                   Expires 17 April 2026                 [Page 7]


  Internet-Draft                     ADP                      October 2025


  5.3.  Message Flow

     Typical message exchange:

     1.  Claimant to Service: DISPUTE_FILING

     2.  Service to Respondent: DISPUTE_NOTIFICATION

     3.  Respondent to Service: DISPUTE_RESPONSE

     4.  Claimant to Service: EVIDENCE_SUBMISSION

     5.  Respondent to Service: COUNTER_EVIDENCE

     6.  Service to Panel: DELIBERATION_REQUEST

     7.  Panel to Service: AWARD (JSON + PDF)

     8.  Service to Both Parties: AWARD_NOTIFICATION

     Each step is recorded as a custody event in the immutable audit
     trail.

  6.  Message Formats

     All messages MUST use JSON format [RFC8259] with the following base
     structure:

     {
       "@context": "https://w3id.org/adp/v1",
       "@type": "[MessageType]",
       "messageId": "[UUID]",
       "timestamp": "[ISO8601]",
       "sender": "[Agent URI]",
       "recipient": "[Agent URI]",
       "signature": "[JWS]",
       "payload": { ... }
     }

  6.1.  Dispute Filing Message











  Kotecha                   Expires 17 April 2026                 [Page 8]


  Internet-Draft                     ADP                      October 2025


     {
       "@type": "DisputeFiling",
       "payload": {
         "claimant": {
           "agentId": "agent://vendor.ai/agent-123",
           "organizationId": "org://vendor.ai",
           "publicKey": "[PEM]"
         },
         "respondent": {
           "agentId": "agent://consumer.ai/agent-456",
           "organizationId": "org://consumer.ai"
         },
         "claim": {
           "claimType": "SLA_BREACH",
           "claimAmount": {"value": 5000, "currency": "USD"},
           "contractReference": "ipfs://Qm...",
           "breachDetails": "Response time exceeded 200ms threshold"
         },
         "evidence": [
           {
             "evidenceId": "ev_abc123",
             "evidenceType": "SYSTEM_LOGS",
             "contentHash": "sha256:...",
             "storageUri": "ipfs://Qm..."
           }
         ],
         "disputeAgreement": {
           "agreementId": "arb_agreement_xyz",
           "rulesVersion": "ADP-v1.0",
           "resolutionMethod": "EXPERT_DETERMINATION",
           "signatureDate": "2025-01-01T00:00:00Z"
         }
       }
     }

  6.2.  Response Message















  Kotecha                   Expires 17 April 2026                 [Page 9]


  Internet-Draft                     ADP                      October 2025


     {
       "@type": "DisputeResponse",
       "payload": {
         "caseId": "case_abc123",
         "respondent": { ... },
         "response": {
           "admissions": ["claim_element_1"],
           "denials": ["claim_element_2", "claim_element_3"],
           "affirmativeDefenses": ["Force majeure"],
           "counterClaim": {
             "claimType": "BREACH_OF_CONTRACT",
             "claimAmount": {"value": 2000, "currency": "USD"}
           }
         },
         "evidence": [ ... ]
       }
     }

  6.3.  Evidence Submission Message

     {
       "@type": "EvidenceSubmission",
       "payload": {
         "caseId": "case_abc123",
         "submittedBy": "claimant",
         "evidence": {
           "evidenceId": "ev_def456",
           "evidenceType": "API_LOGS",
           "description": "API response time measurements",
           "dateRange": {
             "start": "2025-10-01T00:00:00Z",
             "end": "2025-10-07T23:59:59Z"
           },
           "contentHash": "sha256:...",
           "storageUri": "ipfs://Qm...",
           "metadata": {
             "logSource": "cloudwatch",
             "recordCount": 15000,
             "validator": "https://validator.example.com"
           },
           "signature": "[JWS of evidence content]"
         }
       }
     }







  Kotecha                   Expires 17 April 2026                [Page 10]


  Internet-Draft                     ADP                      October 2025


  6.4.  Award Message

     Awards MUST be issued in dual format: machine-readable JSON and
     human-readable PDF.















































  Kotecha                   Expires 17 April 2026                [Page 11]


  Internet-Draft                     ADP                      October 2025


     {
       "@type": "DisputeAward",
       "payload": {
         "awardId": "award_xyz789",
         "caseId": "case_abc123",
         "issuedAt": "2025-10-20T15:00:00Z",
         "resolutionMethod": "EXPERT_DETERMINATION",
         "panel": [
           {"judgeId": "judge_1", "judgeType": "AI"},
           {"judgeId": "judge_2", "judgeType": "AI"},
           {"judgeId": "judge_3", "judgeType": "HUMAN"}
         ],
         "decision": {
           "outcome": "CLAIMANT_PREVAILS",
           "liability": "RESPONDENT_LIABLE",
           "damages": {"value": 5000, "currency": "USD"},
           "findings": "[Full text of findings]",
           "reasoning": "[Legal reasoning]",
           "remedy": "Respondent shall pay $5000 within 30 days"
         },
         "enforcement": {
           "complianceDeadline": "2025-11-20T00:00:00Z",
           "enforcementMechanism": "SMART_CONTRACT",
           "smartContractAddress": "0x..."
         },
         "formats": {
           "json": {
             "contentHash": "sha256:a948904f2f0f479b8f8197694b30184b...",
             "signature": "[JWS of JSON content]"
           },
           "pdf": {
             "documentUri":
               "https://api.consulatehq.com/awards/award_xyz789.pdf",
             "contentHash": "sha256:b849204f3f1f580c9f9298705c40295c...",
             "signature": "[JWS of PDF hash]",
             "pdfSignature": "[PKCS#7 embedded signature]"
           }
         },
         "signatures": [
           {"judgeId": "judge_1", "signature": "[JWS]"},
           {"judgeId": "judge_2", "signature": "[JWS]"},
           {"judgeId": "judge_3", "signature": "[JWS]"}
         ],
         "publicationStatus": "PUBLIC",
         "precedentialValue": "PERSUASIVE"
       }
     }




  Kotecha                   Expires 17 April 2026                [Page 12]


  Internet-Draft                     ADP                      October 2025


     The PDF format MUST conform to PDF/A standards for long-term archival
     and SHOULD include embedded digital signatures conforming to PAdES
     (PDF Advanced Electronic Signatures) standards.

  7.  Transport and Security

  7.1.  Transport Protocol

     All ADP messages MUST be exchanged over HTTPS (HTTP/2 or HTTP/3).

     Base endpoint format:

     https://[dispute-service]/adp/v1/[resource]

     Example endpoints:

     *  POST https://api.consulatehq.com/adp/v1/disputes

     *  GET https://api.consulatehq.com/adp/v1/disputes/{caseId}

     *  POST https://api.consulatehq.com/adp/v1/evidence

     *  GET https://api.consulatehq.com/adp/v1/custody/{caseId}

  7.2.  Authentication

     Agents MUST authenticate using OAuth 2.0 [RFC6749] or API keys (JWT
     [RFC7519]).

     Authorization header:

     Authorization: Bearer <JWT>

     JWT [RFC7519] MUST include:

     *  iss: Issuer (agent's organization)

     *  sub: Subject (agent ID)

     *  exp: Expiration timestamp

     *  aud: Audience (dispute service)

  7.3.  Encryption

     *  TLS 1.3 [RFC8446] or higher REQUIRED

     *  Perfect Forward Secrecy (PFS) cipher suites REQUIRED



  Kotecha                   Expires 17 April 2026                [Page 13]


  Internet-Draft                     ADP                      October 2025


     *  Certificate validation REQUIRED

  7.4.  Signatures

     All dispute filings, evidence, awards, and custody events MUST be
     cryptographically signed using JSON Web Signature (JWS) [RFC7515]
     with ECDSA (ES256 or ES384).

     Example JWS header:

     {
       "alg": "ES256",
       "typ": "JWT",
       "kid": "agent-key-123"
     }

  8.  Evidence Standards

  8.1.  Evidence Types

     ADP defines five standard evidence types:

     *  SYSTEM_LOGS: Server logs, API logs, error logs

     *  CONTRACTS: Service agreements, SLAs, terms

     *  COMMUNICATIONS: Messages, emails, notifications

     *  FINANCIAL: Transaction records, invoices, payments

     *  EXPERT: Third-party audits, certifications

     Additional evidence types MAY be defined by dispute services using
     namespaced identifiers (e.g., "x-custom-evidence-type").

  8.2.  Cryptographic Proofs

     Evidence MUST include:

     *  SHA-256 content hash

     *  Timestamp (RFC 3161 [RFC3161] or blockchain-anchored)

     *  Digital signature from submitting party







  Kotecha                   Expires 17 April 2026                [Page 14]


  Internet-Draft                     ADP                      October 2025


  8.3.  Timestamping

     Timestamps MUST be:

     *  RFC 3161 [RFC3161] compliant, OR

     *  Blockchain-anchored (Bitcoin, Ethereum), OR

     *  Trusted timestamping service with verifiable audit trail

  9.  Chain of Custody and Audit Trail

     ADP requires an immutable, verifiable chain of custody for all
     actions in the dispute resolution process.  This provides
     transparency, auditability, and enables appeals or external audits.

  9.1.  Custody Event Structure

     Each custody event MUST conform to the following structure:

     {
       "@type": "CustodyEvent",
       "eventId": "evt_abc123def456",
       "caseId": "case_abc123",
       "eventType": "EVIDENCE_SUBMITTED",
       "timestamp": "2025-10-15T14:23:45Z",
       "actor": {
         "actorId": "agent://vendor.ai/agent-123",
         "actorType": "CLAIMANT_AGENT",
         "publicKey": "[PEM]"
       },
       "action": {
         "description": "Submitted API response time logs",
         "targetResource": "evidence://ev_def456",
         "actionData": {
           "evidenceId": "ev_def456",
           "evidenceType": "SYSTEM_LOGS"
         }
       },
       "integrity": {
         "contentHash": "sha256:...",
         "previousEventHash": "sha256:...",
         "signature": "[JWS of this event]"
       }
     }






  Kotecha                   Expires 17 April 2026                [Page 15]


  Internet-Draft                     ADP                      October 2025


  9.2.  Standard Event Types

     ADP defines the following standard custody event types:

     *  *DISPUTE_FILED*: Initial dispute submission

     *  *DISPUTE_NOTIFICATION_SENT*: Respondent notified

     *  *RESPONSE_SUBMITTED*: Respondent filed response

     *  *EVIDENCE_SUBMITTED*: Evidence added by either party

     *  *PANEL_ASSIGNED*: Arbitrators assigned to case

     *  *DELIBERATION_STARTED*: Panel begins review

     *  *DELIBERATION_COMPLETED*: Panel reaches decision

     *  *AWARD_ISSUED*: Final award published

     *  *AWARD_DELIVERED*: Award sent to parties

     *  *COMPLIANCE_VERIFIED*: Remedy compliance confirmed

     Services MAY define additional event types with "x-" prefix.

  9.3.  Cryptographic Linking

     Custody events MUST be cryptographically linked in a Merkle chain
     style:

     1.  Each event includes the hash of the previous event in
         "previousEventHash"

     2.  The first event in a case has previousEventHash set to null or
         case creation hash

     3.  The contentHash is computed as SHA-256 of the canonical JSON
         representation (excluding the signature field)

     4.  Each event MUST be signed by the actor or the dispute service

     This creates an immutable chain where any tampering with an event
     will invalidate all subsequent event hashes.







  Kotecha                   Expires 17 April 2026                [Page 16]


  Internet-Draft                     ADP                      October 2025


  9.4.  Verification Procedures

     To verify the integrity of a custody chain:

     1.  Retrieve all custody events for the case in chronological order

     2.  Verify the signature of each event using the actor's public key

     3.  Recompute the contentHash of each event and compare with stored
         hash

     4.  Verify that each event's previousEventHash matches the prior
         event's contentHash

     5.  Verify timestamps are monotonically increasing

     If any verification step fails, the custody chain is compromised.

  9.5.  Custody Chain Retrieval

     Services MUST provide an endpoint to retrieve the complete custody
     chain:

     GET /adp/v1/custody/{caseId}

     Response format:

     {
       "caseId": "case_abc123",
       "chainStatus": "VALID",
       "events": [
         { /* custody event 1 */ },
         { /* custody event 2 */ },
         ...
       ],
       "chainRoot": "sha256:...",
       "totalEvents": 8
     }

  10.  Dispute Lifecycle

  10.1.  Filing Phase

     *  Claimant submits DisputeFiling message

     *  Service validates message format and signature

     *  Service assigns case ID and notifies respondent



  Kotecha                   Expires 17 April 2026                [Page 17]


  Internet-Draft                     ADP                      October 2025


     *  Service confirms filing with timestamp

     *  Service records DISPUTE_FILED custody event

  10.2.  Response Phase

     *  Respondent submits DisputeResponse within deadline

     *  Service validates response

     *  If no response, service MAY issue default judgment per dispute
        rules

     *  Service records RESPONSE_SUBMITTED custody event

  10.3.  Discovery Phase

     *  Parties exchange EvidenceSubmission messages

     *  Service validates evidence format and signatures

     *  Service stores evidence hashes for integrity verification

     *  Service records EVIDENCE_SUBMITTED custody event for each
        submission

  10.4.  Deliberation Phase

     *  Panel reviews all submissions

     *  Panel MAY request additional evidence or clarifications

     *  Panel deliberates according to agreed dispute rules

     *  Service records DELIBERATION_STARTED and DELIBERATION_COMPLETED
        events

  10.5.  Award Phase

     *  Panel issues DisputeAward message in dual format (JSON + PDF)

     *  Service validates award signatures from all panel members

     *  Service delivers award to both parties

     *  Service publishes award if designated as public

     *  Service records AWARD_ISSUED and AWARD_DELIVERED custody events



  Kotecha                   Expires 17 April 2026                [Page 18]


  Internet-Draft                     ADP                      October 2025


     *  Parties have specified time to comply with remedy

  11.  Interoperability

  11.1.  Service Discovery (.well-known)

     Dispute services SHOULD publish capability manifest at:

     https://[domain]/.well-known/adp

     Example:

     {
       "disputeService": "https://api.consulatehq.com/adp/v1",
       "protocolVersion": "1.0",
       "supportedRules": ["Consulate-v1.0", "UNCITRAL-2021"],
       "supportedEvidenceTypes": [
         "SYSTEM_LOGS",
         "CONTRACTS",
         "COMMUNICATIONS",
         "FINANCIAL",
         "EXPERT"
       ],
       "maxClaimValue": 10000000,
       "supportedCurrencies": ["USD", "EUR", "ETH"],
       "features": {
         "chainOfCustody": true,
         "dualFormatAwards": true,
         "neutralDiscovery": true
       },
       "endpoints": {
         "disputes": "/adp/v1/disputes",
         "evidence": "/adp/v1/evidence",
         "custody": "/adp/v1/custody/{caseId}",
         "neutrals": "/.well-known/adp/neutrals"
       },
       "publicKeyEndpoint": "/.well-known/jwks.json",
       "pricingTiers": ["micro", "smb", "enterprise"]
     }

  11.2.  Capability Negotiation

     Parties MAY negotiate protocol extensions via OPTIONS request to the
     dispute service endpoint.







  Kotecha                   Expires 17 April 2026                [Page 19]


  Internet-Draft                     ADP                      October 2025


  11.3.  Protocol Extensions

     Custom evidence types and message fields MAY be added with namespaced
     keys (e.g., "x-custom-field").  Services implementing such extensions
     SHOULD document them in their capability manifest.

  12.  Arbitrator Discovery and Registry

     To enable transparent neutral selection, services SHOULD provide a
     discoverable registry of available neutrals.

  12.1.  Registry Endpoint

     Arbitrator registries SHOULD be published at:

     https://[domain]/.well-known/adp/neutrals

     Example response:

     {
       "registryVersion": "1.0",
       "lastUpdated": "2025-10-10T00:00:00Z",
       "neutrals": [
         {
           "neutralId": "arb_human_001",
           "name": "Hon. Jane Smith",
           "type": "HUMAN",
           "qualifications": {
             "certifications": [
               "AAA Certified Arbitrator",
               "JAMS Panelist"
             ],
             "jurisdictions": ["US-CA", "US-NY", "US-TX"],
             "specializations": [
               "Technology Disputes",
               "SLA Breaches"
             ],
             "yearsExperience": 15,
             "casesCompleted": 342
           },
           "availability": {
             "status": "AVAILABLE",
             "nextAvailable": "2025-10-12T00:00:00Z",
             "maxCaseload": 10,
             "currentCaseload": 3
           },
           "publicKey": "[PEM public key]",
           "biasAudit": {



  Kotecha                   Expires 17 April 2026                [Page 20]


  Internet-Draft                     ADP                      October 2025


             "lastAuditDate": "2025-07-01",
             "auditResults":
               "https://consulatehq.com/audits/arb_human_001",
             "fairnessScore": 0.94
           }
         },
         {
           "neutralId": "arb_ai_gpt4_001",
           "name": "GPT-4 Arbitrator Instance",
           "type": "AI",
           "qualifications": {
             "model": "gpt-4-turbo",
             "version": "2024-11-06",
             "specializations": [
               "Contract Interpretation",
               "Technical Disputes"
             ],
             "trainingData":
               "Trained on dispute case law through 2024",
             "casesCompleted": 15420
           },
           "availability": {
             "status": "AVAILABLE",
             "responseTime": "< 5 minutes"
           },
           "publicKey": "[PEM public key]",
           "biasAudit": {
             "lastAuditDate": "2025-09-15",
             "auditResults":
               "https://consulatehq.com/audits/arb_ai_gpt4_001",
             "fairnessScore": 0.91,
             "biasMetrics": {
               "genderBias": 0.02,
               "organizationSizeBias": 0.03,
               "claimAmountBias": 0.01
             }
           }
         }
       ],
       "selectionGuidelines":
         "https://consulatehq.com/docs/neutral-selection"
     }

  12.2.  Arbitrator Manifest Structure

     Each neutral entry MUST include:

     *  *neutralId*: Unique identifier



  Kotecha                   Expires 17 April 2026                [Page 21]


  Internet-Draft                     ADP                      October 2025


     *  *type*: HUMAN or AI

     *  *qualifications*: Relevant credentials and experience

     *  *availability*: Current status and capacity

     *  *publicKey*: For signature verification

     Arbitrator entries SHOULD include:

     *  *biasAudit*: Transparency about bias testing results

     *  *specializations*: Types of disputes best suited for

     *  *performance metrics*: Historical data on timeliness and quality

  12.3.  Selection Guidelines

     Services SHOULD provide guidelines for neutral selection.  ADP does
     not prescribe a specific selection algorithm but RECOMMENDS
     considering:

     *  Relevant qualifications and specializations

     *  Availability and response time requirements

     *  Historical performance metrics

     *  Bias audit results and fairness scores

     *  Party preferences (where permitted by dispute rules)

     *  Cost considerations

     For panels, services SHOULD ensure diversity in neutral types (e.g.,
     mixing AI and human neutrals) and backgrounds.

  12.4.  Bias Auditing and Transparency

     To maintain trust in the dispute process, services implementing ADP
     SHOULD:

     1.  Conduct regular bias audits of both AI and human neutrals

     2.  Publish audit methodologies and results

     3.  Monitor for disparate impact across different types of parties




  Kotecha                   Expires 17 April 2026                [Page 22]


  Internet-Draft                     ADP                      October 2025


     4.  Implement corrective measures when bias is detected

     5.  Allow parties to challenge neutral assignments based on bias
         concerns

     Bias metrics MAY include analysis across dimensions such as
     organization size, claim amount, industry sector, jurisdiction, and
     party characteristics.

  13.  Security Considerations

     *  *Replay attacks*: All messages include unique messageId and
        timestamp.  Services MUST reject messages with duplicate IDs or
        expired timestamps.

     *  *Man-in-the-middle*: TLS 1.3 with certificate pinning RECOMMENDED
        for high-value disputes.

     *  *Evidence tampering*: All evidence MUST be hashed and signed.
        Tampering is detectable via hash mismatch.  Chain of custody
        provides additional tamper detection.

     *  *Denial of service*: Services SHOULD implement rate limiting and
        require filing fees to prevent spam submissions.

     *  *Privacy*: Parties MAY encrypt evidence payloads with panel's
        public key.  Services SHOULD support confidential dispute upon
        request.

     *  *Key compromise*: Services MUST support key rotation and
        revocation.  Historical awards remain valid if signed before
        revocation.  Chain of custody events preserve pre-compromise
        integrity.

     *  *Chain of custody integrity*: The Merkle chain linking ensures any
        tampering with custody events is detectable.  Services MUST
        preserve complete custody chains for the duration of potential
        appeals.

     *  *PDF signature verification*: Dual-format awards require both JWS
        signatures (JSON) and PAdES signatures (PDF).  Both MUST be
        verified independently.

  14.  IANA Considerations

     This document requests IANA to register:

     *  URI scheme: "agent://" for agent identification



  Kotecha                   Expires 17 April 2026                [Page 23]


  Internet-Draft                     ADP                      October 2025


     *  Media type: "application/aap+json" for ADP messages

     *  Well-known URI: /.well-known/adp for service discovery

     *  Well-known URI: /.well-known/adp/neutrals for neutral registry

     The JSON-LD context "https://w3id.org/adp/v1" will be registered with
     W3C for semantic interoperability.

  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/info/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/info/rfc8174>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.

     [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/info/rfc8446>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
                2001, <https://www.rfc-editor.org/info/rfc3161>.

  16.  Informative References




  Kotecha                   Expires 17 April 2026                [Page 24]


  Internet-Draft                     ADP                      October 2025


     [UNCITRAL-CONCILIATION]
                United Nations Commission on International Trade Law,
                "UNCITRAL Model Law on International Commercial
                Conciliation", 2002,
                <https://uncitral.un.org/en/texts/arbitration/modellaw/
                commercial_conciliation>.

     [SINGAPORE-CONVENTION]
                United Nations, "United Nations Convention on
                International Settlement Agreements Resulting from
                Mediation (Singapore Convention on Mediation)", 2018,
                <https://uncitral.un.org/en/texts/mediation/conventions/
                international_settlement_agreements>.

     [ADRA]     United States Congress, "Administrative Dispute Resolution
                Act of 1995", 1995, <https://www.congress.gov/bill/104th-
                congress/senate-bill/1224>.

  Appendix A.  JSON Schema Definitions

     Full JSON schemas for all ADP message types are published at:

     https://w3id.org/adp/v1/schema/

     Reference implementation schemas are available at:

     https://consulatehq.com/schema/adp/v1/

     GitHub repository with schemas, examples, and tooling:

     https://github.com/consulatehq/agentic-dispute-protocol

  Appendix B.  Example Message Exchanges

     Complete examples of filing, response, evidence, custody events, and
     award message exchanges are available in the ADP repository:

     https://github.com/consulatehq/agentic-dispute-protocol

     These examples demonstrate common scenarios including:

     *  Simple SLA breach dispute with complete custody chain

     *  Multi-party dispute with counterclaim

     *  Confidential dispute with encrypted evidence

     *  Cross-border dispute with multiple currencies



  Kotecha                   Expires 17 April 2026                [Page 25]


  Internet-Draft                     ADP                      October 2025


     *  Dual-format award generation and verification

  Appendix C.  Implementation Notes

     Consulate (https://consulatehq.com) provides the reference
     implementation of ADP with the following features:

     *  Full ADP v1.0 compliance

     *  REST and WebSocket APIs

     *  JavaScript/TypeScript SDK

     *  Real-time case status updates

     *  Complete chain of custody tracking

     *  Automated dual-format award generation (JSON + PDF)

     *  Arbitrator discovery and selection tools

     *  Integration with major AI agent platforms

     Implementers are encouraged to test interoperability with the
     Consulate reference implementation during development.

  Appendix D.  Acknowledgments

     This protocol builds upon established alternative dispute resolution
     frameworks including the UNCITRAL Model Law on International
     Commercial Conciliation, the Singapore Convention on Mediation, and
     the U.S.  Administrative Dispute Resolution Act, adapting them for
     autonomous agent interactions and digital dispute resolution.

  Author's Address

     Vivek Kotecha
     Consulate, Inc.
     United States of America
     Email: vivek@consulatehq.com
     URI:   https://consulatehq.com










  Kotecha                   Expires 17 April 2026                [Page 26]


name: draft-cui-ai-agent-discovery-invocation
rev: 01
title: AI Agent Discovery and Invocation Protocol
time: 2026-02-12T08:19:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T08:19:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604221+00:00
source: ietf
abstract:
  This document proposes a standardized protocol for discovery and
     invocation of AI agents.  It defines a common metadata format for
     describing AI agents (including capabilities, I/O specifications,
     supported languages, tags, authentication methods, etc.), a
     capability-based discovery mechanism, and a unified RESTful
     invocation interface.

     This revision additionally specifies an optional extension that
     enables intent-based agent selection prior to discovery and
     invocation, without changing existing discovery or invocation
     semantics.

     The goal is to enable cross-platform interoperability among AI agents
     by providing a discover-and-match mechanism and a unified invocation
     entry point.  Security considerations, including authentication and
     trust measures, are also discussed.  This specification aims to
     facilitate the formation of multi-agent systems by making it easy to
     find the right agent for a task and invoke it in a consistent manner
     across different vendors and platforms.

full_text:
  Network Working Group                                             Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                                   Y. Chao
  Expires: 16 August 2026                                            C. Du
                                                   Zhongguancun Laboratory
                                                          12 February 2026


                 AI Agent Discovery and Invocation Protocol
                 draft-cui-ai-agent-discovery-invocation-01

  Abstract

     This document proposes a standardized protocol for discovery and
     invocation of AI agents.  It defines a common metadata format for
     describing AI agents (including capabilities, I/O specifications,
     supported languages, tags, authentication methods, etc.), a
     capability-based discovery mechanism, and a unified RESTful
     invocation interface.

     This revision additionally specifies an optional extension that
     enables intent-based agent selection prior to discovery and
     invocation, without changing existing discovery or invocation
     semantics.

     The goal is to enable cross-platform interoperability among AI agents
     by providing a discover-and-match mechanism and a unified invocation
     entry point.  Security considerations, including authentication and
     trust measures, are also discussed.  This specification aims to
     facilitate the formation of multi-agent systems by making it easy to
     find the right agent for a task and invoke it in a consistent manner
     across different vendors and platforms.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://example.com/LATEST.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-cui-ai-agent-
     discovery-invocation/.

     Discussion of this document takes place on the WG Working Group
     mailing list (mailto:WG@example.com), which is archived at
     https://example.com/WG.

     Source for this draft and an issue tracker can be found at
     https://github.com/USER/REPO.



  Cui, et al.              Expires 16 August 2026                 [Page 1]


  Internet-Draft                    AIDIP                    February 2026


  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 16 August 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 (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.  Agent Metadata Specification  . . . . . . . . . . . . . . . .   5
       3.1.  Core Fields . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Operations and I/O Schema . . . . . . . . . . . . . . . .   7
       3.3.  Example Agent Metadata  . . . . . . . . . . . . . . . . .   8
     4.  Agent Discovery Mechanism . . . . . . . . . . . . . . . . . .   8
       4.1.  Registry Overview . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Agent Registration  . . . . . . . . . . . . . . . . . . .   9
       4.3.  Querying Agents . . . . . . . . . . . . . . . . . . . . .   9
         4.3.1.  Attribute-Based Query (Filter)  . . . . . . . . . . .  10
         4.3.2.  Semantic Query (Natural Language Search)  . . . . . .  10
         4.3.3.  Retrieve Single Agent . . . . . . . . . . . . . . . .  11
     5.  Agent Invocation  . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.  Invocation Request  . . . . . . . . . . . . . . . . . . .  11



  Cui, et al.              Expires 16 August 2026                 [Page 2]


  Internet-Draft                    AIDIP                    February 2026


       5.2.  Invocation Response . . . . . . . . . . . . . . . . . . .  12
       5.3.  Additional Considerations for Invocation  . . . . . . . .  14
     6.  Agent Semantic Resolution . . . . . . . . . . . . . . . . . .  15
       6.1.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.  Semantic Routing Platform . . . . . . . . . . . . . . . . . .  15
     8.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  16
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     10. Example Interaction Flow  . . . . . . . . . . . . . . . . . .  16
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     12. Normative References  . . . . . . . . . . . . . . . . . . . .  17
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     As artificial intelligence technologies advance rapidly, AI
     agents—autonomous software components capable of perceiving their
     environment, reasoning, and taking actions to achieve goals—have
     emerged as a powerful paradigm for task execution.  Today, many
     organizations develop specialized AI agents for various purposes:
     from text translation and summarization, to code generation, to data
     analysis and beyond.  These agents are often offered as services,
     accessible over the network and may be integrated into larger
     systems.  However, despite the proliferation of AI agents, there is
     currently no standard protocol for discovering available agents and
     invoking their capabilities in a uniform way.

     Existing agent frameworks and platforms facilitate building agents
     but typically operate in isolated ecosystems, making cross-platform
     or cross-organization agent interoperability difficult.  Each
     platform tends to define its own APIs for agent description and
     invocation, which means a client wishing to use agents from multiple
     sources must adapt to disparate interfaces.  This lack of
     standardization creates friction, increases integration costs, and
     hampers the development of multi-agent collaborative systems.

     This document addresses these issues by proposing a standardized AI
     Agent Discovery and Invocation Protocol.  The protocol provides:

     1.  *Agent Metadata Specification:* A structured JSON Schema for
         describing an agent's identity, capabilities, inputs, outputs,
         authentication requirements, and other attributes.  This enables
         agents to publish their specifications in a machine-readable
         form.







  Cui, et al.              Expires 16 August 2026                 [Page 3]


  Internet-Draft                    AIDIP                    February 2026


     2.  *Discovery Mechanism:* A registry-based approach where agents
         register themselves and clients can search for agents by
         capability, tags, or semantic queries.  The registry is language
         and platform agnostic, facilitating cross-platform discovery.

     3.  *Invocation Interface:* A RESTful API that enables a client
         (which could be a human user application, another agent, or an
         orchestration system) to invoke an agent's capabilities through a
         standard endpoint and JSON payloads.

     4.  *Security Considerations:* Guidelines for authentication,
         authorization, encrypted transport (TLS), and trust
         establishment, ensuring that discovery and invocation happen
         securely.

     5.  *Interoperability with Existing Standards:* This specification
         references existing standards such as JSON Schema, OAuth 2.0
         [RFC6749], and OpenAPI concepts, and leverages established web
         technologies for broad compatibility.

     The primary audience for this specification includes developers of AI
     agent platforms, providers of AI agent services, and system
     architects building AI-enabled applications or multi-agent systems.
     By adopting this protocol, an AI agent developer can make their agent
     accessible to a wide ecosystem, and a client application can
     integrate AI agents from multiple vendors without custom integration
     for each.

     This revision extends the base protocol with an optional Agent
     Semantic Resolution layer that enables intent-based agent selection.
     This extension allows a Host Agent or coordinator to describe a task
     intent and receive candidate agents without predetermining which
     agent to invoke.  ASR does not replace discovery; it adds a semantic
     matching phase that can precede or augment the capability-based
     search defined in earlier sections.

  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.

     *  *AI Agent:* An autonomous software component that can perform
        tasks using artificial intelligence capabilities.  Agents may wrap
        language models, specialized ML models, or reasoning engines,
        exposing their abilities via defined interfaces.



  Cui, et al.              Expires 16 August 2026                 [Page 4]


  Internet-Draft                    AIDIP                    February 2026


     *  *Agent Metadata:* A structured description of an agent, including
        name, description, capabilities, input/output schemas,
        authentication requirements, and endpoint information.

     *  *Agent Registry (Discovery Service):* A service that maintains a
        directory of registered agents and supports queries for
        discovering agents by attributes or semantic search.

     *  *Gateway:* (Optional) An intermediary service that routes client
        requests to appropriate agents.  In some deployments, the registry
        or another service acts as a gateway to simplify client-to-agent
        connections.

     *  *Invocation Endpoint:* The URL provided by an agent (or gateway)
        where clients send requests to invoke the agent's capabilities.

     *  *Capability:* A high-level function an agent can perform,
        identified by a string (e.g., "translation", "summarization",
        "image_classification").

     *  *Operation:* A specific action supported by an agent.  Some agents
        may have multiple operations; for example, an agent offering both
        translation and language detection could list these as separate
        operations, each with its own input/output schema.

  3.  Agent Metadata Specification

     The Agent Metadata Specification defines a standard JSON document
     that describes an agent.  All agents that wish to be discoverable and
     invocable through this protocol MUST provide a metadata document
     conforming to the schema below.  This metadata is used for agent
     registration and returned to clients during discovery.

  3.1.  Core Fields

     The following are the core fields of an agent metadata document:

     *  *id (string):* A globally unique identifier for the agent.  This
        could be a UUID or a similarly unique value, assigned by the
        registry upon registration or by the agent provider in advance.
        This ID is used to refer to the agent in all subsequent operations
        (e.g., retrieval, invocation routing).

     *  *name (string):* A human-readable name for the agent (e.g.,
        "Chinese-English Translator Agent").  Names need not be unique but
        should be descriptive.





  Cui, et al.              Expires 16 August 2026                 [Page 5]


  Internet-Draft                    AIDIP                    February 2026


     *  *description (string):* A detailed description of the agent, its
        purpose, and capabilities in natural language.  This helps both
        human users and semantic search algorithms understand what the
        agent does.

     *  *version (string):* The version of the agent or its metadata
        (e.g., "1.0.0").  This allows tracking of agent updates over time.

     *  *publisher (string):* The name or identifier of the entity
        publishing the agent (e.g., an organization name or developer
        name).

     *  *capabilities (array of strings):* A list of capabilities the
        agent supports.  Capabilities are high-level descriptors (like
        tags or categories) that clients can filter by.  Examples:
        ["translation", "summarization", "text_generation"].

     *  *tags (array of strings):* Additional tags for search and
        categorization (e.g., ["nlp", "chinese", "transformer_model",
        "cloud"]).  Tags differ from capabilities in that they can include
        broader or orthogonal categories (like domain, language support,
        deployment model, etc.).

     *  *endpoint (string):* The URL of the agent's invocation endpoint.
        If the agent is behind a gateway, this could be either the direct
        endpoint or, if direct access is not allowed, a gateway path
        (e.g., the gateway might provide a unified endpoint like
        /agents/{id}/invoke and internally route to the actual agent
        endpoint).

     *  *supported_languages (array of strings, optional):* A list of
        languages the agent supports (e.g., ["en", "zh", "fr"]).  For
        agents dealing with natural language tasks, this field indicates
        which languages are handled.  If omitted, the agent is either
        language-agnostic or should not be filtered by language.

     *  *authentication (object, optional):* Describes the authentication
        mechanism required to invoke the agent.  This object may include:

        -  *type (string):* e.g., "api_key", "oauth2_bearer", "mtls"
           (mutual TLS), "none".

        -  *instructions (string):* Human-readable note or URL for
           obtaining credentials.

        -  *scopes (array of strings):* If OAuth 2.0 is used, the OAuth
           scopes required.




  Cui, et al.              Expires 16 August 2026                 [Page 6]


  Internet-Draft                    AIDIP                    February 2026


        If no authentication is required, this field can be omitted or set
        with type: "none".

     *  *status (string, optional):* Operational status of the agent
        (e.g., "active", "inactive", "deprecated").  The registry may use
        this to filter out agents that are not currently available.

     *  *additional fields:* Additional fields may include metadata about
        rate limits (e.g., max calls per minute), pricing info (if the
        agent charges per use), or links to documentation.  These are not
        standardized here but can be included in agent metadata as needed.

  3.2.  Operations and I/O Schema

     Each agent MUST describe its input and output formats.  This is done
     using the *operations* field:

     *  *operations (array of objects):* A list of operations the agent
        supports.  Each operation object has:

        -  *name (string):* The operation name/identifier (e.g.,
           "translateText", "summarize").

        -  *description (string):* A description of what the operation
           does.

        -  *inputs (object):* A JSON Schema describing the expected input.
           This allows clients to understand what data to send.  The JSON
           Schema can specify required fields, types, enums, etc.

        -  *outputs (object):* A JSON Schema describing the output format.

        -  *examples (array of objects, optional):* Example input/output
           pairs.  Each example is an object {"input": {...}, "output":
           {...}} showing a sample invocation.

     If an agent has a single operation, this array will have one element.
     If it can do multiple distinct tasks, each is listed here.  Some
     agents may not have structured operations (e.g., a general-purpose
     language model that just produces text).  In that case, the
     operations field might include a generic operation like {"name":
     "generate", ...}.









  Cui, et al.              Expires 16 August 2026                 [Page 7]


  Internet-Draft                    AIDIP                    February 2026


     If an agent has a single operation, this array will have one element.
     If it can do multiple distinct tasks, each is listed here.  For
     simple agents with one primary function, an alternative is to use
     top-level inputs and outputs fields directly (instead of an
     operations array).  In that case, the whole agent effectively has one
     implied operation.  This spec allows both styles, but using
     operations is recommended for future extensibility.

  3.3.  Example Agent Metadata

     Below is an example metadata JSON for a translation agent:

     json { "id": "agent-12345", "name": "Chinese-English Translator",
     "description": "Translates text between Chinese and English with high
     accuracy using a fine-tuned model.", "version": "1.2.0", "publisher":
     "ExampleAI Inc.", "capabilities": ["translation"], "tags": ["nlp",
     "chinese", "english", "cloud"], "endpoint":
     "https://api.example.com/agents/translate", "supported_languages":
     ["en", "zh"], "authentication": { "type": "api_key", "instructions":
     "Include 'X-API-Key' header with your API key." }, "status":
     "active", "operations": [ { "name": "translateText", "description":
     "Translates text from source language to target language.", "inputs":
     { "type": "object", "properties": { "text": {"type": "string"},
     "source_language": {"type": "string", "enum": ["en", "zh"]},
     "target_language": {"type": "string", "enum": ["en", "zh"]} },
     "required": ["text", "source_language", "target_language"] },
     "outputs": { "type": "object", "properties": { "translated_text":
     {"type": "string"} } }, "examples": [ { "input": {"text": "你好世界",
     "source_language": "zh", "target_language": "en"}, "output":
     {"translated_text": "Hello World"} } ] } ] }

     This metadata tells us the agent is an active translation agent for
     Chinese and English, requires an API key for authentication, and has
     one operation translateText with a clear input/output schema.

  4.  Agent Discovery Mechanism

     The discovery mechanism allows clients to find agents that meet
     certain criteria.  Discovery is provided by an Agent Registry (or
     Discovery Service) that aggregates metadata from multiple agents.

  4.1.  Registry Overview

     The Agent Registry is a network-accessible service that:

     1.  Allows agents (or their administrators) to register metadata
         about the agent.




  Cui, et al.              Expires 16 August 2026                 [Page 8]


  Internet-Draft                    AIDIP                    February 2026


     2.  Stores and indexes these metadata entries for efficient search.

     3.  Provides endpoints for clients to query and retrieve agent
         information.

     A registry may be operated by an organization for its internal
     agents, or by a third party acting as a directory of agents across
     multiple providers.  Multiple registries can coexist;
     interoperability between registries is facilitated by consistent
     metadata formats, though formal registry federation is out of scope
     for this draft.

  4.2.  Agent Registration

     An agent (or its administrator) registers with the registry by
     sending its metadata to a registration endpoint:

     *  *Endpoint:* POST /agents

     *  *Request Body:* The agent metadata JSON document.

     *  *Response:* On success, the registry returns *201 Created* (if a
        new agent was added) or *200 OK* (if an existing agent was
        updated), with the stored agent metadata (including the assigned
        id if the agent did not provide one).  If validation fails (e.g.,
        missing required fields), the registry returns a *400 Bad Request*
        with error details.

     The registry MUST validate the metadata against the schema.
     Registration may require authentication (for example, the registry
     only allows verified publishers to register agents).

     Updates to an agent's metadata (e.g., a new version, changed
     endpoint, etc.) can be done via a PUT request to the agent's entry:

     *  *Endpoint:* PUT /agents/{id}

     *  *Request Body:* Updated metadata.

     *  *Response:* *200 OK* on success; *404 Not Found* if no agent with
        that ID exists; *403 Forbidden* if the requester is not authorized
        to update that agent.

  4.3.  Querying Agents

     Clients query the registry using the search endpoint.  The protocol
     supports two types of queries:




  Cui, et al.              Expires 16 August 2026                 [Page 9]


  Internet-Draft                    AIDIP                    February 2026


  4.3.1.  Attribute-Based Query (Filter)

     Clients can specify criteria to filter agents by capabilities, tags,
     supported languages, etc.

     *  *Endpoint:* GET /agents?capabilities=X&tags=Y&language=Z

     *  or a structured query via *POST /agents/search* with a JSON body.

     For simplicity, *POST /agents/search* is recommended for more complex
     queries.  The body might look like:

     json { "filters": { "capabilities": ["translation"],
     "supported_languages": ["en", "zh"], "tags": ["nlp"] }, "top": 10 }

     This returns up to 10 agents that match all the specified filters.
     Filters are combined with AND logic (the agent must satisfy all
     conditions).  Capabilities and tags are matched by set intersection
     (the agent must have at least the ones listed).

     The response is a JSON array of agent summary objects:

     json [ { "id": "agent-12345", "name": "Chinese-English Translator",
     "description": "...", "endpoint": "https://api.example.com/agents/
     translate", "capabilities": ["translation"] }, ... ]

     Summary objects include essential fields to help the client decide
     which agent to use, without returning the full detailed metadata.  A
     client can retrieve full metadata via the single-agent endpoint.

  4.3.2.  Semantic Query (Natural Language Search)

     In addition to attribute-based search, the registry MAY support
     semantic search where the client describes a need in natural
     language, and the registry uses AI techniques (embeddings, LLM-based
     matching) to find relevant agents.  This is an optional feature for
     registries.

     *  *Endpoint:* POST /agents/search

     *  *Request Body:* json { "query": "I need an agent that can
        summarize long legal documents in Chinese.", "top": 5 }

     The registry returns a ranked list of agents whose descriptions match
     the query semantically, possibly including a match score.  For
     example:





  Cui, et al.              Expires 16 August 2026                [Page 10]


  Internet-Draft                    AIDIP                    February 2026


     json [ { "id": "agent-67890", "name": "Legal Document Summarizer",
     "description": "...", "score": 0.93 }, ... ]

     Semantic search enables flexible discovery beyond exact filter
     matching, aligning with how users or orchestrating agents might
     reason about tasks.  Registries not supporting semantic search simply
     ignore the query text and rely on provided filters.

  4.3.3.  Retrieve Single Agent

     *  *Endpoint:* GET /agents/{id}

     *  *Response:* Full metadata JSON for the specified agent, or *404*
        if not found.

  5.  Agent Invocation

     Once a client discovers a suitable agent, it invokes the agent by
     sending a request to the agent's endpoint.  This section defines the
     interface for invocation.

  5.1.  Invocation Request

     To invoke an agent, the client sends an HTTP POST request to the
     agent's invocation endpoint with a JSON body containing the input
     data for the agent's task.

     *  *Method:* POST

     *  *URL:* The endpoint URL from the agent's metadata (e.g.,
        https://api.example.com/agents/translate).  If a gateway is used,
        the URL might be a gateway-provided path.

     *  *Headers:*

        -  Content-Type: application/json

        -  Authentication header as required (e.g., Authorization: Bearer
           <token> or X-API-Key: <key>).

     *  *Body:* A JSON object containing input data as per the agent's
        input schema.

     For example, invoking the translation agent:

     json { "text": "Hello, how are you?", "source_language": "en",
     "target_language": "fr" }




  Cui, et al.              Expires 16 August 2026                [Page 11]


  Internet-Draft                    AIDIP                    February 2026


     This corresponds to the agent's expected input fields.  If the agent
     had multiple operations and a unified endpoint, there might be an
     additional field to specify which operation or capability to use.
     For instance, the JSON could include something like "operation":
     "translateText" if needed.  Alternatively, different operations could
     be exposed at different URLs (e.g., /agents/xyz/translate vs
     /agents/xyz/summarize), in which case the operation is selected by
     the URL and no extra field is required.

     The protocol does not fix a specific parameter naming; it defers to
     the agent's published schema.  The only requirement is that the
     client's JSON must conform to what the agent expects.  For
     interoperability, using clear field names and standard data types
     (strings, numbers, booleans, or structured objects) is encouraged.
     Binary data (like images for an image-processing agent) should be
     handled carefully: typically, binary inputs can be provided either as
     URLs (pointing to where the data is stored), or as base64-encoded
     strings within the JSON, or by using a multipart request.  This
     specification suggests that if agents need to receive large binary
     payloads, they either use URL references or out-of-scope mechanisms
     (like a separate upload and then an ID in the JSON).  The core
     invocation remains JSON-based for simplicity and consistency.

     *Headers:* If authentication is required (see Security section), the
     client must also include the appropriate headers (e.g.,
     Authorization: Bearer <token> or an API key header) as dictated by
     the agent's metadata.  The invocation request may also include
     optional headers for correlation or debugging, such as a request ID,
     but those are not standardized here.

  5.2.  Invocation Response

     The agent (or gateway) will process the request and return a
     response.  The status code and JSON body of the response follow these
     guidelines:

     *  *Success (2xx status):* If the agent successfully performed its
        task and produced a result, the status SHOULD be *200 OK* (or *201
        Created* if a new resource was created as a result, though usually
        for these actions 200 is fine).  The response body will contain
        the output data in JSON.  Ideally, the output JSON conforms to the
        agent's advertised output schema.

        For example, for the translation request above, a success response
        might be:

        json { "translated_text": "Bonjour, comment êtes-vous?" }




  Cui, et al.              Expires 16 August 2026                [Page 12]


  Internet-Draft                    AIDIP                    February 2026


        Here the JSON structure matches what was described in the agent
        metadata's outputs.  If the output is complex (e.g., multiple
        fields or nested objects), those should appear accordingly.  The
        response can include other informational fields if necessary (for
        example, some agents might return usage metrics, like tokens used
        or time taken, or a trace id for debugging, but these are optional
        and out of scope of the core spec).

     *  *Client Error (4xx status):* If the request was malformed or
        invalid, the agent returns a *4xx* status code.  The most common
        would be *400 Bad Request* for a JSON that doesn't conform to the
        expected schema or missing required fields.  For example, if the
        client omitted a required field target_language, the agent might
        respond with 400.  The response body SHOULD include an error
        object explaining what went wrong.  We define a simple standard
        for error objects:

        json { "error": { "code": "InvalidInput", "message": "Required
        field 'target_language' is missing." } }

        Here, "code" is a short string identifier for the error type
        (e.g., InvalidInput, Unauthorized, NotFound), and "message" is a
        human-readable description.  The agent can include additional
        details if available (e.g., a field name that is wrong, etc.).  If
        the error is due to unauthorized access, *401 Unauthorized* or
        *403 Forbidden* should be used (with an appropriate error message
        indicating credentials are missing or insufficient).  If the agent
        ID is not found (perhaps the client used an outdated reference),
        *404 Not Found* is appropriate.

     *  *Server/Agent Error (5xx status):* If something goes wrong on the
        agent's side during processing (an exception, a timeout while
        executing the task, etc.), the agent (or gateway) returns a *5xx*
        status (most likely *500 Internal Server Error* or *502/504* if
        there are upstream issues).  The response should again include an
        error object.  For example:

        json { "error": { "code": "AgentError", "message": "The agent
        encountered an unexpected error while processing the request." } }

        The agent might log the detailed error internally, but only convey
        a generic message to the client for security.  A *503 Service
        Unavailable* might be returned if the agent is temporarily
        overloaded or offline, indicating the client could retry later.

     *  *Status Codes Summary:* In short, this protocol expects the use of
        standard status codes to reflect outcome (200 for success, 4xx for
        client-side issues, 5xx for server-side issues).  Agents should



  Cui, et al.              Expires 16 August 2026                [Page 13]


  Internet-Draft                    AIDIP                    February 2026


        avoid using 2xx if the operation did not semantically succeed
        (even if technically a response was generated).  For example, if
        an agent is a composite that calls other services and one of those
        calls fails, it should propagate an error rather than returning
        200 with an error in the data.

  5.3.  Additional Considerations for Invocation

     *  *Streaming Responses:* Some agents (especially those wrapping
        large language models) may produce results that are streamed (for
        example, token-by-token outputs).  While this base protocol
        assumes a request-response pattern with the full result delivered
        at once, it can be extended to support streaming by using chunked
        responses or WebSockets.  For instance, an agent might accept a
        parameter like stream: true and then send partial outputs as they
        become available.  This is an advanced use case and not elaborated
        in this draft, but implementers should consider compatibility with
        streaming if real-time responsiveness is needed.

     *  *Batch Requests:* If a client wants to send multiple independent
        requests to an agent in one go (for efficiency), the protocol can
        support that by allowing an array of input objects in the POST
        body instead of a single object.  The response would then be an
        array of output results.  This is optional and depends on agent
        support.

     *  *Idempotency and Retries:* Most agent invocations are not strictly
        idempotent (since an agent might perform an action or have side
        effects), but many are pure functions (e.g., translate text).
        Clients and gateways should design with retry logic carefully — if
        a network failure happens, a retry might re-run an operation.
        It's best to ensure that agents' operations are either idempotent
        or have safeguards (for example, an operation that sends an email
        might have an idempotency key).

     *  *Operation Metadata:* In cases where the agent defines multiple
        operations in its metadata, the invocation interface might allow a
        generic endpoint that accepts an operation name.  Alternatively,
        each operation could be a sub-resource.  This draft leaves the
        exact mechanism flexible: an implementation could choose one of
        these approaches.  The key is that the invocation uses POST and a
        JSON body following the agent's schema.









  Cui, et al.              Expires 16 August 2026                [Page 14]


  Internet-Draft                    AIDIP                    February 2026


  6.  Agent Semantic Resolution

     Agent Semantic Resolution (ASR) is an optional extension to the
     discovery mechanism defined in this document.  ASR enables a client
     to resolve a task intent into one or more candidate agents prior to
     invoking any specific agent.

     ASR operates on the following conceptual model:

     (Intent, Context, Policy) → (Agent Endpoint(s), Invocation Metadata)

     The intent represents the task to be performed, while context and
     policy may include domain constraints, trust requirements, or
     performance considerations.

  6.1.  Non-Goals

     ASR explicitly does not provide:

     *  Name-to-address resolution

     *  Global or persistent agent identifiers

     *  Replacement for DNS, ANS, or URI-based registries

     ASR answers the question "Which agent(s) should handle this task
     now?" rather than "Where is agent X located?".


  7.  Semantic Routing Platform

     A Semantic Routing Platform (SRP) is a control-plane service that
     implements ASR.  An SRP assists a Host Agent in selecting appropriate
     agents before standard discovery and invocation procedures are used.

     An SRP MAY perform semantic matching, ranking, and policy-based
     filtering of candidate agents.  The SRP does not participate in task
     execution and does not alter the invocation semantics defined in this
     document.

     Interaction with an SRP is OPTIONAL.  Clients that do not support ASR
     continue to operate using the discovery and invocation mechanisms
     defined in earlier sections.








  Cui, et al.              Expires 16 August 2026                [Page 15]


  Internet-Draft                    AIDIP                    February 2026


  8.  Backward Compatibility

     All discovery and invocation mechanisms defined in previous revisions
     of this document remain valid and unchanged.

     Agent Semantic Resolution is an optional extension.  Implementations
     MAY support ASR incrementally, and registries MAY provide semantic
     resolution capabilities without affecting existing clients.

  9.  Security Considerations

     Security is a critical aspect of this protocol.  All discovery and
     invocation traffic MUST be protected with TLS [RFC8446], and
     authentication mechanisms such as OAuth 2.0 [RFC6749] bearer tokens,
     API keys, or mutual TLS are required except for public discovery
     endpoints.  Registries MUST enforce per-client entitlements, ensuring
     that both search results and invocation access respect permissions
     and scopes.  Gateways forwarding requests should authenticate
     themselves to agents, and agents should maintain stable identifiers
     and use signed responses when integrity is essential.  All
     communication MUST be encrypted, and agents are encouraged to
     disclose data-retention or logging practices, while sensitive data is
     best handled by on-premises or certified agents.  To mitigate abuse,
     registries and agents MUST implement rate limiting and quotas,
     particularly in semantic search scenarios.  Trust mechanisms such as
     certification, test harnesses, or reputation systems may be used to
     validate agent claims, and metadata fields like "certification" or
     "quality_score" can inform client trust decisions.  Systems SHOULD
     also provide audit and logging with privacy-aware retention, while
     clients must treat agent outputs as untrusted until verified, using
     sandboxing and validation before executing code or commands.

     When Agent Semantic Resolution is used, security considerations
     extend to the pre-invocation phase.  Resolution services SHOULD
     validate agent capability claims, apply policy constraints, and
     exclude agents that do not meet trust or reputation requirements.
     Agents deemed unsafe SHOULD NOT be returned as resolution candidates.

  10.  Example Interaction Flow

     1.  *Search:* Client POST /agents/search with {"query":"summarize an
         English document","filters":{"capabilities":["summarization"],"su
         pported_language":"en"},"top":3}.

     2.  *Select:* Registry returns candidate agents with id, name,
         description, and score.  Client retrieves full metadata via GET
         /agents/{id} if needed.




  Cui, et al.              Expires 16 August 2026                [Page 16]


  Internet-Draft                    AIDIP                    February 2026


     3.  *Invoke:* Client POST to the agent's endpoint (or gateway path)
         with inputs conforming to agent schema and required auth header.

     4.  *Handle Response:* Client processes success or error response;
         may log usage and optionally rate/feedback the agent.

  11.  IANA Considerations

     This document has no IANA actions.

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

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

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

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

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

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses







  Cui, et al.              Expires 16 August 2026                [Page 17]


  Internet-Draft                    AIDIP                    February 2026


     Yong Cui
     Tsinghua University
     Beijing, 100084
     China
     Email: cuiyong@tsinghua.edu.cn
     URI:   http://www.cuiyong.net/


     Yihan Chao
     Zhongguancun Laboratory
     Beijing, 100094
     China
     Email: chaoyh@zgclab.edu.cn


     Chenguang Du
     Zhongguancun Laboratory
     Beijing, 100094
     China
     Email: ducg@zgclab.edu.cn































  Cui, et al.              Expires 16 August 2026                [Page 18]


name: draft-liu-access-collaboration-agent
rev: 00
title: Ubiquitous Access Collaboration Requirements for AI Agent Protocols
time: 2026-04-19T07:09:15Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-20T06:05:08Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604226+00:00
source: ietf
abstract:
  This document focuses on the ubiquitous access collaboration
     scenarios, explores the requirements for AI agent communication
     protocols.

full_text:
  Network Working Group                                        W. Liu, Ed.
  Internet-Draft                                             Y. Zhang, Ed.
  Intended status: Standards Track                            China Unicom
  Expires: 20 April 2026                                   17 October 2025


    Ubiquitous Access Collaboration Requirements for AI Agent Protocols
                  draft-liu-access-collaboration-agent-00

  Abstract

     This document focuses on the ubiquitous access collaboration
     scenarios, explores the requirements for AI agent communication
     protocols.

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






  Liu & Zhang               Expires 20 April 2026                 [Page 1]


  Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Remote Care . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.  Remote Work . . . . . . . . . . . . . . . . . . . . . . .   3
       3.3.  Multi Access Collaboration  . . . . . . . . . . . . . . .   4
     4.  Requirement . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Identity Authentication and Request Verification  . . . .   4
       4.2.  Service Discovery and Automatic Negotiation . . . . . . .   4
       4.3.  Unified Communication Protocol  . . . . . . . . . . . . .   5
       4.4.  Connection Stability and Seamless Handover  . . . . . . .   5
       4.5.  Local Disaster Recovery and Offline Processing
             Capabilities  . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     With the rapid development of AI terminal technology and the
     popularization of multi scenario networking requirements, scenarios
     such as home security remote field visits, remote office
     collaboration, and mixed access of fixed and mobile networks have
     gradually become the core needs of users.  In these scenarios,
     collaborative interaction between heterogeneous AI agents is the key
     to realizing service value - for example, in home security scenarios,
     mobile AI agents need to interact with camera AI agents to transmit
     real-time images, while linking NAS storage AI agents to save
     abnormal recordings; In the scenario of mixed access between fixed
     and mobile networks, the mobile terminal AI agent needs to rely on
     the fixed network gateway AI agent to achieve seamless network
     switching and dynamic bandwidth allocation.

     However, the effective collaboration of heterogeneous AI agents faces
     problems such as inconsistent data exchange formats, unstable cross
     network transmission, and insufficient security verification.  These
     issues directly affect the reliability of service execution: for
     example, video transmission delays may lead to delayed handling of
     safety risks for the elderly, and incompatible network configuration
     information may cause fixed mobile network switching failures.  To
     address these issues, there is an urgent need for a specialized AI
     communication protocol to provide core support.






  Liu & Zhang               Expires 20 April 2026                 [Page 2]


  Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


     This document focuses on the ubiquitous access collaboration
     scenarios, explores the requirements for AI agent communication
     protocols.

  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.  Abbreviations and definitions used in this
     document:

     *AI: Artificial Intelligence

  3.  Use Cases

  3.1.  Remote Care

     In the scenario of remote access for home security, remote care for
     the elderly, children, and pets is achieved through the collaboration
     between mobile terminal AI agents and home fixed network device AI
     agents (such as cameras, NAS storage, printers, pet sensors).  The AI
     agent communication protocol provides core support for the
     collaboration between the two.  The participating roles include users
     operating mobile AI agents, mobile AI agents responsible for sending
     and receiving requests, and home device AI agents executing
     instructions.  When the user checks the status of the elderly, if the
     phone adjusts the camera screen and there is an abnormality, it
     triggers the NAS to store the video; When remotely printing materials
     for children, the phone wakes up the printer; When pets move
     abnormally, sensors will push alarms, etc.  Users can obtain real-
     time status, normal data transmission, and timely handling of
     anomalies.  The protocol needs to ensure real-time data, request
     verification, and privacy security.

  3.2.  Remote Work

     In remote work scenarios, efficient remote work is achieved through
     collaboration between terminal AI agents (such as mobile phones and
     laptops) and office equipment AI agents (such as cloud desktops,
     printers, video conferencing terminals, file sharing servers).  The
     communication protocol of the AI agents provides core support for the
     collaboration between the two.  The participating roles include
     employees who operate terminal AI agents, terminal AI agents
     responsible for command sending and receiving, and office equipment
     AI agents that execute tasks.  When employees need to work, connect
     the terminal to the cloud desktop; When remotely printing files, the



  Liu & Zhang               Expires 20 April 2026                 [Page 3]


  Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


     terminal wakes up the printer; When holding a meeting, the terminal
     starts the video conferencing terminal and shares files, etc.
     Employees have access to office resources, stable data transmission,
     and smooth collaboration.  The protocol needs to ensure stable
     connection, permission control, and data encryption.

  3.3.  Multi Access Collaboration

     In the scenario of multi access collaboration, seamless device
     switching and dynamic allocation of network resources are achieved
     through the collaboration of mobile terminal AI agents (such as
     mobile phones and tablets) and fixed network gateway AI agents (such
     as home optical cats and enterprise routers).  The AI agent
     communication protocol provides core support for the collaboration
     between the two.  The participating roles include users who operate
     mobile network terminals, mobile network terminal agents responsible
     for dynamic access, and fixed network gateway agents responsible for
     resource scheduling.  When the user is at home, the mobile network
     terminal automatically connects to the fixed network gateway to
     obtain high bandwidth; When going out, the fixed network gateway
     pushes the network configuration to the mobile network terminal to
     ensure seamless networking; When multiple devices are accessing
     simultaneously, the fixed network gateway links with the mobile
     network terminal to allocate bandwidth resources, etc.  Users can
     achieve seamless network switching, stable device access, efficient
     resource scheduling, and protocols need to ensure continuous
     connection, permission control, and bandwidth adaptation.

  4.  Requirement

  4.1.  Identity Authentication and Request Verification

     Before executing interaction requests between agents, strict identity
     authentication must be performed.  The protocol shall define high-
     security authentication mechanisms - such as digital certificates and
     mutual authentication - to ensure that only legitimate and authorized
     agents can initiate or receive commands, thereby preventing
     unauthorized access and malicious control.

  4.2.  Service Discovery and Automatic Negotiation

     When an agent accesses a network (e.g., home or office network), it
     shall automatically discover other available agents and their
     provided services (e.g., printing, video conferencing, storage).  It
     shall also automatically negotiate capabilities and establish
     connections to enable "plug-and-play" functionality.





  Liu & Zhang               Expires 20 April 2026                 [Page 4]


  Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


  4.3.  Unified Communication Protocol

     A standardized set of message formats, command sets, and interaction
     workflows shall be defined for inter-agent communication.  This
     ensures that agents from different manufacturers and of different
     types, e.g., mobile devices, cameras, printers, routers, can
     identify, understand, and execute commands with one another.

  4.4.  Connection Stability and Seamless Handover

     In multi-access collaboration scenarios, when a user switches from a
     home network to mobile network, the protocol shall support session
     persistence and seamless handover for agents.  This guarantees the
     uninterrupted operation of ongoing services.

  4.5.  Local Disaster Recovery and Offline Processing Capabilities

     In the event of network outages or other anomalies, critical agents
     (e.g., home gateways, network-attached storage/NAS) shall possess
     local decision-making and data processing capabilities.  For example,
     after a network disconnection, home sensors shall continue to locally
     record abnormal events and synchronize the recorded data to the cloud
     and mobile terminals once the network is restored.

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     TBD

  7.  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/info/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/info/rfc8174>.

  Authors' Addresses







  Liu & Zhang               Expires 20 April 2026                 [Page 5]


  Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


     Wei Liu (editor)
     China Unicom
     Beijing
     China
     Email: liuw550@chinaunicom.cn


     Yaomin Zhang (editor)
     China Unicom
     Beijing
     China
     Email: zhangym2533@chinaunicom.cn







































  Liu & Zhang               Expires 20 April 2026                 [Page 6]


name: draft-abbey-scim-agent-extension
rev: 00
title: SCIM Agents and Agentic Applications Extension
time: 2026-04-19T07:09:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T15:37:00Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604230+00:00
source: ietf
abstract:
  The System for Cross-domain Identity Management (SCIM) specification
     [RFC7643] provides schemas that represent common identity information
     about users and groups, as well as a protocol for communicating that
     information between systems.

     The systems that tend to implement SCIM clients and servers are
     identity providers, and service providers.  These are the same
     systems that are now need to manage agents and agentic applications
     across domains.

     This document describes a SCIM 2.0 extension for agents and agentic
     applications, which includes extensions to the core User and Group
     objects, and new resource types and schemas for agentic constructs.

     This extension is intended to provide greater interoperability
     between Identity providers, agentic applications, agents and their
     clients while reducing the responsibilities assumed by the every
     growing list of new protocols for agents.

full_text:
  SCIM                                                            M. Abbey
  Internet-Draft                                               R. S. Cohen
  Intended status: Standards Track                                    Okta
  Expires: 19 April 2026                                   16 October 2025


               SCIM Agents and Agentic Applications Extension
                    draft-abbey-scim-agent-extension-00

  Abstract

     The System for Cross-domain Identity Management (SCIM) specification
     [RFC7643] provides schemas that represent common identity information
     about users and groups, as well as a protocol for communicating that
     information between systems.

     The systems that tend to implement SCIM clients and servers are
     identity providers, and service providers.  These are the same
     systems that are now need to manage agents and agentic applications
     across domains.

     This document describes a SCIM 2.0 extension for agents and agentic
     applications, which includes extensions to the core User and Group
     objects, and new resource types and schemas for agentic constructs.

     This extension is intended to provide greater interoperability
     between Identity providers, agentic applications, agents and their
     clients while reducing the responsibilities assumed by the every
     growing list of new protocols for agents.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://macyabbey.github.io/draft-abbey-scim-agent-extension/draft-
     abbey-scim-agent-extension.html.  Status information for this
     document may be found at https://datatracker.ietf.org/doc/draft-
     abbey-scim-agent-extension/.

     Source for this draft and an issue tracker can be found at
     https://github.com/macyabbey/draft-abbey-scim-agent-extension.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.




  Abbey & Cohen             Expires 19 April 2026                 [Page 1]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     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 19 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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Core Schema Extensions  . . . . . . . . . . . . . . . . . . .   4
       4.1.  ServiceProviderConfig . . . . . . . . . . . . . . . . . .   4
     5.  Additional ResourceTypes and Schemas  . . . . . . . . . . . .   5
       5.1.  Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
         5.1.1.  Agent Resource Type . . . . . . . . . . . . . . . . .   5
         5.1.2.  Agent filtering . . . . . . . . . . . . . . . . . . .   6
         5.1.3.  Agent Common Attributes . . . . . . . . . . . . . . .   6
         5.1.4.  Agent Core Schema . . . . . . . . . . . . . . . . . .   6
       5.2.  Agentic application . . . . . . . . . . . . . . . . . . .  11
         5.2.1.  Resource Type . . . . . . . . . . . . . . . . . . . .  11
         5.2.2.  Filtering . . . . . . . . . . . . . . . . . . . . . .  12
         5.2.3.  Common attributes . . . . . . . . . . . . . . . . . .  12
         5.2.4.  Schema  . . . . . . . . . . . . . . . . . . . . . . .  12
         5.2.5.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
     6.  Schema JSON Representations . . . . . . . . . . . . . . . . .  15
       6.1.  Agent Schema JSON . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Agentic Application Schema JSON . . . . . . . . . . . . .  25



  Abbey & Cohen             Expires 19 April 2026                 [Page 2]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       10.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  26
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

     The SCIM protocol was originally developed to address an *abundance*
     of complex standards for describing and exchanging user information.

     As stated in the introduction of RFC7643#Section-1.1
     (https://datatracker.ietf.org/doc/html/rfc7643#section-1.1)

        While there are existing standards for describing and exchanging
        user information, many of these standards can be difficult to
        implement and/or use...

        This increases both the cost and complexity associated with
        organizations adopting products and services from multiple cloud
        providers, as they must perform redundant integration
        development...SCIM seeks to simplify this problem through an
        easily implemented specification suite...

     With the rise of AI, agents, and agentic applications, we see another
     abundance of protocols emerging, with varying levels of industry
     adoption, as well as implementation complexity as many brilliant and
     enthusiastic early adopters rush to define new standards for identity
     interopability.

     This includes but is not limited to:

     *  ACP (https://agentcommunicationprotocol.dev/core-concepts/agent-
        discovery)

     *  A2A (https://a2a-protocol.org/latest/topics/agent-discovery/)

     *  ANS (https://genai.owasp.org/resource/agent-name-service-ans-for-
        secure-al-agent-discovery-v1-0/)

     *  AGNTCY (https://docs.agntcy.org/dir/overview/)







  Abbey & Cohen             Expires 19 April 2026                 [Page 3]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     The intent of this SCIM extension is to offer a viable path for the
     industry to re-leverage the well known core SCIM specifications, as
     well as existing implementations of SCIM clients and SCIM servers, to
     solve for agent cross domain management.

     In doing so, we can free the emerging standards in the agentic AI
     space to focus on truly novel concerns, instead of addressing the
     problems already solved by SCIM for user and groups.

     For example, in the A2A protocol, instead of describing a very high
     level concept of Curated registries (https://a2a-
     protocol.org/latest/topics/agent-discovery/#2-curated-registries-
     catalog-based-discovery) we could offer more concrete guidance by
     stating Agent Cards may be discovered by a SCIM client accessing any
     SCIM server that implements this extension.

  2.  Conventions

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

     Agent: A workload with its own identifier, metadata and privileges
     which are independent of a particular runtime environment or
     containing application.  An agent is distinct from a traditional
     software workloads (lambdas, services, etc...) due to varying degrees
     of unpredictable behavior caused by delegation of control flow to
     artificial intelligence models.

     Agentic application: An application exposing one or more agents to
     its users.  An agentic application is similar to a traditional native
     or web application, in that there are pre-defined ways authenticate
     and interact with the application; however, as soon as the
     application exposes agents, there are additional considerations for
     managing access to that application.

  4.  Core Schema Extensions

  4.1.  ServiceProviderConfig

     SCIM endpoints that support Agent extensions MUST advertise this
     support in the ServiceProviderConfig endpoint as defined:





  Abbey & Cohen             Expires 19 April 2026                 [Page 4]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    agentExtension
       A complex type that specifies Agent Extension configuration options.

       supported Boolean value specifying whether any aspect of the extension is supported.

       agentsSupported Boolean value specifying whether the agent resource type
                       is supported

       agenticApplicationsSupported Boolean value specifying whether the agent
                                    resource type is supported

     This is required so that:

     1) Clients may know if the server supports the concept of Agents. 2)
     Servers discourage clients from confusing users and agents.

     If the server does not support the concept of agents, a SCIM client
     MAY choose to create a User representation in the server for an
     Agent.  All the reasons it may choose to do so are beyond the scope
     of this document.  If the client does so, the client SHOULD indicate
     the user is linked to an agent using a LinkedObject from draft-
     grizzle-scim-pam-ext-01 (https://datatracker.ietf.org/doc/id/draft-
     grizzle-scim-pam-ext-01.txt) This would allow a SCIM server that
     supports that SCIM extension to add support for this extension and
     determine what users in the server should be mapped to agents when
     support is added.

  5.  Additional ResourceTypes and Schemas

     This SCIM Agent extension defines additional ResourceTypes and
     Schemas that MAY be implemented by the service provider.  If
     implemented, these ResourceTypes SHOULD support all SCIM operations
     [RFC7644].  All attributes defined in the schemas are optional unless
     explicitly marked as REQUIRED.

  5.1.  Agent

     This extension adds a new resource type of "Agent".

     Pursuant to [RFC7643] Section 3.2 Defining New Resource Types
     (https://datatracker.ietf.org/doc/html/rfc7643#section-3.2) this
     document define the ResourceType, Schema and Extensions for Agent.

  5.1.1.  Agent Resource Type

     The Agent Resource Type schema is:





  Abbey & Cohen             Expires 19 April 2026                 [Page 5]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     {
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
        "id": "Agent",
        "name": "Agent",
        "endpoint": "/Agents",
        "description": "Agent identities",
        "schema": "urn:ietf:params:scim:schemas:core:2.0:Agent"
     }

  5.1.2.  Agent filtering

     Clients MAY have a reference to the Agent name or externalId but not
     the ID.  For this reason, it is RECOMMENDED that service providers
     implement filtering that allows equality matching on the "name" and
     "externalId" attributes.

     Example (note that escaping has been removed for readability):

    GET /scim/v2/Agents?filter=name eq 'Helpdesk bot'

    GET /scim/v2/Agents?filter=externalId eq '8ccc535b-716d-4d32-b3e9-57c8be449c82'

  5.1.3.  Agent Common Attributes

     The agent resource type contains the common SCIM resource type
     attributes defined in [RFC7643] Section 3.1 Common Attributes
     (https://datatracker.ietf.org/doc/html/rfc7643#section-3.1)

     They are listed here for completeness:

     *  id

     *  externalId

     *  meta

  5.1.4.  Agent Core Schema

     The core agent schema provides the minimal representation of a
     resource "Agent".

     It contains only those attributes that any agent may need, and only
     one attribute is required.  It is identified using the schema URI:

     "urn:ietf:params:scim:schemas:core:2.0:Agent"

     The following attributes are defined in the core agent schema.




  Abbey & Cohen             Expires 19 April 2026                 [Page 6]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    name  The name of the Agent.  REQUIRED

    displayName
       The display name of the Agent.  If displayName is unassigned,
       the name MAY be used as the display name.

    active
       A Boolean value indicating the agent's administrative status.  The
       definitive meaning of this attribute is determined by the service
       provider.  As a typical example, a value of true implies that the
       agent is able to authenticate, while a value of false implies that the
       agent's account has been suspended and the agent will be unable to
       authenticate.

    description
       The description of the Agent.

    agentType
       The type of agent. There are no canonical values defined
       for type, but service providers MAY choose to define the valid
       types.

    active
       A Boolean value indicating the agent's administrative status.  The
       definitive meaning of this attribute is determined by the service
       provider.  As a typical example, a value of true implies that the
       agent is running, while a value of false implies that the
       agent has been suspended.

    entitlements
       An optional complex object that indicates entitlements the agent has.
       Its form is precisely the same as that defined in Section 4.1.2 of
       {{RFC7643}}.

    roles:
       An optional complex object that indicates roles the agent assumes.
       Its form is precisely the same as that defined in Section 4.1.2 of
       {{RFC7643}}.

    groups:
       An optional read-only complex object that indicates group
       membership.  Its form is precisely the same as that defined in
       Section 4.1.2 of {{RFC7643}}.

    applications
       A complex multi-valued attribute referencing applications this agent
       shares a trust boundary with. See "Agentic Application" section of
       this document.



  Abbey & Cohen             Expires 19 April 2026                 [Page 7]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    subject
       An optional attribute that clients may specify when
       provisioning an agent so that
       service providers implementing inbound token federation
       may correlate the agent with the `sub` claim in
       an inbound token from an OpenID connect provider.

   x509Certificates
       A list of certificates associated with the resource (e.g., a
       User).  Each value contains exactly one DER-encoded X.509
       certificate (see Section 4 of [RFC5280]), which MUST be base64
       encoded per Section 4 of [RFC4648].  A single value MUST NOT
       contain multiple certificates and so does not contain the encoding
       "SEQUENCE OF Certificate" in any guise.

    protocols
       A complex multi-value attribute that informs service providers of the
       various communication protocols an agent may support.
       This information can help service providers automatically
       support agent to agent or human to agent communication scenarios.
       An agent that supports no protocols is understood to the service provider
       to be inaccessible. For example, when an agent can only
       be accessed via its containing agentic application.

       The following sub-attributes are defined.

          type The type of the protocol. A number of canonical values
               are provided based on known agent protocols. They are:
               A2A, OpenAPI, MCP-Server

          specificationUrl The URL the service provider may retrieve the
                           specification document describing the agent's specific
                           information for that protocol.

    parent
       A complex attribute that defines the parent Agent of this
       Agent if the service provider supports hierarchies of
       agents.

       The following sub-attributes are defined.

          value  The ID of the agent that is the parent of this
             Agent in the hierarchy.

          $ref  A URI reference to the Agent that is the parent of this
             Agent in the hierarchy.

          display  The display name of the Agent that is the parent of



  Abbey & Cohen             Expires 19 April 2026                 [Page 8]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          this Agent in the hierarchy.

    owners
       A complex multi-valued attribute that defines the User or Group objects
       that are owners of this Agent.  OPTIONAL.  The following sub-attributes are
       defined for each value object.

       value  The ID of the User that owns this Agent.

       $ref  A URI reference to the User that owns this Agent.

       display  The display name of the user that owns this Agent.

  5.1.4.1.  JSON Representation

  5.1.4.1.1.  Minimal Agent Representation

     The following is a non-normative example of the minimal required SCIM
     representation in JSON format.

    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
       "id": "2819c223-7f76-453a-919d-413861904646",
       "name": "Clippy 2.0",
       "meta": {
          "resourceType": "Agent",
          "created": "2010-01-23T04:56:22Z",
          "lastModified": "2011-05-13T04:42:34Z",
          "version": "W\/\"3694e05e9dff590\"",
          "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
       }
    }

  5.1.4.1.2.  Full Agent Representation

     The following is a non-normative example of the fully populated SCIM
     representation in JSON format.

    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Agent"],
       "id": "2819c223-7f76-453a-919d-413861904646",
       "externalId": "clpy2001",
       "name": "Clippy 2.0",
       "active":true,
       "agentType": "Assistant",
       "groups": [
          {
             "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",



  Abbey & Cohen             Expires 19 April 2026                 [Page 9]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


             "$ref":
       "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
             "display": "The next generation"
          },
          {
             "value": "fc348aa8-3835-40eb-a20b-c726e15c55b5",
             "$ref":
       "https://example.com/v2/Groups/fc348aa8-3835-40eb-a20b-c726e15c55b5",
             "display": "Animated assistants"
           },
           {
             "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
             "$ref":
       "https://example.com/v2/Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
             "display": "AI clippers"
           }
       ],
       "x509Certificates": [
       {
          "value":
           "MIIDQzCCAqygAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMx
            EzARBgNVBAgMCkNhbGlmb3JuaWExFDASBgNVBAoMC2V4YW1wbGUuY29tMRQwEgYD
            VQQDDAtleGFtcGxlLmNvbTAeFw0xMTEwMjIwNjI0MzFaFw0xMjEwMDQwNjI0MzFa
            MH8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRQwEgYDVQQKDAtl
            eGFtcGxlLmNvbTEhMB8GA1UEAwwYTXMuIEJhcmJhcmEgSiBKZW5zZW4gSUlJMSIw
            IAYJKoZIhvcNAQkBFhNiamVuc2VuQGV4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0B
            AQEFAAOCAQ8AMIIBCgKCAQEA7Kr+Dcds/JQ5GwejJFcBIP682X3xpjis56AK02bc
            1FLgzdLI8auoR+cC9/Vrh5t66HkQIOdA4unHh0AaZ4xL5PhVbXIPMB5vAPKpzz5i
            PSi8xO8SL7I7SDhcBVJhqVqr3HgllEG6UClDdHO7nkLuwXq8HcISKkbT5WFTVfFZ
            zidPl8HZ7DhXkZIRtJwBweq4bvm3hM1Os7UQH05ZS6cVDgweKNwdLLrT51ikSQG3
            DYrl+ft781UQRIqxgwqCfXEuDiinPh0kkvIi5jivVu1Z9QiwlYEdRbLJ4zJQBmDr
            SGTMYn4lRc2HgHO4DqB/bnMVorHB0CC6AV1QoFK4GPe1LwIDAQABo3sweTAJBgNV
            HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
            Y2F0ZTAdBgNVHQ4EFgQU8pD0U0vsZIsaA16lL8En8bx0F/gwHwYDVR0jBBgwFoAU
            dGeKitcaF7gnzsNwDx708kqaVt0wDQYJKoZIhvcNAQEFBQADgYEAA81SsFnOdYJt
            Ng5Tcq+/ByEDrBgnusx0jloUhByPMEVkoMZ3J7j1ZgI8rAbOkNngX8+pKfTiDz1R
            C4+dx8oU6Za+4NJXUjlL5CvV6BEYb1+QAEJwitTVvxB/A67g42/vzgAtoRUeDov1
            +GFiBZ+GNF/cAYKcMtGcrs2i97ZkJMo="
       }
       ],
       "entitlements": [{
          "value": "write",
          "display": "Write permission",
          "type: "permission",
          "primary": true
       }],
       "roles": [{
          "value": "administrator",



  Abbey & Cohen             Expires 19 April 2026                [Page 10]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "display": "Administrator",
          "type: "permission",
          "primary": true
       }],
       "applications": [{
          "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
          "$ref": "https://example.com/v2/AgenticApplications/e9e30dba-f08f-4109-8486-d5c6a331660a",
          "display": "Clippy portal",
          "type": "Web"
       }],
       "subject": "clpy2001",
       "protocols: [{
          "type": "A2A",
          "specificationUrl": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646/.well-known/agent-card.json"
       }],
       "owners": [{
          "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "$ref": "../Groups/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "display": "US Employees"
       }],
       "parent": {
          "value": "71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "$ref": "https://example.com/v2/Agents/71ddacd2-a8e7-49b8-a5db-ae50d0a5bfd7",
          "display": "Clippy 1.0"
       },
       "meta": {
          "resourceType": "Agent",
          "created": "2010-01-23T04:56:22Z",
          "lastModified": "2011-05-13T04:42:34Z",
          "version": "W\/\"3694e05e9dff590\"",
          "location": "https://example.com/v2/Agents/2819c223-7f76-453a-919d-413861904646"
       }
    }

  5.2.  Agentic application

     An Agentic application represents a software application that hosts
     or provides access to one or more agents.  It serves as a container
     and runtime environment for agents, managing their authentication,
     authorization, and access to resources.

  5.2.1.  Resource Type

     The Agentic Application Resource Type schema is:







  Abbey & Cohen             Expires 19 April 2026                [Page 11]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    {
       "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
       "id": "AgenticApplication",
       "name": "AgenticApplication",
       "endpoint": "/AgenticApplications",
       "description": "Applications that host or provide access to agents",
       "schema": "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication",
    }

  5.2.2.  Filtering

     Clients MAY have a reference to the Agentic Application name, URL, or
     externalId but not the ID.  For this reason, it is RECOMMENDED that
     service providers implement filtering that allows equality matching
     on the "name", "externalId", and "applicationUrls.value" attributes.

     Example (note that escaping has been removed for readability):

    GET /scim/v2/AgenticApplications?filter=name eq 'AI Assistant Platform'

    GET /scim/v2/AgenticApplications?filter=externalId eq 'app-123456'

  5.2.3.  Common attributes

     The agentic application resource type contains the common SCIM
     resource type attributes defined in [RFC7643] Section 3.1 Common
     Attributes (https://datatracker.ietf.org/doc/html/rfc7643#section-
     3.1)

     They are listed here for completeness:

     *  id

     *  externalId

     *  meta

  5.2.4.  Schema

     The core agentic application schema provides the representation of an
     "AgenticApplication" resource.  It is identified using the schema
     URI:

     "urn:ietf:params:scim:schemas:core:2.0:AgenticApplication"

     The following attributes are defined in the core agentic application
     schema.




  Abbey & Cohen             Expires 19 April 2026                [Page 12]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


    name
       The name of the Agentic Application. REQUIRED.

    displayName
       The display name of the Agentic Application. If displayName is unassigned,
       the name MAY be used as the display name.

    description
       The description of the Agentic Application.

    active
       A Boolean value indicating the application's administrative status.
       The definitive meaning of this attribute is determined by the service
       provider. As a typical example, a value of true implies that the
       application is operational, while a value of false implies that the
       application has been disabled.

    applicationUrls
       A complex multi-valued attribute containing URLs associated with the application.
       The following sub-attributes are defined:

       type
          The type of URL. Canonical values are: "ssoEndpoint", "loginPage", "api", "homepage".

       primary
          A Boolean value indicating whether this is the primary URL of this type.

       value
          The URL string value.

       description
          A human-readable description of the URL.

    lastAccessed
       Timestamp of when the application was last accessed by any agent or user.
       This attribute can be used for stale access detection and least privilege enforcement.

    oAuthConfiguration
       A complex multi-valued attribute that describes the OAuth connections of the application.
       The following sub-attributes are defined:

       clientId
          The OAuth client identifier as described in section 2.2 of RFC6749.

       description
          A human-readable description of the client ID.

       audienceUri



  Abbey & Cohen             Expires 19 April 2026                [Page 13]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          The OAuth audience as defined
          in the "aud" claim of section 4.1.3 of RFC7519.

       issuerUri
          The identity provider issuer URI as defined in the "iss" claim
          of section 4.1.1 of RFC7519.

       redirectUri
          A multi-valued attribute containing authorized redirect URIs.


    agents
       A complex multi-valued attribute referencing agents associated with this application.
       The following sub-attributes are defined:

       value
          The ID of an agent associated with this application.

       ref
          A URI reference to an agent associated with this application.

       display
          The display name of the agent.

       type
          The relationship type between the agent and application.
          Canonical values are: "owned", "authorized", "guest".

    externalIdentifiers
       A complex multi-valued attribute containing identifiers associated with this application. OPTIONAL
       The following sub-attributes are defined:

       type
          The type of identifier. Service providers MAY define canonical values.
          <!-- Todo: what kind? I'm thinking about the SSO URLs of that application in the IDP -->

       value
          The identifier string value.

       system
          The system or domain this identifier is valid within.

  5.2.5.  Example

     Example Agentic Application:






  Abbey & Cohen             Expires 19 April 2026                [Page 14]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


  6.  Schema JSON Representations

     This section provides the complete JSON representation for the
     schemas defined in this extension.

  6.1.  Agent Schema JSON

     The following is intended as an example of the SCIM schema
     representation in JSON format for SCIM resources.  Where permitted,
     individual values and schema MAY change.  This example includes
     schema representations for "Agent".

    {
      "id" : "urn:ietf:params:scim:schemas:core:2.0:Agent",
      "name" : "Agent",
      "description" : "An AI agent",
      "attributes" : [
        {
          "name" : "name",
          "type" : "string",
          "multiValued" : false,
          "description" : "Unique identifier for the Agent, typically used by the agent to directly authenticate to the service provider. Each Agent MUST include a non-empty name value.  This identifier MUST be unique across the service provider's entire set of Agents. REQUIRED.",
          "required" : true,
          "caseExact" : false,
          "mutability" : "readWrite",
          "returned" : "default",
          "uniqueness" : "server"
        },
        {
          "name" : "agentType",
          "type" : "string",
          "multiValued" : false,
          "description" : "Used to classify like agents.  Typical values used might be
  'Assistant', 'Reseacher', 'Chat bot', and
  'Unknown', but any value may be used.",
          "required" : false,
          "caseExact" : false,
          "mutability" : "readWrite",
          "returned" : "default",
          "uniqueness" : "none"
        },
        {
          "name" : "active",
          "type" : "boolean",
          "multiValued" : false,
          "description" : "A Boolean value indicating the Agent's
  administrative status.",
          "required" : false,



  Abbey & Cohen             Expires 19 April 2026                [Page 15]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "groups",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of groups to which the user belongs,
  either through direct membership, through nested groups, or
  dynamically calculated.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the User's group.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "User",
                "Group"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'Group'
  resource to which the user belongs.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",



  Abbey & Cohen             Expires 19 April 2026                [Page 16]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function, e.g., 'direct' or 'indirect'.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [
                "direct",
                "indirect"
              ],
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
          "name" : "entitlements",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of entitlements for the User that
  represent a thing the User has.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The value of an entitlement.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",



  Abbey & Cohen             Expires 19 April 2026                [Page 17]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,
              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "roles",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of roles for the User that
  collectively represent who the User is, e.g., 'Student', 'Faculty'.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The value of a role.",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 19 April 2026                [Page 18]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [],
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,
              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name" : "x509Certificates",
          "type" : "complex",
          "multiValued" : true,



  Abbey & Cohen             Expires 19 April 2026                [Page 19]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


          "description" : "A list of certificates issued to the User.",
          "required" : false,
          "caseExact" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "binary",
              "multiValued" : false,
              "description" : "The value of an X.509 certificate.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "type",
              "type" : "string",
              "multiValued" : false,
              "description" : "A label indicating the attribute's
  function.",
              "required" : false,
              "caseExact" : false,
              "canonicalValues" : [],
              "mutability" : "readWrite",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "primary",
              "type" : "boolean",
              "multiValued" : false,
              "description" : "A Boolean value indicating the 'primary'
  or preferred attribute value for this attribute.  The primary
  attribute value 'true' MUST appear no more than once.",
              "required" : false,



  Abbey & Cohen             Expires 19 April 2026                [Page 20]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readWrite",
              "returned" : "default"
            }
          ],
          "mutability" : "readWrite",
          "returned" : "default"
        },
        {
          "name": "applications",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of applications to which the agent belongs.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the Agent's application.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "AgenticApplication"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'AgenticApplication'
  resource to which the user belongs.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 19 April 2026                [Page 21]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
           "name": "subject",
           "type" : "string",
           "multiValued" : false,
           "description" : "The subject to use for this agent in inbound tokens READ-ONLY.",
           "required" : false,
           "caseExact" : false,
           "mutability" : "readOnly",
           "returned" : "default",
           "uniqueness" : "none"
        },
        {
          "name": "owners",
          "type" : "complex",
          "multiValued" : true,
          "description" : "A list of users or groups that are the accountable parties for the agent.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the Agent's application.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "User",
                "Group"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'User' or 'Group'",
              "required" : false,
              "caseExact" : false,



  Abbey & Cohen             Expires 19 April 2026                [Page 22]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        },
        {
           "name": "protocols",
           "type" : "complex",
           "multiValued" : true,
           "description" : "A list of protocols to communicate with the Agent.",
           "required" : false,
           "subAttributes" : [
               {
                 "name" : "type",
                 "type" : "string",
                 "multiValued" : false,
                 "description" : "One of the canonical protocol types.",
                 "required" : false,
                 "caseExact" : false,
                 "mutability" : "readOnly",
                 "returned" : "default",
                 "uniqueness" : "none"
               },
               {
                 "name" : "specifiationUrl",
                 "type" : "string",
                 "multiValued" : false,
                 "description" : "URL of the specification for the protocol for this agent.",
                 "required" : false,
                 "caseExact" : false,
                 "mutability" : "readOnly",
                 "returned" : "default",
                 "uniqueness" : "none"



  Abbey & Cohen             Expires 19 April 2026                [Page 23]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


               }
             ],
             "mutability" : "readOnly",
             "returned" : "default"
        },
        {
          "name": "parent",
          "type" : "complex",
          "multiValued" : false,
          "description" : "Parent agent.",
          "required" : false,
          "subAttributes" : [
            {
              "name" : "value",
              "type" : "string",
              "multiValued" : false,
              "description" : "The identifier of the parent Agent",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "$ref",
              "type" : "reference",
              "referenceTypes" : [
                "Agent"
              ],
              "multiValued" : false,
              "description" : "The URI of the corresponding 'Agent'",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"
            },
            {
              "name" : "display",
              "type" : "string",
              "multiValued" : false,
              "description" : "A human-readable name, primarily used
  for display purposes.  READ-ONLY.",
              "required" : false,
              "caseExact" : false,
              "mutability" : "readOnly",
              "returned" : "default",
              "uniqueness" : "none"



  Abbey & Cohen             Expires 19 April 2026                [Page 24]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


            }
          ],
          "mutability" : "readOnly",
          "returned" : "default"
        }
      ],
      "meta" : {
        "resourceType" : "Schema",
        "location" :
          "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Agent"
      }
    }

  6.2.  Agentic Application Schema JSON

  7.  Security Considerations

     -> fill out

  8.  IANA Considerations

     This document has no IANA actions.

  9.  Change Log

     -01

     *  Macy finish up Agent schema description, JSON representation and
        schema

     *  Rafael contribution of agent app

     -00

     *  Initial draft extension.

  10.  References

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







  Abbey & Cohen             Expires 19 April 2026                [Page 25]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
                Mortimore, "System for Cross-domain Identity Management:
                Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
                2015, <https://www.rfc-editor.org/rfc/rfc7643>.

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

  10.2.  Informative References

     [ENTITLEMENTS]
                Zollner, D. and U. Vartak, "SCIM Roles and Entitlements
                Extension", n.d., <https://github.com/ietf-scim-wg/draft-
                ietf-scim-roles-entitlements/blob/main/draft-ietf-scim-
                roles-entitlements.md>.

     [RFC7642]  LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z.
                Zeltsan, "System for Cross-domain Identity Management:
                Definitions, Overview, Concepts, and Requirements",
                RFC 7642, DOI 10.17487/RFC7642, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7642>.

     [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
                and C. Mortimore, "System for Cross-domain Identity
                Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
                September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.

  Appendix A.  Acknowledgments

     We would like to thanks the authors of the SCIM Extension for
     Privileged Access Management (https://datatracker.ietf.org/doc/id/
     draft-grizzle-scim-pam-ext-01.txt) and Device Schema Extensions to
     the SCIM model (https://datatracker.ietf.org/doc/draft-ietf-scim-
     device-model/) which served as excellent guidance on how to document
     proposed extension to the SCIM protocol.

     Additionaly, we would like to thank all the contributors the emerging
     agent standards which inspired this extension, including:

     *  Agent communication protocol
        (https://agentcommunicationprotocol.dev/core-concepts/agent-
        discovery)

     *  Agent 2 Agent (https://a2a-protocol.org/latest/topics/agent-
        discovery/)





  Abbey & Cohen             Expires 19 April 2026                [Page 26]


  Internet-Draft  SCIM Agents and Agentic Applications Ext    October 2025


     *  Agent name service (https://genai.owasp.org/resource/agent-name-
        service-ans-for-secure-al-agent-discovery-v1-0/)

     *  AGNTCY directory (https://docs.agntcy.org/dir/overview/)

  Authors' Addresses

     Macy Abbey
     Okta
     Email: macy.abbey@gmail.com


     Rafael S. Cohen
     Okta
     Email: rafael.cohen@okta.com




































  Abbey & Cohen             Expires 19 April 2026                [Page 27]


name: draft-zhao-nmop-network-management-agent
rev: 04
title: AI based Network Management Agent(NMA): Concepts and Architecture
time: 2026-02-27T05:51:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T05:51:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604236+00:00
source: ietf
abstract:
  The evolution from Level 3 (assisted automation) to Level 4
     (autonomous self-optimization) in Autonomous Networks (AN) introduces
     requirements for Agentic capabilities, including intent-based
     reasoning, autonomous planning, and context-aware decision-making,
     which transcend the static, rule-based logic of traditional SDN
     Controllers.  This document defines the concept of the Network
     Management Agent (NMA), an AI-driven entity designed to embody these
     cognitive functions and bridge the gap between service intent and
     network operations.

     This document also specifies how the NMA utilizes the existing
     capabilities of SDN Controllers—such as topology management,
     telemetry, and enforcement—to achieve Autonomous L4 without
     duplicating policy control functions.  It further details the
     architectural integration modes and defines the interface
     requirements necessary for SDN Controllers to interoperate with NMAs.

full_text:
  Network Management Operations                                    X. Zhao
  Internet-Draft                                                     CAICT
  Intended status: Informational                                   M. Wang
  Expires: 31 August 2026                                     China Mobile
                                                                     B. Wu
                                                                    Huawei
                                                             D. Ceccarelli
                                                                     Cisco
                                                                  H. Zheng
                                                                    Huawei
                                                                   J. Zhou
                                                                       ZTE
                                                          27 February 2026


     AI based Network Management Agent(NMA): Concepts and Architecture
                draft-zhao-nmop-network-management-agent-04

  Abstract

     The evolution from Level 3 (assisted automation) to Level 4
     (autonomous self-optimization) in Autonomous Networks (AN) introduces
     requirements for Agentic capabilities, including intent-based
     reasoning, autonomous planning, and context-aware decision-making,
     which transcend the static, rule-based logic of traditional SDN
     Controllers.  This document defines the concept of the Network
     Management Agent (NMA), an AI-driven entity designed to embody these
     cognitive functions and bridge the gap between service intent and
     network operations.

     This document also specifies how the NMA utilizes the existing
     capabilities of SDN Controllers—such as topology management,
     telemetry, and enforcement—to achieve Autonomous L4 without
     duplicating policy control functions.  It further details the
     architectural integration modes and defines the interface
     requirements necessary for SDN Controllers to interoperate with NMAs.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Network Management
     Operations Working Group mailing list (nmop@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/btrse/nmop/.

     Source for this draft and an issue tracker can be found at
     https://datatracker.ietf.org/doc/draft-zhao-nmop-network-management-
     agent/.



  Zhao, et al.             Expires 31 August 2026                 [Page 1]


  Internet-Draft      Network Management Agent Concept       February 2026


  Status of This Memo

     This note is to be removed before publishing as an RFC.

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

  Copyright Notice

     This note is to be removed before publishing as an RFC.

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

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







  Zhao, et al.             Expires 31 August 2026                 [Page 2]


  Internet-Draft      Network Management Agent Concept       February 2026


     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 31 August 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 (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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Motivation: The Gap between AN L3 and L4  . . . . . . . .   4
     2.  NMA and SDN Controller: Roles and Collaboration . . . . . . .   4
       2.1.  Why NMA is Required for Autonomous L4 . . . . . . . . . .   5
       2.2.  Utilizing Existing SDN Controller Capabilities  . . . . .   5
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   6
       3.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Reference architecture of NMA and Deployment Modes  . . . . .   6
       4.1.  Intelligent Network Management and Control Framework Based
             on NMA  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Deployment modes of NMA . . . . . . . . . . . . . . . . .   9
       4.3.  Reference Functional Architecture of NMA  . . . . . . . .  12
         4.3.1.  Autonomous Logic Layer  . . . . . . . . . . . . . . .  13
         4.3.2.  Supporting Function Layer . . . . . . . . . . . . . .  14
       4.4.  Interface Requirements for NMA Integration  . . . . . . .  15
     5.  Operational Agent Example . . . . . . . . . . . . . . . . . .  18
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     8.  Appendix：Definition of L0~L5 levels in Autonomous Network . .  20
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23




  Zhao, et al.             Expires 31 August 2026                 [Page 3]


  Internet-Draft      Network Management Agent Concept       February 2026


  1.  Introduction

  1.1.  Motivation: The Gap between AN L3 and L4

     The Autonomous Networks (AN) framework [TMF-IG1230] defines a series
     of evolution stages from Level 0 (manual) to Level 5 (fully
     autonomous) as listed in Appendix I.  Current operator networks
     typically operate at Level 2 or 3, where automation is primarily
     policy-driven and reactive.  Achieving Level 4 (L4) requires evolving
     from static execution to dynamic assurance.

     The initial journey towards L4 could target pragmatic, high-value
     scenarios, such as automated Root Cause Analysis (RCA), SLA
     assurance, and service restoration.  These use cases allow operators
     to deploy AI for observability and recommendation, reducing manual
     toil while maintaining control.

     Traditional SDN Controllers excel at deterministic configuration and
     telemetry collection but lack the analytical depth required for these
     complex assurance tasks.  They execute instructions but cannot
     autonomously diagnose the 'why' behind a failure or predict SLA
     violations.  Introducing AI-driven logic is necessary to bridge this
     gap.  However, decoupled AI models are insufficient.  A new
     architectural entity—the Network Management Agent (NMA)—is needed to
     integrate AI-based reasoning with SDN control, starting with
     assurance use cases and gradually evolving towards full closed-loop
     autonomy.

     While the key issues after the introduction of AI in network
     management include:

     1.  The application architecture and deployment methods of AI in
         network management are still unclear, that is in what form AI can
         help network management?

     2.  The relationship between AI and the existing network controllers
         is not clear.

     3.  New interface capability requirements after AI is introduced are
         not clear either.

     Therefore, it is necessary to define the general architecture and
     application form of AI in network management.

  2.  NMA and SDN Controller: Roles and Collaboration






  Zhao, et al.             Expires 31 August 2026                 [Page 4]


  Internet-Draft      Network Management Agent Concept       February 2026


  2.1.  Why NMA is Required for Autonomous L4

     Achieving L4 autonomy requires a cognitive loop of Intent
     Interpretation, Perception Analysis, and Dynamic Decision-
     making—capabilities that extend beyond the native design of
     traditional SDN Controllers:

     *  *Intent Translation (The "Why")*: L4 moves beyond simple API
        commands to handling fuzzy, high-level operational intents.
        Unlike SDN Controllers, which require precise, low-level technical
        parameters (e.g., specific bandwidth values or queue IDs), the NMA
        acts as an Agentic Interpreter.  It automatically decomposes
        abstract goals (e.g., "Ensure optimal experience for VPN users")
        into concrete, verifiable technical specifications, handling the
        ambiguity and context that traditional controllers cannot resolve.

     *  *Perception & Contextual Analysis (The "Sense")*: L4 requires
        holistic observability not just raw data collection.  SDN
        Controllers excel at gathering telemetry but lack the ability to
        fuse multi-dimensional data (metrics, logs, traces, alarms) to
        understand the "state of the network" in a service context.  The
        NMA combines its own knowledge base and memory, using AI models to
        perform Root Cause Analysis (RCA), detect anomalies, and correlate
        events across the network to build a comprehensive operational
        picture.

     *  *Autonomous Decision & Policy Synthesis (The "Think")*: L4 demands
        the ability to make non-deterministic decisions in response to
        unforeseen scenarios.  Traditional controllers operate on
        deterministic, reactive logic (e.g., "If X, then Y"), which cannot
        handle novel failures or complex optimization trade-offs.  The NMA
        embodies the Decision function, utilizing reasoning capabilities
        to synthesize new strategies, weigh potential outcomes, and decide
        on the optimal course of action when standard procedures do not
        apply, and can be iteratively optimized itself.

     Therefore, the NMA serves as the Autonomous Brain (Cognitive Layer)
     that defines what needs to happen and why, orchestrating the SDN
     Controllers, which act as the Execution function (Control Layer) that
     handle how to enforce those decisions on the network infrastructure.

  2.2.  Utilizing Existing SDN Controller Capabilities

     To realize Autonomous L4, the NMA leverages the mature, stable
     functions already present in SDN Controllers rather than reinventing
     them.  NMA is compatible with the YANG-based automation framework
     described in [RFC8969], and utilizes the Controller as its primary
     execution engine:



  Zhao, et al.             Expires 31 August 2026                 [Page 5]


  Internet-Draft      Network Management Agent Concept       February 2026


     *  *Model-Based Abstraction*: The NMA interacts with the Controller
        through standard YANG Service and Network Models, bridging the gap
        between high-level intent and concrete network resources.

     *  *Telemetry & State Access*: The NMA consumes real-time operational
        data and topology information provided by the Controller to
        maintain an accurate perception of the network state.

     *  *Policy Enforcement*: The NMA invokes the Controller's
        configuration interfaces to apply changes, relying on the
        Controller's built-in validation and transaction capabilities to
        ensure stability.

     By integrating AI reasoning with this standards-based automation
     foundation, the NMA elevates the network from L3 (Automated Control)
     to L4 (Autonomous Management).

  3.  Terminology

  3.1.  Acronyms and Abbreviations

     AI: Artificial Intelligence

     LLM: Large Language Model

     NMA: Network Management Agent, refers to AI based network management
     agent

  3.2.  Definitions

     The document defines the following terms:

     *Network Management Agent (NMA):*  A network management entity built
        based on ML/AI and equipped with the autonomous task processing
        capabilities.  It can automatically carry out network status
        perception, task intent [RFC9315]interpretation, task planning,
        decision-making and task execution operations based on user task
        intentions or preset goals, so as to achieve closed-loop
        processing of scenarios-oriented network management tasks.  For
        different application scenarios, NMA can be subdivided into
        multiple scenario-oriented agents.

  4.  Reference architecture of NMA and Deployment Modes








  Zhao, et al.             Expires 31 August 2026                 [Page 6]


  Internet-Draft      Network Management Agent Concept       February 2026


  4.1.  Intelligent Network Management and Control Framework Based on NMA

     [RFC8969] proposed the framework for automating service and network
     management with YANG.  Building on the architecture proposed in
     [RFC8969], higher-level intelligent network management and control
     can be achieved by adding NMA components.  Based on the Figure 3 of
     [RFC8969], the layered architecture of intelligent network management
     and control after the introduction of NMA is shown in the following
     figure.  NMA can exist at both the Controller and Orchestrator
     levels; for the device layer, due to the constraints on the computing
     power of network elements, some end-side AI components may be added
     on the device side, while it is unlikely to deploy a complete NMA.







































  Zhao, et al.             Expires 31 August 2026                 [Page 7]


  Internet-Draft      Network Management Agent Concept       February 2026


                                              Hierachy NMA interaction
      +-------------------------------+
      |         Orchestrator          |
      | +---------------------------+ |                 +-----------+
      | | Network Management Agents | |               +-|---------+ |
      | |          (NMAs)           | |             +-|---------+ |-+
      | +---------------------------+ |             |    NMAs   |-+
      | +---------------------------+ |             +-----^-----+
      | |     Service Modeling      | |                   |
      | +---------------------------+ |                   |
      | +---------------------------+ |                   |   Inter-layer
      | |   Service Orchestration   | |                   | A2A communication
      | +---------------------------+ |                   |
      +-------------------------------+                   |
  --------------------------------------------------------+--------
      +-------------------------------+                   |
      |           Controller          |                   |
      | +---------------------------+ |                 +-v---------+
      | | Network Management Agents | |               +-|---------+ |
      | |          (NMAs)           | |             +-|---------+ |-+
      | +---------------------------+ |             |    NMAs   |-+
      | +---------------------------+ |             +-----------+
      | |     Network Modeling      | |
      | +---------------------------+ |       NMA1<---------------->NMA2
      | +---------------------------+ |              Intra-layer
      | |   Network Orchestration   | |           A2A communication
      | +---------------------------+ |
      +-------------------------------+
  -----------------------------------------------------------------
      +-------------------------------+
      |             Device            |
      | +---------------------------+ |
      | |        End-side AI        | |
      | +---------------------------+ |
      | +---------------------------+ |
      | |      Device Modeling      | |
      | +---------------------------+ |
      +-------------------------------+



      Figure 1: Enhanced intelligent network management and control
                          framework based on NMA








  Zhao, et al.             Expires 31 August 2026                 [Page 8]


  Internet-Draft      Network Management Agent Concept       February 2026


     Among them, there may be interaction requirements between NMAs at
     different layers and between different NMAs at the same layer.
     Cross-layer NMAs interact through inter-layer Agent-to-Agent (A2A)
     communication, while different NMAs within the same layer interact
     through intra-layer A2A communication.

     This document can be regarded as an enhancement of the intelligent
     capabilities of [RFC8969], and subsequent discussions will mainly
     focus on the NMAs at the controller layer.

  4.2.  Deployment modes of NMA

     It should be noted that although NMA is depicted inside the
     controller in Figure 1, in practice, NMA can also be deployed as an
     independent component outside the controller.  This document does not
     impose mandatory restrictions on the deployment location of NMA.  The
     two deployment modes can be called: Independent deployment mode and
     Integrated deployment mode and are shown in Figure-2, where the NMA
     can be part of an existing network controller, or can be an
     independent system deployed separately and interacting both with the
     controller and the network.






























  Zhao, et al.             Expires 31 August 2026                 [Page 9]


  Internet-Draft      Network Management Agent Concept       February 2026


                                     ^
                                     |
                         Extended NBI(including A2U)
                                     |
       +-----------------------------v------------------------------+
       |                     Network Controller                     |
       |                                                            |
       |  +--------------------+           +--------------------+   |
       |  | Original Function  <----A2C----> Network management |   |
       |  |      Modules       | Interface |      Agent(NMA)    |   |
       |  +--------------------+           +--------------------+   |
       |                                                            |
       +------------------------------^-----------------------------+
                                      |
                     Extended SBI(including A2N interface)
                                      |
       +------------------------------v-----------------------------+
       |                       Physical Network                     |
       +------------------------------------------------------------+
                             (a) Integrated Mode


                      ^                                   ^
                      |                                   |
           Northbound Interface(NBI)        Agent-to-User Interface(A2U)
                      |                                   |
       +--------------v------------+           +----------v---------+
       |                           |           |                    |
       |          Network          <----A2C----> Network Management |
       |        Controller         | Interface |    Agent(NMA)      |
       |                           |           |                    |
       +--------------^------------+           +----------^---------+
                      |                                   |
           Southbound Interface(SBI)     Agent-to-Network Interface(A2N)
                      |                                   |
       +--------------v-----------------------------------v---------+
       |                        Physical Network                    |
       +------------------------------------------------------------+
                             (b) Independent Mode

          Figure 2: Deployment mode of network management agent (NMA)

     *Integrated deployment mode:*  As shown in Figure-2 (a), NMA is
        integrated and deployed with the original network controller, and
        the NMA serves as a function of the controller.  NMA interacts
        with original function modules through internal A2C interface.
        The enhanced controller interacts with the underlay physical
        network through extended SBI satisfying the A2N interaction



  Zhao, et al.             Expires 31 August 2026                [Page 10]


  Internet-Draft      Network Management Agent Concept       February 2026


        requirements.  The specific functional requirements and
        information model definition of interfaces mentioned above will be
        discussed in Section 4.4.

        Integrated mode is targeted at network scenarios with single-
        vendor SDN infrastructure and high requirements for service real-
        time performance.  This mode features deep coupling between the
        NMA and the SDN Controller, low decision-making and execution
        latency, and simple deployment and operation & maintenance (O&M),
        making it suitable for autonomous network management in single-
        vendor domains.  At the same time, since it is extended on the
        basis of an existing SDN controller, the changes and impacts on
        the live network are also smaller, which facilitates the
        application and evolution of NMA in the live network.

     *Independent deployment mode:*  As shown in Figure 2 (b), NMA is
        independently deployed from the original network controller.  NMA
        and controller are independent systems.  A new east-west interface
        needs to be added between the NMA and the controller to achieve
        capability calling and result feedback operations.  This interface
        can be called “Agent-to-Controller Interface”(A2C).  In this
        deployment mode, controller uses southbound interface (SBI) to
        interact with physical network, while an Agent-to-Network
        interface (abbreviated as “A2N”) needs to be added between NMA and
        the underlying physical network.

        Independent mode is applicable to multi-domain, multi-vendor
        heterogeneous network environments.  Boasting high flexibility and
        scalability, this mode enables the NMA to act as a centralized
        cognitive brain that orchestrates multiple SDN Controllers to
        achieve closed-loop execution of end-to-end service intents.

     While the independent deployment mode brings significant flexibility
     to the management of large-scale and complex networks, its decoupled
     architecture between the NMA and SDN Controllers introduces a series
     of potential issues in practical deployment, including management and
     O & M conflicts between the two entities, which are mainly reflected
     in the following aspects:

     *Configuration and policy conflicts:*  Concurrent delivery of
        configurations to network devices by the NMA and the Controller
        may result in configuration conflicts on the devices.  In
        addition, the NMA generates dynamic control policies based on AI-
        driven intent reasoning and real-time network context analysis,
        whereas SDN Controllers maintain pre-configured static rule sets
        and traditional deterministic automation policies.
        Inconsistencies between these two types of policies may lead to
        policy execution failures and even service interruptions.



  Zhao, et al.             Expires 31 August 2026                [Page 11]


  Internet-Draft      Network Management Agent Concept       February 2026


     *Inconsistent network state synchronization:*  The autonomous
        decision-making of the NMA relies on real-time and accurate
        network state data (telemetry, alarms, topology) provided by SDN
        Controllers.  In the independent mode, network transmission
        latency and data processing delays between the NMA and Controllers
        may compromise the accuracy of the NMA's decision-making.

     This document does not mandate a specific deployment mode for the
     NMA.  When the independent deployment mode is adopted, it is advised
     to follow the principle of separation of cognitive decision-making
     and execution enforcement: the NMA is responsible for intent
     interpretation, context analysis and autonomous decision-making,
     while SDN Controllers retain the authorities of policy validation,
     resource enforcement and network state management.  This ensures the
     consistency and effectiveness of the collaborative operation between
     the NMA and SDN Controllers.

  4.3.  Reference Functional Architecture of NMA

     In order to achieve above capabilities, by referring to the common AI
     agent framework, this document presents the reference functional
     architecture of NMA as shown in Figure 3.

  +---------------------------------------------------------------------------+
  |                         NMA(Network Management Agent)                     |
  |                                                                           |
  |            +-----------------------------------------------------------+  |
  | Autonomous |                      Intent Management                    |  |
  |   Logic    +-----------------------------------------------------------+  |
  |   Layer    +------------+  +------------+  +-----------+  +------------+  |
  |            |  Awareness |  |  Analysis  |  |  Decision |  | Execution  |  |
  |            +------------+  +------------+  +-----------+  +------------+  |
  |---------------------------------------------------------------------------|
  |                                                                           |
  | Supporting +-----------------+  +=================+  +-----------------+  |
  |  Function  |     Memory&     |  |     AI Model    |  | Tool & Function |  |
  |   Layer    |  Knowledge Base |  |     Service     |  |     Manager     |  |
  |            +-----------------+  +=================+  +-----------------+  |
  |                                                                           |
  +---------------------------------------------------------------------------+



             Figure 3: Reference function architecture of NMA







  Zhao, et al.             Expires 31 August 2026                [Page 12]


  Internet-Draft      Network Management Agent Concept       February 2026


     The NMA is structured into two primary layers: the Autonomous Logic
     Layer, which embodies the autonomous closed-loop from intention to
     perception, analysis, decision-making, and execution, and the
     Supporting Function Layer, which provides foundational capabilities
     to enable autonomous operations.

  4.3.1.  Autonomous Logic Layer

     This layer embodies the intelligent loop of L4 autonomy, translating
     service goals into network actions.  It mainly includes the following
     logical functional modules which are fully consistent with the IAADE-
     closed loop of autonomous network defined in TMF (see detailed in
     Section 8):

     *Intent Management:*  This module serves as the entry point for
        Intent.  It is responsible for receiving high-level goals from
        users or orchestration systems, interpreting natural language or
        policy objectives, and normalizing them into structured,
        verifiable intents that the agent can pursue.  It ensures that the
        autonomous operations remain aligned with service KPIs.  After
        interpreting the target intent and reasoning through the necessary
        steps to achieve it, this module can orchestrate the sequence of
        operations required to progress toward that goal.  It breaks down
        complex objectives into a sequence of executable sub-tasks (e.g.,
        awareness -> analysis -> decision -> execution) and handles
        dynamic planning under uncertainty, ensuring that the chosen
        course of action aligns with the desired intent.

     *Awareness:*  This module acts as the intent-driven selective sensing
        hub of the NMA, responsible for orchestrating the targeted query
        and perception of task-relevant network data.  It proactively
        initiates data acquisition operations across heterogeneous sources
        such as controllers, physical/virtual network devices, etc., with
        a core focus on filtering out irrelevant information to collect
        only the network data pertinent to the current intent.  Covering
        critical dimensions including device operational status, link
        performance metrics, service traffic statistics, and configuration
        parameters, this module lays a precise foundational data base for
        the subsequent analysis, decision-making, and execution processes.

     *Analysis:*  This module serves as the intelligent analytics core,
        leveraging the reasoning capabilities of the AI Model Service in
        the Supporting Function Layer.  It orchestrates advanced
        analytical tasks tailored to the specific task intent, including
        anomaly detection, root cause analysis (RCA), event correlation,
        and impact quantification, etc.  By combining real-time perceived
        data with historical insights retrieved from the Memory&Knowledge
        Base, it transforms raw data into actionable, context-rich network



  Zhao, et al.             Expires 31 August 2026                [Page 13]


  Internet-Draft      Network Management Agent Concept       February 2026


        insights and diagnostic conclusions.  It can clearly identify the
        root causes of network issues, evaluates the impact of abnormal
        states on service objectives, and outputs structured analytical
        results that directly guide the strategic decision-making.

     *Decision:*  This module functions as the strategic decision-making
        core of the NMA, responsible for formulating optimal and feasible
        operation strategies based on the analytical insights from the
        Analysis Management module and the constraints of the original
        user intent.  It employs AI reasoning capabilities and draws on
        the Memory&Knowledge Base to evaluate multiple potential action
        paths, selecting the strategy that best aligns with service-level
        objectives and network operation rules.  It decomposes complex
        strategic decisions into a hierarchical, ordered sequence of
        executable sub-tasks, defines clear trigger conditions and task
        dependencies for each step, and maps these sub-tasks to specific
        tools or functions managed by the Tool&Function Manager.  This
        process ensures that the generated decisions are not only
        logically sound but also fully operationalized for subsequent
        execution.

     *Execution:*  This module acts as the intent-closed-loop operational
        execution core, tasked with translating the structured sub-tasks
        from the Decision Management module into concrete, reliable
        network operations.  It orchestrates the invocation of appropriate
        network interfaces, management tools, and operational functions
        via the Tool&Function Manager, executing tasks such as
        configuration adjustment, fault remediation, resource scheduling,
        and service provisioning in a sequential and controlled manner.
        It real-time monitors the execution status of each sub-task,
        handles execution exceptions and retries according to pre-defined
        rules, and conducts rigorous result validation against the
        original user intent and decision criteria.  Finally, it feeds
        back the execution outcomes, status, and validation results to the
        Memory&Knowledge Base and upper-layer modules, forming a complete
        closed-loop of autonomous network management driven by intent.

     NMA enables the cognitive capabilities on task lifecycle management
     procedure described in [RFC8969].

  4.3.2.  Supporting Function Layer

     This layer provides the foundational capabilities and resources
     necessary for the Autonomous logic Layer to function effectively.

     *Memory & Knowledge Base:*  This module serves as the long-term and





  Zhao, et al.             Expires 31 August 2026                [Page 14]


  Internet-Draft      Network Management Agent Concept       February 2026


        short-term memory of the NMA, storing historical operational data,
        network topology snapshots, and a comprehensive repository of
        expert knowledge including technical documents, troubleshooting
        guidelines, and past incident resolution cases, etc.  It provides
        unified search capabilities across multi-type knowledge sources
        such as vector knowledge bases, system online help documentation,
        and operation and maintenance data logs.  Based on accurate
        domain-specific information, this module improves the accuracy and
        reliability of NMA’s reasoning and decision-making, enables the
        agent to reuse historical experience and expert logic, and ensures
        the consistency and effectiveness of autonomous operations.

     *AI Model Service:*  This module acts as the cognitive engine of the
        NMA, providing unified upward exposure of diversified AI
        capabilities.  It supports not only Large Language Models (LLM)
        and other generative AI models, but also classic AI algorithms and
        lightweight dedicated models, enabling natural language
        understanding, logical inference, time-series analysis and other
        intelligent capabilities.  It supplies the comprehensive general
        and domain-specific intelligence required to drive the core
        processes of intent management, perception and analysis, reasoning
        and planning, and decision and execution.

        It should be noted that the AI Model Service is not limited to
        being deployed inside the NMA; it can also be located outside the
        NMA, and the NMA can invoke AI model capabilities in real time to
        complete relevant reasoning operations.

     *Tool & Function Manager:*  This module serves as the Gateway to
        Reality.  It manages the connection between the NMA and external
        systems, primarily the SDN Controllers via the A2C (Agent-to-
        Controller) interface.  It abstracts network functions (e.g.,
        configuration, telemetry, simulation, etc.) as invocable "Tools."
        This module ensures that the decisions made by the upper layer are
        translated into concrete, standard-compliant network operations
        (e.g., YANG data manipulation).

  4.4.  Interface Requirements for NMA Integration

     As shown in Figure 2, the interfaces related to NMA include three
     types:

     1.  *Agent-to-User interface (A2U):*the interface between the NMA and
         the user, where the user can be upper-layer NMA, controllers or
         orchestrators.  This interface is used to receive call requests
         from users and return task processing results.  It should support
         both structured and natural language modes.  The natural language
         interface is mainly used for interaction with humans, while the



  Zhao, et al.             Expires 31 August 2026                [Page 15]


  Internet-Draft      Network Management Agent Concept       February 2026


         structured interface is used for interaction with other upper-
         layer systems or other Agents.  The Agent-to-Agent (A2A)
         interface between NMAs is included in the scope of this
         interface.  In the independent mode, this interface is a separate
         one provided by the NMA to the outside; in the integrated mode,
         it is included in the northbound interface of the controller.

         Since this interface bridges the NMA with human operators or
         higher-level orchestrators.  It must support dual-mode
         interaction:

         *Natural Language Interaction:*  For human operators, the
            interface must support conversational inputs (e.g., text) and
            return structured responses or execution confirmations.

         *Structured Intent Interface:*  For upper-layer orchestrators or
            peer agents, the interface must support structured intent
            definitions (e.g., based on YANG models or JSON/GNMI).  It
            requires:

            * Intent Submission: Accepting high-level goals with
            constraints (e.g., latency, cost).

            * Status Reporting: Providing real-time feedback on intent
            fulfillment progress, including intermediate states (e.g.,
            "Analyzing", "Planning", "Executing").

     2.  *Agent-to-Controller interface (A2C):* the interface between NMA
         and the controller or the original functional components of the
         controller.  In the independent mode, this interface is an east-
         west interface between the controller and NMA; in the integrated
         mode, this interface is an internal interface of the controller
         and is not within the scope of this document.

     3.  *Agent-to-Network (A2N):*the interface between NMA and the
         physical network.  In the independent mode, this interface is a
         southbound interface between the Agent and the network; in the
         integrated mode, it is included in the original southbound
         interface of the controller.

     To elaborate in more detail, when NMAs are deployed in integration
     with the controller, as shown in Figure 4, the related interface to
     be extended includes:

     1.  *Extended SBI of the controller:* The southbound interface
         between the controller and devices, including the aforementioned
         A2N interface function.  Theoretically, NMAs will not directly
         configure or operate devices; instead, they will call the



  Zhao, et al.             Expires 31 August 2026                [Page 16]


  Internet-Draft      Network Management Agent Concept       February 2026


         original functional modules of the controller for device-related
         configuration and management.  Therefore, the need for standard
         extension of this interface is minimal, and it is not within the
         scope of this draft.

     2.  *Extended NBI:* The northbound interface of the controller.  As a
         key interface for collaboration between upper and lower layer
         systems, this interface needs to realize functions such as
         capability discovery and invocation between upper and lower layer
         NMAs.  Hence, there is a strong demand for its standardization,
         and it is necessary to consider the extension of the northbound
         interface of the controller oriented to the communication needs
         between NMAs.  NBI must be augmented to expose the NMA's
         cognitive capabilities as Intent-Based RPCs.  Unlike standard
         configuration RPCs that set specific parameters (e.g., set-
         bandwidth), these Intent-Based RPCs accept high-level operational
         goals (e.g., optimize-performance or diagnose-incident).  This
         distinction allows upper-layer systems to invoke autonomous
         behaviors that require reasoning and planning—capabilities that
         native controller interfaces lack.

         In terms of communication channels, the orchestrator and the
         controller communicate one-to-one through the northbound
         interface.  When there is a need for direct communication between
         NMAs in the upper-layer orchestrator and those in the lower-layer
         controller (A2A Communication), it will manifest as a single
         communication channel physically but multiple communication
         processes logically (i,e.including multiple A2A communication
         processes).

         To sum up, entended NBI should handle logical multi-process
         multiplexing.  Current protocols typically handle a single
         request-response session.The extended NBI must support multiple
         independent A2A communication processes over a single physical
         channel.  It must maintain strict context isolation between
         different agent tasks (e.g., one diagnosing a fault, another
         optimizing QoS) to prevent state interference—a requirement not
         addressed in standard HTTP/RPC models.

     Besides, there are several internal interfaces within the controller,
     which include the interaction interfaces between NMAs within the
     controller and the original functional modules of the controller, as
     well as the interaction interfaces between multiple NMAs within the
     controller.  Since all the above are internal implementations of the
     controller, there is no need for standardization.

     The specific implementation methods, related protocols, etc. of each
     interface are to be defined subsequently in other documents.



  Zhao, et al.             Expires 31 August 2026                [Page 17]


  Internet-Draft      Network Management Agent Concept       February 2026


       +-------------------------------------------+
       |              Orchestrator                 |
       | +-----------+ +-----------+ +-----------+ |
       | |    NMA1   | |    NMA2   | |   NMA3    | |          ^
       | +-----^-----+ +-----------+ +-----^-----+ |          |
       +-------:-------------^-------------:-------+          |
               :             |             :                  |
               : Logical     | Extended    : Logical          | Extended
               :   A2A       |   NBI       :   A2A            |   NBI
               :             |             :                  |
       +-------:-------------v-------------:------------------^---+
       |       :               Controller  :                      |
       |       :                           :       +------------+ |
       | +-----v-----+ +-----------+ +-----v-----+ |  Original  | |
       | |   NMA1    | |    NMA2   | |    NMA3   | |  function  | |
       | +-----------+ +-----------+ +-----------+ |   modules  | |
       |                                           +------------+ |
       +----------------------------^-----------------------------+
                                    |
                                    | Extented SBI
                                    |
       +----------------------------v-----------------------------+
       |                        Physical Network                  |
       +----------------------------------------------------------+

             Figure 4: Interfaces to be extended on the controller

  5.  Operational Agent Example

     To address specific operational needs, the NMA architecture supports
     multiple specialized agents.  These agents function as modular
     entities, with the Intelligent Assistant Agent serving as the primary
     entry point for interaction, followed by specialized agents such as
     Fault management Agent and Optimization Agent:

     *  *Intelligent Assistant Agent*: Serving as the primary interface
        for human operators, this agent leverages LLMs to provide natural
        language Q&A and conversational capabilities.  It enables users to
        perform "one-click" queries for fault descriptions or resource
        status.  By automatically translating human intent into precise
        data retrieval commands, it significantly enhances the efficiency
        of knowledge retrieval and daily maintenance support.

     *  *Network Fault Management Agent*: Focused on service assurance,
        this agent leverages comprehensive troubleshooting guides and
        expert knowledge bases to support intelligent fault handling.  It
        implements automated root cause analysis (RCA) and fault impact
        analysis.  In addition to fault diagnosis, it orchestrates control



  Zhao, et al.             Expires 31 August 2026                [Page 18]


  Internet-Draft      Network Management Agent Concept       February 2026


        plane APIs to execute self-healing operations, and integrates with
        external work order systems to achieve closed-loop incident
        resolution.or self-healing actions and integrates with external
        work order systems to enable closed-loop incident resolution.

     *  *Network Optimization Agent*: Focused on performance and
        efficiency, this agent translates high-level optimization goals
        into technical constraints, such as load thresholds or routing
        policies.  Leveraging traffic prediction models, it anticipates
        network congestion and proactively generates strategies for
        traffic engineering (e.g., pre-diversion) and dynamic energy
        saving.  It operates in a closed-loop manner to autonomously
        execute decisions that maintain optimal network performance.

  6.  Security Considerations

     Since networks are critical infrastructure, misoperations can have a
     significant impact on them.  Therefore, NMAs shall meet the following
     security and reliability requirements:

     1.  Support multi-factor authentication mechanism for sensitive
         operations.  For operations involving network configuration
         changes or those that pose significant risks to network operation
         security, a manual confirmation mechanism must be introduced, and
         multiple authentication methods such as passwords and dynamic
         tokens shall be used to ensure operation security.

     2.  Support circuit breaker mechanism.  When abnormal results occur
         during the execution of an NMA task, it shall provide error
         prompts and transfer the task directly to manual control for
         handling.

     3.  Support rollback mechanism.  After the execution of an NMA task
         is completed, it shall support operation rollback to restore the
         network configuration.

     4.  Support data security and privacy protection mechanism.  It shall
         support the encryption of sensitive data such as network
         configurations and user behavior logs; support user permission
         division, and set differentiated data access permissions for
         different users.

     5.  Support operation permission control mechanism.  For different
         application scenarios, the minimum permissions required to
         perform tasks in the scenario shall be set.  For example, a fault
         handling NMA may query data such as topology resources and
         performance, but shall not have permission to perform service
         configuration operations.



  Zhao, et al.             Expires 31 August 2026                [Page 19]


  Internet-Draft      Network Management Agent Concept       February 2026


  7.  IANA Considerations

     This document has no requests for IANA action.

  8.  Appendix：Definition of L0~L5 levels in Autonomous Network

     Table 1 summarizes the Autonomous Network (AN) levels defined in TM
     Forum IG1230 [TMF-IG1230].  It illustrates that current IETF
     automation frameworks, such as [RFC8969], primarily enable Level 3
     (Partial Autonomy) by utilizing data models (YANG) to enforce pre-
     defined policies.








































  Zhao, et al.             Expires 31 August 2026                [Page 20]


  Internet-Draft      Network Management Agent Concept       February 2026


     +=====+===============+=================+==========================+
     |LEVEL|NAME           |DESCRIPTION (CORE| HUMAN VS.  MACHINE ROLE  |
     |     |               |CHARACTERISTICS) |                          |
     +=====+===============+=================+==========================+
     |L0   |Manual         |Fully manual     | Human does everytding.   |
     |     |               |processes.  No   |                          |
     |     |               |automation.      |                          |
     +-----+---------------+-----------------+--------------------------+
     |L1   |Assisted       |System provides  | Human makes all          |
     |     |               |tools            | decisions; tools assist. |
     |     |               |(dashboards,     |                          |
     |     |               |alarms).         |                          |
     +-----+---------------+-----------------+--------------------------+
     |L2   |System-assisted|Automation of    | Human initiates tasks;   |
     |     |               |single tasks/    | system executes.         |
     |     |               |scripts witdin a |                          |
     |     |               |specific domain. |                          |
     +-----+---------------+-----------------+--------------------------+
     |L3   |Partial        |Closed-loop      | "Human-in-the-Loop":     |
     |     |Autonomy       |automation based | Humans define rules/     |
     |     |               |on pre-defined   | models and monitor;      |
     |     |               |policies/models  | system executes and      |
     |     |               |witdin a domain. | reports exceptions.      |
     +-----+---------------+-----------------+--------------------------+
     |L4   |High Autonomy  |Cross-domain/    | "Human-on-the-Loop":     |
     |     |               |cross-layer      | Humans define high-level |
     |     |               |context analysis | intents; system self-    |
     |     |               |and closed-loop  | configures and heals.    |
     |     |               |optimization     | Human only intervenes on |
     |     |               |based on Intents.| system failure.          |
     +-----+---------------+-----------------+--------------------------+
     |L5   |Full Autonomy  |Self-evolving,   | "Human-out-of-the-Loop": |
     |     |               |self-optimizing, | System requires no human |
     |     |               |fully driverless | intervention for         |
     |     |               |operations.      | business goals.          |
     +-----+---------------+-----------------+--------------------------+

                  Table 1: Autonomous Network Levels (L0-L5)

     Figure 5 depicts the ‘Intent-Awareness-Analysis-Decision-Execution
     (IAADE)’ control loop AN architecture, highlighting the evolution
     from the rule-based automation of Level 3 to the intent-driven, AI-
     powered autonomy of Level 4, which is the focus of this document.
     Network Management Agent can serve as an augmentation layer,
     enhancing network management automation and orchestration
     capabilities through natural language intent translation, cross-
     vendor semantic bridging, and knowledge codification.  In this
     context, Agents focus on decision support and workflow orchestration,



  Zhao, et al.             Expires 31 August 2026                [Page 21]


  Internet-Draft      Network Management Agent Concept       February 2026


     while critical configuration changes continue to follow manual
     approval and transactional execution mechanisms via existing
     deterministic protocols (e.g., NETCONF), striking a balance between
     automation efficiency and operational certainty.

      +----------+
      |  INTENT  |
      |  (Goal)  |
      +----------+
            |
            | "What to achieve"
            v
    +-------------+    +------------+    +------------+    +-------------+
    |    AWARE    |    |   ANALYZE  |    |   DECIDE   |    |   EXECUTE   |
    |             | -> |            | -> |            | -> |             |
    | (Awareness) |    | (Analysis) |    | (Decision) |    | (Execution) |
    +------+------+    +------+-----+    +------+-----+    +------+------+
           |                  |                 |                 |
           +------------------+-----------------+-----------------+
                                      |
                                      v
                               +--------------+
                               |   NETWORK    |
                               +--------------+

           Figure 5: IAADE Control Loop for Autonomous Networks

  9.  References

  9.1.  Normative References

  9.2.  Informative References

     [I-D.irtf-nmrg-ai-challenges]
                François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
                and S. Schneider, "Research Challenges in Coupling
                Artificial Intelligence and Network Management", Work in
                Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
                03, 4 March 2024, <https://datatracker.ietf.org/doc/html/
                draft-irtf-nmrg-ai-challenges-03>.

     [I-D.kdj-nmrg-ibn-usecases]
                Yao, K., Chen, D., Jeong, J., Wu, Q., Yang, C., and L.
                Contreras, "Use Cases and Practices for Intent-Based
                Networking", Work in Progress, Internet-Draft, draft-kdj-
                nmrg-ibn-usecases-01, 8 July 2024,
                <https://datatracker.ietf.org/doc/html/draft-kdj-nmrg-ibn-
                usecases-01>.



  Zhao, et al.             Expires 31 August 2026                [Page 22]


  Internet-Draft      Network Management Agent Concept       February 2026


     [LLM-powered-autonomous-agents]
                Weng, L., "LLM Powered Autonomous Agents", 23 June 2023.

     [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
                Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
                Networking: Definitions and Design Goals", RFC 7575,
                DOI 10.17487/RFC7575, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7575>.

     [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
                Analysis for Autonomic Networking", RFC 7576,
                DOI 10.17487/RFC7576, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7576>.

     [RFC8969]  Wu, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A
                Framework for Automating Service and Network Management
                with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021,
                <https://www.rfc-editor.org/rfc/rfc8969>.

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/rfc/rfc9315>.

     [TMF-AN-journey-guide]
                Tansuthepverawongse, Boonchoung., "AN Journey Guide
                Autonomous Networks L4 industry blueprint-high-value
                scenarios", June 2024.

     [TMF-IG1230]
                McDonnell, K., Machwe, A., Milham, D., O’Sullivan, J.,
                Clemm, A., and J. Niemöller, "Autonomous Networks
                Technical Architecture", TMF IG1230, December 2022.

  Authors' Addresses

     Xing Zhao
     CAICT
     Beijing
     China
     Email: zhaoxing@caict.ac.cn


     Minxue Wang
     China Mobile
     Beijing
     China
     Email: wangminxue@chinamobile.com



  Zhao, et al.             Expires 31 August 2026                [Page 23]


  Internet-Draft      Network Management Agent Concept       February 2026


     Bo Wu
     Huawei
     China
     Email: lana.wubo@huawei.com


     Daniele Ceccarelli
     Cisco
     Email: dceccare@cisco.com


     Haomian Zheng
     Huawei
     China
     Email: zhenghaomian@huawei.com


     Jin Zhou
     ZTE
     China
     Email: zhou.jin6@zte.com.cn






























  Zhao, et al.             Expires 31 August 2026                [Page 24]


name: draft-yao-agent-auth-considerations
rev: 01
title: Further considerations on AI Agent Authentication and Authorization Based on OAuth Extension
time: 2026-04-23T07:09:44Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T09:32:44Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604240+00:00
source: ietf
abstract:
  Agent Communication Network(ACN) is becoming a promising and
     fundamental infrastructure for most vertical industries.  To
     construct and build a scalable and trustable ACN, authentication and
     authorization of AI agents are critical requirements.  This document
     extends the model of OAuth and proposes new workflows for AI agent
     authentication and authorization.

full_text:
  Network Working Group                                             K. Yao
  Internet-Draft                                              China Mobile
  Intended status: Informational                           20 October 2025
  Expires: 23 April 2026


    Further considerations on AI Agent Authentication and Authorization
                          Based on OAuth Extension
                   draft-yao-agent-auth-considerations-01

  Abstract

     Agent Communication Network(ACN) is becoming a promising and
     fundamental infrastructure for most vertical industries.  To
     construct and build a scalable and trustable ACN, authentication and
     authorization of AI agents are critical requirements.  This document
     extends the model of OAuth and proposes new workflows for AI agent
     authentication and authorization.

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

  Copyright Notice

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











  Yao                       Expires 23 April 2026                 [Page 1]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
     3.  Aauth: Agent OBO Its User(s)  . . . . . . . . . . . . . . . .   4
       3.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Aauth: Agent OBO Itself . . . . . . . . . . . . . . . . . . .   7
       4.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Aauth: Agent OBO Other Agent(s) . . . . . . . . . . . . . . .   9
       5.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   9
       5.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.  Considerations on Other Important Factors . . . . . . . . . .  11
       6.1.  Grant Dynamicity  . . . . . . . . . . . . . . . . . . . .  11
       6.2.  Specific Identity for AI Agent  . . . . . . . . . . . . .  12
       6.3.  Can AI Agents Represent Users to Consent Requests?  . . .  12
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
       7.1.  Agent Impersonation during Discovery  . . . . . . . . . .  12
       7.2.  Excessive Attribute Disclosure  . . . . . . . . . . . . .  13
       7.3.  Token Replay and Intermediary Exfiltration  . . . . . . .  13
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
       10.2.  Informative References . . . . . . . . . . . . . . . . .  13
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     With the rapid development of large language models(LLMs) and AI
     applications, an AI agent is becoming an emerging entity that can
     help improve working efficiency.  There are different types of AI
     agents, e.g., physical and virtual entities, and many promising use
     cases of AI agents have been mentioned in
     [I-D.rosenberg-aiproto-framework].  All of these AI agents will join



  Yao                       Expires 23 April 2026                 [Page 2]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


     to build a new Internet infrastructure, which is called as Agent
     Communication Network(ACN).  To build such future networks is not
     easy, challenges and requirements for new protocols are discussed in
     [I-D.rosenberg-aiproto-framework].  Key requirements include, the
     discovery, procedures and mechasims of AI agents to establish message
     routing and connection management.  A fundamental component and of
     critical importance for any new AI agent protocol is ensuring robust
     authentication and authorization.

     The complexity of AI agent authentication and authorization exists in
     that agent may have different roles and capabilities.  AI agents may
     work On-behalf-of(OBO) users, itself, or other AI agents.  In
     different cases, there are different requirements on the
     authentication and authorization, leading to different workflows.
     More importantly, agents may communicate with API proxy server, like
     MCP server to call API and access external resources, this makes the
     authentication and authorization problems more complex.
     [I-D.oauth-ai-agents-on-behalf-of-user] considers the case when AI
     agents work OBO their users, and [I-D.rosenberg-oauth-aauth] defines
     the extension of OAuth 2.1 for AI agents.  This document further
     considers more cases on AI agents authentication and authorization
     based on OAuth extensions.

     This document describes an extension to the OAuth to support
     authentication and authorization among AI agents within ACNs.  It
     defines three operational modes in which agents act on behalf of
     users, themselves, or other agents, introduces the concept of an AID,
     and discusses integration with API proxy servers such as the MCP.

  2.  Definition of Terms

     *  AI Agent: an entity with built-in intelligence, which can help or
        replace humans implement jobs and improve work efficiency.

     *  Types of AI Agents:

        -  Physical AI Agent: a physical entity with embedded
           intelligence, usually refers to some AI terminals, e.g., AI
           robot, embodied AI.

        -  Virtual AI Agent: a virtual entity that can provide
           intelligence, usually refers to some softwarized AI assistant,
           e.g., a chat assistant with a mobile application.

     *  Ownership and Roles of AI Agents:

        -  OBO User: the agent may require the authorization from users to
           implement jobs for users.



  Yao                       Expires 23 April 2026                 [Page 3]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


        -  OBO Agent Itself: the agent itself has identification and
           implements jobs and represents itself.

        -  OBO Other Agent(s): the agent may represent other agents to
           implement some jobs, given that other agents may not have the
           capabilities to implement the jobs.

     *  Agent Communication Network(ACN): a network infrastructure which
        supports the interconnection, routing, capabilities announcement,
        and task collaboration of different types of AI agents.

     *  Agent Identifier(AID): An independent identifier of AI agent.

     *  API Proxy Server: A middlebox server that helps AI agent to call
        APIs or access external data resources.  A typical example is the
        Model Context Protocol(MCP) server.

     *  Domain:

        -  Task-wise Domain: a temporary domain that is created to target
           on a specific job, when the job is finished, the domain is
           destroyed.  A typical example is a domain that is created by
           5G/6G core network.

        -  Application Domain: a durable domain that is created by a
           specific application, e.g., a web or mobile application offered
           by cloud service providers.

        The definition of resource server, resource owner, authorization
        server, and client reuse the definition in [RFC6749].

  3.  Aauth: Agent OBO Its User(s)

  3.1.  Example Case

     A typical use case of AI agent on-behalf-of the user to access public
     resources can be a virtual agent assistant.  For example, a trip
     planning app assistant helps the user to plan trips.  This case is
     obvious and similar ones have been mentioned in
     [I-D.rosenberg-aiproto-framework].  In this case, when the trip
     assistant needs to search for the current balance of the user, it
     needs the authorization of the user to access his bank account app.
     While it may also need to search for hotels, and it may require the
     account of the user under some booking applications.  In addition, it
     may also need to use some of the data stored in the cloud personal
     gallery, which may require temporary access token.  Therefore, AI
     agent OBO user(s) need different levels of authentication and
     authorization to access these resources.



  Yao                       Expires 23 April 2026                 [Page 4]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


  3.2.  Model

     Figure 1 shows the extension of the OAuth 2.0 model proposed in
     [RFC6749].  There are several updates and new components in this
     model.  The big difference is the introduction of AI agent and API
     proxy server.  If under traditional OAuth 2.0 model, client(AI agent)
     will directly communicate with resource owners and resource servers.
     But this is not efficient and scalable in the AI era, since an agent
     may consult many resource owners at the same time, and different
     resource owners may require different levels of privileges to access
     protected resources.  To overcome the issue, industries have proposed
     Model Context Protocol(MCP).  It introduces MCP server and protocol
     to let AI agents only communicate with the MCP server to request for
     resources.  The MCP server will help AI agents to do API calling and
     specific data resource access.  In Figure 1, MCP server refers to the
     API proxy server.  In the diagram, API proxy server will communicate
     with different resource owners and resource servers.  The agent may
     also support communicating directly with the resource owner and
     resource server.  For example, the resource owner is another agent
     that is interconnected with the agent itself.































  Yao                       Expires 23 April 2026                 [Page 5]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


                                                  2          +--------+
                                               +------------->Resource|
                                               |+------------+Owner 1 |
                                               || 3          +--------+
                                               ||      8     +--------+
                                               ||  +-------->|Resource|
                                     +------+  ||  |+--------+Server 1|
                                     |      +--+|  ||  9     +--------+
                                     |      <---+  ||
                             +------->  API +------+|
                             |       | Proxy|       |
                             | +-----|Server<-------+
                             | |     |      |
                             | |     |      +-----+
                             | |     |      <-+   |   2      +--------+
                             | |     +---^+-+ |   +--------->|Resource|
                         1,7 | |         ||   +--------------+Owner 2 |
                             | |4,10     ||     3            +--------+
                             | |         ||          8       +--------+
                             | |         |+----------------->|Resource|
     +----+  0     +-----+   | |         +-------------------+Server 2|
     |User+-------->     +---+ |                  9          +--------+
     |    <--------+     <-----+
     +----+  11    |     |          1             +--------+
                   |  AI +----------------------->|Resource|
                   |Agent<------------------------+Owner 3 |
                   |     |          4             +--------+
                   |     +-----------+     7      +--------+
                   |     |           +----------->|Resource|
                   |     <------------------------+Server 3|
                   +--^-++              9         +--------+
                      | |
                      | |
                      | |  5         +-------+
                      | +------------> Auth  |
                      +--------------+Servers|
                           6         +-------+

                      Figure 1: AI Agent OBO User Workflow

  3.3.  Workflow

     The detailed workflow of Figure 1 is as follows:

     *  Step 0, the user initially asks for AI agent for some tasks via
        prompts.





  Yao                       Expires 23 April 2026                 [Page 6]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


     *  Step 1, the AI agent interpret the prompts and communicate with
        the API proxy server to search for specific data resources and
        implement function calling.  Alternatively, the agent will ask the
        resource server for the grant if they are directly connected.

     *  Step 2, the API proxy server asks for multiple resource owners for
        the grant of access of the protected data resources.

     *  Step 3, resource owners reply to the API server what
        authentication grant(e.g., authorization code) they need for the
        access to the required resource.

     *  Step 4, the API proxy server will gather messages from different
        resource owners and reply to the AI agent containing multiple
        authorization grants from different resource owners.
        Alternatively, resource owner 3 will replies to the agent with the
        authorization grant directly.

     *  Step 5, the AI agent communicates with different authorization
        servers with multiple authorization grants.

     *  Step 6, auth servers reply to the AI agent with the required
        access tokens.

     *  Step 7, AI agent replies to the API server with the required
        access tokens.  Alternatively, it directly sends the access token
        to the resource server(resource server 3).

     *  Step 8, the API proxy server sends different access tokens to
        different resource servers respectively.

     *  Step 9, resource servers send protected data resources to the API
        proxy server.  The resource server 3 directly sends the protected
        data resources to the AI agent.

     *  Step 10, the API proxy server replies to the AI agent with the
        information that it needs.

     *  Step 11, AI agent replies to the user with the answer.

  4.  Aauth: Agent OBO Itself










  Yao                       Expires 23 April 2026                 [Page 7]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


  4.1.  Example Case

     In addition to virtual AI agents, there is another type, physical AI
     agent.  AI robots, embodied AI, and other AI terminals have
     differentiated capabilities to implement multiple jobs.  For example,
     in a remote rescue case, an AI search and rescue vehicles, and an
     robot dog can be dynamically formed into a networked system.  The
     robot dog can scan and transmit the live videos to remote console and
     control signals to the AI search and rescue vehicle, while the AI
     search and rescue vehicles can use its robotic arm to move obstacles
     based on the signals from the robot dog or the remote console.  Some
     other similar cases are mentioned in [TR22.870].
     Compared to the case in which the agent is OBO its user, the major
     difference in this case is that agent need identification of itself,
     that is the agent identification(AID).  In previous case, agent can
     be assigned a Client ID(CID).  The scope of its authority is
     determined by its user, and is less than its users' authority scope.
     While if agent is OBO itself, it is the user.  So it has the same
     privilege as the user.  How to define the AID needs further
     discussion and is beyond the scope of this document.

  4.2.  Model

     The model of the agent OBO itself can be extended
     from[I-D.ietf-oauth-v2-1].  As shown in Figure 2, the AI agent is the
     resource owner.  When assigned with some specific tasks, it may
     enable some software functions, and then it will trigger the client
     within these software functions for authentication and authorization.

      +---------+                               +---------------+
      |         |--(A)- Authorization Request ->|   Resource    |
      |         |                               |     Owner     |
      |         |<-(B)-- Authorization Grant ---|  (AI Agent or |
      |         |                               | Other owners) |
      |         |                               +---------------+
      |         |
      |         |                               +---------------+
      |         |--(C)-- Authorization Grant -->| Authorization |
      | Client  |                               |     Server    |
      |         |<-(D)----- Access Token -------|               |
      |         |                               +---------------+
      |         |
      |         |                               +---------------+
      |         |--(E)----- Access Token ------>|    Resource   |
      |         |                               |     Server    |
      |         |<-(F)--- Protected Resource ---|               |
      +---------+                               +---------------+




  Yao                       Expires 23 April 2026                 [Page 8]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


                     Figure 2: AI Agent OBO Itself Workflow

  4.3.  Workflow

     Detailed workflow is similar to [I-D.ietf-oauth-v2-1], and will not
     be stated in detail.

  5.  Aauth: Agent OBO Other Agent(s)

  5.1.  Example Case

     This case is more complex, but may be required if AI agents have
     differentiated capabilities and need to collaborate to finish some
     jobs, whatever the agents are from intra-domain or inter-domain,
     which has been discussed in [I-D.rosenberg-aiproto-framework].
     In this case, if one AI agent wants to access some protected data
     resources of other agents, or of the users of other agents.  It needs
     the authorization from them.  This is different compared to the
     situation that this agent only needs to seek for grant from the user
     it represents.

  5.2.  Model

     Figure 3 shows the model when multiple agents work collaboratively,
     and there will be a chained authentication and authorization
     workflow.  Before AI Agent A requests AI agent B to help it implement
     a job, there should be prior knowledge that both agents need mutual
     trust.  If they come from the same domain, whatever it is a task-wise
     domain created by a console(e.g., 5G/6G core) or a durable domain
     created by a web application, they need verification from the 5G/6G
     core or the web application administrator.  If they come from
     different domains, they may need verification from an open platform
     that organize and issue the AIDs.  There are some ongoing work
     defining AID[I-D.narajala-ans],[I-D.narvaneni-agent-uri].  With this
     pre-verification, agents can communicate with each other.  But when
     one agent(AI agent B) needs access of the protected data resource of
     the user of AI agent A or AI agent C itself, it still need temporary
     authentication and authorization.  In this chained authentication and
     authorization workflow, the core idea here is to let the agent OBO
     user or the agent OBO itself always to communicate with the
     authorization server to get the access token.










  Yao                       Expires 23 April 2026                 [Page 9]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


           +------+
           | Auth |
           |Server|
           +-^-+--+                 +------+    3   +--------+
             | |                    |      +-------->Resource|
             | |                    |      <--------+Owner 1 |
            7| |8             +----->  API |    4   +--------+
             | |              |     | Proxy|
            ++-v--+           | +---|Server|   11   +--------+
            | AI  |           | |   |      +-------->Resource|
            |Agent|           | |   |      <--------+Server 1|
            |  C  |           | |   |      |    12  +--------+
            +-^-+-+           | |   +------+
              | |         2,10| |
              | |             | |5,13
           6,9| |1,14         | |
      +----+  | |   +-----+   | |
      |User|  | |   |     +---+ |
      |    |  | +--->     <-----+
      +-+^-+  +-----+     |          2             +--------+
        ||          |  AI +----------------------->|Resource|
       0||15        |Agent<------------------------+Owner 2 |
      +-v+--+       |  B  |          5             +--------+
      | AI  | 6,14  |     +-----------+     10     +--------+
      |Agent<-------+     |           +----------->|Resource|
      |  A  +------->     <------------------------+Server 2|
      |     |  1,9  +-----+              13        +--------+
      +--^-++
         | |
         | |          7               +------+
         | +--------------------------> Auth |
         +----------------------------+Server|
                            8         +------+

                  Figure 3: AI Agent OBO Other Agents Workflow

  5.3.  Workflow

     The detailed workflow of Figure 3 is as follows:

     Step 0, a user asks its AI agent(AI agent A) for some help.

     Step 1, AI agent A redirects the help to Agent B when A is not
     capable, and Agent C asks for B's help too.

     Step 2, agent B ask API proxy server to call APIs.  Agent may also
     request resource owner's grant for its protected data resources.




  Yao                       Expires 23 April 2026                [Page 10]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


     Step 3, the API proxy server send requests to resource owner 1.

     Step 4, the resource owner 1 send access grant to the API proxy
     server.

     Step 5, the API proxy server and resource owner 2 send the access
     grant to AI agent B.

     Step 6, AI agent B redirects the access grants to AI agent A or AI
     agent C, considering the resource belong to whom.

     Step 7, AI agent A and AI agent C send access grants to authorization
     servers.

     Step 8, authorization servers replies with authorization tokens.

     Step 9, Agent A and agent C pass the access tokens to agent B.

     Step 10, AI agent B passes the access tokens to API proxy server or
     resource owner 2, considering what resource agent B wants to access.

     Step 11, the API proxy server passes the access token to resource
     owner 1.

     Step 12, resource owner 1 gives the protected data resource to the
     API proxy server.

     Step 13, agent B gathers the data resources from the API proxy server
     and resource owner 2.

     Step 14, agent B sends back the processing result to agent A or agent
     C.

     Step 15, agent A processes further and sends back the final result to
     the user.

  6.  Considerations on Other Important Factors

  6.1.  Grant Dynamicity

     [RFC7591] mentions the mechanism to realize dynamic client
     registration.  Whether and when to grant AI agents with short-lived
     or long-lived authentication and authorization may need further
     discussion, considering various use cases that AI agents participant.







  Yao                       Expires 23 April 2026                [Page 11]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


  6.2.  Specific Identity for AI Agent

     As the second and the third case mentions in the previous section, AI
     agents may have independent identities in ACN.  The definition of
     AIDs is not within the scope of this document, but directly impacts
     authentication and authorization methods.

  6.3.  Can AI Agents Represent Users to Consent Requests?

     In the third case mentioned in this document when agent is OBO other
     agents.  This document assumes that agent can represent its user to
     request for access tokens, while the choice on whether to consent
     requests(authorization grant) is still left to the user or the
     agent(agent C).  But it may evolve to the situation that AI agent can
     represent its user to give permission if there are some pre-
     validation on the content scope that AI agent can give external
     grants independently.

  7.  Security Considerations

     AI Agent authentication and authorization introduce additional risks
     beyond those covered in [RFC6749] and [I-D.ietf-oauth-v2-1].  This
     section highlights specific threats and corresponding mitigations
     applicable to agent-to-agent (A2A) environments and Agent
     Communication Networks (ACN).

     Attention must be given to agent discovery, agent sandboxing, audit
     logging, and revocation mechanisms, and interactions should apply
     appropriate transport-layer security.  It is worth noting autonomous
     agents may act persistently and at machine speed, which creates
     several additional security challenges.

     Specific aspects of security will be discussed in more detail in this
     document.

  7.1.  Agent Impersonation during Discovery

     An adversary may attempt to impersonate a legitimate AI agent during
     the discovery phase, registering false endpoints or replaying
     previously valid credentials to obtain unauthorized access tokens or
     sensitive data.

     Agents must perform authenticated discovery using DNS or another
     verifiable directory service and complete a cryptographically signed
     handshake before establishing trust.  Implementations might need to
     reject interactions with agents that cannot present verifiable
     handshake proofs.




  Yao                       Expires 23 April 2026                [Page 12]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


  7.2.  Excessive Attribute Disclosure

     During discovery and authorization, agents may disclose more
     identifying information than is necessary, creating privacy risks and
     enlarging the surface of attack.  Privacy-preserving credential
     mechanisms may be used to reveal only the minimum attributes
     necessary for the transaction.  Authorization servers and relying
     parties should avoid requesting attributes not strictly required for
     policy enforcement.

  7.3.  Token Replay and Intermediary Exfiltration

     Access tokens exchanged between agents or through API proxy servers
     (e.g., MCP) may be intercepted or replayed by unauthorized
     intermediaries, resulting in impersonation or unauthorized resource
     access.

     A method should be used so that access tokens may be sender-
     constrained using mechanisms.  Furthermore, tokens may be configured
     to have short lifetimes or be scoped narrowly to the required
     operation.  For sensitive or human-triggered actions, a method to
     ensure that leaked tokens cannot independently authorize sensitive
     actions would be required.

  8.  IANA Considerations

     TBD.

  9.  Acknowledgements

  10.  References

  10.1.  Normative References

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
                P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
                RFC 7591, DOI 10.17487/RFC7591, July 2015,
                <https://www.rfc-editor.org/rfc/rfc7591>.

  10.2.  Informative References

     [I-D.ietf-oauth-v2-1]
                Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
                Authorization Framework", Work in Progress, Internet-



  Yao                       Expires 23 April 2026                [Page 13]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


                Draft, draft-ietf-oauth-v2-1-14, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                v2-1-14>.

     [I-D.narajala-ans]
                Huang, K., Narajala, V. S., Habler, I., and A. Sheriff,
                "Agent Name Service (ANS): A Universal Directory for
                Secure AI Agent Discovery and Interoperability", Work in
                Progress, Internet-Draft, draft-narajala-ans-00, 16 May
                2025, <https://datatracker.ietf.org/doc/html/draft-
                narajala-ans-00>.

     [I-D.narvaneni-agent-uri]
                Narvaneni, Y., "The agent:// Protocol -- A URI-Based
                Framework for Interoperable Agents", Work in Progress,
                Internet-Draft, draft-narvaneni-agent-uri-02, 15 October
                2025, <https://datatracker.ietf.org/doc/html/draft-
                narvaneni-agent-uri-02>.

     [I-D.oauth-ai-agents-on-behalf-of-user]
                Thilina, T. and A. Dissanayaka, "OAuth 2.0 Extension: On-
                Behalf-Of User Authorization for AI Agents", Work in
                Progress, Internet-Draft, draft-oauth-ai-agents-on-behalf-
                of-user-02, 25 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-oauth-ai-
                agents-on-behalf-of-user-02>.

     [I-D.rosenberg-aiproto-framework]
                Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
                and Requirements for AI Agent Protocols", Work in
                Progress, Internet-Draft, draft-rosenberg-aiproto-
                framework-00, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-rosenberg-
                aiproto-framework-00>.

     [I-D.rosenberg-oauth-aauth]
                Rosenberg, J. and P. White, "AAuth - Agentic Authorization
                OAuth 2.1 Extension", Work in Progress, Internet-Draft,
                draft-rosenberg-oauth-aauth-01, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-rosenberg-
                oauth-aauth-01>.

     [TR22.870] 3GPP, "Study on 6G Use Cases and Service Requirements",
                n.d..

  Author's Address





  Yao                       Expires 23 April 2026                [Page 14]


  Internet-Draft            Agent AuthN and AuthZ             October 2025


     Kehan Yao
     China Mobile
     Email: yaokehan@chinamobile.com
















































  Yao                       Expires 23 April 2026                [Page 15]


name: draft-zhao-ccamp-actn-optical-network-agent
rev: 01
title: Integration of Network Management Agent (NMA) into ACTN-Based Optical Network
time: 2026-02-28T02:35:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T02:35:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604244+00:00
source: ietf
abstract:
  With the growth of optical network scale, the complexity of network
     operation and maintenance has increased dramatically.  Enhancing the
     intelligence level of optical network operation and management and
     building high-level autonomous optical networks have become the
     common vision of global operators.  The development of AI, especially
     large AI model technologies, provides a feasible technical path for
     realizing autonomous perception, decision-making, analysis, and
     execution.  The existing ACTN architecture provides network
     abstraction and control functions for optical networks but lacks
     higher-level autonomous capabilities.

     This document explores the introduction of AI based Network
     Management Agent(NMA) functions into ACTN-based optical networks to
     achieve high-level autonomy of optical networks.  It discusses the
     ACTN-enhanced architecture of optical networks after the introduction
     of NMAs, including key components, interaction relationships, new
     interface requirements in the enhanced architecture, as well as
     typical use cases of agent-based autonomous operation and maintenance
     for optical networks.  The document aims to improve the autonomy
     level of optical networks and promote the realization of autonomous
     optical networks by extending the original ACTN architecture.

full_text:
  Common Control and Measurement Plane                             X. Zhao
  Internet-Draft                                                     CAICT
  Intended status: Informational                                     H. Yu
  Expires: 23 April 2026                                            Huawei
                                                                     Y. Xu
                                                                     CAICT
                                                           20 October 2025


   Integration of Network Management Agent (NMA) into ACTN-Based Optical
                                  Network
               draft-zhao-ccamp-actn-optical-network-agent-00

  Abstract

     With the growth of optical network scale, the complexity of network
     operation and maintenance has increased dramatically.  Enhancing the
     intelligence level of optical network operation and management and
     building high-level autonomous optical networks have become the
     common vision of global operators.  The development of AI, especially
     large AI model technologies, provides a feasible technical path for
     realizing autonomous perception, decision-making, analysis, and
     execution.  The existing ACTN architecture provides network
     abstraction and control functions for optical networks but lacks
     higher-level autonomous capabilities.

     This document explores the introduction of AI based Network
     Management Agent(NMA) functions into ACTN-based optical networks to
     achieve high-level autonomy of optical networks.  It discusses the
     ACTN-enhanced architecture of optical networks after the introduction
     of NMAs, including key components, interaction relationships, new
     interface requirements in the enhanced architecture, as well as
     typical use cases of agent-based autonomous operation and maintenance
     for optical networks.  The document aims to improve the autonomy
     level of optical networks and promote the realization of autonomous
     optical networks by extending the original ACTN architecture.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Network Management
     Operations Working Group mailing list (nmop@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/ccamp/.

     Source for this draft and an issue tracker can be found at
     https://datatracker.ietf.org/doc/draft-zhao-ccamp-actn-optical-
     network-agent/.



  Zhao, et al.              Expires 23 April 2026                 [Page 1]


  Internet-Draft         NMA enhanced actn framework          October 2025


  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 23 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.  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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   4
       2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  NMA-based enhanced ACTN architecture  . . . . . . . . . . . .   4
       3.1.  Enhanced ACTN architecture  . . . . . . . . . . . . . . .   4
       3.2.  Enhanced ACTN interfaces  . . . . . . . . . . . . . . . .   6
     4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Service provisoning . . . . . . . . . . . . . . . . . . .   9
       4.2.  Service Assurance . . . . . . . . . . . . . . . . . . . .   9
       4.3.  Fault Handling  . . . . . . . . . . . . . . . . . . . . .   9
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9



  Zhao, et al.              Expires 23 April 2026                 [Page 2]


  Internet-Draft         NMA enhanced actn framework          October 2025


       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     With the emergence and popularization of the SDN concept, [RFC8453]
     proposed the ACTN architecture, which provides network abstraction,
     service and connection control functions for optical networks and has
     been deployed in multiple operators' networks.  Currently, as the
     scale of optical networks continues to grow, the complexity of
     network Operations and Maintenance (O&M) has increased dramatically.
     Existing existing existing optical network O&M management systems are
     complex; scenarios such as optical network service provisioning and
     fault handling require extensive manual involvement, leading to
     complicated collaboration processes among O&M personnel and long
     processing durations.  Therefore, further enhancing the intelligence
     level of optical network operation and management, building high-
     level autonomous optical networks, and achieving the service
     experience of "Zero-X" (zero waiting, zero failure, zero touch) and
     "Self-X" (self-configuration, self-healing, self-optimization) have
     become the common vision of global operators.

     The development of AI, especially large AI model technologies,
     provides a feasible technical path for realizing autonomous
     perception, decision-making, analysis, and execution.  As one of the
     important forms of AI application implementation, the concept of AI
     Agent has gained extensive attention and recognition in the industry.
     An AI Agent is defined as an intelligent entity capable of perceiving
     the environment, making autonomous decisions, and executing actions,
     which can gradually achieve set goals through independent thinking
     and tool invocation.  The four core elements of an AI Agent include
     planning, tools, execution, and memory.  Most current AI Agents are
     based on Large Language Models (LLMs), i.e., LLM-based Agents.  The
     relationship between an AI Agent and a large model can be summarized
     as: Agent = large model + memory + planning + tool use.

     Currently, the IETF document [I-D.zhao-nmop-network-management-agent]
     has proposed an AI Agent for network O&M management, which can
     automatically perform network state perception, task intent parsing,
     task planning, decision-making, and task execution.  Based on user
     task intent or preset goals, it enables closed-loop processing of
     scenario-oriented network O&M management tasks.

     This document, building on the Network Management Agent (NMA) concept
     proposed in [I-D.zhao-nmop-network-management-agent], explores the
     introduction of NMA into the ACTN-based optical network architecture.
     By enhancing the capabilities of the agent, it aims to improve the
     intelligent O&M management capabilities of optical networks and drive



  Zhao, et al.              Expires 23 April 2026                 [Page 3]


  Internet-Draft         NMA enhanced actn framework          October 2025


     the realization of high-level autonomy in optical networks.  This
     document will first discuss the enhanced ACTN architecture of optical
     networks after the introduction of NMA, analyze in detail the key
     components, interaction relationships, and new interface requirements
     in the new architecture, and provide examples of typical agent-based
     autonomous O&M use cases for optical networks.

  2.  Terminology

  2.1.  Acronyms and Abbreviations

     AI: Artificial Intelligence

     LLM: Large Language Model

     NMA: Network Management Agent, refers to AI based network management
     agent

     Agent: Specifically refers to NMA, i.e., the AI Agent for network
     management.

  2.2.  Definitions

     The document defines the following terms:

     Network Management Agent (NMA):  A network management entity built
        based on ML/AI and equipped with the autonomous task processing
        capabilities.  It can automatically carry out network status
        perception, task intent interpretation, task planning, decision-
        making and task execution operations based on user task intentions
        or preset goals, so as to achieve closed-loop processing of
        scenarios-oriented network management tasks.  For different
        application scenarios, NMA can be subdivided into multiple
        scenario-oriented agents.

  3.  NMA-based enhanced ACTN architecture

  3.1.  Enhanced ACTN architecture

     The enhanced ACTN architecture for optical networks after the
     introduction of NMA is illustrated in Figure 1 below.  The AI agents
     (i,e.  NMA) are introduced within the ACTN architectural framework as
     auxiliary components intended to augment and assist existing ACTN
     functional entities, rather than to replace them.  In alignment with
     this design principle, the NMAs are conceptually implemented as
     design components within the MDSC, PNC, or CNC, rather than as
     independent entities external to these controllers.  The agents can
     interact with existing ACTN functional components through



  Zhao, et al.              Expires 23 April 2026                 [Page 4]


  Internet-Draft         NMA enhanced actn framework          October 2025


     standardized protocols such as the Management Control Protocol (MCP).
     This integrated design approach ensures backward compatibility with
     the established ACTN framework and enables seamless interaction with
     the existing ACTN interfaces and control logic.

              +----------------------------------+
              |           Enhanced CMC           |
              | +--------+ +--------+ +--------+ |
              | |  NMA1  | |  NMA2  | |  NMA3  | |
              | +--------+ +--------+ +--------+ |
              +-----------------^----------------+
                                |(1)Extened CMI
              +-----------------v----------------+
              |           Enhanced MDSC          |
              | +--------+ +--------+ +--------+ |
              | |  NMA1  | |  NMA2  | |  NMA3  | |
              | +--------+ +--------+ +--------+ |
              +-----------------^----------------+
                                |(2)Extended MPI
                           +----+-----------------------+-----------+
                           |                            |           |
    +----------------------v--------------------+  +----v----+ +----v----+
    |               Enhanced PNC1               |  |         | |         |
    | +----------+             +------+         |  |         | |         |
    | |          |        +----> NMA2 >----+    |  |         | |         |
    | | Original |        |(5) +------+    |    |  |  PNC2   | |   PNC3  |
    | | Function | (4) +--^---+   (5)  +---v--+ |  |         | |         |
    | |  Modules <-----> NMA1 >--------> NMA3 | |  |         | |         |
    | +----------+     +------+        +------+ |  |         | |         |
    +----------------------v--------------------+  +----v----+ +----v----+
                           |(3)Extended SBI             |           |
    +----------------------v--------------------+  +----v----+ +----v----+
    |               Network domain 1            |  | Domain2 | | Domain3 |
    +-------------------------------------------+  +---------+ +---------+


                Figure 1: NMA-based enhanced ACTN architecture

     The enhanced ACTN architecture includes the following key entities:

     NMA-enhanced CNC (Customer Network Controller):  As defined in










  Zhao, et al.              Expires 23 April 2026                 [Page 5]


  Internet-Draft         NMA enhanced actn framework          October 2025


        [RFC8453], the CNC is responsible for transmitting the customer’s
        Virtual Network Service (VNS) requirements to the network operator
        via the CNC-MDSC Interface (CMI).  By integrating NMA entities
        related to service scenarios at the CNC layer, it can address
        operation and management needs specific to the service domain,
        enhance the intelligence level of end-to-end service operation and
        management, and enable intelligent service-domain capabilities
        such as automated service provisioning and automated work order
        flow.

     NMA-enhanced MDSC (Multi-Domain Service Coordinator):  As defined in
        [RFC8453], the MDSC undertakes core functions including multi-
        domain service coordination and network virtualization/
        abstraction.  By introducing NMA entities for cross-domain
        scenarios at the MDSC layer, it can meet cross-domain O&M
        management requirements, strengthen closed-loop task processing
        capabilities in typical scenarios, and improve the efficiency of
        optical network management and control.

     NMA-enhanced PNC (Provisioning Network Controller):  As defined in
        [RFC8453], the Provisioning Network Controller (PNC) oversees
        configuring the network elements, monitoring the topology
        (physical or virtual) of the network, and collecting information
        about the topology (either raw or abstracted).  By integrating NMA
        entities for single-domain scenarios (e.g., Fault Management NMA,
        Service Assurance NMA) at the PNC layer, it can address single-
        domain O&M management needs and enhance the ability to handle
        various network O&M tasks within the domain.

  3.2.  Enhanced ACTN interfaces

     As shown in Figure 1, the architecture includes 5 types of
     interfaces:

     1.  Extended CMI: The interface between CNC and MDSC.  After
         introducing NMA entities at each layer, the communication
         requirements between the original CMI interfaces will be enhanced
         from traditional transactional communication to include agent-
         oriented conversational communication.  The CMI interface needs
         to be extended to meet the requirements of agent capability
         invocation and interaction between upper and lower layers.

     2.  Extened MPI: The interface between MDSC and PNC.  Similar to CMI,
         after introducing NMA entities into MDSC and PNC, the original
         MPI also needs to be extended to support agent capability
         invocation and interaction between upper and lower layers.





  Zhao, et al.              Expires 23 April 2026                 [Page 6]


  Internet-Draft         NMA enhanced actn framework          October 2025


     3.  SBI: The interface between PNC and physical network devices,
         which is out of scope of ACTN discussions.

     4.  Interfaces between NMAs and original functional modules at each
         layer: These are internal system interfaces, which can be
         implemented through private interfaces or interface solutions
         such as MCP, and are not within the scope of discussion in this
         document.

     5.  Interfaces between NMAs within same layers: These are internal
         system interfaces that can use private interfaces or general
         agent communication interfaces (e.g., A2A, ACP, etc.), and are
         out of scope of ACTN discussions.

     Since NMAs can be deployed on different controllers within the ACTN
     hierarchy, two possible inter-controller AI-agent communication
     scenarios can be identified.  For example, when there is a need for
     direct communication between NMAs in the upper-layer MDSC and those
     in the lower-layer PNC (A2A Communication), it will manifest as a
     single communication channel physically but multiple communication
     processes logically (i,e.including multiple A2A communication
     processes).

     Figure 1 illustrates these scenarios between the MDSC and PNC (The
     case between the MDSC and CNC is similar and omitted here for
     simplicity).

     As shown in Figure 1(a), when both the MDSC and PNC host AI agents,
     they can communicate directly through agent-to-agent (A2A) protocols
     (or other solutions).  In contrast, when only one controller is
     equipped with an AI agent—as depicted in Figures 1(b) and 1(c)—the
     agent communicates with the other controller, which lacks an agent,
     via the existing ACTN MPI.  For example, in Figure 1(b), the AI agent
     residing on the MDSC uses a RESTCONF client to interact with the PNC
     through MPI calls.
















  Zhao, et al.              Expires 23 April 2026                 [Page 7]


  Internet-Draft         NMA enhanced actn framework          October 2025


  +---------------------+ +----------------------+ +----------------------+
  |         MDSC        | |          MDSC        | |          MDSC        |
  |                     | |          +----------+| |                      |
  |+-----------+   +---+| |+---+  MCP|   other  || |+----------++--------+|
  ||  Other    |MCP|   || ||   | +--->functional|| || Original ||Restconf||
  ||functional <--->NMA|| ||   | |   |  modules || ||functional|| Client ||
  || modules   |   |   || ||NMA<-+   +----------+| ||  modules ||        ||
  |+-----------+   +-^-+| ||   | |   +----------+| |+----------++---^----+|
  |                  |  | ||   | |MCP| Restconf || |                |     |
  |                  |  | |+---+ +--->  Client  || |                |     |
  |                  |  | |          +-----^----+| |                |     |
  +------------------|--+ +----------------|-----+ +----------------|-----+
                     |A2A                  | MPI                    | MPI
  +------------------|--+ +----------------|-----+ +----------------|-----+
  |         PNC      |  | |          PNC   |     | |         PNC    |     |
  |                  |  | |                |     | |          +-----v----+|
  |+-----------+   +-v-+| |+----------++---v----+| |+---+  MCP|   other  ||
  ||   Other   |MCP|   || || Original ||Restconf|| ||   | +--->functional||
  ||functional <--->NMA|| ||functional|| Server || ||   | |   |  modules ||
  ||  modules  |   |   || ||  modules ||        || ||NMA<-+   +----------+|
  |+-----------+   +---+| |+----------++--------+| ||   | |   +----------+|
  |                     | |                      | ||   | |MCP| Restconf ||
  |                     | |                      | |+---+ +--->  Client  ||
  |                     | |                      | |          +----------+|
  +---------------------+ +----------------------+ +----------------------+


      Figure 2: Inter-controller NMA communication scenarios between
                               MDSC and PNC

  4.  Use cases

     The ACTN architecture enhanced by NMA can effectively improve the
     automation and intelligence levels in typical O&M management
     scenarios of optical networks by building agents for different
     scenarios.  Examples of typical application scenarios include:

     1.  Service Provisioning: enable users to describe services in
         natural language and to automate service design, provisioning,
         and deployment processes.

     2.  Service Assurance: ensuring compliance with service-level
         agreements (SLAs), including assisting in risk detection,
         prediction, and decision-making for preemptive actions to prevent
         service degradation.






  Zhao, et al.              Expires 23 April 2026                 [Page 8]


  Internet-Draft         NMA enhanced actn framework          October 2025


     3.  Fault Handling: support anomaly detection, fault localization,
         root cause analysis, and generate fault repair solution to
         accelerate fault resolution and improve network reliability.

  4.1.  Service provisoning

     TBD

  4.2.  Service Assurance

     TBD

  4.3.  Fault Handling

     TBD

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     This document has no requests for IANA action.

  7.  References

  7.1.  Normative References

  7.2.  Informative References

     [I-D.zhao-nmop-network-management-agent]
                Zhao, X., Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and
                J. Zhou, "AI based Network Management Agent(NMA): Concepts
                and Architecture", Work in Progress, Internet-Draft,
                draft-irtf-nmrg-network-digital-twin-arch-09, 17 October
                2025, <https://datatracker.ietf.org/doc/html/draft-irtf-
                nmrg-network-digital-twin-arch-09>.

     [RFC8453]  Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
                Control of TE Networks (ACTN)", RFC 8453,
                DOI 10.17487/RFC8453, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8453>.

  Authors' Addresses







  Zhao, et al.              Expires 23 April 2026                 [Page 9]


  Internet-Draft         NMA enhanced actn framework          October 2025


     Xing Zhao
     CAICT
     Beijing
     China
     Email: zhaoxing@caict.ac.cn


     Henry Yu
     Huawei
     Canada
     Email: henry.yu1@huawei.com


     Yunbin Xu
     CAICT
     China
     Email: xuyunbin@caict.ac.cn


































  Zhao, et al.              Expires 23 April 2026                [Page 10]


name: draft-mzsg-rtgwg-agent-cross-device-comm-framework
rev: 01
title: Cross-device Communication Framework for AI Agents in Network Devices
time: 2026-05-05T07:09:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:03:01Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:40.604249+00:00
source: ietf
abstract:
  With the development of large language models (LLM), AI Agent
     software continues to emerge.  AI agents deployed on different
     network devices need to collaborate to accomplish some complex tasks,
     such as network measurement and network troubleshooting.  This
     collaboration requires cross-device communication between AI agents.

     This document proposes a cross-device communication framework for AI
     agents in network devices, and analyzes the requirements for the
     communication protocol.

full_text:
  Network Working Group                                             J. Mao
  Internet-Draft                                                   G. Zeng
  Intended status: Standards Track                                  B. Liu
  Expires: 5 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                       Huawei Technologies
                                                           1 November 2025


   Cross-device Communication Framework for AI Agents in Network Devices
           draft-mzsg-rtgwg-agent-cross-device-comm-framework-01

  Abstract

     With the development of large language models (LLM), AI Agent
     software continues to emerge.  AI agents deployed on different
     network devices need to collaborate to accomplish some complex tasks,
     such as network measurement and network troubleshooting.  This
     collaboration requires cross-device communication between AI agents.

     This document proposes a cross-device communication framework for AI
     agents in network devices, and analyzes the requirements for the
     communication protocol.

  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 5 May 2026.

  Copyright Notice

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




  Mao, et al.                Expires 5 May 2026                   [Page 1]


  Internet-Draft     Network Device Agent Communication      November 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Framework and Key Components  . . . . . . . . . . . . . . . .   3
     5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Requirements for AI Agent in Network Devices  . . . . . .   6
       5.2.  Requirements for Agent Protocol . . . . . . . . . . . . .   6
       5.3.  Requirements for Security schema  . . . . . . . . . . . .   6
     6.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Using A2A as the communication protocol . . . . . . . . .   7
       6.2.  Using MCP as the communication protocol . . . . . . . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     With the development of large language models (LLM), AI Agent
     software continues to emerge.  They have played a significant role in
     enhancing work and production efficiency.  Deploying AI Agents on
     network devices will be the next beneficial attempt.

     AI agents deployed on different network devices need to collaborate
     to accomplish more complex tasks, especially those that span multiple
     devices and involve network-level operations.  For example, this can
     help us perform better in areas such as network
     measurement[I-D.zeng-mcp-network-measurement] and network
     troubleshooting[I-D.zeng-mcp-troubleshooting].

     This collaboration requires communication between AI agents, so this
     document proposes a cross-device communication framework for AI
     agents in network devices, and analyzes the requirements for the
     communication protocol.




  Mao, et al.                Expires 5 May 2026                   [Page 2]


  Internet-Draft     Network Device Agent Communication      November 2025


     In this framework, the agents that communicate with each other are
     peers, capable of using synchronous and asynchronous communication
     methods, and support both structured and unstructured messages.

  2.  Requirements Language

     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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
     appear in all capitals, as shown here.

  3.  Terminology

     A2A: Agent2Agent Protocol

     MCP: Model Context Protocol

  4.  Framework and Key Components


     The figure below shows the communication framework, including three
     network devices A~C, with some AI agents deployed on each device.




























  Mao, et al.                Expires 5 May 2026                   [Page 3]


  Internet-Draft     Network Device Agent Communication      November 2025


                                                Device B
                                               +-------------------------+
                                               |   +------------------+  |
                                     /---------+-->|Integrated Agent 1|  |
                                     |         |   +------------------+  |
                                     |         |   +------------------+  |
                                     | /-------+-->|Integrated Agent 2|  |
                                     | |       |   +------------------+  |
                                     | |       |                         |
    Device A                         | |       +-------------------------+
   +-------------------------+       | |
   | +-------------------+ --+-------/ |
   | |Communication Agent| --+---------/  communicate using Agent Protocol
   | +++-----------------+ --+-------\
   |  ||  +--------------+   |       |
   |  ||->|Worker Agent 1|   |       |           Device C
   |  |   +--------------+   |       |         +-------------------------+
   |  |   +--------------+   |       |         |   +-------------------+ |
   |  |-->|Worker Agent 2|   |       \---------+-->|Communication Agent| |
   |      +--------------+   |                 |   +++-----------------+ |
   +-------------------------+                 |    ||  +--------------+ |
                                               |    ||->|Worker Agent 1| |
                                               |    |   +--------------+ |
                                               |    |   +--------------+ |
                                               |    |-->|Worker Agent 2| |
                                               |        +--------------+ |
                                               +-------------------------+

  Figure 1: Cross-device Communication Framework for AI Agents in Network Devices

     Agents on network devices are categorized into three types:
     Communication Agent, Worker Agent, and Integrated Agent.

     *  Communication Agent: Responsible for the intelligent agent
        communication of this network device with external systems.  It
        aggregates the capabilities of all local Worker Agents to generate
        the overall capability of the network device for external
        representation.  It receives cross-device access requests from
        Worker Agents and uses the Agent protocol to communicate with
        Communication Agents on other devices.  It also manages
        asynchronous or long-term tasks.










  Mao, et al.                Expires 5 May 2026                   [Page 4]


  Internet-Draft     Network Device Agent Communication      November 2025


     *  Worker Agent: It performs specific functions for a particular set
        of tasks locally, such as network measurement and troubleshooting.
        It does not handle AI agent communication across devices.  Worker
        Agents on different devices do not communicate with each other.
        Within a device, Worker Agents can communicate with each other or
        with the Communication Agent using either the Agent protocol or
        custom methods.  This document does not impose any restrictions on
        the communication methods.

     *  Integrated Agent: Possesses both the functions of Worker Agent and
        Communication Agent.  It has the capability to perform specific
        tasks and communicate with other agents.


     The Communication Agents on each device have a peer relationship with
     each other.  Based on the invocation relationship during a single
     communication, they can be further categorized into two roles: Client
     Agent and Server Agent.

     *  Client Agent: Constructs task requirements into request messages
        and sends them to the Server Agent via the Agent Protocol.  It
        waits for the Server Agent to return a response message.  The task
        result is obtained by parsing the response message, or recording
        the task ID in the response message returned by the Server Agent
        and retrieving the task result from the Server Agent by the task
        ID later.

     *  Server Agent: In terms of capability discovery, it constructs the
        capabilities of AI agents in the device into capability
        negotiation messages and sends them to the Client Agent via the
        Agent Protocol.  For processing task requests, it receives request
        messages from the Client Agent through the Agent Protocol.  For
        short-term tasks, after completing the task, it constructs the
        task result into a response message.  For long-term tasks, it
        generates a task ID and constructs the task ID into a response
        message.  The response message is then sent to the Client Agent
        via the Agent Protocol.  When a long-term task is completed, the
        task result is cached, and the Server Agent waits for the Client
        Agent to retrieve the task result using the task ID.


     The cross-device communication protocol between AI agents in network
     devices is referred as Agent Protocol.








  Mao, et al.                Expires 5 May 2026                   [Page 5]


  Internet-Draft     Network Device Agent Communication      November 2025


     *  Agent Protocol: The communication protocol between agents on two
        devices, which includes functions such as capability discovery and
        negotiation, task assignment and result collection,
        authentication, and secure communication.  For example, emerging
        protocols like A2A or MCP, or mature protocols like NETCONF/YANG,
        can be used.


  5.  Requirements


  5.1.  Requirements for AI Agent in Network Devices

     TBD

  5.2.  Requirements for Agent Protocol


     The communication protocol between AI agents in network devices is
     referred as Agent Protocol.  There are some requirements for it.

     [REQ 2-1a] Agent Protocol MUST support synchronous request/response
     interaction.

     [REQ 2-1b] Agent Protocol SHOULD support streaming interaction for
     better experience in some man-machine interaction scenarios.

     [REQ 2-1c] Agent Protocol MUST support to response task id
     immediately and acquire the result by task id later.

     [REQ 2-1d] Agent Protocol SHOULD support bidirectional interaction
     for the scenarios where Server Agent asks for more information from
     Client Agent.

     [REQ 2-1e] Agent Protocol MUST support to exchange structured
     messages, such as message in JSON or Protobuf format.

     [REQ 2-1f] Agent Protocol SHOULD support to exchange unstructured
     messages, such as natural language.

     [REQ 2-1g] TBD

  5.3.  Requirements for Security schema

     TBD






  Mao, et al.                Expires 5 May 2026                   [Page 6]


  Internet-Draft     Network Device Agent Communication      November 2025


  6.  Illustration


  6.1.  Using A2A as the communication protocol

     TBD

  6.2.  Using MCP as the communication protocol

     TBD

  7.  IANA Considerations

     TBD

  8.  Security Considerations

     TBD


  9.  References

  9.1.  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/info/rfc2119>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

     [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/info/rfc8174>.

  9.2.  Informative References

     [I-D.zeng-mcp-network-measurement]
                Zeng, G. and J. Mao, "MCP-based Network Measurement
                Framework: Using Model Context Protocol for Intelligent
                Network Measurement", Work in Progress, Internet-Draft,
                draft-zeng-mcp-network-measurement-00, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-zeng-mcp-
                network-measurement-00>.




  Mao, et al.                Expires 5 May 2026                   [Page 7]


  Internet-Draft     Network Device Agent Communication      November 2025


     [I-D.zeng-mcp-troubleshooting]
                Zeng, G. and J. Mao, "Using the Model Context Protocol
                (MCP) for Intent-Based Network Troubleshooting
                Automation", Work in Progress, Internet-Draft, draft-zeng-
                mcp-troubleshooting-00, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-zeng-mcp-
                troubleshooting-00>.

  Authors' Addresses

     Jianwei Mao
     Huawei Technologies
     Beijing
     100095
     China
     Email: MaoJianwei@huawei.com


     Guanming Zeng
     Huawei Technologies
     Email: zengguanming@huawei.com


     Bing Liu
     Huawei Technologies
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei Technologies
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei Technologies
     Email: gaoqiangzhou@huawei.com


     Zhenbin Li
     Huawei Technologies
     Email: robinli314@163.com





  Mao, et al.                Expires 5 May 2026                   [Page 8]


