Why You Cannot Trust Your Agent (And How to Isolate It)

A developer published a Bash function called `confine` that uses the Linux sandboxing tool `bwrap` (bubblewrap) to run AI code agents such as Claude and Codex under kernel-level filesystem isolation, after concluding that application-level guardrails are insufficient. The function mounts the root filesystem read-only, hides the real `$HOME` and `/var/tmp` behind tmpfs, and bind-mounts only the target project directory with read/write access, so an agent working in `~/Projects/ClientA/app` has no kernel-level path to read credentials or source in `~/Projects/ClientB/app`, `~/.bashrc`, or `.env` files. The approach matters because locally run agents otherwise inherit all the permissions of the user account that launches them.

The rapid integration of AI code agents tools like Claude, Codex, and various internal LLM deployments into our development workflow promises unparalleled productivity. These agents, capable of reading, analyzing, and modifying complex codebases, are revolutionizing how we build software. However, this power comes with a critical security question: How do you prevent an autonomous, powerful AI agent from looking at your secrets, reading unrelated projects, or even accessing sensitive files outside the scope of the project you asked it to work on? A recent internal technical discussion highlighted this exact dilemma. I found myself facing a choice: trust the AI's "good intentions", or implement rigorous, kernel-level isolation. Here is a breakdown of the problem, the initial theories, and the definitive technical solution we settled on. When an AI agent runs locally, it typically executes as a process under your standard user account. This means that, by default, it inherits all the permissions of your user. If you are working on ~/Projects/ClientA/app , and the agent decides to traverse the filesystem, there is nothing in the application layer stopping it from reading configuration files, credentials, or source code in ~/Projects/ClientB/app , or even reading your personal configuration files like ~/.bashrc or .env . The biggest fears are twofold: Early solutions were often abstract: The consensus quickly shifted: Application-level guardrails are not sufficient. I needed true filesystem confinement. bwrap The most robust way to solve this is to limit the agent's view of the filesystem at the operating system kernel level before the agent even starts running. I adopted bwrap bubble wrap , a powerful tool designed for creating unprivileged sandboxes in Linux. Instead of asking the AI not to look at /etc , we explicitly tell the operating system that the agent cannot see /etc . The core concept is to redefine the agent's accessible filesystem structure. / is mounted read-only, preventing any accidental system modifications. HOME directory is presented to the agent in a highly restricted manner. $TARGET is bound into the sandbox with full read/write permissions. .config , .local , .cache are mounted as overlays. This means the agent can The result is a confined environment: the agent runs in its sandbox, believing it has access to your project and necessary configurations, but it has absolutely no kernel-level path to traverse the rest of your system. This Bash function creates an isolated and secure sandbox using the bubblewrap bwrap tool to execute programs without allowing them to permanently modify your system files or your primary home directory $HOME . The main concept is: the application runs with read-only access to the root system, and any modifications it attempts to make to your user directories happen only in your RAM temporary storage using overlays. confine { if -z "$1" ; then echo "Usage: confine PATH COMMAND " return 1 fi local TARGET=$ realpath "$1" ; shift mkdir -p "$HOME"/{.home,.config,.local,.cache} bwrap --ro-bind / / --dev-bind /dev /dev --proc /proc \ --tmpfs "$HOME" --tmpfs /var/tmp --bind /tmp /tmp \ --overlay-src "$HOME/.home" --tmp-overlay "$HOME" \ --overlay-src "$HOME/.config" --tmp-overlay "$HOME/.config" \ --overlay-src "$HOME/.local" --tmp-overlay "$HOME/.local" \ --overlay-src "$HOME/.cache" --tmp-overlay "$HOME/.cache" \ --bind "$TARGET" "$TARGET" --chdir "$TARGET" "${@:-bash}" } This is where the isolation happens, line by line: --ro-bind / / /usr , /etc , etc. --dev-bind /dev /dev and --proc /proc --tmpfs "$HOME" --tmpfs /var/tmp $HOME and /var/tmp . This completely hides your actual personal files from the sandbox. --bind /tmp /tmp --overlay-src ... --tmp-overlay ... lines --bind "$TARGET" "$TARGET" --chdir "$TARGET" "${@:-bash}" bash shell by default. The lesson from this discussion is clear: Never rely solely on the policy or "settings" of an LLM application for security. Whether you are using Claude, Codex, or a proprietary internal model, the underlying execution environment is the critical control point. If the agent runs under your user account, it has your user's power. For professional environments, especially those handling multiple client projects, the answer isn't "trust", and it isn't always a massive, resource-intensive VM for every task. The answer is granular, kernel-level filesystem confinement. By wrapping the agent in a robust sandbox, we move the security conversation from "Will the AI be well-behaved?" to "Is the operating system enforcing the boundaries?" And that is always the safer bet.