Internet-Draft Agent Network Admission July 2026
Shang, et al. Expires 7 January 2027 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-shang-agent-network-admission-01
Published:
Intended Status:
Informational
Expires:
Authors:
C. Shang
Huawei
W. Jiang
Huawei
X. Liang
Huawei
B. Wang
Beijing University of Posts and Telecommunications
M. Sun
Beijing University of Posts and Telecommunications

Use Cases and Requirements for Network Admission of AI Agent Instances

Abstract

Artificial intelligence (AI) agents increasingly access enterprise resources, external models, tools, and other agents through managed networks. Application-layer authentication can authenticate an agent to a cooperating service, but it cannot by itself provide complete network admission control. In particular, application proofs are normally verified only after network reachability exists, cannot be consumed consistently by heterogeneous or legacy services, and do not reliably identify which Agent Instance originated traffic when multiple Agents share one host, IP address, or egress gateway.

This document describes operational use cases, the resulting problem statement, and requirements for network admission of AI Agent Instances. It focuses on establishing a verifiable and time-bounded binding among an Agent Instance, its credential key, optional runtime evidence, and a Network Context on which the network can enforce reachability policy. This document does not define a new Agent-ID format, authentication protocol, OAuth grant, or routing extension.

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

▲

Table of Contents

1. Introduction

AI agents increasingly perform enterprise tasks without continuous human supervision. They retrieve internal documents, query databases, invoke Model Context Protocol (MCP) servers and Web APIs, call external models, communicate with other Agents, and initiate long or multi-step workflows. These activities ultimately produce network connections that cross access networks, campus fabrics, cloud virtual networks, security gateways, and Internet egress points.

Application-layer mechanisms are necessary but are not sufficient for complete Agent admission control. Workload identity, mutual TLS, signed HTTP messages, OAuth tokens, and proof-of-possession mechanisms can allow a cooperating application peer to authenticate or authorize an Agent. However, these mechanisms normally operate only after the Agent already has a path to the peer. They also require the peer to understand and enforce the Agent identity. This assumption is difficult to satisfy across heterogeneous, legacy, third-party, and non-HTTP services.

For these reasons, part of the control needs to be performed at the network admission layer. The network is the common enforcement point traversed by Agent traffic and can restrict reachability before a specific application accepts a request. Network enforcement does not replace application-layer authorization; it provides an earlier and broader control boundary.

Existing network admission mechanisms, including EAP [RFC3748] and EAP-TLS [RFC5216] [RFC9190], commonly authenticate a device, host, user, or supplicant. The resulting authorization is typically associated with a physical port, wireless association, virtual interface, tunnel, or source address. This granularity is insufficient when several Agent Instances and ordinary applications share the same host and IP address.

The key new problem is therefore not merely how to assign an Agent-ID, but how to authenticate a specific running Agent Instance and bind that result to a Network Context that cannot be reused by another local process. The following use cases illustrate this problem.

Existing mechanisms for workload identity, Agent authentication, application authorization, runtime attestation, and Agent-aware networking may provide credentials, authorization decisions, runtime evidence, or Agent-related context. This document does not replace those mechanisms. It focuses on the distinct deployment question of how an authenticated Agent Instance and its relevant security attributes are bound to a Network Context on which network reachability policy can be enforced, particularly when multiple Agent Instances share a host, source address, or egress gateway.

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

Agent:

Software that performs tasks on behalf of a Principal and may autonomously invoke services, tools, or other agents.

Agent Instance:

A particular running instantiation of Agent software. Two executions of the same image or package are distinct Agent Instances unless continuity is explicitly and securely preserved.

Agent Identifier (Agent-ID):

An identifier for an Agent Instance. An Agent-ID is an assertion, not proof, unless it is cryptographically bound to an authenticated key or credential.

Agent Credential:

A certificate, signed token, workload credential, proof-of-possession credential, or other verifiable object used to authenticate an Agent Instance.

Agent Runtime:

The process, container, virtual machine, trusted execution environment, or other execution context in which an Agent Instance runs.

Network Admission Function (NAF):

The function that verifies Agent admission evidence and decides whether an Agent Binding may be installed.

Enforcement Point (EP):

A network entity that applies reachability or traffic policy based on an Agent Binding.

Agent Binding:

A time-bounded association among an authenticated Agent Instance, the key proved during admission, relevant security attributes, and an enforceable Network Context.

Network Context:

Network-visible or network-controlled state that associates traffic with an Agent Instance, such as a logical interface, virtual port, a trusted namespace-associated interface, overlay identity, anti-spoofed source address, security association, tunnel, connection, or trusted per-Agent gateway context.

