Agent containment
Why AI agents that can run commands should run inside containers, and what containment does and does not buy you.
agentscontainerssecurityconcepts
Agent containment
An agent is an AI system that can take actions: read files, run commands, install packages, make network requests. That capability is the point — and it is also why the installation method matters more than which model the agent uses.
The core argument
An agent installed directly on your machine runs with your privileges. If it decides to reorganise your home directory, it can. If it is persuaded by poisoned content to run something harmful, it will.
A container narrows that to the filesystem and network access you grant. The blast radius becomes the container, which you can delete.
This is not a hypothetical. Prompt injection turns untrusted text — a web page, an email, a README — into instructions. An agent that can execute commands and also read untrusted text is a system where containment is the difference between "annoying" and "expensive".
How our recommended tools handle it
| Tool | Default posture |
|---|---|
| Agent Zero | The framework runs in a Docker container as the standard install |
| Hermes Agent | Installs as a CLI; we recommend its devcontainer |
Both approaches are legitimate. Agent Zero makes containment the path of least resistance. Hermes Agent gives you a choice, and we recommend choosing the container.
What containment actually buys
- Filesystem scope. The agent sees the container filesystem plus whatever you mount. A disposable work directory beats your home folder.
- Reversibility. Delete the container and its volume; the host is unchanged.
- Reproducibility. A pinned image is the same environment next month, on another machine, or on a colleague's laptop.
- A clear audit surface. What the agent can reach is declared in a compose file or devcontainer configuration, not scattered across your system.
What it does not buy
- It is not a security boundary against a determined attacker the way a hardened VM is. Containers share the host kernel.
- It does not stop data exfiltration if the container has network access and you have mounted secrets. Mounted credentials are available inside the container by definition.
- It does not constrain a mounted directory. Mount all of
$HOMEand you have recreated the problem inside a container. - It does not protect against a bad decision you approved. If you tell the agent to delete a mounted directory, persistence is a feature.
Practical rules
- Mount the smallest directory that does the job. Project folder, not home directory.
- Keep secrets out of the container unless the task needs them, and revoke them after.
- Treat any port you publish as public. Default credentials — like the Hermes devcontainer's published dashboard password — must be changed before exposure.
- Copy valuable output out of the container; the volume is working state, not a backup.
- Use a local model endpoint when the task involves confidential material, so prompts do not leave your network either.
Related
The Agent Zero container-first installation and the Hermes devcontainer's mounts, volume, and default credentials are documented in their respective repositories, read on 2026-10-28. Claims about container isolation limits are general Linux container behaviour, not tool-specific.