Jailed-Agents: Restrict Your AI Coding Agents' System Access

jailed-agents is a Nix-based tool that runs AI coding agents inside a sandbox with restricted system access. This post explains why sandboxing coding agents matters, what jailed-agents is, and how to use it. It is aimed at developers who run AI coding agents and want to limit what those agents can touch on their machines.

Why sandbox your coding agents?

Security is a big challenge when working with coding agents. If you run them as a normal application under your user account, the agent gets access to all the credentials available on your system for that user.

You want to put your coding agents into a jail where they have limited resources and limited access to the outside world. At the same time, you want a flexible solution: for some projects, access to some MCP or other resources makes sense and has low security risks, while for others it is a total no-go.

Many options exist, like VMs and Docker containers. VMs provide the best isolation level, but they also have overhead (e.g. RAM, storage) and lag in flexibility. Docker could also be an option, but it was never invented for this use case. Depending on your use case, you have to build additional Docker images and configure additional access for the container — the main goal here is to limit access, not to provide portability.

In the end, there is currently no single solution for the problem of rogue AI. If you want the best secure option, use a VM, e.g. with firecracker. But the investment to get a good workflow can be high. On the other side, if you want total usability, you do nothing and wait for the first secret leaks or database failures — because the agent did not understand that the data should not be deleted, even if you told it otherwise.

Jailed agents could be a good compromise for AI coding agents running in a sandbox. They are also easy to integrate into devenv, so that every developer in your company has the same secure agent setup.

What jailed-agents is

• Zero-trust sandbox: it shares almost nothing with the host by default — everything is explicit whitelisting.
• Declarative tooling: every access and every dependency is provided by the same Nix package definition.
• Built on the Nix ecosystem, so it also runs on any Linux distribution, macOS, or Windows.
• Predefined configurations for claude-code, codex, hermes-agents, opencode, pi, and more.
• You can build your own custom agents with the provided functions.
• It uses jail-nix as its core, which is a Nix wrapper for bubblewrap.

How it works

The simplest solution is to just run:

But this will most likely not fit your needs — it just runs the predefined packages. Most of the time, you want to customize the jailed agent package to solve your needs. It can be installed in your nix profile, flake, devshell, or devenv.

An example for a nix flake could look like the following:

The most important part is the myJailedAgent variable, which results in a reusable package. It provides the declaration for the package.

Apart from forwarding environment variables or sharing host folders, the flexibility comes from the combinators, which come from jail.nix. You can, for example, share the host time zone, and you can override the hostname of the agent's jail: if you ask a capable agent about its hostname, it will give you the name. There are a lot of other combinators, like camera to share the host's camera, or add-runtime to run code before the agent starts.

This allows you to use the jailed agent with just nix installed:

As already mentioned, you can also install the defined jailed agent package into your system environment, e.g. by using a nix profile. The package can then also be provided by a shared repository. You can also define a module which has approved defaults and can be extended or changed by each developer.

Summary

Jailed agents provide a flexible and declarative way to configure your agents with security in mind. The solution is lightweight and can be reused by multiple developers.