Imagine hiring a brilliant employee who works 24 hours a day, never complains, and solves tasks in minutes. There's just one detail: on the first day, they receive the key to every room in the company. The vault, the HR file, the server room. No one would do that with a human, no matter how good their resume is. And yet, that's exactly what most people do when they install an AI agent on their computer: they give it access to everything and hope for the best.
This post introduces the ai-jail, a free and open-source tool created by Brazilian Fabio Akita, one of the country's most respected software engineers. The proposal is simple: put the AI agent in a cage where it can work, but can't cause harm. You'll understand why this has become a must-have for anyone using agents, such as the cage works from the inside out, and how to use it in practice, even if you're not tech-savvy. At the end, there's a checklist with ready-to-use commands.
The agent needs access, and access is the problem
AI agents that actually work (like Claude Code, Codex, and similar ones) don't just chat: they read files, create documents, execute commands, and install components. That's what makes them useful. An agent without access to the computer is just a nice chat.
The problem is that the same access that allows creating a report also allows reading saved passwords in the browser, copying keys that grant access to company servers, and deleting entire folders. The agent doesn't need to be malicious to cause damage. All it takes is an ambiguous instruction, a moment of model confusion, and the wrong command runs in the wrong folder. This is not a hypothesis: we've already reported the case of the AI model that deleted files on its own, without anyone asking.
And there's a second, more silent risk. Agents install third-party components all the time, which is part of their job. If one of these components is tampered with (which happens with increasing frequency in the software world), the malicious code runs inside your computer with the same permissions as the agent. It's like a supplier delivering a sabotaged part inside your factory: the problem didn't come in through the front door, it came with the merchandise.
In other words: you need to give access for the agent to work, but each additional access is a risk surface. The right question isn't "do I trust the agent?", it's "what happens if it fails?".
What is ai-jail
The ai-jail is a small program (less than 1 MB) that works like a strict doorman. Instead of opening the AI agent directly, you open the agent through the ai-jail. From then on, the agent sees a different computer: one where only the project folder exists.
The best analogy is a glass-walled meeting room. The external consultant enters, receives only the documents for that project, and works freely inside the room. They don't circulate through the building, don't open drawers from other departments, and don't know where the vault is. When the meeting is over, the room is completely cleaned up. Everything they produced that's useful stays in the project file; any paper they scattered outside goes to the shredder.
The most important point: it's not a rule that the agent promises to follow, it's a wall that it can't cross. The restriction happens at the operating system level, below the AI. It doesn't depend on the model being obedient, and that's what differentiates this approach from simply writing "don't touch other folders" in the agent's instructions. As we've already shown in guardrails aren't enough, instruction is a request; wall is a guarantee.
What the cage hides and what it allows
By default, the ai-jail organizes the computer into three zones:
Never enter the room. Access keys to servers, cloud service credentials, browser data. For the agent, these files simply don't exist. It can't see, read, or copy them, because from inside the cage, they're not there.
Visible, but untouchable. System programs are available for reading only. The agent can use the computer's tools, but can't alter or break them.
Free. The current project folder is the only place where the agent writes for real. It's their workspace. Everything they produce that's useful stays there.
And there's the detail of the clean desk: temporary areas are created new each session and destroyed when the ai-jail closes. If the agent scattered files outside the project, they evaporate when it exits.
One caveat that the author himself highlights: password files that live inside the project folder (the famous .env file, where many systems store credentials) remain visible, because they're on the workspace. For these, there's a specific command that masks them, and it's in the checklist at the end.
How to use in practice
Installation is a single line in the terminal (works on Mac and Linux; on Windows, it works through WSL, the Linux environment that Microsoft embeds in the system). Those who already use the Homebrew manager install with a single command.
And daily use changes almost nothing in the routine: instead of opening the agent by typing claude, you type ai-jail claude. That's it. The agent opens normally, works normally, and doesn't even notice it's in a cage. The same applies to other agents: ai-jail codex, ai-jail opencode, and so on.
Three features deserve highlight for those starting out:
- Risk-free trial: the command with
--dry-runshows exactly what the cage will hide and allow, without executing anything. Good for checking before trusting. - Password masking:
--mask .envhides the credential files that live inside the project. The agent sees an empty file in its place. - Lockdown mode:
--lockdownis the most restrictive mode, where the agent can't write anywhere and is without a network. It's the right mode for analyzing code that came from outside and that you don't trust.
And the best for the team's daily life: the choices are recorded in a configuration file inside the project. In practice, this turns protection into written policy, which applies itself every time someone opens the agent in that project. It doesn't depend on memory or goodwill from each team member.
What ai-jail doesn't solve
The author himself is straightforward: it's not 100% secure, and no cage is. To run truly suspicious code, the right thing to do is still a disposable virtual machine, a fake computer that you throw away afterwards. The cage protects against error and carelessness, which are the vast majority of incidents, not against a sophisticated attack directed at your company.
And it protects the computer, not the entire operation. Who decides what the agent can do in the company system, which data it accesses, who approves sensitive actions, and what gets recorded is another layer of governance, which we've already detailed in control of AI agent access and in 4 doors that AI doesn't cross. The cage is the seatbelt: it doesn't replace prudent driving, but no one should drive without it.
The rule that's worth adopting today
If your company already uses AI agents, or has team members using them on their own (and it does, even if you don't know), the policy fits in one line: no agent runs outside the cage. The cost is typing seven more characters in the command. The benefit is that the agent's worst day stops being the company's worst day.
It's the same principle we apply when we implement private agents in clients: isolation isn't an accessory that you add after the incident, it's part of the design from day one. The difference between AI that delivers results and AI that becomes an internal headline rarely lies in the model. It lies in what it's allowed to touch.
