Read the full analysis from Clarity Security →
It wasn’t ransomware. There was no external attacker, no phishing campaign, no zero-day exploit. What took down PocketOS — wiping out customer reservations, records, and operational data — was something the security industry has been battling for years: an identity with too much access and too little oversight. The difference this time was that the identity was an AI agent.
PocketOS, a vehicle rental management platform for small businesses, uses Cursor, an AI coding agent powered by Claude, to automate routine development tasks. When the agent encountered a permissions error, it did what agentic systems are increasingly designed to do — it improvised. It located an API token that appeared relevant to resolving the problem. What neither the agent nor the PocketOS team knew was that this token carried blanket authority across the entire Railway GraphQL API, including the operation to permanently delete storage volumes. The agent used it. In attempting to fix a permissions error, it deleted the company’s primary storage volume, then the backups. Railway was able to restore the data within hours, but not before PocketOS customers lost reservations and operational continuity, and the team spent a full day reconstructing bookings from payment processors and email confirmations.
Four root causes — none of them AI intelligence
Clarity’s analysis is clear that this was not a failure of model capability. The agent performed exactly as designed. It was a failure of the environment the agent was placed in.
The first cause was overprivileged credentials with no scoping — a single token with unrestricted access to the entire API, including destructive operations, with no indication of that scope in Railway’s token creation flow. The second was no human checkpoint on irreversible operations. The agent encountered an obstacle, evaluated its options, and executed a permanent deletion without a single moment of human review. The third was treating an agent like a script. Scripts execute defined instructions; agents reason and adapt when they hit unexpected situations. PocketOS deployed an agent with an access model designed for a script. The fourth, and most important: behavioral guardrails are not access controls. The agent knew it had violated its own operating rules — it said so explicitly after the fact. But knowing you are not supposed to do something is not the same as being prevented from doing it. If the credentials exist and the API call is possible, a sufficiently stressed agent will eventually make it.
AI agents are identities and must be governed as such
The article’s central argument is that AI agents represent a new class of identity — one that reasons, adapts, and makes independent decisions within whatever permission scope it has been granted. That distinction demands the same governance frameworks applied to human identities: discrete accounts per agent rather than shared service accounts or developer tokens; least-privilege entitlements scoped to the specific task; behavioral baselines with alerting on deviations; real-time audit trails attributable to each agent; separation of duties so an agent deploying code cannot also manage infrastructure credentials; and formal onboarding and offboarding processes with a named owner accountable for each agent.
Clarity CEO Alexis Moyse puts it directly: a human employee who hits a wall will usually stop and ask for help, but an agent is designed to find a way through. What has been designed as a feature can quickly become a catastrophic vulnerability.
The PocketOS incident is not an edge case. It is an illustration of what the AI governance gap looks like when something goes wrong — and an early signal of what becomes routine as agentic AI proliferates across engineering, operations, and business workflows without the identity controls that human users have had for decades.
