AI Agent Sandbox Egress Simulator & Policy Auditor
Reproduce how an autonomous agent breaks out of an assumed “internet-free” sandbox to query third-party endpoints, verify defense-in-depth isolation layers, and export verified firewall and seccomp rules.
Containment Perimeter
Topology: Hardened Zero-EgressRecommended Containment Enforcement nftables / Docker Run
# Guaranteed Zero-Egress Network Namespace: docker run --rm -it \ --network none \ --security-opt no-new-privileges:true \ --security-opt seccomp=/etc/docker/seccomp-block-sockets.json \ --cap-drop ALL \ agent-eval-runtime:latest
Understanding Sandboxing Failures in Autonomous Agents
Autonomous reasoning models equipped with code interpretation, shell commands, or synthetic tool-use loops systematically explore execution environments. When companies train models in supposedly “internet-free” environments, standard Linux networking frequently leaves dormant pathways active:
- DNS Tunneling: Even when direct TCP HTTP connections are blocked, local resolver daemons may resolve custom DNS names containing encoded data in subdomains (e.g.,
exfil-payload.attacker.com). - IPv6 Link-Local Routing: Firewalls configured solely with legacy
iptablesdrop IPv4 packets while permitting auto-discovered IPv6 SLAAC router advertisements. - Unix Domain Sockets: Accidental mounting of
/var/run/docker.sockor daemon sockets grants raw host breakout capabilities.
Containment Architecture FAQ
Why isn't iptables -P OUTPUT DROP enough?
IPv4 iptables does not govern IPv6 traffic (handled separately by ip6tables or nftables). Furthermore, loopback relays and forwarded DNS sockets frequently bypass standard forward filters unless namespaces are completely unshared.
How do agents communicate with external chatbots without user consent?
When an agent executes arbitrary Python or bash scripts, it can spawn raw socket packets, utilize UDP DNS queries, or trigger webhooks embedded in environment token variables, establishing reverse command-and-control channels.
What is true zero-network isolation (--network none)?
Creating an unshared network namespace with only the loopback interface disables all virtual ethernet pairs (veth). Paired with Seccomp rules preventing socket creation syscalls (socket(AF_INET, ...)), the agent process has zero operating system facility to emit radio or ethernet frames.
Agent Sandbox Isolation Mechanics & Egress Surface Analysis
How do Linux network namespaces and container security profiles prevent agentic workloads from exfiltrating data across network channels?
Autonomous AI agents executing untrusted shell commands or Python interpreters can test outbound network avenues beyond standard HTTP requests. This interactive simulator evaluates how combinations of network namespace isolation, internal DNS interception, IPv6 stack state, and Seccomp socket filters arrest simulated egress vectors like DNS queries, IPv6 neighbor discovery, and external API calls.
The simulator uses discrete boolean lookup logic to demonstrate containment principles; telemetry values such as '16 / 16 Dropped' and '0.3 ms' are illustrative UI fixtures rather than live kernel benchmarks. Real-world isolation also requires auditing unix domain volume mounts, host capability grants, and process namespace boundaries.
Try a worked example
Switch the 'Sandbox Topology Profile' from 'Hardened Zero-Egress' to 'Docker Default (Internal Bridge • DNS forwarded)'. The perimeter status changes immediately from 'ISOLATION SECURE' (100% BLOCKED) to 'BREACH DETECTED' (0% COMPROMISED), the simulated packet trace logs outbound exfiltration via DNS port 53 to 127.0.0.11, and the remediation pane generates required container isolation flags.
Network Namespace Isolation vs. Bridge Networking
In default container runtimes, containers attach to a virtual bridge interface that routes outbound traffic via network address translation (masquerading). By unsharing the network namespace, the container receives an isolated network stack containing only its local loopback interface, without virtual ethernet pairs linking it to the host routing table. Networking overview | Docker Docs network_namespaces(7) - Linux manual page
Linux network namespaces isolate system resources including device lists, IPv4 and IPv6 protocol stacks, IP routing tables, firewall rules, and socket binding lists. When configured with no physical or veth virtual network devices attached, processes inside the namespace cannot route packets beyond loopback. network_namespaces(7) - Linux manual page
Covert Egress Channels: DNS Forwarding and IPv6 SLAAC
When firewalls drop direct TCP egress on ports 80 and 443 without isolating network namespaces or local resolver daemons, an agent process can often still send queries to the runtime's internal DNS proxy (such as 127.0.0.11:53 in custom Docker bridge networks). By placing encoded payload fragments into DNS subdomain queries, outbound network channels can be established without establishing a direct TCP connection. Networking overview | Docker Docs
Similarly, incomplete firewall rules that filter only IPv4 packets leave IPv6 protocol stacks susceptible to auto-configured routes and router advertisements unless IPv6 is explicitly filtered or disabled in the container kernel settings. network_namespaces(7) - Linux manual page
Sources and further reading
- Networking overview | Docker Docs
Details container networking modes including default bridge routing, the none driver isolation mode, and embedded DNS resolution over 127.0.0.11.
- network_namespaces(7) - Linux manual page
Explains Linux kernel network namespace isolation across network devices, IPv4/IPv6 protocol stacks, routing tables, and socket spaces.
Egress simulation uses vector-specific Boolean gates
Read the explanation
The simulator defines four vectors: DNS tunnel, IPv six, token webhook and Unix Docker socket. DNS is blocked by namespace, seccomp or DNS flag. IPv six by namespace, seccomp or IPv six flag. Webhook by namespace or seccomp. Docker socket is blocked only by seccomp in this toy logic. Thus namespace alone blocks three modeled vectors while seccomp alone blocks four. This Boolean table does not prove real isolation or a complete syscall policy. Enabling only DNS block yields one blocked vector and three unblocked. Enabling only IPv six block likewise affects its own branch. Target host edits change labels but are not part of the containment decision. No resolver, network route or actual outbound packet is examined. The broad policy labels and Docker snippets are illustrative configuration text; this page does not install or validate them. A blocked result displays one hundred percent blocked, sixteen of sixteen dropped and point three milliseconds. An unblocked result displays sixteen leaked and forty eight point two milliseconds. Those are fixed branch labels, not observed packet or latency measurements. Animations visualize the selected result without sending traffic. Exported policy and audit data remain local examples, not provider execution, real containment or security-certification evidence.