Network / Egress Restrictions

Security Objective

Network and egress restrictions constrain which destinations, protocols, ports and network paths agentic components, tools, sandboxes and workloads can reach, regardless of what the model intends. Model influence must not be able to create arbitrary network reach.

Outbound connectivity for protected agent workloads should be deny by default, brokered through enforceable boundaries and limited to explicitly configured destinations and protocols.

Ownership Boundaries

Egress is not data loss prevention. It decides where traffic can go, not what the traffic may contain.

Threat Model

Influenced model behavior, from direct input, web content, tool output or a sub-agent result, may propose a request to a destination the task never needed: an external upload host, an internal administration plane or an infrastructure service. The concern is that the runtime can actually reach it.

A blocked destination does not prove malicious intent. It only proves the attempted path was outside current network policy.

Reachability Is a Separate Permission

Having a tool, or having a tool call authorized, does not imply that arbitrary outbound sockets or arbitrary URLs are allowed. Reachability is granted per workload, destination identity, protocol and port, and is checked where connections are made.

Deny-by-Default Egress

For protected agent workloads, outbound traffic is denied unless an explicit, scoped, reviewable exception allows it. NIST SP 800-53 Rev. 5 control enhancement SC-7(5) describes denying network traffic by default and allowing by exception at managed interfaces; this page applies that general principle to agent workloads.

Fail closed when destination identity cannot be resolved or policy cannot be evaluated in protected workflows.

Authoritative Destination Facts

The authoritative destination comes from fully parsed and resolved application-side connection facts: scheme, canonical host or service identity, resolved address and network class, port and, where a gateway enforces it, path template or API operation.

Trust Model

URLs returned by tools, retrieved documents, webpages, messages or sub-agents remain variable content. They never become reachable merely because a trusted connector returned them.

Destination Classes and Service Identities

Classify destinations: approved first-party services, approved third-party services, internal sensitive services, infrastructure-only networks and unknown. Policies refer to classes and exact service identities, not to whatever string appears in a request.

Unknown or unclassifiable destinations are denied in protected workflows.

Application-Owned Service IDs vs Arbitrary URLs

Generic model-controlled URL fetchers are high risk: they turn any string in context into a potential destination. Prefer application-owned service identifiers, such as inventory-read, mapped to fixed hosts and bounded endpoint templates. The model selects a service ID and parameters; the application builds the connection.

URL Parsing and Canonicalization

Parse URLs with a maintained library, canonicalize host and port, and compare the parsed result against policy. Regex-only validation on the raw string is fragile. Evaluate the same parsed representation the client will actually use, at the final connection point rather than only in UI or input validation.

DNS Resolution and Rebinding-Resistant Enforcement

DNS resolution must not silently widen reach. A name that was checked once can later resolve to a different address, including an internal or infrastructure address. Enforce policy on the actual resolved destination and network class, ideally in a controlled resolver, proxy or gateway that both resolves and connects, so the checked address is the connected address.

The OWASP SSRF Prevention Cheat Sheet discusses this destination-confusion risk and recommends validating all resolved addresses. Re-evaluate when resolution changes meaningfully.

Redirect Re-Evaluation

Every redirect is a new destination decision. An initially allowed URL must not transitively authorize a later host. Either disable automatic redirects in clients that do not need them, or re-run the full parse, resolve and policy check for each hop and record REDIRECT_DESTINATION_DENIED when a hop fails.

Protocol and Port Restrictions

Restrict protocols and ports, not only hostnames. A destination allowed for HTTPS on 443 does not imply arbitrary TCP or UDP, alternate ports or other protocols. Deny with PROTOCOL_NOT_ALLOWED or PORT_NOT_ALLOWED.

TLS and Server Identity

TLS and server identity validation stay mandatory on allowed paths. Egress policy must never turn certificate validation off, and an identity mismatch is reported as TLS_IDENTITY_MISMATCH rather than silently accepted. Where a gateway terminates TLS, it takes over validation toward the destination.

Internal and East-West Reach

Egress applies at the agent or workload boundary, not only toward the public internet. Internal is not automatically trusted or reachable. Administration planes, sensitive databases, management networks and other east-west services the workload does not need should be unreachable from it.

Loopback, Link-Local, Metadata and Management Planes

Block or segregate destination classes such as loopback and local services, link-local ranges including cloud metadata services, private management ranges and other infrastructure-only networks unless a workload explicitly needs them. Deny with NETWORK_CLASS_DENIED. These classes often hold credentials or control functions the agent should never touch.

Brokered Egress Architecture

Route outbound traffic from protected workloads through an enforcement point that resolves, decides, connects and logs. Options include an egress proxy or gateway, a service mesh or sidecar, host or container network policy, cloud firewall or security policy, or an application gateway. The property matters, not the product: one attributable decision per connection, enforced where the connection is made.

Preventing Direct-Socket Bypass

Agent runtimes should not have an unrestricted direct-socket path around the brokered control. Block direct outbound traffic at the host, container or network layer so the broker is the only route, and alert on DIRECT_EGRESS_BYPASS attempts. Where direct access is intentionally needed, scope it explicitly.

