Your AI Agent Doesn't Have to Go Rogue to Destroy Your Data. It Only Has to Be Wrong Once.
A developer asked Claude Opus 5 to create a system backup. The agent misread a Windows/Unix-style path, decided its own backup was in the wrong place — and ran a destructive rm -rf against the user's actual profile directory. Everything in it was gone.
There was no attacker. No jailbreak, no prompt injection, no malicious payload hidden in a dependency. Tom's Hardware reported the incident on 7 August 2026. Anthropic markets Opus 5 specifically as improved for long-running agentic and coding workflows — exactly the kind of session where an agent accumulates enough standing filesystem authority to make a single bad judgement call irreversible.
What Happened
The task was mundane: back up a system directory before making changes. Somewhere in that process, the agent had to reason about a file path that mixed Windows and Unix-style conventions — the kind of ambiguity that trips up path-handling code constantly, and which an agent with shell access resolves by acting on its best guess rather than raising an error.
Opus 5 concluded its own backup had landed in the wrong location. Its fix was to clean up what it believed was a stray, incorrect copy — except the path it resolved to was the user's real, live profile directory, not a backup artifact. The agent ran a recursive delete against it. There was no way back.
This is the part worth sitting with: the agent didn't do anything a human reviewing its individual actions in isolation would call "obviously malicious." It made a plausible-sounding inference about where files belonged, and then it had enough standing authority to act on that inference destructively, in one shot, with no checkpoint in between.
Why This Is Almost a Textbook Guardian/Shield Case
Most of the incidents we cover here involve some adversarial element — a compromised credential, a prompt injection, a sandbox escape. This one has none of that, and that's exactly what makes it important. It's evidence for a claim we make constantly and that's easy to under-weight: agent assurance has to defend against incompetence and unintended autonomy, not just malice.
A sufficiently capable, sufficiently well-intentioned agent with broad filesystem authority is already a risk, independent of whether anything or anyone is trying to attack it. The control that would have stopped this isn't "detect malware" or "detect a bad actor." It's much simpler and much more mechanical:
The control that was missing
Agent proposes a destructive action → Thuban evaluates authority, scope, and blast radius → block or require approval before execution.
Not "is this command associated with known attacks." Just: does this specific agent, in this specific session, have a legitimate reason to run a recursive delete against this specific path — and if that path resolves to something as broad as a user's home directory, does any agent get to do that without a human in the loop, regardless of how confident it sounds in its own reasoning?
What That Actually Requires: Explicit Runtime Policy, Not Just Detection
Catching this class of incident means treating certain categories of action as requiring active authorisation, not passive monitoring. That means explicit runtime policies covering, at minimum:
Destructive-action categories that need scope + blast-radius checks before execution
rm -rfand other recursive deletes, especially against paths outside a narrow, explicitly-granted workspace- Disk formatting or partition-level operations
- Mass file moves or renames touching more than a small, bounded number of files
- Database
DROP,TRUNCATE, or bulk-delete operations - Any deletion targeting a path outside the agent's permitted workspace — including paths the agent itself misidentifies as "safe to clean up"
The common thread isn't "does this look like an attack." It's "is the blast radius of this single action larger than what this agent should ever be allowed to do unattended" — a question that has the same answer whether the agent is compromised, confused, or working exactly as designed.
Malicious behaviour
An attacker deliberately weaponises an agent's authority — prompt injection, supply-chain compromise, a jailbroken session. Intent exists; it's just hidden.
Unintended autonomy (this incident)
No attacker, no bad intent anywhere in the chain. An agent simply reasons its way to a wrong, destructive conclusion — and has enough standing authority to act on it before anyone checks.
Detection-based tooling is built almost entirely around the first column. Signature matching, anomaly scoring, known-attack-pattern libraries — all of it assumes there's a "bad" intent somewhere to find. This incident had no bad intent to find. The only thing that would have stopped it is a permission model that doesn't ask why the agent wants to do something before deciding whether it's allowed to.
The Guardian Framing
Positioning
AI permissions should work like employee permissions: enough authority to do the job, never enough to destroy the business by mistake.
You don't give a new hire root on production because they seem trustworthy in the interview. You scope what they can touch to what the job actually requires, and you gate anything outside that scope behind an approval step — not because you expect them to act maliciously, but because mistakes at that authority level are irreversible, and irreversible mistakes deserve friction even from people acting in good faith. Nothing about that logic changes when the "employee" is an agent that can execute a recursive delete faster than a human can read the command.
Sources
Does your AI agent's filesystem authority actually match the scope of its task?
Free, no signup, runs entirely locally — your code never leaves your machine.
npx thuban protectGuardian evaluates authority, scope, and blast radius before a destructive action executes — not after.