Sandboxing
Agent Harbor provides comprehensive sandbox isolation to ensure AI coding agents cannot harm your computer, access sensitive files, or interfere with each other.
Security Posture
The sandbox is designed with a clear threat model: agents execute potentially hostile code. Defense-in-depth principles apply throughout:
- No publicly known sandbox escapes
- Least privilege everywhere
- Host, secrets, and other tenants protected
Sandbox Strategies
Agent Harbor supports multiple sandboxing approaches:
| Strategy | Description | Use Case |
|---|---|---|
| Local Sandbox | OS-native isolation (namespaces, seccomp) | Default for most users |
| Docker Devcontainer | Containerized environment | VS Code / devcontainer.json |
| Virtual Machine | Full VM isolation | Maximum security |
| No Sandbox | Pre-sandboxed environment | Corporate VDI, Codespaces |
Filesystem Isolation
Read-Only Baseline
The host filesystem is treated as read-only:
- Agents see your project files but cannot modify them directly
- All writes go to a copy-on-write overlay
- Changes are discarded when the session ends (unless explicitly saved)
Sensitive Areas Shielded
By default, access to sensitive directories is blocked:
| Path | Content | Access |
|---|---|---|
~/.ssh | SSH keys | Blocked |
~/.gnupg | GPG keys | Blocked |
~/.aws | AWS credentials | Blocked |
~/.config/gcloud | GCloud credentials | Blocked |
~/.azure | Azure credentials | Blocked |
Dynamic Read Allow-List
Two access control models are available:
Default (Interactive Approval)
- First access to a non-allowed path blocks until you approve or deny
- Access can be granted without restarting the session
- Choices can be saved to user, project, or organization config
Relaxed Mode (Blacklist)
- Read-only view with configurable blacklist for sensitive directories
- Configurable set of writable overlays
- No interactive gating
Writable Carve-Outs
Package manager caches can be made writable for efficiency:
# .ah/config.toml
[sandbox.writable_paths]
paths = [
"~/.cargo/registry",
"~/.cache/pip",
"~/.npm/_cacache",
"~/.cache/go-build"
]Process Isolation
Agents see only their own session processes:
ps,kill, and similar commands only show session processes- No cross-tenant visibility
- Debugging is supported within the sandbox
Network Isolation
Network access is controlled per-session:
| Setting | Behavior |
|---|---|
| Default | Egress disabled, no inbound |
--allow-network true | Egress enabled (opt-in) |
| Inbound | Never allowed unless explicitly configured |
Resource Governance
Per-session limits prevent runaway builds/tests:
| Resource | Control |
|---|---|
| CPU | Core limits |
| Memory | Memory ceiling |
| PIDs | Process count limit |
| I/O | Bandwidth throttling |
Nested Virtualization
Launching containers and VMs inside the sandbox is supported:
# Allow container operations (Docker, Podman)
ah agent start --agent claude --sandbox --allow-containers true --prompt "Build image"
# Allow KVM/VM operations
ah agent start --agent claude --sandbox --allow-kvm true --prompt "Test in VM"Note: These options enable controlled access without exposing host control sockets.
Privilege Model
- No-sudo startup — Privileged steps happen in short-lived helpers that drop privileges immediately
- Capabilities dropped — Workloads run with minimal privileges
- Supervisor external — The supervisor process stays outside the sandboxed context
Usage
Enable Sandbox
ah agent start --agent claude --sandbox --prompt "Run tests"With Specific Sandbox Type
# Local process sandbox (default)
ah agent start --agent claude --sandbox --sandbox-type local --prompt "Run tests"
# Devcontainer
ah agent start --agent claude --sandbox --sandbox-type devcontainer --prompt "Build"
# VM isolation
ah agent start --agent claude --sandbox --sandbox-type vm --prompt "Run untrusted code"With Network Access
ah agent start --agent claude --sandbox --allow-network true --prompt "Install dependencies"With Container Access
ah agent start --agent claude --sandbox --allow-containers true --prompt "Build Docker image"CLI Options
| Flag | Description | Default |
|---|---|---|
--sandbox | Enable sandbox mode | false |
--sandbox-type <TYPE> | Sandbox type: local, devcontainer, vm | local |
--allow-network <BOOL> | Allow network egress | false |
--allow-containers <BOOL> | Allow container operations | false |
--allow-kvm <BOOL> | Allow KVM/VM operations | false |
Platform Support
| Feature | Linux | macOS | Windows |
|---|---|---|---|
| Filesystem isolation | Yes | Yes | Yes |
| Process isolation | Yes | Yes | Yes |
| Network isolation | Yes | Yes | Partial |
| Container access | Yes | Yes | Yes |
| KVM access | Yes | No | No |
Acceptance Criteria
A properly configured sandbox:
- Launches and tears down in seconds with no host residue
- Prevents writes outside approved locations
- Blocks secrets access without explicit approval
- Allows debugging of in-session processes while hiding host processes
- Makes internet/container/VM access a conscious, explicit action