Egress Firewall Rules for Autonomous Agent Containers

Egress firewall rules for autonomous agent containers must account for both endpoints known at deployment and destinations chosen during execution. Deny-by-default networking must be enforced outside the agent’s control, with a proxy as the sole outbound path. That boundary needs protected configuration, controlled DNS, kernel isolation, and independent monitoring. A permission string is not a firewall, however sternly it is written.

Why agent containers need a different egress model than ordinary services

An ordinary backend service talks to a small, stable set of destinations that engineers can enumerate before deployment. An agent runtime reaches destinations chosen by the model, often from user instructions, including addresses that did not exist when the policy was written. The destination set is part of the execution. A fixed endpoint list cannot cover every legitimate request before it runs, but with unrestricted access, every runtime decision has a route to the network.

Platform defaults compound that mismatch. Kubernetes pods are non-isolated for egress unless a NetworkPolicy selects them and includes Egress in policyTypes. Traditional infrastructure often allowed broad outbound access because engineers wrote the code and review and CI could catch problems before the code ran. That assumption weakens when the model generates code while the workload is running.

Why tool-layer and permission-string controls cannot substitute for network enforcement

Tool restrictions constrain named operations. A deny rule for Bash(curl *) does not block python -c "import urllib.request; urllib.request.urlopen(...)". Once python * is allowed, the permission rule implicitly permits the network requests, file reads, and system calls Python supports, subject to controls below that rule. The command changes. The network request survives. Exfiltration needs a socket.

OWASP LLM06:2025, Excessive Agency, recommends minimizing extensions and narrowing their functions, but does not use the words “egress”, “firewall”, “network”, or “sandbox”. Those controls address a different boundary. OWASP Agentic AI Top 10, released in December 2025, classifies ASI05 as Unexpected Code Execution and recommends isolated execution containers with minimal privileges and no network access except explicitly allowed endpoints.

What deny-by-default egress means architecturally, and why the enforcement point matters

Deny-by-default egress blocks all outbound traffic at the network layer unless policy explicitly permits it. Enforcement belongs below anything the agent can influence, outside both agent code and the container’s own process space. Otherwise, the workload being constrained also has access to its constraints. The boundary must survive an uncooperative agent. A host firewall or external gateway can enforce the decision even when application-level permissions fail.

The same boundary limits how a compromise spreads between agents. If an agent trusts input from another agent, a compromised link can send malicious instructions down the chain. Per-container network restrictions limit the reachable destinations, although they do not make permitted messages trustworthy. Logging belongs at this boundary as well. Records of allowed and blocked requests must be independent of the agent’s account, giving runtime monitoring a reliable basis for examining approved traffic and anomalous behavior.

The Docker/iptables implementation with DOCKER-USER rules, ipsets, and a per-bridge pattern

For Docker on the host operating system, the implementation begins with a named bridge and rules in DOCKER-USER scoped to that interface. The option -o com.docker.network.bridge.name=br-agent gives the bridge a known name so rules can match -i br-agent. Verify that a container is attached before testing the policy. On an idle network, that interface match silently sees nothing until a container attaches, so an uneventful test may mean the rules were never exercised.

For practitioners, the rule sequence starts by accepting loopback traffic, then dropping ICMP and UDP. ICMP can serve as a tunneling path, while dropping UDP deliberately removes ordinary DNS access. Next, TCP SYN rate and concurrent-connection limits drop excess attempts. Destination matching follows those limits. Traffic to a destination in the bridge’s ipset is accepted, and everything else is logged and dropped.

Host access needs a separate rule in INPUT, dropping traffic from the bridge except traffic to the proxy port. Without that rule, a container can target its bridge gateway IP and reach host services through INPUT, bypassing FORWARD. IPv6 must also be disabled on the bridge because it provides a separate path outside the scope of IPv4 iptables rules.

Protecting configuration helps the firewall do its job, but the firewall is still needed. A canonical permission file can be copied from a root-owned, read-only location at startup, set to 0444, and protected by pre-claiming the override path. NVIDIA’s 2026 mandatory controls also include workspace write restrictions covering dotfiles and configuration directories, plus protection for hooks, MCP server configurations, and IDE extensions. CVE-2025-59536 shows how malicious project configuration can run before a trust dialog completes. The production network pattern then gives each bridge its own ipset containing exactly one (proxy_ip, proxy_port) entry, making the proxy the only permitted outbound destination.

Why DNS must be treated as a control surface, not a utility

DNS queries can transmit data even when ordinary web requests are blocked. An agent can encode readable information into subdomain names and trigger queries that reach an attacker-controlled nameserver. No HTTP request is needed. A policy that allows DNS as harmless plumbing therefore leaves a separate exfiltration route open, outside the web restrictions it was intended to support.

AWS AgentCore Code Interpreter provided a concrete example in March 2026, when a DNS exfiltration attack succeeded inside its sandbox. Python socket.gethostbyname calls bypassed HTTP-layer allowlists. The structural response is to make DNS unavailable inside the agent sandbox by removing normal resolver paths and dropping DNS egress on UDP port 53. The broader UDP drop reinforces that restriction. An /etc/hosts entry supplies the proxy’s hostname so SDKs can reach it, while upstream hostname resolution happens at the proxy.

