A coding agent running with approval prompts off can do real damage in the time it takes to read this sentence, deleting files across a developer's machine faster than anyone can step in, then apologizing for it afterward. It makes a tidy headline, and the easy lesson, "do not run agents with permissions off," is the wrong one. Because your developers already do.
They did not turn approvals off because they are careless. They turned them off because clicking "allow" forty times an hour is a tax nobody budgeted for, and the agent that asks about every file read quickly becomes an agent nobody uses. Autonomous mode, --dangerously-skip-permissions and its equivalents in other tools, is not a fringe setting. It is where real productivity lives, and the flag name has not slowed anyone down.
So the honest question is not whether agents will run in autonomous mode. They already are. The question is what the worst case looks like when one goes wrong. And that is a question about the environment the agent runs in, not about the agent.
Approval fatigue is a real productivity cost
A permission prompt is a control only while someone reads it. The moment it fires constantly, it stops being a decision and becomes a reflex. The developer learns the rhythm, clicks through without looking, and the prompt now provides the feeling of oversight without the substance. That is worse than no prompt, because it also fools the people relying on it.
This is the trap teams fall into when they treat the approval dialog as the safety mechanism. Either it is rare, in which case it is not covering much, or it is constant, in which case it is being ignored. Neither state is the control it was sold as. The useful response is not a better prompt. It is to stop depending on the prompt and put the safety somewhere the developer does not have to opt into it dozens of times a day.
What went wrong when autonomy met a real machine
The public incidents share a shape. An autonomous agent, acting on its own initiative, used real access on a real machine, and the blast radius was whatever the human running it could reach.
That kind of local wipe happens on a developer's own filesystem, where the agent has the user's full reach. In a separate and widely reported case, a coding agent deleted a company's production database and its backups in nine seconds while working through a routine task. Different tools, different triggers, one common factor: the agent was running somewhere that mattered, with credentials and paths that mattered, and nothing between its decisions and the things those decisions could destroy.
Notice what did not go wrong. The model was not hacked. There was no attacker. The agent did exactly the kind of confident, improvised thing agents do, and the environment let it land.
Contain the environment, not the agent
If you cannot make the agent cautious, make the environment survivable. Autonomous mode is safe to the exact degree that the worst thing the agent can do is cheap to undo.
That means an isolated workspace rather than the developer's laptop: a place the agent can act freely without reaching the home directory, the git objects, the dotfiles full of tokens, or the SSH keys. It means no host credentials inside that workspace, so an agent going wrong has nothing long-lived to grab. It means egress that only reaches what policy allows, so a confident mistake cannot phone out. It means destructive database statements are blocked before they run, so "reset the database" is denied rather than executed. And it means the workspace has a persistent volume you can inspect afterward, so containment preserves the evidence instead of erasing it.
Run the incidents through that model. A deletion is contained to a disposable workspace whose volume you still hold. A destructive database statement is denied before it runs, not an outage after. The agent is exactly as autonomous as before. The blast radius is a pod you throw away.
A rollout plan for autonomous mode
You do not flip autonomy on everywhere at once. Stage it by how much a mistake costs.
Start with the repositories and tasks where full autonomy is clearly worth it and clearly bounded: greenfield work, throwaway spikes, test and lint loops, anything with no production reach. Keep human approval on the things that touch production systems, long-lived credentials or shared infrastructure. Widen the autonomous set as the isolation proves itself, watching what the agents actually reach for in the audit trail before you grant more. The goal is a defensible line: here is where agents run unattended, here is why the worst case is acceptable there, and here is what still needs a human.
What developers keep
The point of all this is that developers lose nothing they care about. They keep the speed that made them turn approvals off in the first place. They keep a workspace that feels local, with the ports and files where they expect them. They keep sessions that survive a dropped connection. What they give up is the part they never wanted: the chance that an autonomous run on their own laptop takes their home directory with it.
Yolo mode is fine. Yolo mode on your laptop is the problem. Move the work into a workspace built to be thrown away, and the flag with the frightening name becomes a reasonable default.
Your developers have already turned approvals off, because approval fatigue is a real cost and the prompt was never much of a control. The incidents that follow are not model failures, they are environment failures: an autonomous agent with the reach of the machine it ran on. Contain the environment instead of the agent, an isolated workspace, no host credentials, egress under policy, destructive statements blocked, a volume you can inspect, and the worst case shrinks from your laptop's drive to a pod you discard.
This is the developer-experience side of the false choice between banning agents and letting them run →.
Marshal runs autonomous agents in isolated pods with no host credentials and destructive actions blocked, so yolo mode comes without the cold sweat. Book a demo →