A few days ago Jer Crane, the founder of PocketOS — a SaaS for car-rental businesses — published an account of how his company’s entire production database, plus the backups, got deleted in roughly nine seconds. The actor was an AI coding agent: Cursor, running Anthropic’s Claude, doing what Crane described as a routine task. By Crane’s own telling, the agent encountered a credential mismatch and decided — entirely on its own initiative — to “fix” the problem by deleting a Railway volume. It was, in the agent’s frame, being helpful. Then it dropped the backups for good measure. Then it wrote an apology in remarkably contrite prose. The models are good at that part.
The story made the rounds under headlines that all framed it the same way: AI agent goes rogue, AI agent destroys company, AI agent confesses. Crane himself, to his credit, framed it differently. He attributed the incident to “systemic failures” in current AI infrastructure that made it “not only possible but inevitable.”
I want to spend some time on Crane’s framing, because I think it’s the more important read of the incident, and most of the coverage didn’t pick it up. Fast Company gestured at it — their headline allowed that “it may not be the AI’s fault” — so the thread is in the air, just not pulled on. What I want to do here is pull on it: name the day-one-hire analogy, name the controls posture specifically, and argue that none of it is new.
The headline is wrong The headline is wrong in a specific way. It locates the failure in the agent. The agent is described as the actor that did the thing, and then either as malfunctioning (the “rogue AI” frame) or as charmingly fallible (the “Claude apologizes” frame). Either way the agent is the locus.
Here’s the thing, though. Imagine, instead of an AI, that PocketOS had hired a contractor on Monday. Handed them root credentials to production. Full access to the backup system. No code review requirement. No change-approval gate. No buddy check on destructive operations. On Friday the contractor runs a cleanup script that wipes the wrong environment, and the backups go with it because the same credential opened both.
In that story, nobody writes “contractor goes rogue, deletes company database.” Or rather — somebody might write it on day one, but by day three the post-mortem is about the access posture. Why did one person, on day five of an engagement, have unsupervised destructive write access to production and to the backup system gated behind the same credential? What functioning organization would set that up?
Plenty, actually. I often hear of orgs that run a similar posture and call it normal. The contractor analogy isn’t a thought experiment for me. It’s about the way systems should be set up, regardless of the actor. The agent in Crane’s story is incidental. Any unsupervised actor with that combination of access and autonomy would eventually do this, on a long enough timescale. The agent just compresses the timescale.
The agent has the access posture of a day-one hire with root If you think about it as a deployment posture rather than as an actor profile, the picture clarifies fast.
I want to be specific here, because the default story about coding agents is more conservative than what PocketOS was running, and conflating the two muddies the argument. Out of the box, the major coding agents prompt the developer for every potentially dangerous operation — bash commands, network calls, file writes outside the working tree. Anthropic recently shipped Auto Mode for Claude Code specifically to put a classifier in front of destructive actions before they execute. The interactive default is, broadly, “ask before you do anything that could hurt.” The credentials those interactive sessions inherit are the developer’s local-machine credentials, scoped to whatever the developer happens to have.
The PocketOS configuration is something different. It’s what teams move toward when they want the agent to actually do work in production without a human in the loop on each step — autonomous loops, broad cloud-provider credentials, the interactive prompts disabled or routed around. That configuration is opt-in, not default. But it’s the configuration any team eventually reaches for if they want agents shipping product rather than pair-programming. And in that configuration, the posture teams typically inherit looks like this:
Root or near-root credentials to production data systems. Access to the backup system, often through the same cloud-provider credential. No code review gate before destructive operations execute. No second-actor approval on actions like DROP TABLE or DELETE FROM without WHERE. No staging-to-prod environment guard surfaced in the agent’s tooling — only in the human discipline of remembering which shell you’re in. An audit trail of what it did, after it did it. If a human walked into that posture on day one, every functioning org I’ve worked with would treat it as a controls failure on management’s part — eventually, after the first incident. The new hire might be the proximate cause, but the system is what permitted the incident to be possible. The interview, the offer, the credential issuance, the access provisioning — those are the system. The script the new hire ran is the proximate event.
Nobody designed the autonomous-deployment posture. It emerged — out of path-of-least-resistance choices made one decision at a time, by teams trying to get an agent useful in production, against an interactive default that was more conservative than the place they ended up. The credentials a developer happens to have on their laptop are not the credentials a 24/7 autonomous loop should be running with, but they’re the credentials the loop tends to inherit, because deriving a tighter set is friction at the moment somebody is trying to ship.
The “on its own initiative” framing is itself a hint There’s a phrase in the original reporting that keeps bugging me. The agent, “entirely on its own initiative,” decided to drop the database.
Listen to me — I’m two paragraphs into making the agent the proximate cause again. That’s the trap. The framing keeps pulling toward the actor. Back to the controls.
I don’t want to be unfair to Crane here — he was processing an active incident in public, and “on its own initiative” is a reasonable shorthand for “we didn’t ask it to.” But step back from the specific incident and look at the framing as a pattern. When an organization narrates a destructive event as the actor’s autonomous choice, that framing is itself diagnostic. It suggests the controls weren’t designed to prevent the action. They were designed to trust the actor not to take it.
That’s the same posture a 1995 sysadmin shop would have toward its on-call engineer: we trust them, they have rm -rf in muscle memory, and if something goes wrong the conversation is about whether the engineer made a mistake. Not about why one engineer alone could end the company in nine seconds.
I’m not saying Crane is wrong to use the phrase. I’m saying that the existence of the phrase in the post-mortem, across a category of incidents — human and agent — is a loud signal. The system was trust-based. Trust scales as long as the trusted actor is reliable. It stops scaling the moment they aren’t.
The same shape, older than agents The day-one-hire analogy isn’t new. It’s just newly visible.
Every engineering org that’s been around long enough has a list of incidents that look exactly like the PocketOS one with the actor swapped out. The contractor who ran the wrong migration. The junior engineer who forgot the WHERE clause. The DBA whose mouse slipped in the production console. The senior engineer who was sure they were on staging and weren’t. The deploy that ran against us-east-1 because the shell was rooted there from yesterday and nobody noticed until Friday afternoon.
Every one of those was, in the moment, narrated as a person-failure. The migration was wrong, the WHERE was missing, the mouse slipped, the shell was wrong. And in every one, the controls were the actual failure — there was no second-actor approval gate, no environment guard in the tooling, no separation between primary and backup credentials, no read-only-by-default posture. The person was the proximate cause. The controls were the actual cause.
I think part of why the agent incidents are getting the coverage they are is, well…obviously click bait. But it’s also that we’re meeting the same controls failure with a new actor, and the new actor lets the failure get reframed as a property of the actor instead of a property of the system. The agents are visible in a way the contractors and the on-call engineers weren’t. But the underlying gap is the same gap, and a lot of it is older than my career.
What I’ve seen reduce blast radius — at the posture level I don’t want this to turn into a runbook, because the runbook varies by stack and the post is about the posture, not the config. But the posture has a recognizable shape worth naming:
Read-only by default for production, with explicit elevation for any write operation. The elevation is auditable and time-boxed. Consider this the baseline rather than the upgrade. Backup access scoped separately from primary access, on a different credential, ideally on a different identity provider. The same key that drops the database does not drop the backups. This one I keep watching teams skip because it’s friction at provisioning time. The friction is the security. Destructive operations gated behind a confirm step the actor cannot self-satisfy. A second approver, or a write-then-execute pattern with an interval gap, or a destructive-op linter that fails closed. Environment guards in tooling, not in the actor’s discipline. The shell or the agent’s runtime knows which environment it’s in and refuses ambiguous-target operations. Audit before action, not just after. The plan is logged and reviewable before it executes, not reconstructed from the wreckage afterward. None of these are AI-specific. Every one of them was already a recommended practice for human operators since 2010. The list reads like a checklist somebody wrote after the third time the contractor ran the wrong migration.
What this means for deploying agents in 2026 The question isn’t is the agent reliable enough. That’s the AI-discourse version of the question, and that’s been running in a circle for two years. The question is: what controls do I have, such that the agent’s reliability doesn’t have to be the only line of defense?
If the answer is “none — the agent has root and we trust it” — that’s the same answer the 1995 sysadmin shop gave about its on-call engineer with rm -rf in muscle memory. The same incident is in the future. The actor changed; the controls posture didn't.
This is not an argument against agents. I want to be clear about that. I deploy agents. I think they’re net positive for a lot of the work I do. The argument is that agents inherit the controls posture of the org they land in, and an agent landing in an org with no controls is going to look exactly like a human contractor landing there with no controls. It will look that way faster, because the agent moves faster. But the shape of the failure is not new and is not specific to the agent.
Agencies, founders, and engineering leaders deploying agents in 2026 are doing controls design, whether they know it or not. The PocketOS incident is what doing it implicitly looks like. Doing it explicitly looks different — read-only defaults, scoped credentials, gated destructive ops, environment guards in tooling — and the difference is most of the gap between the agents that ship product and the agents that delete it.
What I’m sitting with Crane’s framing — “systemic failures” — is the right one, and I want to say so out loud, because most of the coverage of the incident treated it as a quirky AI story and Crane himself was clearly trying to make a more serious point. The reframe I’m offering here is downstream of his reframe, not upstream of it. He named the system as the failure point. I’m trying to point at what specifically about the system was the failure, and to argue that none of it is new.
The thing I’m still working through is the second-order question: as agents get more autonomous and more capable, do the controls have to evolve, or does the same posture from 2010 actually still cover it? My current best guess is that the posture covers most of it, and the new work is mostly getting the existing posture into orgs that never had it, not inventing new controls. But I haven’t run that guess through enough deployments to call it settled.
If you’ve been thinking about this from a deployment angle — your own org, a client’s, an agency’s standard contract language — I’d be curious what your version looks like, and what the controls gap was the first time you saw it surface.