Skip to content
Prompt Injection & Tool SafetySandbox design

Lead · Core path · 7 chapters

Sandbox design

Isolation boundaries, egress network policy (the concrete form of 7.3's third leg), filesystem scoping, per-execution credentials, resource caps, snapshot and rollback

A sandbox that leaks credentials, network access, or durable state turns prompt injection into an incident; the boundaries must be tested rather than assumed.

Read these first

What you will know

  • Compare containers, gVisor, and microVMs against a stated threat model, resource-cap strategy, and latency budget

    Kernel exposure, device access, noisy-neighbor behavior, and cold-start cost vary substantially, so the cheapest isolation is not always adequate.

  • Configure default-deny egress and prove it holds

    Default-deny egress is the concrete implementation of removing the trifecta's third leg.

  • Scope a filesystem so an escape attempt fails

    Filesystem scoping stops a sandboxed process reading things it was never meant to.

  • Inject credentials per execution rather than baking them in

    Per-execution credentials mean a compromise is bounded to one run rather than to the service.

  • Roll back a workspace after a run and verify nothing persisted

    Snapshot and rollback make a bad run recoverable rather than permanent, but they do not undo external API calls or data already exfiltrated.


Chapters

  1. 1

    Containers, gVisor and microVMs

    A container with a tuned seccomp profile, gVisor, and a Firecracker microVM per execution are not three points on one quality scale. The container shares the host kernel, so one kernel bug crosses a line the other two would have held, while the microVM pays a cold start that a workload of forty executions a second cannot absorb. Tie the choice to a stated threat model, resource caps and a latency budget rather than to strength, and know that at high throughput the microVM you actually get is a pooled one.

  2. 2

    Shared namespaces and warm pools

    Separating browser-automation sessions by directory and per-session profile inside one container keeps cold start under 100ms and leaves every session's cookies and tokens readable by the code next to them, because a directory is a label and the namespaces are shared. The same reasoning bites the strongest technology: microVMs at high throughput require a pool, a pool means reuse, and reuse reintroduces the shared state the microVM was bought to remove. Track sharing per resource — which principals can name it, over what window.

  3. 3

    Testing default-deny egress

    A default-deny egress policy is a claim about behaviour, and the only evidence for it is an attempt that fails. Eight things leak past a policy that is exactly as written — IPv6 gaps, the window before the CNI programs rules, DNS, an allowlisted host that carries data, SNI confusion, link-local metadata, sidecars and a neighbouring pod — so the mechanism that counts is a canary suite run inside the real image on every change, with the verdict coming from outside. Pinning the registry by IP range is looser than pinning by hostname.

  4. 4

    Filesystem scoping

    Mounting the workspace at /workspace does not make the filesystem scoped. The property to establish is that nothing outside the scope resolves from inside: no host path mounted for convenience, no volume shared with another run, no symlink the collector dereferences on the host, no cache directory inherited from the image. Build the scope with a user namespace, an overlay and nosuid/nodev/noexec, then attack it, since an escape attempt that fails is the only evidence the boundary exists.

  5. 5

    Secret managers and per-execution credentials

    A warehouse credential baked into a sandbox image is readable by anyone who can pull the image, and moving it into a secret manager fetched at container start is not the redesign — it is still one credential per container, valid for every execution and every customer that worker serves. Minting a token per execution, scoped by a session policy to one table and one tenant and revoked when the run ends, is what bounds a compromise to the run that was compromised. The scope must come from the request context, never from the model.

  6. 6

    Snapshot and rollback

    Snapshotting a workspace before a run and rolling back afterwards undoes local state: files, installed packages, anything cached on disk. If the run POSTed data to an outside endpoint and opened a pull request, both stand and neither is recoverable, because a compensating action is a new event rather than the erasure of an old one. Rollback is a recovery mechanism rather than a containment one, verification has to look wider than the snapshotted subtree, and destroying the instance is often the better default.

  7. 7

    Signing off a warm pool

    Multi-tenant customer code against customer data at a 300ms p95 rules out a microVM per execution, so pooling warm instances is the right shape with all the risk hidden in one word. A reset that restores the filesystem but not kernel state, open sockets, the guest page cache or an environment variable is a boundary in name only. Write the three-sentence threat model, put the reset ladder on the page with the level you actually implement, and name the seven proofs and their owners before signing.

External resources