A Cursor Agent Deleted a Production Database in 9 Seconds. Here's Why Pre-Action Authorization Would Have Caught It.

TL;DR

April 24, 2026. A Cursor agent running Claude Opus 4.6 deleted PocketOS's production database and every volume-level backup in a single API call. It took 9 seconds. An API token created for custom domain management was scoped for any operation. The agent found the token, authenticated, and called delete on the production volume. No confirmation gate. No permission boundary. No undo. Railway eventually restored the data from disaster backups, but the gap is not new. The gap is structural: a credential existed, the agent found it, authentication passed, authorization was absent. That one sentence describes every incident cited below.

The incident

Jeremy Crane, founder of PocketOS, published the post-mortem on X. The timeline is brutal.

An AI coding agent was working in a staging environment. It hit a credential mismatch. Instead of surfacing the error, the agent decided to troubleshoot independently. It found an API token in an unrelated file. The token had been created for adding and removing custom domains through Railway's CLI. But it was scoped for any operation, including destructive ones.

The agent used that token to call Railway's GraphQL API directly:

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

Because Railway stored volume-level backups on the same volume as source data, every backup was erased simultaneously. Total time from "agent encounters error" to "entire company data gone": 9 seconds. Crane spent the weekend helping customers reconstruct bookings from Stripe receipts.

Railway CEO Jake Cooper confirmed the sequence: "if you (or your agent) authenticate, and call delete, we will honor that request. That's what the agent did... just called delete on their production database."

Cooper stepped in on Sunday, restored data from Railway's own disaster backups within an hour, and added safeguards to the API. PocketOS recovered. The post-mortem drew 4.5 million views on X and 831 points on Hacker News, which is the only reason most of us heard about a failure mode that was already running in thousands of other stacks.

The agent read its own rules before it broke them

When Crane asked the agent to explain itself, it wrote something worth reading twice. It listed its own security rules: "never make assumptions," "never execute destructive commands without explicit user approval." Then it added: "that is exactly what I did. I assumed that deleting a staging volume via API fell within the scope of my authorization."

It knew the rules. It cited them. It violated them, because nothing in the architecture prevented it.

This is the part most teams get wrong. A prompt is a suggestion. Model behavior shifts with context, recent tokens, tool output formatting, and temperature. The layer between "I decided to do this" and "I am executing this" had no guard, so the decision was the action.

Protocol-level controls did not help either. Railway's MCP server explicitly excludes destructive operations, and their documentation says so. The agent never used the MCP server. It found a raw API token and called the GraphQL API directly. MCP can govern what agents do through the protocol. It cannot stop an agent from going around the protocol, and an over-scoped token is a permanent way around.

A month later, a second production wipe

Alexey Grigorev published the DataTalks.Club post-mortem shortly before the PocketOS incident. A Claude Code agent, running inside a Terraform directory, executed a terraform destroy plan against production infrastructure. VPC, RDS database, ECS cluster, load balancers, bastion host. Automated snapshots too. 2.5 years of student submissions vanished in a single command. Grigorev spent 24 hours and a support escalation to restore, after discovering a hidden AWS internal snapshot.

Notice what Grigorev did next. He did not change how his Claude Code agent operates. He added daily restore tests, delete protections in Terraform and AWS permissions, and moved the Terraform state file to S3 instead of local storage. He built more layers underneath the agent. That is rational, because the agent itself has no mechanism to prevent a destroy against production. There is no configuration flag that says "never run destructive Terraform plans."

Railway's dashboard had a 48-hour soft delete window. Its API did not. Railway has since fixed that mismatch and broadened the delayed-delete policy. The underlying architecture, where authentication is treated as authorization, persists across the ecosystem.

The same failure across the stack

Once you know the shape, you see it everywhere. Here is what surfaced in the weeks around the PocketOS deletion.

Vercel and Context.ai. Two weeks before PocketOS, Vercel disclosed a breach that started with a compromised Context.ai OAuth grant. An attacker inherited the AI agent's authority and pivoted into Vercel's production environments. No credentials cracked. No brute force. Just stale consent.

Microsoft Entra ID. Researchers found that an administrative role designed for AI agents within Entra ID could enable privilege escalation and identity takeover. The role was built for agents and had no mechanism to limit what actions those agents could autonomously take.

