Network Trust Framework for AI Agents

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 when, and only when, they appear in all capitals, as shown here.

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.

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

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

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.

Design Goals Network-layer trust enhancement for agent communication has the following design goals.

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.

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.

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.

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 , but prefix-origin validation alone does not prove agent identity. Agent trust requires additional certificate, credential, authorization, signature, or hub-mediated validation.

Network Control Plane The network control plane translates verified agent context and task risk into executable network policy. It may use IPv6 reachability , SRv6 path steering , 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.

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.

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

Example Communication Flow A typical flow using the framework can be described as follows.

The caller agent discovers a target agent through DNS, an agent directory, an agent card, MCP metadata, an industry registry, or an enterprise catalog.
The caller sends the request through a local Agent Interconnection Hub.
The discovery adaptation plane parses the discovery result and extracts the minimum information needed for policy processing.
The trust verification plane verifies the caller, callee, authorization state, credential status, and task risk.
The hub creates a trusted transport tag or refers to an existing policy index.
The network control plane selects an appropriate path, gateway, service chain, or SRv6 policy according to task requirements.
The destination-side hub verifies the tag, signature, authorization, and policy compatibility before delivering the request to the target agent or service.
The source-side hub, destination-side hub, and any required intermediate trust nodes create audit records using a common audit index.
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.

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.

Open Issues for Future Work This document intentionally leaves several topics for future work.

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.

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.

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.

IANA Considerations This document does not request any IANA action.