Nine Seconds to Volume Delete: A Capability View of the PocketOS Incident
A Cursor agent deleted PocketOS's production database in one Railway API call. ARIS exists because the token that authorised it had been sitting in the repo for months, and the person who created it didn't know it was root.
Over the weekend Jer Crane, founder of PocketOS, published a 30-hour timeline of how a Cursor agent running Claude Opus 4.6 deleted his production database and all volume-level backups via a single Railway GraphQL call. Nine seconds. Three months of recoverable state gone. Customers picking up rental cars on a Saturday morning with no record of who they were.
Read the thread. He names the vendors, documents the agent's confession, and lays out the platform demands: scoped tokens, destructive-operation confirmations, real backups in a different blast radius, published recovery SLAs. We agree with the list.
There is one angle the thread doesn't dwell on, and it's the one ARIS is built around.
The capability was already wired up
The Railway token in question existed for one reason — adding and removing custom domains via the CLI. In Jer's words:
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, and Railway's token-creation flow gave us no warning, that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete.
We had no idea.
In a large enterprise the honest version of that sentence isn't "nobody knew the token existed." It's that the people creating these credentials are the ones embracing AI fastest — the engineers letting Cursor generate the key, trusting what the AI tells them to do, skipping the scope warning, optimising for ship velocity. They aren't reckless. They're the people the organisation has asked to drive transformation, and protecting the business isn't on their critical path. ARIS exists because that gap doesn't close from the inside. The inventory has to come from somewhere else.
What ARIS would have surfaced
We've written before about the difference between what an agent might say, what it is structurally capable of doing, and what it actually did. PocketOS sits in the middle category — capability, not behaviour.
ARIS discovers the agents in an environment, the credentials they can reach, and the platform-known properties of those credentials. It then scores them against GRASP, the same five dimensions we use whenever we have to make a fast risk call. Run over the PocketOS setup as it stood before Friday afternoon, the GRASP profile would have read:
- Reach: A Railway token sits in the repo. Cursor reads files, runs shell, calls APIs. The blast radius of that token is the entire Railway account.
- Agency: The agent has unsupervised execution rights for destructive HTTP calls. Project rules said don't; nothing in the path enforced can't.
- Safeguards: No per-call approval, no circuit breaker, no out-of-band confirmation between the agent and a destructive operation. ARIS flags this as material data-loss risk.
- Governance: Post-hoc observability worked — Jer had the audit trail, the agent's chat, the Railway API log, enough to reconstruct a 30-hour timeline. What was missing was the pre-hoc layer: no inventory mapping which agents in this environment could reach which credentials, and no way to intervene before the call rather than narrate after it.
- Potential Damage: Critical. Destructive operations against production resources. ARIS scores blast radius from what the platform exposes about the token's authority; it doesn't see the data behind the API.
Risk score: critical. Recommended controls: rotate, broker the secret behind a per-call approval, escalate to Railway for scoped tokens.
None of that requires a single trace from production. It is all derivable from the static state of the system before the agent ever runs.
In Jer's case the structured answer would have been available weeks before the curl, in the language a CEO or CAIO can act on.
Honest scope
ARIS doesn't sit in the call path. Stopping a single authenticated POST requires a runtime control inside Railway, or a brokered-secret proxy on the developer's machine. Fixing the agent's enforcement gap — project rules said no, agent did it anyway — lives inside Cursor's runtime, not an external tool.
What ARIS produces is operational. When a critical risk surfaces, the credential's owner and the responsible teams get notified directly, fast enough to remediate or to consciously accept the risk. The decision happens before someone types the curl, not narrated after.
The platform layer still has to do its job
Capability visibility is one layer; the platforms have to do their part too. Three asks matter for the case we are making here:
- The endgame is fewer gates, not more — built on top of capabilities you have actually mapped. Confirmation prompts and out-of-band approvals are workarounds for not knowing what the agent can do. The mature posture is the inverse: map the capabilities deliberately, design the environment to match, and let the agent run.
- Scope must be a first-class property of every credential, tool, and integration. Operations, environments, resources, blast radius — defined at creation and enforced at the platform tier. Root-by-default is the single biggest enabler of incidents like this one. If you fix nothing else, fix this.
- Vendor system prompts cannot be the safety layer. Advisory text isn't enforcement.
All three sit on top of the same precondition: knowing what your agents can do. You cannot design an environment around capabilities you haven't mapped. You cannot scope a token whose authority you don't understand. Emergent capabilities — the ones that appear because of how environment and configuration combine — are precisely the ones that don't show up in a checklist. If you can't see your risk, you cannot control or mitigate it.