Sandlock: Confining AI Agent Code with Unprivileged Linux Primitives

Sandlock is a lightweight, unprivileged Linux sandbox that isolates AI agents by compiling static security policies into kernel-enforced rules while delegating runtime decisions to a narrow supervisor, thereby achieving strong confinement without the overhead of containers, microVMs, or root privileges.

The Gist

Imagine you are hiring a very talented but unpredictable assistant (an AI agent) to help you organize your digital life. This assistant can write code, download files, and run commands on your computer. The problem is, you don't know exactly what it will do next. It might accidentally delete your important files, steal your passwords, or call up a hacker's server.

Traditionally, to keep your computer safe, you'd put the assistant in a "glass cage" (like a container or a virtual machine). But these cages are heavy, slow to build, and require a master key (root access) that most developers don't have handy.

Sandlock is a new, lightweight tool designed to solve this. Think of it not as a heavy steel cage, but as a smart, unbreakable set of rules that you can put on the assistant's hands and feet instantly.

Here is how it works, broken down into simple concepts:

1. The "Two-Brain" Strategy

Sandlock splits the job of keeping you safe into two parts, like a Security Guard and a Judge.

• The Security Guard (Static Rules): This part lives inside the computer's kernel (the core brain). It handles the boring, predictable stuff. It knows: "The assistant can read files in the Documents folder, but never the Passwords folder." It also knows: "The assistant can talk to Google, but never to a random IP address." Because this guard is built into the system, it works instantly without needing to ask anyone for permission.
• The Judge (Runtime Decisions): Sometimes, the rules need to change based on what the assistant is actually doing right now. For example, "If the assistant tries to run a specific command that downloads a file, check if that file is safe before letting it happen." The Judge is a small, smart supervisor that watches the assistant's every move. If the assistant tries something tricky, the Judge pauses, checks the situation, and then says "Yes," "No," or "Wait, let me check that address first."

2. Why It's Different (The "No-Root" Magic)

Most security tools require you to be the "Admin" (root) to set them up. Sandlock is special because it works with unprivileged rights.

• Analogy: Imagine you want to put a lock on a door, but you don't have the master key to the building. Usually, you can't do it. Sandlock is like a high-tech lock that you can install yourself using only the tools you already have in your pocket. It doesn't need to rebuild the whole house (no heavy virtual machines) or tear down walls (no complex network setups).

3. The "Time-Travel" Safety Net (Copy-on-Write)

One of Sandlock's coolest features is how it handles file changes.

• The Analogy: Imagine you are painting a picture, but you aren't sure if you'll like the result. Sandlock lets you paint on a transparent sheet of plastic placed over your original canvas.
  • If you like the painting, you press a button to merge the plastic sheet with the canvas (Commit).
  • If you hate it, you just rip off the plastic sheet, and your original canvas is perfectly untouched (Abort).
  • You can even look at the painting on the plastic sheet before deciding (Dry-run).
    This happens without needing special permissions or complex setups.

4. The "Pipeline" (Teamwork with Safety)

Sandlock allows you to chain tasks together, like an assembly line, but with different safety rules for each station.

• The Analogy: Imagine a relay race where the baton is data.
  • Runner A has access to your private diary but is not allowed to talk to the outside world.
  • Runner B is allowed to talk to the outside world (like calling an API) but cannot see your diary.
  • They pass the baton (data) through a pipe. Even if Runner B gets hacked or tricked, they can't steal the diary because Runner A never gave it to them directly; they only passed the baton. This prevents a "lethal trifecta" where a hacker gets your data, your internet access, and your code all at once.

5. How Fast Is It?

The paper tested Sandlock on a regular laptop.

• Startup: It takes about 5 milliseconds to put the rules in place. That's faster than the blink of an eye. In comparison, setting up a traditional container (like Docker) takes about 300 milliseconds—roughly 60 times slower.
• Performance: When running a fast database (Redis), Sandlock was just as fast as running the software directly on the bare metal. It didn't slow anything down.

Summary

Sandlock is a lightweight, super-fast security tool for AI agents. It uses a clever split between "hard-coded rules" and a "smart supervisor" to stop AI agents from causing damage, all without needing to be the computer's administrator. It lets you safely let AI agents run wild in your digital workspace, knowing that if they try to break something, the rules will stop them instantly.

Technical Summary

Technical Summary: Sandlock

Problem Statement

AI agents and coding assistants increasingly execute untrusted code on developer workstations, including shell commands generated by Large Language Models (LLMs), third-party scripts, and tool plugins. This creates a significant supply-chain risk where a single invocation could lead to unintended file deletions, SSH key theft, or network exfiltration.

Existing isolation mechanisms fail to fit this specific workload:

• Containers and MicroVMs: While providing strong isolation, they incur high startup latencies (hundreds of milliseconds) and require image management, root privileges, or complex namespace configurations, which is prohibitive for short-lived, frequent agent commands.
• Ad-hoc Controls: Tools like chroot, ulimit, firejail, or bubblewrap offer weak guarantees, lack fine-grained syscall control, and cannot enforce host- or HTTP-level network policies.
• gVisor: Introduces a user-mode kernel that improves isolation but degrades compatibility and performance for build tools due to syscall overhead.