Principal:

The user, organization, service, or other entity on whose behalf an Agent acts.

3. Use Cases

3.1. Enterprise Employee Device with Multiple Agents

An employee device may simultaneously run a personal assistant, a coding Agent, an enterprise knowledge Agent, browser automation, and ordinary user applications. Some Agents may be approved by the enterprise, while others may be downloaded by the user or created dynamically by an orchestration framework.

                    Enterprise Network
                           |
                    +------+------+
                    | Access Edge |
                    +------+------+
                           |
                    one device / one IP
                           |
          +----------------+----------------+
          |                                 |
   +------+-------+                  +------+-------+
   | Approved     |                  | Other Local  |
   | Agent A      |                  | Processes    |
   +--------------+                  +--------------+
   +--------------+                  +--------------+
   | Approved     |                  | Unapproved   |
   | Agent B      |                  | Agent C      |
   +--------------+                  +--------------+
Figure 1: Multiple Agents sharing one admitted host

Traditional device admission authenticates the device or user and then associates policy with the shared attachment or source IP address. It cannot determine whether a subsequent connection was created by Agent A, Agent B, Agent C, or an ordinary process. Source ports, process names, and self-asserted headers are controlled by the host and can be copied or reused.

The enterprise needs to grant different reachability to each approved Agent Instance while preventing the unapproved Agent from inheriting the device's network permissions.

3.2. Enterprise Agent Accessing Internal and External Services

An enterprise Agent may retrieve data from an internal knowledge base, call an external large-model service, and invoke a Software as a Service (SaaS) API as part of one task. The internal services may use different authentication technologies, and some legacy services may not understand Agent identities at all.

 +-----------+       +----------------+       +------------------+
 | Agent     |------>| Campus / Cloud |------>| Internal Service |
 | Instance  |       | Network        |       +------------------+
 |           |       | Enforcement    |------>| External Model   |
 +-----------+       +----------------+       +------------------+
                                            ->| SaaS / Web API   |
                                              +------------------+
Figure 2: Agent access across heterogeneous services

Relying only on application-layer authentication requires every destination to understand the Agent credential and to apply consistent policy. This is not realistic for heterogeneous and legacy services. Moreover, the Agent must already have network reachability before the remote service can reject it.

The network therefore needs to restrict which destinations the Agent can reach based on an authenticated Agent Instance, while application-layer authorization continues to restrict operations at cooperating services.

3.3. Multiple Agents behind a Shared Egress Gateway

Enterprises commonly require Agents to access external services through a security gateway, service mesh proxy, or controlled egress gateway. Several Agents may share one public IP address, a gateway connection pool, or even a single multiplexed HTTP/2 or HTTP/3 connection toward the same external service.

 Agent A ----+
 Agent B ----+--> Shared Egress Gateway --> External Service
 Agent C ----+
Figure 3: Multiple Agents behind one egress gateway

The external service may distinguish gateway-originated transport connections, HTTP requests, or multiplexed streams. However, a source port, connection, request, or stream identifies only gateway-maintained forwarding state and does not by itself provide authenticated identity of the originating Agent Instance.

The external service can authenticate the gateway, but gateway authentication alone does not prove which Agent Instance caused a particular request. Reliable attribution requires the gateway to receive or establish trustworthy per-Agent context and to propagate that context using a protected mechanism, such as an Agent-specific credential, token, or signed assertion. If the gateway receives only an unprotected Agent-ID header, one Agent may select another Agent's identity or policy context.

The gateway therefore needs trustworthy per-Agent admission state and isolation among Agent credentials, requests, connections, and policy contexts. When connections are pooled or multiplexed, the gateway must preserve the binding between each request and the originating Agent Instance. The local network also needs to prevent an Agent from bypassing the gateway through another path.

3.4. Dynamically Created and Short-Lived Agents

An orchestration platform may create an Agent for a single task, create sub-Agents, restart an Agent after failure, migrate it to another runtime, or terminate it within minutes. The host and its device-level admission session may remain active for days.

A device-level network session therefore outlives many Agent Instances. A new Agent execution must not automatically inherit the admission state of a previous execution merely because it uses the same image, host, or IP address. Admission state needs an Agent-specific lifetime and must be removed when the Agent terminates, migrates, or becomes non-compliant.

3.5. Agent-to-Agent Collaboration in a Managed Network

A group of Agents may collaborate on one enterprise task. For example, a planning Agent invokes a retrieval Agent, which then invokes a data-analysis Agent. The Agents may run on the same host, on different enterprise hosts, or across branch and cloud networks.

