AI Agent Filesystem Sandboxing: Containers vs Virtual FS Layers

Sandboxing AI Agent Filesystems: Containers vs Virtual FS Layers

Alan West evaluates filesystem access architectures for AI agents to prevent unauthorized actions like recursive deletion. He notes that container-based isolation, while secure, requires pre-baking every binary the agent might invoke into the image.

Why This Matters

Naive filesystem access allows AI processes to read any host file, creating significant security risks for development environments containing SSH keys and tokens. While container isolation offers a bounded blast radius, it introduces high startup latency and tooling friction, necessitating a middle ground where agent intentions are reviewed before hitting the physical disk. This technical reality forces a choice between physical isolation and the logical review-before-apply workflows provided by emerging virtual filesystem layers.

Key Insights

• Raw FS allowlists are susceptible to TOCTOU races and symlink-based path escapes that can compromise host security.
• Container isolation (Docker) provides a physical blast radius boundary but adds seconds of startup latency and significant tooling overhead.
• The Mirage project (2026) implements a virtual filesystem layer that stages changes in memory for human review before disk commitment.
• Review-before-apply models allow developers to inspect multiple file edits as a single diff before applying changes to the real filesystem.
• Logical isolation in virtual filesystems does not inherently contain subprocesses unless execution calls are specifically wrapped.

Working Examples

Naive Raw FS access with path-resolution allowlists to prevent workspace escapes.

from pathlib import Path; WORK_DIR = Path('/tmp/agent-workspace').resolve(); def safe_read(rel_path: str) -> str: target = (WORK_DIR / rel_path).resolve(); if not target.is_relative_to(WORK_DIR): raise PermissionError('path escapes workspace'); return target.read_text(); def safe_write(rel_path: str, content: str) -> None: target = (WORK_DIR / rel_path).resolve(); if not target.is_relative_to(WORK_DIR): raise PermissionError('path escapes workspace'); target.write_text(content)

Container-based isolation using Docker to bound the agent’s blast radius.

docker run --rm --network=none -v "$PWD/workspace:/work:rw" -v "$PWD/readonly-context:/ctx:ro" --read-only --tmpfs /tmp:size=512m agent-image:latest

Conceptual sketch of a virtual filesystem layer for staging agent changes.

fs = VirtualFS(root='./project', mode='overlay'); fs.write('src/app.py', new_content); diff = fs.pending_changes(); fs.commit()

Migration pattern from raw FS tools to a virtual filesystem with a review loop.

def read_file_tool(path: str) -> str: return fs.read(path); def write_file_tool(path: str, content: str) -> None: fs.write(path, content); def step_complete(): show_diff(fs.pending_changes()); if user_approves(): fs.commit(); else: fs.discard()

Practical Applications

• Interactive Agent Loops: Using Virtual FS to stage changes for human approval before committing to a repository. Pitfall: Relying on logical isolation for subprocesses which may bypass the VFS to access the real host.
• Production Coding Agents: Utilizing Container Isolation for real code changes to ensure physical containment of the agent process. Pitfall: High developer friction due to missing binary dependencies in the container image.

References:

• https://dev.to/alanwest/sandboxing-ai-agent-filesystems-containers-vs-virtual-fs-layers-ffe