In my previous post, I wrote that I barely write code by hand anymore. I mostly manage agents and check their work. And it turns out it’s easy to mistake an agreement in chat for an actual restriction: you give an agent a terminal, Git, server access, and tell it “don’t touch prod.” It agrees, of course, but it still has all the access.
Say the task is to fix order processing and run the tests. All it needs is a working copy of the project and a test database. But the agent is running in your usual environment, with all the production credentials and everything else sitting there. So you gave it a specific, narrow task, but it has access to everything.
From there, all it takes is mixing up a database address, misunderstanding a command, or following instructions from someone else’s document. How much damage that can cause ultimately depends on what the agent can reach.
Restrictions need to be enforced outside the model, with no way for it to change or bypass them. Basically, the good old principle of least privilege, which people seem to be forgetting about when working with agents.
I started with an isolated working environment that only gives the agent access to what it needs for the task. Connected tools need to be accounted for too: if an MCP tool can run a command in production, isolating the local environment won’t remove that access.
For repository work, I use separate permissions covering only the repo it needs and the necessary operations. The agent prepares changes and runs checks, while rules it cannot change or bypass control what gets into main.
CI is worth checking separately because, depending on how it’s configured, of course, code from the PR runs on the runner during builds and tests. If production credentials are accessible there, that code can use them too.
For production deployments, I’ve kept mandatory approval on my side, enforced through CI/CD. The agent cannot approve a deployment itself or change the rules.
I want to be able to leave agents running overnight without worrying: let them write code, run tests, make mistakes, and fix them. But an attempt to connect to the production database should end with access denied.
Top comments (0)