Sandboxing agent actions: file system, network and credential boundaries

What it is

Sandboxing puts an agent's side effects behind operating-system and network boundaries so that a wrong or manipulated action is contained. Three layers are combined. File system: a working directory the agent may write, everything else read-only or invisible. Network: no outbound access by default, an allowlist where needed. Credentials: no long-lived secrets inside the sandbox; authenticated calls go through a tool or proxy that holds the credential outside. Docker's documentation describes the default seccomp profile, which disables around 44 of more than 300 system calls, capability control with --cap-drop, and --privileged, which gives a container all capabilities and access to all devices on the host. gVisor is an application kernel with a Linux-like interface, written in a memory-safe language and running in user space, used through its runsc runtime with Docker or Kubernetes when a stronger boundary than a shared host kernel is wanted.

Why it matters

An agent reads untrusted content (web pages, documents, tool output) and can be steered by it. The sandbox turns "the agent was tricked into running a command" from an incident into a log line. It also absorbs ordinary mistakes: a wrong path in a recursive delete inside a throwaway container costs nothing.

How to apply

• Run tool execution in a fresh container per task or session: non-root user, all capabilities dropped, read-only root file system, a writable volume only for the workspace, memory and CPU limits, no Docker socket.
• Keep the default seccomp profile or a tighter one; do not run unconfined to make something work.
• Default the network to none; where the agent needs an API, route it through an egress proxy with an allowlist and logging, so that an injected "post this file to that URL" fails.
• Mount no secrets. Give the sandbox a short-lived token scoped to the one resource it needs, or place the authenticated call in a tool that runs outside the sandbox and validates its arguments.
• Treat what leaves the sandbox as untrusted: copy out only the expected artefacts, check names and sizes, never execute them on the host.
• For multi-tenant or internet-facing agents, prefer a user-space-kernel or VM boundary over plain containers.

Pitfalls

The user's home directory mounted into the sandbox. Environment variables inherited from the host that carry cloud credentials. Network "off" for the container but a proxy that forwards anything. Long-lived containers that accumulate state and secrets across tasks. Assuming a container boundary equals a VM boundary.