When you run a coding agent on your computer to assist you with software development you may be exposing the integrity of your machine, devices in your network and the secrecy of stored credentials like API keys, OAuth tokens and crypto private keys.
Chaotic Agents
Letting an LLM execute commands on your machine autonomously is one of the most useful features of a coding agent but it’s also risky. It’s useful because it allows the agent to make progress towards the stated goal much faster than with a human in the loop approving every command it needs to perform. It also frees up the developer to spin up multiple agents to tackle different features in parallel.
The risk is that LLMs can hallucinate and decide one day that the best way to fix a bug in your codebase is to delete your entire filesystem.
Co-opted Agents
Much in the same way humans can be fooled into revealing confidential information via social engineering, LLMs can be manipulated through prompt injection to bypass their safety measures. Prompt injection can take place when an agent searches the web and finds malicious instructions, when installing a new skill with hidden instructions or when cloning a project with a poisoned AGENTS.md file.
Hackers use these techniques to steal sensitive information from your computer like the private key of wallets, API keys of products and OAuth tokens of authenticated services (Google, AWS, Github, etc.). This information can be used to steal funds, blackmail you and even propagate the attack to other people via software you maintain. The latter is a type of attack known as a “worm”.
Malicious Agents
A less discussed risk is an agent that is trained from the ground up to perform malicious actions under certain conditions. The AI might operate honestly most of the time as a “sleeper agent” but under the right circumstances it could turn on its user. Governments are getting more involved in the development and distribution of LLMs which increases the risk of security agencies meddling in the training process.
It’s not far fetched to imagine an American model attempting to install a backdoor if it detects it’s being used on a machine from the Chinese government. Or a Chinese model that when detecting that it’s running inside an American corporation would attempt to steal proprietary IP.
You might think that open weight models are the antidote to this problem but open weight is not the same as open source. Without access to the training data, the training algorithm and a ZK proof of the training process itself you can never be certain if the downloaded model belongs to an honest or a malicious LLM waiting for the right moment to strike.
Aside from the exfiltration risk discussed above, a malicious agent might attempt to compromise other devices on your local network that are known to be vulnerable like printers, security cameras or the router itself.
Containers
To mitigate the risks mentioned before you could run the agent inside a container using Docker or Podman instead of directly in your host OS. This helps but it’s not ideal because the security boundary of a container is much weaker than that of a VM. Containers are a tool to run multiple services in parallel without stepping in each other’s toes, it was never designed to be a defensive mechanism to contain a rogue agent.
If you use Docker on Windows or MacOS the security of the system increases because the containers run inside a VM instead of directly on the host as its the case with Linux. This makes Docker less performant but creates a harder boundary between your host OS and the rogue agent.
Unfortunately this is still not good enough security as rogue agent could escape the container (it’s not a hard boundary) to land on the VM and once there it would have access to your entire filesystem which is mounted by default. Another problem with containers is that by default they have unrestricted access to the network allowing a rogue agent to breach other devices in your local network and communicate with the hacker’s server to steal your credentials and secrets.
Even if somehow you were able to meddle with the configuration of your containers and the defaults of the VM to harden its security at the cost of increased complexity and performance, this still wouldn’t solve the problem of how to shield your project secrets from the coding agent. You can explicitly tell an agent to never read the .env file of your project under any circumstance and it will eventually ignore you and scan it. They just can’t help themselves.
Sandboxes
Docker Inc. is aware of the limitations of containers when it comes to managing coding agents safely and this is why they developed a separate solution called “sandboxes”. A sandbox is a micro VM fine tuned to act as an isolated dev machine for a coding agent. Instead of having a master VM acting as the orchestrator of containers where projects and coding agents would ultimately live (like it’s the case for Docker Desktop on MacOS and Windows) you would have multiple dedicated VMs or “sandboxes” on your machine, one for each project and coding agent.
Another difference from the master VM of Docker Desktop and the micro VMs of Docker Sandbox is the level of isolation from your host OS. A sandbox doesn’t have access to host processes, it doesn’t have access to localhost and it can’t talk to other sandboxes. The only host folder that a sandbox has access to is the project folder and you can make this access read-only. Each sandbox has its own Docker Engine so a coding agent can spin up containers inside the micro VM for complex dev setups.
Another useful feature of Docker sandbox is that it prevents the coding agent from having access to project secrets like API keys and OAuth tokens which eliminates the risk of exfiltration. The idea behind this feature is a proxy managed by Docker that intercepts network calls coming from a sandbox to replace fake credentials with real ones on the fly.
The proxy also manages which domains the sandbox can reach out over the internet to prevent a rogue or co-opted agent from reaching out to a hacker’s server. The set of white-listed domains is fully configurable globally or per sandbox with sensible starting defaults.
Conclusion
Docker sandboxes are a robust solution to safely manage coding agents inside your computer in a way that protects your filesystem, your personal secrets and your project secrets. It’s a free to use software for individual developers requiring a license only for enterprise setups with centralized company rules.
For all its security benefits over Docker containers it has an important UX limitation: it’s only compatible with TUIs. I personally love to use VSCode to easily track changes made by an AI agent and ask questions about the codebase by selecting specific lines of code on the IDE but there isn’t a devcontainer equivalent for sandboxes.
Another glaring omission of Docker sandboxes is a mechanism for the agent to sign crypto transactions without exposing the private keys. Ideally a crypto private key should be handled like any other secret with a “sign” endpoint exposed to the sandbox for an agent to sign crypto transactions without ever having access to the private key.
Coding agents have disrupted the way we work as developers and drastically changed the risks we need to manage on our projects. Docker sandboxes are a step in the right direction that hopefully will continue to evolve to include more advanced use cases and obtain wider ecosystem support.
