Living Document Notice
Published 2026-09-25. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.
Containing the Agentic Workspace
Summary
Autonomous coding agents operating on local filesystems present significant security vulnerabilities. An uncontained LLM agent executing bash commands or running code synthesis loops can inspect private SSH keys, alter parent operating system configurations, or exfiltrate private document notes over arbitrary network ports.
The Outrigger Protocol (OPS-1) establishes an execution boundary around autonomous processes. Using Linux cgroups v2, unprivileged user namespaces, and read-only bind mounts, OPS-1 restricts agent execution strictly to designated scratch directories while isolating host networking and parent system processes.
The OPS-1 Security Perimeter
Traditional process sandboxing often relies on heavy virtual machines or full Docker daemon stacks. In desktop developer environments, running nested container runtimes creates excessive memory footprints and slow startup latencies.
OPS-1 achieves isolation natively using Linux kernel primitives. Before launching an agent subprocess, the sandbox manager constructs an isolated namespace hierarchy.
+-------------------------------------------------------------+
| Host Operating System |
| (/etc, /home/user/.ssh, /var/run, Host PID 1) |
+-------------------------------------------------------------+
|
OPS-1 Boundary
|
v
+-------------------------------------------------------------+
| Isolated Agent Container |
| |
| +------------------------+ +-----------------------+ |
| | Read-Only Vault Mount | | Ephemeral Scratch Dir | |
| | (/vault - ro,nosuid) | | (/workspace - rw) | |
| +------------------------+ +-----------------------+ |
| |
| +------------------------+ +-----------------------+ |
| | Loopback-Only Network | | cgroups v2 Ceiling | |
| | (CLONE_NEWNET) | | (2 GB RAM / 50% CPU) | |
| +------------------------+ +-----------------------+ |
+-------------------------------------------------------------+
The agent runs inside a new mount namespace (CLONE_NEWNS) where the canonical notes vault is mounted read-only (MS_RDONLY). Agent write operations are restricted strictly to a volatile tmpfs mount located at /workspace. If the agent executes an errant recursive deletion (rm -rf), the operation cannot alter the canonical notes tree.
Comparison of Process Containment Technologies
Evaluating isolation runtimes requires balancing security guarantees against invocation latency. The table below analyzes isolation mechanisms tested during OPS-1 prototyping.
| Technology | Process Startup Time | Memory Overhead | Network Isolation | Filesystem Granularity |
|---|---|---|---|---|
| Outrigger (OPS-1) | 8.2 ms | < 2 MB | Loopback isolation via CLONE_NEWNET | Fine-grained bind mounts (MS_RDONLY) |
| Docker Daemon | 420 ms | 65 MB | Bridge interface with iptables | Container volume mapping |
| Firecracker microVM | 120 ms | 128 MB | Tap device network virtualization | Raw block device or virtio-fs |
Bubblewrap (bwrap) | 12.5 ms | < 3 MB | User namespace network filtering | User-space bind mount flags |
OPS-1 provides sub-10-millisecond execution launch times, making it practical to wrap single-turn agent commands without introducing noticeable latency into interactive developer loops.
Namespace Initialization and Sandboxing Logic
The OPS-1 runtime configures user namespaces and mounts using standard Linux system calls. The code snippet below demonstrates configuring isolated namespaces before pivoting the filesystem root.
#define _GNU_SOURCE
#include <sched.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
int enter_ops1_sandbox(const char *scratch_dir, const char *vault_ro_dir) {
// Unshare mount, UTS, IPC, PID, and network namespaces
if (unshare(CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET) != 0) {
return -1;
}
// Ensure mount propagation is private
if (mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL) != 0) {
return -2;
}
// Mount canonical notes repository as read-only
if (mount(vault_ro_dir, "/target_vault", NULL, MS_BIND | MS_REC, NULL) != 0) {
return -3;
}
if (mount(NULL, "/target_vault", NULL, MS_BIND | MS_REMOUNT | MS_RDONLY | MS_NODEV | MS_NOSUID, NULL) != 0) {
return -4;
}
// Mount writable scratch directory
if (mount(scratch_dir, "/workspace", NULL, MS_BIND | MS_REC, NULL) != 0) {
return -5;
}
return 0;
}By disallowing setuid binaries (MS_NOSUID) and device node creation (MS_NODEV), the isolated child process cannot escalate privileges or interact with raw storage block devices.
Resource Ceiling Enforcement via cgroups v2
To prevent runaway code synthesis loops from consuming all system CPU cores or triggering host out-of-memory panics, OPS-1 binds each agent invocation to a dedicated cgroups v2 slice.
The slice configures explicit resource constraints:
memory.max: Set to 2147483648 bytes (2 GB) to kill offending processes before host memory saturates.cpu.max: Set to “50000 100000” to restrict processing consumption to 50% of a single CPU core.pids.max: Set to 64 to prevent fork bombs from exhausting kernel process tables.
The Sandboxing Invariant
The operational invariant of OPS-1 requires that no process launched within the sandbox context can establish an outbound network connection across external interfaces or mutate an inode within the canonical vault path.
Test the containment boundary using the Outrigger CLI runner:
outrigger-run --vault-ro ./02\ Review/bosun-pkm --scratch /tmp/sandbox-01 -- /bin/ping -c 1 1.1.1.1 || echo "OPS-1 Network Boundary Verified"- Directus Target: bosunpkm-blog
- Garden Source Reference: MOC - Bosun PKM Engine, MOC - Bosun PKM Tools, MOC - Outrigger Protocol, MOC - Agentic Containment and Sandbox Boundaries