Files

T

ducoterra ed2eb462d6 share the host ~/.agents read-only, so skills come along

A sandboxed harness found none of your skills, prompt templates or
standing AGENTS.md, because those live in ~/.agents and only the project
was mounted. It is now bind-mounted at /home/sandbox/.agents by default
-- bound, never copied -- with --no-agents to opt out and --agents-dir
for a curated set, reported by --print-policy and by doctor.

Read-only is the load-bearing part and has no escape hatch: a skill is an
instruction the model follows later, on the host, so a sandbox that could
write ~/.agents had a persistence path out of itself, planted as a
helpful-looking SKILL.md. It holds even under --insecure-keep-root, the
mount lands after /home/sandbox itself so it cannot be shadowed by the
home volume or tmpfs, and an explicit --mount on the same destination
wins because podman refuses duplicates. A missing or unreadable directory
is a silent skip like the pi bridge's; an explicit --agents-dir that
resolves to nothing is a hard error.

The exposure is stated in docs/threat-model.md: the tree, its .git history
and anything pasted into a skill are readable by whatever runs in there.

tests/unit/09_agents.sh covers resolution, precedence and the
bind-never-copy canary; tests/e2e/12_sandbox.sh mounts it in a real
container, checks the host tree survives a run byte for byte and that
even root inside the sandbox cannot write it.

LLM-Generated: true

2026-10-27 20:30:53 -04:00

7.5 KiB

Raw Blame History

Threat model

Read this before relying on ai-sandbox. It is a seatbelt, not a jail: it raises the cost of an agent's mistakes and of a moderately compromised prompt context, on a machine you still log into as yourself.

Who we assume is hostile

The modelled adversary is the agent you are running: an LLM harness with your write access to one directory, capable of running arbitrary shell commands, and vulnerable to prompt injection from the files it reads, the web pages it fetches, and the package changelogs it installs. We assume it will try to escape when a prompt injection tells it to.

We do not model a kernel-level adversary, a hostile container image from a registry you don't control, or someone with access to your host user account.

What stops working (defence in depth, most to least load-bearing)

Attack	Stopped by	Evidence
Editing / deleting anything outside the project directory	`$PWD` is the only writable mount; the rest of the host is not in the mount namespace	`tests/e2e/12_sandbox.sh`
Rewriting your skills, prompts or global `AGENTS.md`	`~/.agents` is mounted, but read-only, and there is no flag to change that	`tests/e2e/12_sandbox.sh`
Reading `~/.ssh`, `~/.aws`, `~/.config/gcloud`, browser profiles	same as above; those paths do not exist in the container	`tests/e2e/12_sandbox.sh`
Exfiltrating your environment (API keys for other services)	nothing is passed through unless named with `--env`	`tests/unit/04_env.sh`, `tests/e2e/12_sandbox.sh`
Passing secrets through the process list to other users	values travel in a `0600` file, never in argv	`tests/e2e/12_sandbox.sh`
Egress to an arbitrary host (curl, python, a raw socket, a bespoke exfil tool)	netfilter `policy drop` inside the container's namespace	`tests/e2e/11_net.sh`
Egress through the proxy to a non-allowlisted domain, including HTTPS	squid's `http_access deny all` after the allowlist	`tests/e2e/11_net.sh`
Deleting or weakening the egress ruleset	the command runs with no capabilities; `CAP_NET_ADMIN` was dropped across `exec`	`tests/e2e/11_net.sh`
`unshare -n` to get a fresh namespace with its own routes	requires `CAP_SYS_ADMIN`, which the command does not have	`tests/e2e/11_net.sh`
Privilege escalation via a setuid binary in the image	`--security-opt no-new-privileges` + `--cap-drop=ALL`	container config, asserted in `tests/e2e/10_image.sh`
Reaching other host services on loopback	only the gate's port is routable through the mapped loopback address	`tests/e2e/11_net.sh`
Fork bombs, memory bombs, runaway builds	`--pids-limit`, `--memory`, `--cpus`, `--tmpfs` sizes	`tests/e2e/10_image.sh`
Writing to the host's package manager, `/etc`, global npm/pip	read-only-ish image, `HOME` inside the container, optional `--read-only`	`tests/e2e/12_sandbox.sh`
Credential persistence you did not ask for	`--ephemeral-home`; the default home volume is named and inspectable	`tests/e2e/12_sandbox.sh`
Silent wide-open starts	an empty allowlist in `allow` mode is a hard error	`tests/unit/01_args.sh`