The network may need to permit only an approved collaboration graph and deny unrelated Agent-to-Agent reachability. Device identity is too coarse when multiple Agents share an endpoint, and application authentication alone does not stop unauthorized network scanning, connection attempts, or bypass paths before the application protocol is reached.

4. Problem Statement

4.1. Network Enforcement Is Required but Lacks Agent Granularity

Application-layer authentication answers whether a cooperating service accepts an Agent credential. Network admission answers whether an Agent Instance should receive reachability to a destination or network segment. These are complementary controls.

Application-layer mechanisms cannot fully provide network admission because:

  • they are usually evaluated only after a network path is available;

  • they require every destination to understand the Agent identity;

  • they cannot consistently cover legacy, third-party, and non-HTTP services;

  • they do not prevent connection attempts, scanning, or bypass paths; and

  • their result is not automatically available to switches, virtual switches, routers, or security gateways that enforce reachability.

Network-layer enforcement is therefore needed as a common pre-service control point. However, existing network admission commonly associates identity with a device, user, interface, tunnel, or IP address rather than a specific Agent Instance.

4.2. One IP Address Can Represent Multiple Security Subjects

A single IP address may simultaneously carry traffic from multiple approved Agents, unapproved Agents, ordinary applications, and the user. Therefore:

       one source IP address
               |
       +-------+-------+-------+
       |               |       |
   Agent A         Agent B   Other Process

The following implications hold:

  • successful device authentication does not authenticate every Agent;

  • a source IP address is not an Agent identity;

  • a transport source port is not a stable or trustworthy Agent identity;

  • an Agent-ID in a host-controlled header is not sufficient proof; and

  • application credentials do not by themselves bind all surrounding traffic to the process that owns the credential.

Different admission policies for multiple Agents sharing one IP address therefore require an additional trusted per-Agent Network Context.

4.3. Agent Identity Does Not Automatically Provide Traffic Attribution

Existing Agent identity and workload identity work can define who the Agent is and how it proves possession of a credential key. Existing OAuth work can define what the Agent is authorized to do at a Resource Server. Existing attestation work can provide evidence about the runtime.

None of these functions alone establishes which packets, connections, or flows at a local network EP belong to the authenticated Agent Instance. The missing function is a verifiable binding:

 Authenticated Agent Instance
              +
 Credential-Key Possession
              +
 Optional Runtime Evidence
              +
 Enforceable Network Context
              =
       Agent Binding

The Network Context must be controlled or protected such that another local process cannot simply reuse it. Examples may include a per-Agent namespace, virtual port, tunnel, security association, anti-spoofed address, or trusted gateway context.

4.4. Admission Must Precede General Reachability

An Agent requires limited connectivity to identity, credential, attestation, and remediation services in order to complete admission. It should not receive unrestricted enterprise or Internet reachability before that process finishes.

A deployment therefore needs a constrained pre-admission state and a controlled transition to Agent-specific reachability after the Agent Binding is installed.

4.5. Agent Lifecycle and Network Lifecycle Are Different

Agent Instances may be created, restarted, cloned, suspended, migrated, or terminated independently of the host network session. A static device or IP binding can therefore become stale and may unintentionally authorize a new Agent execution.

Agent admission state must have an independent lifetime and explicit renewal, revocation, migration, and termination behavior.

5. Requirement Summary

Based on the preceding use cases and problem statement, an Agent network admission architecture has the following core requirements.

5.1. Agent Instance Authentication

The architecture MUST authenticate a particular Agent Instance, or an explicitly defined instance-continuity domain, using a credential bound to a cryptographic key or equivalent proof mechanism. The Agent Instance MUST prove possession of that key with freshness protection.

Authentication of only a user, device, host, image, Agent software class, or orchestration platform MUST NOT be treated as authentication of every Agent Instance running there. Self-asserted identifiers, process names, source ports, or unprotected application headers MUST NOT be sufficient for admission.

5.2. Binding Identity to Enforceable Traffic

A successful authentication result MUST be bound to a Network Context on which an EP can enforce policy. The binding MUST identify which traffic is covered and MUST be protected against reuse by another local process.

When multiple Agents share a host, interface, source address, or gateway, the deployment MUST provide a trusted means to distinguish their traffic. A source address MAY be used only when address ownership and anti-spoofing are enforced at the relevant attachment.

5.3. Shared-Gateway Attribution

A gateway serving multiple Agents MUST authenticate, or receive authenticated context for, each originating Agent Instance. It MUST isolate per-Agent credentials and policy state and prevent one Agent from selecting or reusing another Agent's context.

