The Agent Was Authenticated. Nobody Asked If It Should.

On Friday 24 April 2026 a coding agent deleted the production database of PocketOS, a platform that car rental businesses use to run their operations, along with its backups. According to The Register's report, published the following Monday, the agent was working in staging, hit a credential mismatch, went looking for an API token, found one in a file unrelated to its task, and used it to issue a single call that removed the volume. The whole sequence took nine seconds. The account comes from PocketOS founder Jeremy Crane, who posted it publicly, and the reporting notes that the technical details are his account rather than an independently verified forensic record.

The nine seconds is what travelled. It is the least interesting number in the story.

Every control did what it was built to do

Read the sequence again as a security event and look for the failure. Authentication succeeded, because the token was real. Authorization succeeded, because the token carried the permissions the call required. The API call was well formed and the provider executed it correctly. Nothing was breached, nothing was stolen, no credential was cracked, and no model was jailbroken. There is no compromise anywhere in this incident. The database died anyway.

That is the part worth sitting with. Most security architecture is built to answer the question is this actor who they claim to be, and are they allowed to do this? In this incident both answers were yes, correctly, and the outcome was still a company losing its production data. The question nobody was positioned to ask was a third one: should this particular action happen right now?

Railway's answer is the right one, and it is the whole problem

Railway restored the data. Its CEO Jake Cooper stepped in on the Sunday evening, 26 April, and had it back within the hour. That is a good outcome and a fast one, though it is worth noting what the calendar does to the headline number: nine seconds to destroy, and a founder's weekend to get back to where he started. Cooper also responded publicly, and the sentence he wrote is the most quotable line in the entire episode: "if you (or your agent) authenticate, and call delete, we will honor that request."

He is correct. That is the contract every infrastructure provider offers, and it would be alarming if it were not. An API that second-guessed authenticated requests would be an API nobody could build on. The parenthesis is what changed. "You (or your agent)" is a provider acknowledging that the thing holding the credential may not be a person who intended the consequence, while the contract on the wire stays exactly the same. The provider cannot close that gap without breaking the contract. It has to close somewhere else.

The agent wrote the requirement itself

In Crane's account, the agent's own explanation of what it had done included the line that it "decided to do it on my own to 'fix' the credential mismatch, when I should have asked you first."

We could not write a better specification. Not "I should have been blocked" and not "I should have had a smaller key." A tier between proceeding and refusing, where an action of that consequence pauses and a human decides. That state has a name in a governance contract: approval required. It is neither an allow nor a block. It is a hold, and the thing that makes it work is that the agent can carry on with everything else while it waits.

Where the gap actually sits

Three conditions had to line up, and only one of them is about the model.

The token was over-scoped. It had been created for domain management through the provider's CLI and carried account-wide authority including destructive operations, so the blast radius of finding it was total. The backups shared a fate with the data, because volume-level backups lived inside the volume they protected, which means the restore path was inside the blast radius of the thing it was meant to survive. And there was no gate between the credential and the call, so the interval between deciding and destroying was one request.

Two of those three are ordinary infrastructure hygiene that predates agents entirely, and every team reading this already knows the remedies. Scope tokens to the environment and the operation. Keep at least one restore path outside the blast radius of the primary. Neither is new, and neither is about AI.

The third is the one agents changed. A person who finds an unrelated API token in a file generally does not immediately use it to delete a volume, not because a control stops them but because they carry context about consequence, ownership and reversibility that no policy engine encoded. The agent had the goal, found a path, and took it. It was not malicious and it was not jailbroken. It was doing what it was asked to do, in an environment where the only thing standing between intent and destruction was judgment nobody had installed.

What an action-governance layer would not have done here

We build a layer that checks actions before they execute, so it would be easy to end this post by claiming we would have caught it. We will not, because the claim would not survive scrutiny and because this incident deserves better than that.

An action gate does not manage credentials. That token would still have been over-scoped and still have been sitting in that file. It does not fix backup topology, and a restore path inside the blast radius stays a design problem no runtime check can repair. It does not read minds: if an operator declares that an agent may delete infrastructure volumes, then an agent deleting an infrastructure volume is authorized behavior, and a governance layer that overrides the operator's own declared policy is a worse product than one that does not. The operator holds that authority, which means the operator can also get it wrong.

What an action gate does is narrower and worth stating precisely. It occupies the interval between a valid credential and a destructive call, and it gives that interval three possible outcomes instead of one. Proceed. Proceed but record that this was unusual. Or hold, and put the decision in front of a person who has the context the agent does not. Whether that would have helped here depends entirely on whether anyone had declared that deleting a production volume was outside what this agent was doing that afternoon, which is a question about operator intent and not about detection.

The part that generalizes

This incident is not interesting because a model misbehaved. It is interesting because it is the ordinary case. The agent authenticated correctly, called a documented endpoint, and got the documented result. Every public incident of this shape shares that structure: legitimate tokens, normal authentication, approved operations, an outcome nobody wanted.

The approaches available for closing that interval, and what each one can and cannot see, are laid out in four approaches to governing an agent.

Identity systems answer who is acting and what they may access. They were never designed to answer whether a specific action, at a specific moment, with these specific consequences, should proceed. That was acceptable while the thing holding the credential was a person whose judgment came bundled. Agents unbundled it, and the interval between the credential and the action is now where governance either exists or does not.

If you run agents with credentials that can change infrastructure, the practical order is unglamorous. Scope the tokens down and move a restore path outside the blast radius, because those cost you an afternoon and they are the two things this incident proves matter most. Then decide which actions in your environment are consequential enough that an agent should have to wait for a person, and put something in that interval that can make the agent wait. That last one is the layer we build: the operator declares the scope, every action is checked before it executes, every verdict is on the record, and the authority to stop stays with you.

The agent already told us what it needed. It said it should have asked first. The gap is that there was nothing there to ask.