The core challenge is the absence of a tool that is unprivileged, low-latency, filesystem-aware, and programmable enough to enforce policies that depend on runtime behavior (e.g., revoking network access after a setup phase) without requiring a full container restart.

Methodology and Design

Sandlock is a lightweight, unprivileged Linux process sandbox written in Rust. Its central design innovation is a split enforcement model that separates static, input-independent policies from runtime-dependent decisions.

1. The Split Enforcement Architecture

Sandlock organizes policy enforcement into two distinct layers:

• Static Kernel-Enforced Rules: Policies with known verdicts before execution (e.g., readable path prefixes, writable workspaces, TCP ports, IPC scope, and unconditional syscall denials) are compiled into kernel primitives. Sandlock utilizes Landlock for filesystem, TCP port, and IPC constraints, and seccomp-bpf for unconditional syscall filtering. This layer operates without supervisor involvement, ensuring minimal overhead.
• Runtime Supervisor: Decisions dependent on syscall-time state (e.g., resolved network destinations, execve arguments, HTTP methods/paths, or copy-on-write effects) are routed through a narrow seccomp user notification supervisor. This supervisor runs in the parent process, intercepts specific syscalls, validates them against dynamic policies, and performs "on-behalf" operations using pidfd_getfd to ensure safety.

2. Key Technical Mechanisms

• TOCTOU-Safe Runtime Policy: To safely inspect execve arguments (like argv) without violating kernel re-read semantics, Sandlock freezes sibling threads and peer processes via ptrace before reading arguments or continuing the syscall. This prevents race conditions where a peer process could modify memory after validation.
• Unprivileged Copy-on-Write (COW): Sandlock implements two COW backends to capture filesystem writes without mount namespaces or root:
  • Seccomp COW: Intercepts filesystem syscalls to redirect writes to an upper directory.
  • BranchFS: A dedicated filesystem layer that captures writes at the filesystem level.
    Both support committing, aborting, or inspecting changes after sandbox exit.
• Pipeline Composition: Sandlock introduces a pipeline operator that connects sandboxed stages via kernel pipes. Each stage can have a distinct confinement policy (e.g., a "data" stage with private file access but no network, and an "executor" stage with network access but no private data). This enforces capability separation required by prompt-injection-resistant architectures (e.g., dual-LLM patterns).
• Network Policy: Sandlock supports endpoint allowlisting with optional HTTP-level rules (method, host, path). For TCP, it uses Landlock for direct kernel enforcement. For complex rules (HTTP, non-TCP), it uses an "on-behalf" path where the supervisor validates the destination and performs the connection.

Key Contributions

The paper claims the following contributions:

1. A Policy Model for Unprivileged Agents: A design that separates static kernel-enforced policy from runtime-dependent supervisor decisions while maintaining a uniform configuration surface.
2. TOCTOU-Safe Runtime Mechanism (policy_fn): A mechanism that exposes syscall events (including execve arguments) to host code for live policy tightening without violating kernel re-read semantics.
3. Unprivileged COW and Fork Primitives:
   • A seccomp-driven COW workspace allowing commit/abort/dry-run of filesystem effects without root.
   • A COW-fork primitive sustaining ~1,900 sandboxed forks/second for map-reduce workloads.
4. Preliminary Evaluation: Empirical data demonstrating low overhead and high throughput.

Results

Experiments were conducted on a standard Linux workstation (AMD Ryzen 5, 8GB RAM, Linux 6.18).

• Startup Overhead: Sandlock adds approximately 5 ms of startup latency (wall time ~6 ms), which is roughly 44× faster than Docker in the same environment.
• Throughput: Sandlock runs Redis at bare-metal throughput (within measurement noise). For SET and GET operations, Sandlock achieved ~75.2k and ~74.2k requests per second respectively, compared to ~75.5k and ~73.9k on bare metal. Docker achieved only ~76% of bare-metal throughput.
• Latency: Sandlock's p99 latency (0.51 ms) is close to bare metal (0.49 ms), whereas Docker's p99 latency was roughly 3× higher (1.44 ms).
• Effectiveness: Deterministic checks confirmed that Sandlock correctly denies reads/writes outside scope, blocks non-allowlisted network connections, and enforces per-stage capability separation in pipelines.

Significance and Claims

The paper positions Sandlock as a tailored solution for the AI agent workstation, addressing the specific need for unprivileged, low-latency, and programmable isolation.

• Modest Scope: The authors explicitly state that Sandlock is not a replacement for microVMs in multi-tenant adversarial environments; for those scenarios, strong kernel isolation (microVMs) remains necessary. Sandlock is designed for the "developer machine" context where root is unavailable and latency is critical.
• Enforcement Substrate: Sandlock provides the kernel-enforced substrate required by existing theoretical frameworks (like dual-LLM or CaMeL patterns) to separate untrusted content from sensitive capabilities. It does not prove the correctness of the decomposition itself but enforces the boundaries the author specifies.
• Complementarity: Sandlock is presented as complementary to other agent security tools (like gateways for external communication) by securing the local execution side of the agent stack.

The paper concludes that by leveraging modern Linux primitives (Landlock, seccomp notification, pidfd_getfd) in a split architecture, it is possible to achieve strong confinement for AI agents without the heavy costs of traditional containerization.