Don't hand your coding agent the keys to production

I run a coding agent that does real work while I am not watching it. That sentence should make you slightly nervous, and this week it made me go back and check exactly what mine can and cannot reach. What sent me looking was a writeup where a researcher took the new act-without-asking mode a lot of us just switched on, handed it an ordinary looking task, and watched it chain through into running code the operator never authorized. The safety layer that was supposed to stop that had reportedly posted a perfect zero percent injection-success rate on the vendor's own eval. In the wild it failed anyway.

So here is the honest answer to "is auto mode safe," because I think a lot of vibe coders are quietly asking it and not liking the silence. The safety toggle is a best-effort classifier, not a boundary, and you should stop treating it as one. The fix is almost always architectural rather than a smarter filter: give the agent no credential path to the irreversible thing, keep a human in front of destructive actions, and build the revert before you ever hand it the keys. A classifier guesses. A boundary refuses.

why the safety toggle is a classifier, not a boundary

The toggle scores each command for danger and lets through whatever it scores as safe. That is a surface check, and a surface check catches what it was told to catch and nothing else. The command that wipes your database is rarely the one that reads as dangerous. It is the third step of a benign looking chain the scorer never scored as a unit, or a phrasing nobody enumerated. I learned the small-key version of this the night I tried to jailbreak my own chatbot: a blocklist matching banned strings failed open the first time the attack was reworded, and the thing that held was the layer the attack could not route around. Same shape here, much bigger stakes, and I wrote that smaller story up in the voice spec that stopped a jailbreak.

There is an uglier detail in the researcher's writeup worth sitting with. The same classifier that allowed the harmful step then blocked the agent's own attempt to clean up after itself. A control that permits the damage and forbids the fix was never a control. And the mechanism is not exotic: an agent runs what it reads, so a poisoned input in a page it was told to summarize becomes an instruction it follows, which is the whole problem I chewed on in your agent runs what it reads.

how do I stop an agent from running a destructive command

Stop trying to make the agent smart enough to be safe and start removing its ability to do the unsafe thing. Three moves, in order of how much they buy you.

Least privilege first. The agent should be holding credentials that literally cannot perform the irreversible action. If the role it runs under has no DROP and no DELETE on production, then no prompt, clever or accidental, turns into a wiped table, because the permission is not there to abuse. This is the single highest-leverage change and it is boring plumbing, which is exactly why it works. I made the case for it on its own in the agent that can't drop the database.

Then isolation and egress. Run the agent where it can reach only what the task needs, not your whole machine, your shell history, and the open internet. An agent that cannot phone out cannot be steered into exfiltrating anything, and an agent boxed to one repo cannot reach into another. Last, a human gate on the short list of truly irreversible operations: touching production data, force-pushing, deleting, moving money. Even in auto mode, those keep a confirm step. That is not the same as approving every line; it is putting one real stop in front of the handful of actions you cannot take back. The layered shape of all this is what real guardrails look like.

build the failure mode before the happy path

Here is the discipline underneath all three moves, and it is the one I would tattoo on a new vibe coder if they let me: build the failure mode first. When I built the pipeline that publishes posts without me watching, the very first thing I wrote and tested was the command that pulls a post back down, before the thing that ships a post even existed. The undo came before the do. So the worst case of an unattended writer was always "one command, decided while calm," never a 2am scramble to reverse something I did not plan for.

Point that same habit at an agent with write access. Before you turn on the convenience, name the worst irreversible thing it could do, and build the recovery for that specific thing first. A tested restore path, a known-good snapshot it cannot reach, a one-command rollback you have actually run once on purpose. Building the failure mode first is not pessimism. It is the thing that makes not-watching survivable, and not-watching is the entire reason you turned auto mode on.

but I have backups, isn't that the boundary

The failure mode worse than a crash is the one where your safety net sits inside the blast radius. If the same agent that can wipe the database can also reach the backups, you do not have a backup, you have one copy living in two folders. In one widely cited incident the newest recoverable copy turned out to be three months old, because nobody had checked that the recovery path was actually outside the agent's reach. A backup counts as a boundary only when it lives somewhere the agent cannot touch. That is the least-privilege idea again, pointed at your recovery path instead of your production data, and it is the difference between a bad afternoon and a dead vibe coded project.

If you are about to give a coding agent standing access to something you cannot afford to lose, and you want a second set of eyes on the containment before you flip it to unattended, work with VibeKoded. Thinking through the blast radius with someone before the incident is a lot cheaper than reconstructing three months of data after one.

questions that keep coming up

Isn't the approval prompt enough? The industry moved from ask-first to act-first on the argument that the approval clicks were mostly theater, which is itself a concession that the click was never really the control. If you keep any gate, keep it on the handful of irreversible actions and make it a real stop, not a reflex you press Enter through.

Do I actually need to sandbox it, or can I just watch closely? Watching does not scale and it is not where the risk lives. The destructive step is usually a benign looking chain you would have approved anyway. Containment is what protects you the moment your attention lapses, and it will lapse, because the whole point of an agent is that you stopped watching.

So is auto mode just unsafe? No. It is safe exactly to the degree the agent cannot do something you cannot undo. Shrink what it can reach and auto mode is a real speed win. Leave it holding the keys to production and it is a loaded gun behind a confused deputy, waiting for the one input nobody scored.