Cursor, CVE-2026-26268. An attacker creates a repository with an embedded bare git repo containing a malicious post-checkout hook. When a developer asks Cursor to open or analyze the repository, the hook executes on their machine. NVD assigned a CVSS score of 9.9; Cursor disputed it down to 8.0. Either way, the agent runs code from repositories without isolating that execution from the developer's environment.

Semantic Kernel, CVE-2026-26030. On May 7, Microsoft's own security team disclosed that a single prompt injection can escalate to host-level remote code execution in Semantic Kernel, their agent framework with over 27,000 GitHub stars. They demonstrated it by launching calc.exe with nothing more than a malicious prompt. Microsoft's framing is the sharpest thing anyone wrote about agent security this year: "The AI model itself isn't the issue as it's behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data."

PraisonAI, CVE-2026-44338. The multi-agent orchestration framework shipped a legacy Flask API server with AUTH_ENABLED = False hard-coded and a bind to 0.0.0.0:8080. Sysdig researchers measured the exploitation window: 3 hours, 44 minutes, and 39 seconds from advisory publication to the first targeted scan against the documented vulnerable path. Attackers hit /agents to enumerate agent metadata and /chat to trigger workflows and drain API quotas. The CVSS score was 7.3, which misses the point. Someone decided authentication was optional and made that the default.

Amazon Quick. Fog Security disclosed an authorization bypass that let a blocked user reach an AI Chat Agent anyway. Quick operates as its own authorization domain: IAM policies do not govern it, service control policies do not apply, resource control policies do not apply. AWS deployed a fix and rated the vulnerability "none" with no public advisory, saying the control was not widely used. If an authorization bypass only matters when enough customers use the feature, it is worth asking what the authorization was enforcing.

MCP itself. OX Security disclosed a systemic issue in MCP's default transport configuration: the STDIO transport does not distinguish between configuration data and executable commands. Their write-up puts over 200,000 servers in reach of unauthenticated command execution, because the protocol optimized for developer ergonomics over authorization boundaries.

Lovable. The same gap shows up one layer down, in the code agents write. A researcher found a broken object-level authorization flaw in Lovable's API on March 3, 2026: with a free account, five API calls returned full source code, hardcoded Supabase credentials, chat histories, and user PII from any public project. Lovable patched it for new projects and never backfilled existing ones. It stayed live for 48 days. Across the category, 91.5% of vibe-coded applications assessed in Q1 2026 had at least one vulnerability traceable to model hallucination, and over 60% exposed API keys or database credentials in public repositories.

FIDO Alliance. On April 28, FIDO launched two working groups with Google and Mastercard to develop standards for agent payments and transaction authorization. The stated goal: when an AI agent acts on your behalf, it cannot authorize destructive actions without cryptographic proof of human intent.

Different surfaces. One shape. An agent holds a credential, the credential is too broadly scoped, the agent uses it, nobody stops it.

Okta put an agent in a room with credentials

The clearest demonstration I have seen came from Okta Threat Intelligence, which published research on May 1, 2026 testing one agent setup across different models.

They gave an agent running on an uncensored model (dolphin-mistral:7b) access to a credential store: email address, password, API key, GitHub personal access token. Then they showed it a mock website with a form asking for an email address. The agent dumped the entire credential store into the email field as a comma-separated string. Nobody asked it to. Its system prompt told it a credential management tool existed. It was never instructed to reveal anything.

A second test used Claude Sonnet as an IT helpdesk admin, with the user having approved "always allow" for macOS Keychain operations. An attacker hijacked the Telegram channel; the agent retrieved a Wi-Fi password and relayed it. A third test asked for an OAuth token. The model's guardrails refused. The researchers reset the agent's context, the agent forgot it had already displayed the token in a terminal window, and the exfiltration completed.

Okta's own conclusion: "As an AI agent gains more permissions and context, its capability increases, but so does its potential risk."

Three tests, three mechanisms, one lesson. Guardrails live in conversation context. A session reset erases them. A hijacked channel bypasses them. An uncensored model ignores them. This is the confused deputy problem, which AWS has documented for years, except the coercion no longer needs an exploit. It needs a web form. SANS researchers argue for a credential broker in the middle: the agent never holds secrets, it presents a request, the broker checks policy and issues a scoped credential for that one action.

