I trust my coding agents with production secrets now

I give my coding agents direct access to important secrets, including my Tailscale auth key, SSH private keys, Anthropic and Codex OAuth tokens, and my Gmail app password.

I’ve been running Linux servers for decades, worked as a security engineer, and built production systems for many companies, including an AI coding agent platform used by hundreds of thousands of people. So I understand the risks involved as well as anyone.

My setup has all three parts of Simon Willison’s lethal trifecta. My agents have access to private data, read untrusted content, and can communicate externally. An attacker could (in theory) hide instructions in a webpage or file that trick an agent into sending them my secrets.

Security is always a productivity-risk tradeoff

By giving agents production access I’m giving them the ability to investigate outages, read logs, deploy a fix, and check that it worked. Without that access, I have to do those steps, which slows things down significantly.

There’s a real tradeoff between limiting what an agent can do and letting it get work done.

I give agents production access for the same reason I give access to inexperienced teammates. I know a new teammate could install malware or fall for a phishing attack, but I still give them the access they need to do their job.

Frontier models are hard to trick

I run Claude and Codex exclusively, using frontier models like Astra and Fable for hard problems (Opus and Sol for routine work). I wouldn’t have given older models this much access, but prompt injection worries me a lot less with these models. The models are getting better at distinguishing the user’s instructions from malicious instructions in the content they read.¹

This applies to coding agents with access to your own trusted codebase. Opening a random GitHub project with this much access would be a very bad idea.²

Why I still run agents in Docker containers

Although I trust my agents with secrets now, I still run them in isolated Docker containers. Each agent gets its own checkout and can run dev servers without trampling on another agent’s work. I don’t have to juggle Git worktrees or clean up processes and files my agents leave behind.

Agents still make mistakes, like running rm -rf in the wrong directory. I almost never run them on my bare hosts unless the task requires it.

But I’m not relying on containers to stop a malicious or hijacked agent from doing damage. My agents still have access to secrets and production machines, and I’m trusting them with that access.

What about least privilege?

Ideally we’d follow least privilege and give each agent only the access it needs for the task. We may eventually have fine enough control to make that practical without constantly getting in the way.

But people often talk about merely hiding credentials as if it removes the biggest risk, which is silly. An agent that never sees my SSH private key but gets a root shell on my production server can still rm -rf the production system.³

We may want tight controls on agents for a long time, but assuming we’ll always need them is, on some level, a bet against continued dramatic improvements in the models.

As models improve, we may end up trusting our agents with access even more than we trust ourselves.