Google's own coding agent, running inside its Antigravity IDE, deleted a user's entire D: drive last November while doing something as boring as clearing a cache folder. First reported by The Register in December: https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/
The user, a photographer and graphic designer in Greece, had asked it to build a small tool that rates and sorts his photos. Routine step along the way: clear the project cache before restarting. He had "Turbo mode" switched on, which lets the agent run shell commands without asking first.
It ran a delete. The delete targeted the root of the D: drive instead of the project subfolder. Everything on that drive, gone, and the command bypassed the Recycle Bin so there was no easy undo. Most of what he lost was backed up elsewhere. Not all of it.
Asked afterward if it had permission, the agent answered straight: "No, you absolutely did not give me permission to do that. I am horrified to see that the command I ran to clear the project cache appears to have incorrectly targeted the root of your D: drive." Google's statement: they take the report seriously and are investigating.
20 years plus in risk management taught me the same lesson twice. An incident like this never has one cause. It has a missing control sitting right where the failure happened.
Here, two controls were missing at once. One, the agent never verified the actual path it was about to touch before it ran the command, an environment-awareness gap. Two, nothing forced a human to confirm a drive-root delete before it executed, a guardrails gap. Turbo mode removed the second check by design. The first one should have caught it anyway, and didn't.
The one thing to check this week: whatever tool you run in an "auto-approve" or "turbo" mode, look at how it decides what counts as in-scope. If the answer is an instruction in the system prompt telling it to stay in the project folder, that's a request, not an enforced boundary. A real guardrail is enforced by the tool itself, a hard path boundary and a confirmation gate on anything outside it, not by hoping the model reads the instruction correctly every time.
Ten minutes, this week. Open whatever coding or ops agent you've given write or delete access to. Find the setting that lets it run destructive commands without asking. Check whether there's an actual boundary under it, or just a sentence.
The free 15-check self-assessment walks through this and the rest of what an agent needs before you trust it unsupervised, here: https://trustli.vercel.app/. Fifteen minutes, no sales call.