| Internet-Draft | AI Agent Network Trust | June 2026 |
| Yu | Expires 31 December 2026 | [Page] |
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.¶
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 31 December 2026.¶
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.¶
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 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.¶
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:¶
This document does not define:¶
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.¶
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.¶
Network-layer trust enhancement for agent communication has the following design goals.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
A trusted transport tag can include:¶
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.¶
A typical flow using the framework can be described as follows.¶
This flow is illustrative. It does not require every deployment to use the same hub topology or the same path-control mechanism.¶
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:¶
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.¶
This document intentionally leaves several topics for future work.¶
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.¶
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.¶
This document does not request any IANA action.¶