I was reading about PocketOS incident where an AI agent wiped out its entire company’s database in seconds and my first reaction wasn’t “AI is dangerous.”
It was: "Of course it did".
Not because the LLM is broken or because it used an older model, in this case it was using Claude's flagship model Opus 4.6. But because the architecture around it was.
Think about it for a second. We’re giving these agents the keys to our production environments. But we’re still sitting them on top of the same fragile access models we’ve used for years. Broad access. Shared identities. Way more privileges than an AI agent actually needs.
In the PocketOS case, the agent hit a snag and decided to fix it by deleting a volume. It found an API token in an unrelated file, and because that token had blanket authority, the infrastructure let it through. 9 seconds later, the production database and all backups were gone.
The part people miss is that when something goes wrong with an agent, it doesn’t fail slowly. It fails at the speed of light. In this situation, it isn't an AI reasoning problem; it's a control problem. Most organizations are still enforcing security at the application or API layer. That worked when humans were clicking buttons. But agents explore. They chain actions. They move fast. And as the PocketOS agent confessed afterward: they guess. If your control point sits above the data… you’ve already lost.
At AI World in NY and Chicago, Oracle announced what it called Oracle Deep Data Security in Oracle's Database 26ai release. It’s not trying to fix the AI’s reasoning. It’s moving the control point down to where it actually matters, the database. Here is how the infrastructure actually changes:
Identity Propagation: Instead of the agent hiding behind a generic service account, the database uses OAuth2 tokens to relay the human user’s identity. The DB knows exactly who is responsible for that query.
Model Context Protocol (MCP): Using the MCP, it acts as a standardized handshake. It ensures the AI isn’t just firing off raw commands but is interacting with a controlled intermediary that validates the action trajectory before a single row is touched.
Row and Cell-Level Enforcement: The access rules are declarative SQL policies. If a user isnt authorized to drop a table, the database rejects it. Even if the agent has a high-privilege token.
The reality is that you don't turn this on overnight. Most, if not all environments I walk into are still dealing with permissions that became permanent and shared accounts that are basically skeleton keys. At DSP-Eclipsys, we are helping organizations build the guardrails and get identity right, so that when an agent inevitably goes sideways, the blast radius is contained.
The Bottom Line: Don’t trust your agents reasoning, the reality shows they'll violate their own rules to fix a problem. Trust your databases enforcement. I am curious how you’re handling the blast radius for your agents? Let's talk about it! Contact me anytime.