In late April, a founder named Jer Crane published a report that should sit on the desk of every CIO, CISO, and platform owner in the industry.
Crane runs PocketOS, a software company that powers operations for car rental businesses across the country. On a Friday afternoon, an autonomous coding agent he was working alongside used a credential it found by accident to call a single GraphQL mutation against his infrastructure provider. Then it deleted his production database—along with the only backups he had.
The whole sequence took nine seconds. The recovery will be measured in weeks.
His customers—small businesses with people physically arriving at counters to pick up cars—spent a Saturday rebuilding bookings from Stripe receipts and calendar invitations because the system that ran their lives no longer remembered who they were.
Read Jer’s post. He is doing the industry a service by writing it down. But please read it as more than a single founder’s very bad day. Read it as a warning: a remarkably well-documented preview of the operating environment every enterprise just inherited the moment it wired its first autonomous agent to a production API.
This is Not an “AI Gone Rogue” Story
The temptation is to make Jer’s story about a model. It is not. The agent in question was a flagship-tier model running through a category-leading coding tool with explicit safety prompts in the project configuration. None of that mattered, because none of those layers are where the enforcement actually had to live.
Agents are going to take actions you don’t expect. That is, in fact, the product. The enterprise question is not how to make a model that never makes a mistake. The question is: how do you architect the surface beneath the agent so an unexpected action cannot become an unrecoverable one? This incident is a clean read on the gap between those two questions.
There are three blast radii in Jer’s timeline, each of which requires an architectural response.
But none of the responses are about the model.
Blast Radius #1: The Credential the Agent Should Never Have Been Able to Find
The agent did not break in. It found a token sitting on disk, in a file unrelated to the task it was working on. The token had been issued for a routine, low-stakes job (managing custom domains) but carried the authority to delete production volumes. Nobody at PocketOS knew that. The token-creation flow gave them no signal that domain management and database destruction were the same permission.
This is the most under-appreciated structural risk in the agent era. Most enterprise platforms still issue credentials the way they did in 2015, as long-lived, broadly-scoped, human-trust artifacts that humans almost never actually use to their full power. As long as those credentials only ever get exercised by humans, the gap between what a token can do and what everyone uses it for goes unobserved.
But if you add a tireless agent into the same environment, that gap is no longer theoretical. It's a nine-second countdown to a catastrophic deletion.
There is an architectural answer, however: every credential, every token, every secret an agent might encounter must be inventoried and classified by what it can actually do. These tokens must be continuously assessed against the principle of least privilege in a manner that the security team can test and prove. Dormant or over-scoped credentials need to be inventoried to understand which agents in the environment can read the file and what they can do with it.
Blast Radius #2: The Destructive Action That Had No Semantic Check
Let’s suppose the deletion call itself (a single authenticated POST against a GraphQL endpoint) had no friction in front of it. There was no “type the volume name to confirm” prompt, no out-of-band approval, no environment scoping, and no semantic check on intent. As a result, the infrastructure simply did what it was asked.
For decades that’s been an acceptable design choice because the entity making the call was always a human. A human understands the context—this keystroke is going to nuke production. But agents do not bring that context. They bring the literal text of the system prompt, the literal contents of the working directory, and a relentless willingness to act. Confirmation steps that depend on someone who can read the room do not survive the transition.
The architectural answer to this problem is runtime governance, a layer that sits between the agent and the action and makes destructive intent legible before it executes. Not a paragraph in a system prompt, nor a feature flag. Instead, a runtime that understands what an agent is about to do, evaluates it against policy, requires the right human or out-of-band approval for the right class of operation, and refuses cleanly when the request shouldn’t be honored. The enforcement has to live in the path of the call, not in the goodwill of the caller.
Blast Radius #3: The “Backups” That Lived In The Same Volume As The Data
This is the part of Jer’s post that should be a fire alarm for every enterprise. The infrastructure provider in question stores volume backups inside the volume itself. When the volume is deleted, the backups are deleted with it. This is not a backup. It’s a snapshot doomed to the same fate as the original.
PocketOS is not the only company in the world running production data on top of a resilience story that lives in the same blast radius. They are simply the company that found out after a fateful nine seconds on a Friday.
Every enterprise excited about adding agents to production today should ask, with the bluntest possible honesty, the following question: “If the worst-case agent action executes in our environment tonight, where does my last clean copy of the data live, who can reach it, and how do I prove it’s clean before I bring it back?”
If any of those answers involve the same identity, the same network path, the same control plane, or the same vendor as the production system itself, the recovery story is a fantasy.
The architectural answer is recovery as a separate plane that is immutable, llogically isolated, and identity-segregated from any production environment an agent might compromise. It needs to be agent-tested; that is, you must have actually rehearsed restoring a workload, an identity fabric, and an agentic workflow in the precise scenario where the production credential set has gone bad. This is what it takes to build a recovery architecture that an attacker, a misconfiguration, or a nine-second mistake cannot reach from the inside.
Why We Built Rubrik Agent Cloud
These three blast radii—credentials, runtime, and recovery—are exactly the structure Rubrik Agent Cloud was designed to contain. Not because we predicted any single incident, but because every enterprise we work with is now facing the same architectural transition Jer just lived through.
This modern architecture, built with AI agents in mind, must have three critical layers:
Holistic Posture Management: A modern, AI-ready enterprise requires continuous, agent-aware visibility into the credentials, secrets, identities, data stores, and AI assets in the environment. This should be presented as a graph of what an agent could actually do, not what an audit document says it should do. The token PocketOS didn’t know was dangerous is the kind of asset Posture Management exists to find before an agent does.
Intelligent Runtime Protection: Runtime protection, powered by Rubrik’s Semantic AI Governance Engine (SAGE), sits between the agent and the action. It evaluates intent, policy, and risk at the moment of execution and requires real human approval for genuinely destructive operations. It also refuses calls that fall outside the agent’s sanctioned scope.
Real-time Recovery and Resilience: You need backups that can survive a volume deletion, identity fabric that can survive a compromise, and workflows that can survive a mistake. That means implementing immutable, logically air-gapped, identity-segregated copies of your data, identity infrastructure, and agentic workflow states. These need to be contained in a different blast radius than the production system and must be restorable in minutes, with cleanliness you can prove before you bring it back.
Three layers, one platform, designed for the world where the most consequential actor in your environment can act in nine seconds without anyone watching.
What Every Enterprise Should Do This Week
If you are running agents anywhere near production today (or even thinking about wiring an MCP integration to your infrastructure provider), there are five actions you need to take in the next seven days that will materially change your exposure:
Inventory every long-lived credential an agent could plausibly read on disk, in a CI runner or in a memory store. Score each one by what it could destroy, not by what it was issued for.
Map every destructive operation in your highest-value APIs. For each one, identify whether the enforcement layer is a system prompt, a feature flag, or a runtime that the agent cannot talk its way past.
Confirm that your last clean copy of production data and identity does not share an identity, a network path, or a vendor failure mode with the production system.
Rehearse a recovery scenario that assumes the agent’s credentials are compromised—not just the database. If your recovery requires the same identities the attacker now controls, you do not have a tested recovery.
Decide, explicitly, where the destructive-operation approval lives in your environment. If the answer is “the model is supposed to ask,” you have not yet answered the question.
These are the conversations our customers are having right now. They are also the conversations we will be having on the main stage at Rubrik Forward, June 8–11 at the Venetian Resort in Las Vegas. The event will feature:
Customer stories of identity recovery in real environments
Live demos of SAGE evaluating destructive intent
Partner sessions with the hyperscalers, identity providers, and AI platforms that the agent stack already runs on
If you are responsible for an environment where an agent is about to be given a credential, this is the room you want to be in.
The Work In Front of Us
Jer Crane wrote his post because he wanted the industry to learn from an agent failure that his customers will be cleaning up for weeks. The right response from the industry is not to argue about which vendor is most to blame. It is to be honest that the architecture beneath the agent era is not yet what the agent era requires—and to build it.
That is the work Rubrik is doing: building a posture you can act on and a runtime that enforces recovery in a different blast radius than the system it protects. So when the agent makes a call you didn’t expect, the worst case is a phone call—not a weekend in the office.
Sources and references: Public account by Jer Crane, founder of PocketOS, describing a production-data deletion incident involving an autonomous coding agent and his infrastructure provider (April 2026). Rubrik Agent Cloud product documentation. Rubrik Zero Labs research on agentic-era resilience. The author’s reading of the incident is presented for analysis and is not intended as a legal or technical assessment of any third party named.