Internet Engineering Task Force H. Yu Internet-Draft China Internet Network Information Center Intended status: Informational 29 June 2026 Expires: 31 December 2026 Network Trust Framework for AI Agents draft-yu-network-trust-framework-for-ai-agents-00 Abstract AI agents are expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Existing agent mechanisms mainly focus on application-layer discovery, capability description, identity, authorization, tool invocation, and agent-to-agent collaboration. These mechanisms are important, but they often treat the IP network as a transparent connectivity substrate. This document describes a framework for using network-layer and network-control capabilities to enhance trust for AI agent communication after agent discovery. The framework introduces an Agent Interconnection Hub, trusted transport tags, policy-driven path selection, and audit indexing as building blocks for recognizable identity, accountable paths, enforceable policy, and traceable invocation records. This document does not define a new agent discovery protocol, a new application-layer agent collaboration protocol, a new authentication or authorization mechanism, a new IPv6 extension header, or a new SRv6 behavior. It provides architectural considerations and requirements for future work. 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." Yu Expires 31 December 2026 [Page 1] Internet-Draft AI Agent Network Trust June 2026 This Internet-Draft will expire on 31 December 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. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Architectural Components . . . . . . . . . . . . . . . . . . 6 7.1. Discovery Adaptation Plane . . . . . . . . . . . . . . . 6 7.2. Trust Verification Plane . . . . . . . . . . . . . . . . 7 7.3. Network Control Plane . . . . . . . . . . . . . . . . . . 7 7.4. Audit Governance Plane . . . . . . . . . . . . . . . . . 7 8. Trusted Transport Tags . . . . . . . . . . . . . . . . . . . 7 9. Example Communication Flow . . . . . . . . . . . . . . . . . 8 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 11. Open Issues for Future Work . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 15. Normative References . . . . . . . . . . . . . . . . . . . . 11 16. Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Yu Expires 31 December 2026 [Page 2] Internet-Draft AI Agent Network Trust June 2026 2. Introduction AI agents are moving from isolated application components toward large-scale, cross-domain collaboration. An agent may discover other agents, invoke tools, access data, call APIs, and perform tasks on behalf of a user, organization, or system. When these actions become continuous, autonomous, and cross-domain, agent communication becomes not only an application-layer issue but also an Internet infrastructure issue. Application-layer mechanisms such as agent cards, tool metadata, directory services, DNS-based discovery, decentralized identifiers, certificates, authorization tokens, and agent collaboration protocols can help an agent find a peer and determine what it can do. However, after discovery, the communication still traverses networks that may only observe IP addresses, transport connections, and limited metadata. The network may not be able to associate a flow with the responsible agent, the delegated authority, the task risk, the intended path, or the audit obligation. This document explores how network-layer and network-control capabilities can enhance trust for agent communication without replacing existing application-layer mechanisms. The goal is to make discovered agents not only reachable, but also more trustworthy, path-accountable, policy-enforceable, and auditable. 3. Scope and Non-Goals This document focuses on a framework for network-layer trust enhancement for AI agent communication. It discusses how identity verification results, task risk, network policy, path selection, and audit indexing may be associated after agent discovery. This document discusses: * an Agent Interconnection Hub as a trusted mediation point between application-layer discovery and network forwarding; * trusted transport tags that bind a communication task to minimum necessary trust and policy metadata; * policy-driven path selection using existing IPv6, SRv6, gateway, security-service, and network-management capabilities; * audit indexing across source-side, destination-side, and intermediate trust points; Yu Expires 31 December 2026 [Page 3] Internet-Draft AI Agent Network Trust June 2026 * privacy-aware minimization of information exposed to network nodes. This document does not define: * a new agent discovery protocol; * a new application-layer agent collaboration protocol; * a new authentication, authorization, delegation, or attestation protocol; * a replacement for DNS, HTTPS, OAuth, OIDC, DID, VC, WIMSE, RATS, SCITT, A2A, MCP, RDAP, or audit frameworks; * a requirement that ordinary Internet routers understand prompts, tasks, agent semantics, or application payloads; * a new IPv6 extension header, SRv6 behavior, or packet encoding; * a mandatory global registry or a single root node for all agents. 4. Terminology Agent: A software entity that can perceive context, reason, plan, invoke tools, communicate with other agents, and perform tasks on behalf of a user, organization, or system. Agent Communication: Communication initiated by, received by, or mediated for an agent, including tool calls, API calls, data access, agent-to-agent calls, and gateway-mediated interactions. Agent Interconnection Hub: A trusted mediation point between application-layer discovery systems and the network. It performs discovery adaptation, trust verification, network policy generation, path selection, and audit indexing. Trusted Transport Tag: A signed or integrity-protected structure associated with an agent communication task. It carries minimum necessary metadata such as identity digests, task type, risk level, network service requirement, audit level, validity period, and revocation pointer. Yu Expires 31 December 2026 [Page 4] Internet-Draft AI Agent Network Trust June 2026 Network-Layer Trust Enhancement: The use of network-layer or network-control capabilities, such as locator binding, policy tags, path selection, service chaining, verification records, and audit indexes, to improve the trustworthiness, controllability, and traceability of agent communication. Agent Domain: An administrative or operational domain in which agents, gateways, registries, policy systems, audit systems, or network functions are managed under a common authority. 5. Motivation Current agent interconnection mechanisms are largely developed at the application layer. They can describe capabilities, publish endpoints, exchange credentials, call tools, and coordinate agent-to- agent tasks. These functions are necessary, but they do not by themselves provide all of the network-layer support required by high- value or high-sensitivity agent communication. Three gaps are particularly relevant. * Agent identity and network reachability are weakly associated. A network path may carry a flow without knowing whether the source or destination is authorized to represent a particular agent. * Agent tasks and transport paths are weakly associated. Low-risk queries, financial operations, government workflows, industrial control tasks, and security operations may require different latency, path, inspection, and audit properties. * Agent operation logs and network evidence are weakly associated. Application logs, gateway logs, platform records, and network telemetry may not share a common audit index. These gaps make it difficult to answer operational questions such as which agent initiated a call, under which authority, for what type of task, through which path, under which network policy, and with what verification result. A network-layer trust enhancement framework attempts to provide a coherent way to relate these questions without requiring the network to inspect application payloads. 6. Design Goals Network-layer trust enhancement for agent communication has the following design goals. Yu Expires 31 December 2026 [Page 5] Internet-Draft AI Agent Network Trust June 2026 Recognizable identity: The network-control environment can associate a communication task with identity digests, authorization status, and trust state without exposing unnecessary identity details. Accountable paths: The network-control environment can select paths according to task risk, data sensitivity, latency, jurisdiction, and audit requirements. Enforceable policy: Application-layer task context can be translated into network- executable policy for gateways, service chains, path controllers, or security functions. Traceable audit: Source-side, destination-side, and necessary intermediate nodes can produce audit records that share a common index. Privacy-aware operation: Network nodes receive only the information needed for routing, policy matching, enforcement, and audit indexing. Incremental deployment: The framework reuses existing Internet, IPv6, SRv6, certificate, credential, gateway, and audit mechanisms where possible. 7. Architectural Components This framework is organized into four logical planes. A deployment may combine these functions in a single gateway, distribute them across multiple nodes, or integrate them with existing operator, enterprise, or industry infrastructure. 7.1. Discovery Adaptation Plane The discovery adaptation plane interfaces with existing discovery and capability-description mechanisms, such as DNS records, service- binding metadata, agent cards, MCP server metadata, DID documents, industry registries, enterprise catalogs, or platform directories. This plane normalizes discovery results into a common access description that can include the target entry point, supported capabilities, access conditions, security requirements, and minimum information needed by the trust-verification and network-control planes. Yu Expires 31 December 2026 [Page 6] Internet-Draft AI Agent Network Trust June 2026 7.2. Trust Verification Plane The trust verification plane verifies agent identity, responsible entity, authorization, credential state, and task risk. It may use agent identity credentials, domain certificates, DID/VC material, platform signatures, enterprise authorization, API tokens, gateway certificates, and session signatures. RPKI and ROA can be used to validate the origin of an IPv6 prefix [RFC6480], but prefix-origin validation alone does not prove agent identity. Agent trust requires additional certificate, credential, authorization, signature, or hub-mediated validation. 7.3. Network Control Plane The network control plane translates verified agent context and task risk into executable network policy. It may use IPv6 reachability [RFC8200], SRv6 path steering [RFC8986], gateway selection, service chaining, application-aware networking, security inspection points, or network-management interfaces. Example policies include best-effort forwarding for low-risk tasks, trusted paths for government or financial tasks, mandatory security inspection for sensitive data access, audit-node traversal for cross- domain tasks, and explicit low-latency paths for time-sensitive operations. 7.4. Audit Governance Plane The audit governance plane creates and correlates audit records for agent communication. It records structured evidence such as caller and callee identity digests, task type, policy identifier, trusted transport tag digest, verification result, path policy, important transit nodes, timestamp, and exception state. The audit governance plane is not intended to record application plaintext by default. Recording prompts, tool inputs, tool outputs, or user data can significantly increase privacy risk and needs separate authorization and legal basis where applicable. 8. Trusted Transport Tags A trusted transport tag is a framework concept for associating an agent communication task with trust and policy metadata. This document does not specify a wire format. Future work could define a format, or deployments could use existing token, certificate, attestation, gateway, or controller mechanisms. Yu Expires 31 December 2026 [Page 7] Internet-Draft AI Agent Network Trust June 2026 A trusted transport tag can include: * a digest of the caller agent identity; * a digest of the callee agent identity or gateway identity; * the task type or policy class; * the risk level and audit level; * network service requirements, such as latency, reliability, inspection, or path constraints; * a validity period and scope; * a signature or integrity-protection value; * a revocation or status pointer. A trusted transport tag should be designed for minimization. It should not directly expose full user identity, full organization identity, prompts, business content, or sensitive credentials to arbitrary intermediate nodes. 9. Example Communication Flow A typical flow using the framework can be described as follows. 1. The caller agent discovers a target agent through DNS, an agent directory, an agent card, MCP metadata, an industry registry, or an enterprise catalog. 2. The caller sends the request through a local Agent Interconnection Hub. 3. The discovery adaptation plane parses the discovery result and extracts the minimum information needed for policy processing. 4. The trust verification plane verifies the caller, callee, authorization state, credential status, and task risk. 5. The hub creates a trusted transport tag or refers to an existing policy index. 6. The network control plane selects an appropriate path, gateway, service chain, or SRv6 policy according to task requirements. Yu Expires 31 December 2026 [Page 8] Internet-Draft AI Agent Network Trust June 2026 7. The destination-side hub verifies the tag, signature, authorization, and policy compatibility before delivering the request to the target agent or service. 8. The source-side hub, destination-side hub, and any required intermediate trust nodes create audit records using a common audit index. 9. If verification fails or risk changes, the system can revoke the tag, block the request, reroute the flow, reduce privileges, or generate an alert. This flow is illustrative. It does not require every deployment to use the same hub topology or the same path-control mechanism. 10. Deployment Considerations The framework is intended for incremental and distributed deployment. It is not necessary or desirable to require all public Internet agent traffic to pass through a single mandatory control point. Initial deployment is more likely in high-value or high-sensitivity environments where identity, authorization, path control, audit, and accountability requirements are explicit. Candidate deployment environments include: * government agent collaboration across departments; * financial agent workflows involving risk management or compliance checks; * industrial Internet and energy-control environments; * cross-cloud agent invocation and enterprise agent gateways; * network-security automation and response systems; * regional or industry testbeds based on IPv6 and SRv6. Agent Interconnection Hubs can be deployed as enterprise gateways, operator edge nodes, industry trust nodes, regional exchange points, or cross-domain mediation nodes. Different deployments may implement different subsets of the logical planes described in this document. 11. Open Issues for Future Work This document intentionally leaves several topics for future work. Yu Expires 31 December 2026 [Page 9] Internet-Draft AI Agent Network Trust June 2026 * whether a common trusted transport tag format is needed; * how tags should be carried, referenced, protected, and revoked; * how application-layer agent identity should be mapped to IPv6 locators or Agent Gateways; * how cross-domain policy conflicts should be detected and resolved; * which minimum audit record format is sufficient for cross-domain reconstruction; * how to prevent trusted metadata from becoming a new privacy or surveillance surface; * how this framework should relate to existing work on workload identity, attestation, supply-chain transparency, and secure telemetry. 12. Security Considerations Agent communication can involve delegated authority, tool invocation, data retrieval, cross-domain access, and autonomous decision-making. Weak linkage among agent identity, network flows, authorization decisions, and audit evidence can make impersonation, misuse, excessive privilege, and incident reconstruction more difficult to manage. A trusted transport tag or equivalent policy object can itself become an attack target. Implementations need to consider integrity protection, authentication of tag issuers, replay protection, scope limitation, expiration, revocation, downgrade attacks, substitution attacks, and confused-deputy risks. Agent Interconnection Hubs are security-sensitive components. If a hub is compromised, an attacker might issue false trust metadata, suppress audit records, reroute flows, or authorize unintended communication. Deployments need operational controls, key management, monitoring, least-privilege administration, and fail-safe behavior. This document does not define a new protocol mechanism. Any future protocol work derived from this framework will need protocol-specific security analysis. Yu Expires 31 December 2026 [Page 10] Internet-Draft AI Agent Network Trust June 2026 13. Privacy Considerations Agent communication can reveal sensitive information about users, organizations, tasks, data sources, tools, models, policies, and business relationships. Trust metadata and audit records can also become sensitive, even when application content is encrypted. Deployments should minimize what is exposed to network nodes. Full identity, business content, prompts, tool inputs, tool outputs, and detailed reasoning traces should not be included in network-visible metadata by default. Identity digests, policy classes, short-lived tags, and audit indexes can reduce exposure, but they can still be linkable if reused too broadly. Audit designs need to balance traceability and minimization. More complete logs can improve accountability, but can also create new data stores and new privacy risks. Access to audit records should be controlled and logged. 14. IANA Considerations This document does not request any IANA action. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16. Informative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Yu Expires 31 December 2026 [Page 11] Internet-Draft AI Agent Network Trust June 2026 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [I-D.yu-ai-agent-ipv6-networking-considerations] Yu, H., "IPv6 Networking Considerations for AI Agent Communication", . [I-D.pioli-agent-discovery] Pioli, L., "Agent Registration and Discovery Protocol", . [Agent2Agent-Archive] IETF, "IETF Agent2Agent Mailing List Archive", . Author's Address Haisheng Yu China Internet Network Information Center Email: yuhaisheng@cnnic.cn Yu Expires 31 December 2026 [Page 12]