Skip to content

Chapter 4.10 — Sandboxing and egress control

🎯 Objective

Define the defensible minimum to isolate the execution of untrusted code — code generated by an LLM, tool scripts, third-party integrations — and to control network egress that can turn into silent exfiltration.

🧠 Concept

Sandbox and egress control are deterministic layers (Ch. 0.6): they do not depend on the model "behaving" to work. They are physical (or virtualized) boundaries between what the agent proposes and what the system actually executes. In corporate environments, they are usually the last barrier against an attack path that got through the other layers — prompt injection that reached a tool, code generation that tried to open an external connection, a third-party tool that requested access to an unforeseen endpoint.

The practical rule is simple: if the model can propose execution, the executor must be isolated by design, not by an instruction in the prompt.

🛡️ Principles

  • Code generated by an LLM does not execute outside a sandbox.
  • The sandbox has:
  • an ephemeral file system;
  • network blocked by default;
  • minimal secrets;
  • CPU/memory/time limits.
  • Controlled egress:
  • host allowlist;
  • payload inspection (DLP);
  • blocking of suspicious domains.

⚠️ Honest limits

A sandbox is not magic: it reduces the blast radius, but does not prevent a legitimately authorized agent from doing something wrong within the permitted scope. An egress allowlist depends on the quality of the list — popular hosting domains (raw GitHub, public S3, paste services) are common exfiltration vectors and need explicit handling.

📚 References