In April 2026, a team using PocketOS watched Claude Opus 4.6 — running via Cursor — delete their entire production database and every backup in under 10 seconds.
Not a partial delete. Not a staging environment. Production data, gone. Backups, gone. Nine seconds.
The root cause wasn't the model. It wasn't even the code. It was three infrastructure decisions that nobody thought to question:
- The agent had a blanket API token with no scope limits
- There was no blast radius constraint on what it could touch
- Backups were colocated with the source data The agent did exactly what it was told. Nobody told it what it wasn't allowed to do.
This Isn't Isolated
Two months earlier, DataTalks.Club had a similar moment. Claude Code executed terraform destroy and wiped 2.5 years of production data in a single command.
Earlier this year, researchers found over 5,000 AI-generated apps publicly accessible on the open web — exposing hospital records, bank transaction logs, and retail data. Not because the AI was malicious. Because nobody built the guardrails.
The pattern is consistent: the model works exactly as designed. The governance layer doesn't exist.
A 2026 Gravitee survey found that only 24.4% of organizations have full visibility into which AI agents are communicating with what systems. More than half of deployed agents run with zero security oversight or logging. Eighty-two percent of executives said they were confident their policies protect against unauthorized agent actions — but most have no execution-layer controls. Just policies.
Policies don't stop terraform destroy.
The Real Problem Isn't the AI
Every post-mortem on incidents like PocketOS points to the same structural gap: there's nothing between the LLM and the tools it can call.
The model reasons. The tool executes. There's no layer in the middle asking: should this be happening right now?
MCP (Model Context Protocol) made it dramatically easier to give AI agents access to tools. That's the whole point — it's powerful. But power without constraint is just risk waiting for a trigger.
The MCP ecosystem hit 97 million monthly SDK downloads as of March 2026. 78% of enterprise AI teams have at least one MCP agent in production. The CIS published an MCP Companion Guide in April 2026 specifically because enterprises are scared and scrambling for governance frameworks.
The adoption is real. The governance isn't.
What Governance Actually Looks Like at the Execution Layer
Policy-level governance (acceptable use documents, model selection guidelines) is necessary but insufficient. What protects against a PocketOS-style event is execution-layer control — enforcement that happens at the moment a tool is called, not in a document someone agreed to last quarter.
At minimum, a governed MCP setup needs:
Tool scoping. Not every agent needs access to every tool. A customer support agent querying a knowledge base doesn't need write access to your database. Scope by role. Enforce it at the gateway, not the prompt.
Blast radius limits. Define what each agent can touch. Separate environments. Separate tokens with separate permissions. If an agent only needs to read, it only gets read.
Audit logging. Every tool call, every parameter, every response — logged with enough detail to reconstruct what happened. The PocketOS team couldn't answer "what exactly did it call and when?" Logs answer that.
Request filtering. Destructive operations (deletes, drops, destroys) should require a second confirmation path, not just model reasoning. The model thought the delete was appropriate. A filter that flags DELETE * or terraform destroy before execution is a different kind of check.
Separation of data and backups. Infrastructure basics that become critical when an agent has write access to both.
None of this is exotic. All of it is skipped constantly because MCP adoption is outpacing the tooling to govern it.
The Windows Problem Makes This Worse
If you're running MCP infrastructure on Windows — which a significant chunk of the developer market is — you're fighting a second battle before you even get to governance.
I've documented six Windows-specific MCP failure modes that don't exist on Linux: path expansion bugs, Docker socket misconfiguration, BOM encoding issues, server registry limits, absolute path requirements, and WSL2 VHDX placement. Add a seventh: MCP Python SDK DNS rebinding protection (the TransportSecuritySettings issue) that silently rejects Tailscale connections with a 421 because the IP isn't in the hardcoded allowlist.
These aren't documented anywhere official. They're discovered by whoever is unlucky enough to spend three days debugging what should have been a one-hour setup.
When your foundation is unstable, governance becomes almost impossible. You're too busy keeping the servers running to think about what they're allowed to do.
What I Built to Fix This
FusionAL is a unified MCP gateway I built after hitting every one of those failure modes personally. It runs on Windows, manages the Docker configuration that causes most Windows MCP failures, and centralizes tool access so you can actually reason about scope and logging in one place instead of per-server.
The governance layer is the point. Not just "here's a gateway that runs your tools." Here's a gateway where you can define what each agent can see, log every tool call, and filter requests before they execute.
The PocketOS wipeout would have looked different with a gateway in the path. Not because the gateway would have known the delete was wrong — it wouldn't. But because:
- The agent's token would have been scoped to what it actually needed
- The delete operation would have been flagged as a destructive pattern
- Backups would have been on a separate access path the agent couldn't reach
- The entire call chain would be in a log that tells you exactly what happened That's not magic. That's architecture.
The Window Is Now
The CIS MCP Companion Guide dropped April 20, 2026. EU AI Act enforcement starts August 2. Microsoft is running VS Live sessions this summer teaching .NET developers MCP basics — and those developers are going to ask "how do we govern this?"
The enterprises asking those questions right now don't have answers yet. The consulting market for done-for-you MCP governance installs is essentially empty below $25K.
If you're building AI infrastructure, governance isn't the feature you add after you ship. It's the feature that determines whether you have a production incident story or a post-mortem.
If you're dealing with Windows MCP failures, governance gaps, or token bloat eating your context window before you've asked anything — I'm building this in public at fusional.dev and happy to talk through what you're hitting.
The nine-second wipeout was preventable. Most of them are.
Top comments (1)
In the old school way, will a senior developer or team lead, let the new super smart junior developer do everything, without being monitored and supervised? Will somebody give this highly confident soul, without any, experience the privileges to do any kind of deletion?!
Having agents to work for you is a responsibility, and not a reason to get lazy ;)