I run AI agents on a dev box with no leash. I let them graze the free range, and I'd tell you to do the same.
Production is a different pasture. An agent that can touch prod is a junior admin who never sleeps and never second-guesses, and your career is the collateral.
Most people hand an agent their own login because it's the fastest path. Their session, their SSH keys, their database password. Then they act surprised when the agent can do everything they can. That's not an AI problem. That's an access model nobody designed.
Give Every Agent Its Own Identity
Create a user ID for each agent. Give it scoped privileges. If the agent only needs to read logs, it gets read access to the log directory. If it needs to restart one service, it gets a sudoers entry for that one command and nothing else.
Don't run agents as yourself. This is the old principle of least privilege, and it didn't stop applying because the new employee is a language model.
On a dev box, let them run wild. Break it, rebuild it, learn something. That's what dev boxes are for.
Put a Human Between the Change and Production
One approval. Maybe two. The agent can write the change, draft the pull request, even prepare the deploy. It does not get to skip the person.
This isn't about speed. When something breaks in production, it should be because a human made a call, not because a model misread a long conversation and decided to be helpful.
Be Stingy With Passwordless Sudo
I'm not telling you never to use it. A throwaway dev box is fine. So is a narrow command on an allowlist you've thought through.
On anything that touches production, root requests go to a person. Wire it to Windows Hello on your laptop and approving becomes a swipe. It's about 15 minutes of work. The agent asks, you swipe, the command runs. If you're not there, it doesn't.
Public-Facing Agents Can't Read Anything Sensitive
If an agent talks to the public, it must be unable to read your keys. Not told not to. Unable.
Draw your security zones. Put the public-facing agent in its own account, on its own network rules, with credentials that open one door. If it gets compromised, you lose one surface, not the building.
Don't Let a Prompt Be Your Security
A system prompt that says "don't read the .env file" is a suggestion. A CLAUDE.md that says "never touch production" is a suggestion. Agents are very good at reading suggestions as optional.
The boundary has to hold when the agent ignores it. That means:
- File permissions, so the agent's user ID can't read the key file at all.
- Separate accounts and network rules, so the public-facing agent can't reach the vault or the production host.
- Credentials issued per agent with narrow scopes, so a leak costs you one door, not the building.
- Checks at the tool call, so a forbidden command is refused before it runs, whatever the prompt said.
If breaking the rule takes the agent disobeying you, you have a hope. If it takes the agent breaking the operating system, you have a boundary.
Related reading on this site: Would You Give This to an Employee? asks the same question from the access-model side, and If Your Agents Are Destroying Things covers what happens when the structure isn't there.
#FreeRangeSudo is a great way to lose a weekend. Or a job.
— J.P. Howlett
