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

2026-11-03

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.

The Unbounded Agent Problem

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:

Data Leakage (Read Access): An agent reading credentials, API keys, or proprietary information from files outside its designated scope.
System Corruption (Write Access): An agent modifying system files or accidentally overwriting important personal data.

Early solutions were often abstract:

"I just trust the AI". (The easiest, but most dangerous option).
Using Docker/Podman for every single project. (Highly secure, but incredibly cumbersome and poor for developer workflow).
Chroot/VM. (Effective, but massive overhead and complexity).

The consensus quickly shifted: Application-level guardrails are not sufficient. I needed true filesystem confinement.

The Solution: Kernel-Level Sandboxing with `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.

How the Isolation Works

The core concept is to redefine the agent's accessible filesystem structure.

Root Read-Only: The entire root filesystem (/) is mounted read-only, preventing any accidental system modifications.
Home Directory Containment: The user's HOME directory is presented to the agent in a highly restricted manner.
Target Bind: Only the specific project directory ($TARGET) is bound into the sandbox with full read/write permissions.
Overlay for Persistence: Sensitive personal folders (.config, .local, .cache) are mounted as overlays. This means the agent can read these files for context, but any writes it makes are confined to an in-memory, temporary copy that vanishes when the session ends, preventing permanent changes to your actual configuration.

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.

The Technical Implementation

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 / /: Mounts your entire file system as Read-Only. The sandboxed program can see your system files but cannot delete, rewrite, or modify anything in /usr, /etc, etc.
--dev-bind /dev /dev and --proc /proc: Exposes hardware devices and system process information so applications can function normally.
--tmpfs "$HOME" --tmpfs /var/tmp: Mounts empty temporary filesystems in RAM over your $HOME and /var/tmp. This completely hides your actual personal files from the sandbox.
--bind /tmp /tmp: Shares your host's actual temporary directory with the sandbox.
The --overlay-src ... --tmp-overlay ... lines: Create non-destructive overlay filesystems. The sandbox can read the files from your real .config or .local folders, but any new files or changes are written to temporary RAM storage. When the sandbox closes, those changes vanish.
--bind "$TARGET" "$TARGET": Makes an exception for your target folder. It mounts your specified path with real read/write access. Any files created or modified inside this folder will be saved permanently to your disk.
--chdir "$TARGET": Changes the working directory inside the sandbox to your target folder automatically.
"${@:-bash}": Executes the command you passed after the path. If you didn't specify a command, it drops you into an isolated bash shell by default.

Security vs. Convenience

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.