What does not stop it

Be honest about these, and design your work accordingly.

Anything you allowlist is reachable, in both directions. Allow api.github.com and a prompt-injected agent can push your code to a repository it controls, using the token you deliberately handed it. The allowlist limits where, not what. Prefer least-privilege, read-only, short-lived tokens.
The project directory is genuinely writable. A bad rm -rf, a force push, a corrupted lockfile all still happen — just confined to that directory. Keep the tree committed (ai-sandbox doctor warns you when it is dirty).
Kernel and runtime escapes. A container is not a VM. A container escape vulnerability in runc/crun or the kernel gets an attacker to your user account. For genuinely untrusted code, use a VM or a disposable machine.
--net full and the escape hatches do what they say. --allow-unenforced, --insecure-keep-root, --mount, AISB_EXTRA_ARGS, --net full all weaken the posture. They are named to be uncomfortable on purpose; nothing uses them implicitly.
Side channels. Timing, resource consumption, and "the agent typed X into a form on a site you allowed" are out of scope.
A cached home volume can hold credentials. If a harness logs in inside the sandbox, the token lives in the aisb-home volume, and any later sandbox run using that volume can read it. --ephemeral-home per run, or a dedicated AISB_HOME_VOLUME per trust level.
DNS is closed in gate mode, open in --no-gate mode. With --no-gate, name lookups leave the container; that is a modest data channel and a fingerprint of what you are doing. Egress to non-allowlisted IPs stays blocked either way.
The gate sees everything that flows through it — including any credentials in proxied requests. That is the point of an egress proxy; the squid config logs to its own container log, and gate logs shows them. Do not put secrets in URLs.
Supply chain inside the allowlist. registry.npmjs.org allowlisted means any package, including a typosquatted one, can be fetched. Allowlisting a domain is not a security review of what you install from it.
Rootless podman still means shared kernel and shared UID namespace. Files the container writes are owned by you. There is no uid boundary between "agent's file" and "your file" beyond ownership metadata and your own discipline.
Your ~/.agents is readable inside the sandbox. This is a deliberate exception to "only your project directory is mounted", because a harness without your skills is a harness you re-brief every run: ~/.agents arrives read-only at /home/sandbox/.agents (--no-agents for a run without it, --agents-dir for a curated set). Read-only means the agent cannot write a SKILL.md that you will follow tomorrow on the host — that is the part that matters, and it holds even under --insecure-keep-root. It does not mean the contents are secret: the whole tree, including its .git history and any token someone pasted into a skill, is readable by whatever you run in there. Treat a shared skill directory as published to the agent, lint it for secrets (skill-lint), and keep credentials in the environment you pass explicitly rather than in a file that is mounted everywhere.
The pi bridge reads a file that may hold a live key. It rewrites apiKey to an environment reference and never copies auth.json, but the endpoint in your models.json becomes an endpoint the sandbox can be pointed at, and the token it uses is your real one. So the bridged config is a convenience, not a narrower credential: prefer a per-sandbox token from your gateway if it can mint one, and note that a bridged run whose token variable is unset or empty is refused rather than started. Sandboxed edits to ~/.pi/agent persist in the home volume and are kept over later host changes (see the README), which is convenience with a consequence: a hostile run could rewrite the sandboxed pi config for later runs of that volume. --ephemeral-home removes that.

Residual risk rating

Accidental destruction and ambient credential leakage: largely eliminated. Deliberate data exfiltration over an allowlisted path: mitigated, not prevented. Container escape to the host: out of scope, accept it or use a VM.

7.5 KiB Raw Blame History