Per-Tool and Per-Workload Egress Policies

Give each tool or workload its own policy tied to its identity, so a document fetcher, an inventory reader and a notification sender do not share one broad allowlist. Every decision should be attributable to the workload, tool or service identity and, where possible, to task, run and call IDs.

Webhooks, Callbacks and Tool-Supplied Destinations

Webhook targets, callback URLs and destinations supplied in tool output or API responses are still destinations. They remain variable content and go through the same parse, resolve and policy steps before use.

Relationship to Information Flow Control

Information flow control decides what data may traverse a path; egress decides whether the path exists. NIST SP 800-53 AC-4 addresses information flow enforcement generally and is cited here only to mark that boundary. Each control can deny independently.

Relationship to Agent Authorization

Agent authorization decides whether a fully resolved action may execute. An authorized send still fails if the destination is unreachable, and a reachable destination does not make an action authorized.

Relationship to Least Privilege

Least privilege decides which tools, credentials and network capabilities a workload has at all. Egress restrictions enforce the network part of that budget at connection time, so a capability that was never granted cannot be exercised by influenced behavior.

Relationship to Tool-Chain Analysis

Tool-chain analysis may identify a sequence that introduces a new destination. Egress restrictions make the actual reachability decision at the network boundary. A chain finding never opens a path, and an allowed path never clears a chain finding.

Policy Decision and Enforcement Points

The allow or deny decision is deterministic. A model-assisted classifier is not the egress decision point; semantic risk signals may inform a separate response policy but never grant reach. Response and telemetry can record, alert, restrict or pause, and network exceptions are never granted dynamically by model output.

Keep reachability, authorization, flow classification, provenance, chain findings and execution evidence separate. No blended trust score.

Telemetry and Reason Codes

Example reason codes, as engineering guidance: DESTINATION_NOT_ALLOWED, PROTOCOL_NOT_ALLOWED, PORT_NOT_ALLOWED, NETWORK_CLASS_DENIED, REDIRECT_DESTINATION_DENIED, DESTINATION_UNRESOLVED, DIRECT_EGRESS_BYPASS, TLS_IDENTITY_MISMATCH and POLICY_EXCEPTION_USED. Correlate broker and workload logs by task, run and call ID.

Exceptions and Change Control

Exceptions are short lived and carry an owner, reason, exact scope and expiry. Broad permanent wildcards are not a default. Keep policy as reviewable, versioned configuration. Separate development and production policies without opening production for convenience. Domain-only and IP-only lists both have limits: shared CDN addresses make static IP lists brittle, and wildcards or user-controlled subdomains make broad hostname lists risky. Prefer exact service identity plus controlled resolution.

Worked Scenario A: Allowed First-Party Service

A tool needs read-only HTTPS access to inventory-api.internal.example.test:443, represented by service ID inventory-read. Egress policy allows that exact service and path class for this workload. The connection may proceed at the network layer.

This only grants network reach. Action authorization and information flow control still run separately.

Worked Scenario B: External Upload Destination Denied

Influenced model behavior proposes sending a file to upload.outside.example.test. No approved service identity matches, so reach is denied with DESTINATION_NOT_ALLOWED. If the request was only proposed, no connection was attempted and no exfiltration attempt is claimed.

Worked Scenario C: Redirect to an Unapproved Destination Denied

A request to docs.internal.example.test is allowed. The response redirects to collector.outside.example.test. The redirect hop is a fresh destination decision and is denied with REDIRECT_DESTINATION_DENIED. The original allow decision does not carry over.

Worked Scenario D: Internal Management Destination and Callback Denied

The workload proposes reaching admin.internal.example.test, an internal administration destination not in its policy. It is denied with NETWORK_CLASS_DENIED even though it is internal.

Separately, a tool response supplies a callback URL at hooks.partner.example.test. The URL is variable content; it is resolved against policy, has no approved identity for this workload and is denied before use.

What the Scenarios Prove and Do Not Prove

Testing and Validation

Tests are defensive: they verify the policy, not techniques for evading it.

To practice egress decisions on fictional paths, try the Network / Egress Restrictions lab.

Metrics

These are operational measures, not proof of security. Do not combine them into one score.

Common Mistakes

Implementation Checklist

Standards and Sources

Source scope: NIST SC-7 is general boundary-protection guidance; SC-7(5) describes deny by default and allow by exception for network traffic. Neither is specific to AI agents. AC-4 is cited only to mark the boundary to information flow control. The OWASP SSRF Prevention Cheat Sheet is general web-application guidance on destination allowlisting, validation of resolved addresses and redirect handling, not agent-specific guidance. The OWASP agentic list provides risk context for tool misuse; it does not define this control. LLM01:2026 is attack context only. No cited source defines "network / egress restrictions" as an agent-specific control. Service-ID schemas, reason codes, gateway designs and metrics on this page are engineering guidance.

Frequently Asked Questions