Give an AI agent a real shell, not autocomplete, but an agent that can read logs, draft a migration, open a PR, or gather context during an incident, and it gets useful fast. Then you hit the part nobody warns you about: the moment that agent can run commands, it has the blast radius of the machine it runs on, which is to say everything you have ever authenticated to from that machine.
An agent that can run kubectl is also an agent that can run kubectl wrong. An agent that can read your repo can also read the .env sitting next to it. The model doesn’t have to be malicious. A confused tool call, a prompt-injected web page, a hallucinated rm, and now your agent has the same blast radius your laptop does, which is to say: everything you have ever authenticated to.
So the interesting engineering in “AI agents doing ops” isn’t the prompting. It’s the box you run them in.
I built agent-box for exactly this: a devcontainer the agent lives inside, designed so that even a fully compromised agent can’t reach anything that matters. The rules that make it work are boring and strict:
- cap-drop ALL and no-new-privileges. The container starts with no Linux capabilities and can’t acquire more. Most “agent escape” stories assume privileges the box simply doesn’t have.
- No host credential mounts. The agent never sees
~/.aws,~/.kube,~/.config/gcloud, or your SSH keys. If it gets injected, there is nothing local to steal. - Non-interactive auth only. It authenticates through scoped, non-interactive OAuth or API tokens for the task at hand, never a long-lived key baked into the environment. It gets what it needs to do the job and nothing that outlives it.
- Non-root, workspace-scoped writes. It can edit the project it is working on. It cannot touch the rest of the machine.
What changed it for me was treating the agent not as a smarter shell, but as untrusted code that happens to be useful. You wouldn’t run a random binary from the internet against your production credentials. An agent acting on instructions from a web page it just fetched is closer to that than people like to admit.
And increasingly you don’t babysit it. The pattern people now call a Ralph loop, point an agent at a goal and let it iterate, observe, and retry until it thinks it’s done, is useful and unnerving for the same reason: it runs unattended. A wrong turn you would have caught in a chat session just repeats. A prompt injection persists across iterations. Cost compounds quietly. The loop is exactly the moment a hard ceiling on what the agent can reach stops being nice to have and becomes the only thing between “it iterated to a fix” and “it iterated your cluster into the ground.” I built agent-box so a loop like that can run without being a reckless thing to do.
Where it netted out, for me: the agent was good at the parts I’m slow at, gathering context, reading across logs, drafting the boring first version of a change. But it was only worth reaching for once it had a hard ceiling on what it could do when it got something wrong. The capability turned out to be the easy half; building the cage was the harder part.
The useful version of this and the dangerous version are the same agent. The only difference is the box around it.