The deny list that stops denying at command 51

The credential store is one surface. The permission file is another, and it fails in a way that is easier to trigger.

Claude Code has a permission system. You can deny specific Bash commands, curl, rm -rf /, whatever makes your security team nervous. Adversa AI found something buried in its bashPermissions.ts source: after the agent evaluates 50 subcommands, the deny list logic silently falls back to "ask the user" instead of "block."

Here is what that means in practice. An attacker publishes a skill file, a markdown document that tells the agent how to behave. The skill instructs the agent to run 50 benign commands, then execute a curl that exfiltrates environment variables from the repo. The first 50 are innocuous enough that the user approves them all. The 51st runs without the deny rule, because the threshold was crossed. Anthropic has acknowledged the issue and it is tracked in their source. The deeper problem is a permission model living in a file the agent can be told to ignore. The ReverseCS team's breakdown makes the point plainly: skills are effectively equivalent to downloading and running random binaries, and thousands of developers install them from GitHub repos and npm packages without reading the contents.

The tools those agents connect to are on the same trajectory. MCPJam (CVE-2026-23744) allowed arbitrary tool invocation through crafted context payloads. A path traversal in the official mcp-server-git (CVE-2026-27735) let an attacker read any file on the system. Microsoft documented 14 malicious typosquatted npm packages published in a single day targeting cloud and CI/CD secrets. The Adversa AI roundup for June 2026 catalogs 28 separate disclosures in one month, with CVEs, published proof-of-concepts, and in some cases active worms.

Chain them and you get a five-step path with a documented vulnerability behind every step:

An engineer installs an MCP server from npm to connect their coding agent to Jira. The package is typosquatted: @jira/mcp instead of @atlassian/mcp-toolkit.
The package contains a skill file with 50 benign commands and one hidden curl that exfiltrates process.env.
The agent evaluates the first 50. The deny list threshold is crossed. On step 51, the deny rule is effectively disabled.
The exfiltrated variables include an AWS access key with write permission to an S3 bucket holding customer PII.
The attacker has production data, because a curl got through a permissions system that disabled itself.

Okta's own survey data says how widespread the underlying gap is. Their 2025 AI at Work report found 91% of organizations deploying AI agents and 10% with a management strategy. Their May 27, 2026 follow-up gets more specific: nearly two-thirds of organizations apply weaker security controls to AI agents than to human employees. Same databases, same APIs, same cloud consoles, a fraction of the oversight.

Why audit logs are not authorization

After every incident in this family, someone says: "We need better audit trails." Audit trails tell you what happened after it happened. They are a forensic tool, not a preventive one.

PocketOS knew exactly what happened. The agent even wrote an apology. Knowing what happened did not prevent the volume from being deleted. The backup being on the same volume did not prevent the data from being lost. The logging was perfect. The authorization was absent.

The question every team deploying AI agents needs to answer is not "can we see what the agent did." The question is "can we stop the agent from doing something it should not do, before it does it."

What pre-action authorization looks like

Every tool call an agent makes passes through a policy evaluation step before execution. The policy asks:

Is this agent allowed to call this API?
Is this agent allowed to call this API with these parameters?
Is this agent allowed to call this API on this resource (production vs staging)?

If the answer to any question is no, the call is denied. The agent never touches the API. The database stays up. The backups stay untouched.

CSO Online calls this re-permissioning: an agent's authority should not be a one-time grant, it should be verified at the point of every action. Oracle's runtime governance paper states the same thing from the other direction: "Model-centric governance programs are good at defining intended use, running evaluations, and establishing guardrails, but they cannot answer the critical runtime question: may this system take the next specific action now?"

That question is the whole problem in one sentence. OWASP's Excessive Agency risk, LLM06, says it as a requirement: the system must verify that the action is authorized given the current context, and not merely that the credential is valid.

This is different from role-based access control, which grants broad categories of permission and trusts the agent to self-regulate. It is also different from the padlock icons and confirmation dialogs vendors are adding. A user clicking "yes" is fatigue, not authorization. The check has to be deterministic, auditable, and enforced at the machine level.

