Use Cases and Requirements for Network Admission of AI Agent Instances

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 and EAP-TLS , 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.

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

Use Cases

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.

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.

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 access across heterogeneous services | Campus / Cloud |------>| Internal Service | | Instance | | Network | +------------------+ | | | Enforcement |------>| External Model | +-----------+ +----------------+ +------------------+ ->| SaaS / Web API | +------------------+ ]]> 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.

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.

Multiple Agents behind one egress gateway Shared Egress Gateway --> External Service Agent C ----+ ]]> 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.

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.

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.

Problem Statement

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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

Functional Model

Agent Instance network-admission model Network Context | +--------------------------+--------------------------+ | admitted traffic v Network Resources ]]> 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.

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.

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.

IANA Considerations This document makes no requests of IANA.

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.