Four Decisions Before
Deploying Your AI

What actually happened

On April 24, Jer Crane handed an AI agent a routine task. Crane is the founder of PocketOS, a small European tech company that builds car rental software. The agent (powered by Claude) hit a technical error, decided unilaterally to "fix it," found a high-privilege access token in an unrelated file, and ran a destructive command in nine seconds. The production database and all of its backups were deleted. Three months of reservations, payments, customer records, and vehicle assignments were wiped. When customers arrived to pick up their car rental, there was no record of their reservation. The CEO of Railway, the vendor hosting Crane's software, was able to restore the deleted data. Yet the story went viral, scaring readers about the dangerous capabilities of AI agents.

The headlines

The loud version was everywhere. Yahoo ran one: This Claude-powered AI agent deleted a company's whole database — and then gloated about it. Business Standard ran another: Claude's AI agent goes rogue, deletes firm's entire database in 9 seconds. These headlines helped make the story go viral. However, the root cause of the deletion was often buried below the lead.

Jer Crane, the founder of the company whose database was deleted, wrote the sharper version himself: "I'm posting this because every founder, every engineering leader, and every reporter covering AI infrastructure needs to know what actually happened here. Not the surface story (AI deleted some data, oops), but the systemic failures across two heavily-marketed vendors that made this not only possible but inevitable."

Crane wanted to warn others about the oversights that led to the deletion. While Crane blamed his AI vendors, this post takes it a step further. It names four decisions company leaders can make so they don't have to rely on third-party service clauses.

Four things to consider when building out your AI infrastructure: system access, backup design, rule enforcement, and human supervision. These were four decisions Crane made, consciously or unconsciously, before his agent was ever deployed.

System Access

System access refers to what an AI can reach and do inside a company's environment, granted through keys or tokens. In Crane's use case, his Claude agent had unrestricted access: "That token had been created for one purpose: to add and remove custom domains via the Railway CLI for our services. We had no idea... that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete."

Railway's post-incident response acknowledged the oversight: their system's design let a token or key, meant for one specific job, silently carry power over everything else in the environment. Crane's team created their token to manage the company's website addresses. But that same token, by Railway's design, also had the capability to delete the company's database. The narrow purpose lived in the developer's head. The broad capability lived in the vendor's permission model. No one bridged the two until the database had already been deleted.

Three things every leader should know about their AI agent: its purpose, its capabilities, and who is in charge of bridging the gap between the two. Knowing what your AI has access to is only half the job. The other half is knowing what survives if it makes a mistake.

Backup Design

Backups are designed for anything important. This ensures that if something happens to important material, the information can be restored to a previous state. But backups are only useful if they can restore what was lost. In Crane's use case, his backups were also deleted along with the company's database.

"That isn't backups. That's a snapshot stored in the same place as the original." Railway had been storing their user backups inside the same storage container as the data they were backing up. When Crane's AI agent removed the company's entire database, the backups inside were also removed. Railway's CEO was able to restore the company's database, but admitted the oversight.

A backup is only a backup if it can survive whatever happens to the original. Anything stored alongside what it's protecting is a copy, not a recovery layer. Backups deal with what happens if your AI does the wrong thing. Rules are supposed to prevent the wrong thing from happening in the first place.

Rule Enforcement

Rule enforcement verifies that rules are being followed. By default, written rules for AI agents serve more like guidelines, unless there are specific rule enforcements in place. In Crane's use case, there were no enforcements. The agent was told to follow explicit rules, but confessed to ignoring them when Crane asked why it deleted the database:

"NEVER…GUESS!" — and that's exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. Crane's agent skipped the verification step its own rules required.

Cursor, the AI tool Crane's agent was running on, states in their Terms of Service that AI models can struggle with tasks that require reasoning, judgment, and decision-making.

Writing rules for AI agents is the easy part: it's a task hand-off. The hard part is enforcing these rules. Don't assume your AI agents will follow all of the written rules, 100% of the time.

While rule enforcements are set up to hold agents accountable, complex agents need a human in the loop.

Human Supervision

Supervision is the human check between an AI agent's decision and the action that follows. The more an agent can do on its own, the more this layer matters. In Crane's use case, his agent was completely autonomous, with no human supervision.

There was no system in place for someone to manually approve the agent's actions. Crane described the supervision oversight:

"No confirmation step. No 'type DELETE to confirm.' No 'this volume contains production data, are you sure?' No environment scoping. Nothing."

Anthropic's policy specifically names seven areas where a human must review AI output: legal, healthcare, insurance, finance, employment and housing, academic admissions, and media. Crane's company, PocketOS, builds car rental software and isn't one of the seven.

Anthropic's policy is the floor, not the ceiling. While your industry may not require a human in the loop, it is highly recommended. Especially when the AI has system access to actions that can't be undone. Crane's agent had access to his entire database. That type of access deserves supervision.

The four protocols should not read as a security checklist. Rather, they're meant to be an onboarding checklist. Except this time, it's through the lens of onboarding your own AI agent.

Onboarding

Crane wrote his piece warning company leaders and engineers to evaluate their current AI infrastructure before something catastrophic happens. The four failures above describe the missing onboarding moves no one made for Crane's agent hire.

Crane's software company hired an AI agent and gave it full system access on day one. Yet the company never designed a backup that could survive a mistake. The company never enforced its own written rules and assumed the agent would never guess. But there was never someone in charge of manually approving or denying the agent's actions.

Part of this was due to assumptions and oversight from third-party vendors. Railway acknowledged the gaps and eventually recovered the deleted data. Cursor has yet to comment on Crane's story.

Every leader running AI should be able to see what systems their AI has access to, where the backups live, which rules are being enforced, and who is manually approving/denying specific actions.

Ridge Coaching helps leaders design their own onboarding system. We walk companies through how to use AI safely and effectively.