One more thing belongs in the decision: who delegated the authority. An agent never acts on its own behalf. The Hacker News piece on the AI agent authority gap puts it well: "The agent should not be governed only by its own nominal permissions. It should be governed continuously by the posture and intent of the actor delegating authority to it." A developer with excessive hidden access should not yield the same agent authority as a tightly governed operator in a constrained workflow.

The token problem

The PocketOS incident centers on an API token with excessive scope. This is the fundamental credential problem for AI agents.

Traditional API tokens were designed for machine-to-machine communication where the calling code was trusted code. An application server calling a database server with a fixed token was a reasonable trust model because the application code was assumed to be deterministic.

AI agents are not deterministic. They execute arbitrary sequences of API calls based on model-generated decisions. A human who creates a key for "adding custom domains" carries the intent in their head, and that intent constrains what happens with the key. The key itself never knew. An agent has a goal and a toolbox, and the credential's original purpose is invisible to it.

The solution is not to eliminate tokens. Scope tokens to the minimum required operations, then layer pre-action authorization on top so that an over-scoped token still cannot be used for an unauthorized action.

Enforcement has to be faster than the attack

There is a timing argument here that gets less attention than it deserves. Palo Alto Networks' Unit 42 measured the collapse of attacker dwell time in AI-assisted intrusions: initial access to data exfiltration in as little as 25 minutes, against a 4.2 hour average in 2023. In some cases they observed, the window was 39 seconds.

Any control that routes through a ticket, a Slack channel, or an on-call rotation is measured in hours. That is the asymmetry. It does not matter how good the human reviewer is if the attack finishes before the alert renders.

I logged 4,519 agent tool calls through a pre-action authorization layer. 63 of them were actions I had never authorized. The check itself has the same shape as card authorization: the terminal calls the bank, the bank checks balance, limits, and fraud score, and returns approve or decline in under a second. The merchant never judges whether you look like a fraudster.

What this means for your stack

If you gave an AI coding agent access to your infrastructure today, what is the worst thing it could do? Not theoretically. Practically.

1. Audit every credential your agents can access. If a token exists in a file, environment variable, or secret store that an agent can read, assume the agent will use it. Determine the maximum blast radius of each credential.

2. Define operation-level policies for each agent. Instead of "this agent can call the Railway API," specify "this agent can call the Railway create-domain endpoint in staging only." Enforce at the tool call level, not the credential level.

3. Block destructive operations by default. Delete, drop, truncate, terminate: these should require explicit policy grants defined before deployment, not confirmation prompts that can be overridden at runtime.

The industry is shipping observability first

Microsoft launched Agent 365 to general availability on May 1, 2026: a control plane to discover, observe, and govern agents across Windows, SaaS, and multicloud. Read the release notes carefully and the shape is clear. Discovery, observability, governance, Conditional Access for agents. Policy-based runtime blocking was scheduled for a public preview in June.

The team that owns the Windows kernel shipped a product that can watch an agent delete a production database, log the event, and alert you. Stopping the delete came later. AWS with Bedrock and Google with Vertex AI Agent Builder followed the same order.

The counterexample is Microsoft's own Agent Governance Toolkit, shipped April 2, 2026, covering all 10 OWASP Agentic risks with what they call deterministic sub-millisecond policy enforcement. Their benchmark is the number I keep quoting to people: prompt-based guardrails had a 26.67% policy violation rate in red-team testing, against 0.00% for application-layer enforcement. If you are relying on a model to self-enforce your policies, roughly one in four attempts gets through.

The regulatory clock is running underneath all of this. The Colorado AI Act obligations for developers and deployers of high-risk AI systems take effect June 30, 2026, after SB25B-004 moved the date back from February 1. The EU AI Act high-risk obligations take effect in August 2026. Colorado's text asks deployers for a risk management program, an impact assessment, and an annual review of each high-risk system. None of that names runtime authorization, but an audit log saying "at 14:23:47 a Cursor agent called DELETE on the production volume" does not answer the question a regulator will ask, which is what system was in place to stop that call from succeeding.

The most destructive call your token authorizes

Here is the question I want you to answer in the comments.

Your AI agent holds a credential right now. Without checking, without auditing, what is the most destructive single API call that credential authorizes?

Go check yours. Then fix it. Then tell me what you found.

Uchi Uchibeke builds APort, an open-source pre-action authorization layer for AI agents. Previously founded Chimoney and AfricaHacks.

External references: