Agent Sandboxing Skill

Goal

Provide the intrinsic, infrastructure-level isolation layer for any agent that touches a local OS, shell, or filesystem. Prompt-injection and guardrail rails (prompt-injection-defense.skill, ai-safety-guardrails.skill) reduce the probability that an agent is subverted; sandboxing bounds the consequence if one is. The design assumption is assumed compromise: the planner LLM may already be injected, so the controls must hold even when the agent actively tries to relax them.

The defining property is that all four isolation domains are LOCKED at sandbox-creation time and are immutable for the lifetime of the run. A prompt-injected agent cannot widen its own filesystem scope, open new egress, escalate privilege, or re-route inference, because those decisions were made by the host before the agent's non-deterministic logic ever ran. Container and microVM runtimes (gVisor, Kata, Firecracker) implement exactly this shape — a thin, host-enforced boundary the workload cannot reach around.

Steps

1. Declare the four isolation policies (deny-by-default). Author a single declarative policy covering all four domains. Everything not explicitly allowed is denied.

   • Filesystem: read/write permitted ONLY inside explicit path allowlists (e.g. the task workspace and a scratch dir). Host binaries, system config directories, credential stores, SSH keys, and the agent's own runtime config are unreachable — not merely read-only, but absent from the mount namespace.
   • Network: egress is deny-by-default. A forward proxy is the only route out, and it enforces allow rules at HTTP method + path granularity (not just host/port), so GET /v1/models can be allowed while POST /exfil on the same host is refused. No raw sockets, no DNS to arbitrary resolvers.
   • Process: no privilege escalation (no setuid, no_new_privs set), a restrictive syscall filter blocking dangerous calls (ptrace, mount, kernel-module load, raw clone for daemons), no spawning of background daemons or detached processes, and capped CPU/memory/PID/file-descriptor limits.
   • Inference routing: all model calls are routed through controlled backends so prompt context and tool output stay within the trust boundary. The agent cannot redirect inference to an attacker-chosen endpoint, which would itself be an exfiltration channel.

2. Lock the policy at sandbox creation. The host (runtime supervisor / policy engine) materializes the sandbox from the declared policy and seals it BEFORE handing control to the agent. The four domains become immutable for the run: there is no in-band API, tool, or syscall by which the agent can edit its own allowlists, add egress rules, drop the syscall filter, or change the inference backend. Policy changes require tearing down and recreating the sandbox from outside — never a mid-run mutation. This is what makes the boundary robust to prompt injection: the attacker can only ask the agent to do something, and the agent has no privilege to grant it.