Two Locks Keep A Sandbox Honest
Sandboxed code execution is safe because of two locks: no filesystem outside the box, no network egress. Open the network and a prompt-injected agent can exfiltrate whatever it just read; keep egress shut and even a successful attack has nowhere to send the loot. Use the domain allowlist for the few hosts a job genuinely needs.
Why it works
Sandboxed execution is safe because of two locks working together: no filesystem beyond the box, no network egress out of it. Open the network and a prompt-injected agent — one that read a poisoned file or webpage — can exfiltrate whatever it has seen. Keep egress shut and even a successful injection is a non-event: the attack runs, finds no exit, and dies inside. The allowlist exists for the few hosts a job genuinely needs.
How to do it
- Leave sandbox network access OFF as the standing default — it's the safe configuration.
- A job needs packages or one API? Allowlist those specific domains, not the internet.
- Before each allowlist addition, ask the exit-interview question: 'what leaks if this domain turns hostile?'
- Keep the sandbox's file scope equally tight — it shouldn't see folders the job doesn't touch.
- Full egress is a deliberate, per-job decision with a reason you could defend in writing.
- Revisit the allowlist when the job changes; permissions outliving their purpose is the classic drift.
Copy this
For this sandboxed task, list every domain you'd need network access to and why. I'll allowlist the minimum — assume everything else stays blocked.
What to watch for
- Prompt injection isn't exotic: any file, page, or email the agent reads can carry instructions it may treat as yours. The network lock is what makes that survivable.
- 'It needs the internet to be useful' conflates the AGENT (which reaches the world through you and your connectors) with the SANDBOX (which mostly doesn't need to).
Sources