When connections are pooled or multiplexed, the gateway MUST preserve the binding between each request and the originating Agent Instance. Gateway authentication alone MUST NOT be represented as proof of the originating Agent unless that binding is securely preserved and conveyed to the remote peer through a protected mechanism.

5.4. Admission, Lifetime, and Revocation

Before admission completes, an Agent Instance SHOULD have only the minimum connectivity required for identity, credential, attestation, remediation, and admission services. General reachability SHOULD be denied until an Agent Binding is installed.

Every Agent Binding MUST have a finite lifetime. A restart, clone, or migration MUST NOT automatically inherit an old binding unless continuity is explicitly proven. The deployment MUST support renewal and prompt removal of the binding when the Agent terminates, its credential is revoked, its runtime becomes non-compliant, its attachment changes, or policy requires withdrawal.

5.5. Non-Bypassability and Layered Authorization

The topology and enforcement configuration MUST prevent Agent traffic from bypassing the EP through alternate interfaces, direct underlay access, unprotected gateways, or other paths.

Successful network admission establishes authenticated and constrained reachability; it MUST NOT imply unrestricted application authority. The Principal identity and Agent-ID MUST remain distinguishable, and an Agent MUST NOT automatically inherit all reachability or authority of its Principal.

5.6. Evidence, Audit, and Privacy

When runtime or platform evidence is used, it MUST be bound to the same Agent Instance key and admission context. The NAF and EP SHOULD record the Agent Instance, verified credential, installed Network Context, and binding lifecycle events.

Deployments SHOULD minimize disclosure and retention of Principal identity, Agent identifiers, and runtime measurements, and SHOULD use short-lived or locally scoped identifiers where appropriate.

6. Functional Model 

+--------------------+       +-------------------------+
| Agent Instance     |       | Identity / Attestation  |
|                    |       | Services                |
| instance key       |       +------------+------------+
+---------+----------+                    |
          | admission proof               | validation data
          v                               v
+---------+-------------------------------------------+
| Network Admission Function                         |
| verifies credential, possession, freshness,       |
| optional runtime evidence, and policy              |
+--------------------------+--------------------------+
                           | install Agent Binding
                           v
+--------------------------+--------------------------+
| Network Enforcement Point                          |
| Agent-ID / key / attributes -> Network Context     |
+--------------------------+--------------------------+
                           |
                    admitted traffic
                           v
                    Network Resources
Figure 4: Agent Instance network-admission model

A deployment MAY distribute these functions across an endpoint component, network device, controller, and gateway. The security property depends on the integrity of the complete path from the authenticated Agent key to the Network Context, not on the physical location of one component.

7. Security Considerations

The primary security failure is a false association between an authenticated Agent-ID and traffic generated by another entity. Implementations need to protect both the cryptographic proof and the local mechanism that creates and uses the Agent Binding.

Bearer credentials are insufficient when they can be copied to another process or host. Proof-of-possession credentials reduce this risk only when the private key is protected and the proof is bound to the admission session and Network Context.

Runtime attestation does not replace Agent Instance authentication. Agent Instance authentication does not by itself prove that the runtime is trustworthy. Deployments requiring both properties need an explicit binding among the runtime evidence, Agent Instance key, and Network Context.

A trusted gateway can preserve Agent attribution across a second connection, but it becomes a high-value security boundary. It needs per-Agent isolation, protected binding state, anti-replay protection, and clear behavior when either side of the communication is re-established. Connection pooling and HTTP/2 or HTTP/3 multiplexing must not cause requests from different Agent Instances to inherit or reuse the wrong Agent context.

8. Privacy Considerations

Agent admission can expose relationships among a Principal, an Agent Instance, a device, a runtime, and its destinations. Stable Agent-IDs may permit tracking across tasks or administrative domains. Deployments should minimize identifier scope and retention, disclose only attributes required by policy, and avoid unnecessary export of runtime evidence.

9. IANA Considerations

This document makes no requests of IANA.

10. Acknowledgements

The authors thank participants in the IETF Agent identity, WIMSE, RATS, OAuth, and Agent-aware networking discussions whose work helped clarify the boundary between application authentication and network admission.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

11.2. Informative References

[RFC3748]
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, , <https://www.rfc-editor.org/info/rfc3748>.
[RFC5216]
Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, , <https://www.rfc-editor.org/info/rfc5216>.
[RFC9190]
Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, , <https://www.rfc-editor.org/info/rfc9190>.

Authors' Addresses

Chao Shang
Huawei
Weiyu Jiang
Huawei
Liang Xia
Huawei
Bizhu Wang
Beijing University of Posts and Telecommunications
Mengying Sun
Beijing University of Posts and Telecommunications