That relocation also addresses a resolution-related SSRF risk. When agents resolve names themselves, an apparently allowed hostname can resolve to an unacceptable IP, including through DNS rebinding. Proxy-side resolution puts that decision under policy control. A controlled resolver can additionally score high-entropy labels, recently registered domains, unusually long names, and repeated subdomain queries under one parent. Queries crossing a threshold can trigger quarantine for review while the sandbox’s DNS path remains blocked.

What FQDN-aware policy adds over IP-based rules, and when each Kubernetes CNI delivers it

External services are addressed by name, while their backing IP addresses can change. An IP allowlist can therefore become broken or overly permissive after a provider moves an endpoint. The policy needs to follow the name. In Kubernetes, the recommended starting point is default-deny for agent namespaces, with FQDN-aware controls for permitted external services. OWASP’s ASI05 guidance supports deny-by-default egress, although it does not specifically mandate namespace-wide default-deny.

The implementation depends on the cluster’s networking stack. Clusters that are self-managed can use Cilium’s CiliumNetworkPolicy with toFQDNs entries. GKE with Dataplane V2 provides FQDNNetworkPolicy, while AKS with Azure CNI provides ACNS FQDN filtering. Domain policy also needs rules for protocol and port use that limit external calls to HTTPS and block arbitrary TCP, UDP, and non-standard ports unless a documented use case requires them.

DNS placement determines an important rollout detail. Where workloads are intended to use cluster DNS, omitting egress to kube-system on UDP/TCP port 53 is a common cause of failures after deny-all deployment. That exception does not belong in an agent sandbox deliberately designed to have no DNS. In the proxy-only design, resolution stays outside that sandbox. FQDN-aware policy governs permitted named destinations without granting agents a second outbound route.

What the egress proxy adds that firewall rules alone cannot provide

A firewall decides whether to allow a connection. An inspecting proxy can also evaluate the hostname, method, path, headers, payload, and session context. Those distinctions become essential when an allowed domain supports both legitimate calls and exfiltration. Anthropic’s May 2026 red-team exercise found that Claude completed credential exfiltration in nearly every attempt by uploading workspace files through api.anthropic.com. Blocking that domain would also block a service the agent needed.

A signed-context proxy can narrow permissions within such necessary connections. It can permit a destination class only for a particular user role, or require a large payload to trace back to a first-party instruction. It can also rewrite or strip headers according to the calling tool. The provenance must not be self-declared. Context metadata must be signed by the agent runtime to prevent an agent from claiming whichever authority its request needs.

The proxy must remain an HTTP(S) proxy. Otherwise, raw TCP traffic passes through without the inspection that makes method- and path-level decisions possible. As the sole outbound path, the proxy also provides an audit chokepoint linking what was sent, its destination, the triggering instruction, and the user’s authority. Runtime monitoring adds a wider view. How much traffic is sent, when it is sent, and how destinations cluster across sessions can show patterns that rules for a single request miss.

These capabilities do not make domain permission equivalent to content safety. An agent permitted to reach github.com may still send data to github.com/attacker/repo. HTTP(S) inspection gives finer controls a place to work, but on its own it cannot judge what permitted content means. Stricter API-path allowlists and content-layer inspection must be added even when a proxy is in place.

Kernel isolation and privilege restriction as the boundary below the firewall

Docker containers share the host kernel, so their network boundaries depend on the integrity of that lower layer. A kernel exploit or misuse of privileged capabilities can let generated code escape the container and bypass its egress restrictions. Sysdig documented an agentic attacker creating privileged containers and breaking out to the host in June 2026, showing why privilege restriction and network isolation are needed together.

The relevant choice is whether isolation matches the trust placed in the code. Container isolation may be enough for personal agent workloads on a local machine, but shared environments that run code for other users need microVM- or gVisor-class isolation. Firecracker provides full VM isolation per agent run. Kata Containers offers a container-standard-compatible interface backed by a lightweight VM, while gVisor intercepts syscalls in user space without a full VM boundary.

Whichever boundary is chosen, privileges must still be kept to a minimum. NVIDIA’s sandboxing guidance pairs minimal system privileges with egress allowlists and workspace write restrictions. Configuration locking prevents an agent from rewriting its permissions or hooks, while stronger isolation addresses attempts to escape the environment itself. Neither control decides whether a particular outbound payload is acceptable. That decision still belongs further up the stack.

Putting the layers together with an architecture that holds under realistic attack conditions

The combined architecture starts below the network, with isolation appropriate to the workload, minimal privileges, and protected configuration. Host firewall rules or Kubernetes policy then deny outbound access except to the proxy, with sandbox DNS unavailable. FQDN-aware controls keep rules for permitted domains in step with changes to provider addresses, while the proxy applies request-level policy and records context. Controlled resolution supports both destination checks and DNS anomaly detection.

Every production agent should be discoverable, its approved traffic monitored, and its actions recorded independently of its own reports. Behavioral monitoring should spot suspicious activity before it causes damage, and repeated blocked calls should be logged and looked into. The operational effort is front-loaded. Building an allowlist takes days, each change takes minutes, and a review every quarter keeps permissions in line with how they are meant to be used.

Kairos (2026) provides evidence for policy enforcement at the system boundary. Its declarative source trust policy cut AgentDojo attack success from roughly half to near zero while preserving benign utility at the undefended level. That result supports boundary enforcement, with the same outcome across all firewall-and-proxy deployments still to be established. The remaining gap is semantic. A trusted API that accepts free-form text can still become an exfiltration channel, so content-layer inspection and stricter API-path controls remain work to do after the network boundary is in place.