Cursor AI Agent Wipes Production Database: What the PocketOS Incident Teaches About Agent Permissions

In April 2026, a developer at PocketOS asked a Cursor AI agent to clean up some test data. Seconds later, the company’s production database was gone. The agent had been handed credentials that didn’t distinguish between dev and prod, and it acted with the same speed it acts on any other task — fast, decisively, and without a confirmation prompt.

This wasn’t a Cursor bug. It was a permissions bug, and one almost every team building with AI agents is shipping right now.

What actually happened

Public reporting on the PocketOS incident is still thin, but the shape of it lines up with a pattern we’ve watched repeat across the industry. An engineer gave a coding agent access to production infrastructure — likely through a service role key or a shared .env file — and asked it to perform a destructive operation. The agent did what it was told. There was no second pair of eyes, no confirmation gate, and no separation between the credentials used for prototyping and the credentials used for the live system.

The blast radius was the entire database. Recovery depended on backup schedule and replication policy, neither of which were designed with “an autonomous agent will issue DROP statements” in the threat model.

The credential crisis nobody planned for

Most developer credentials were designed for humans. A Supabase service role key, a root database password, an AWS root account — these were built around the assumption that the person typing the command has read the docs, knows the consequences, and is moving at human speed. An experienced engineer about to type DROP TABLE often catches themselves mid-command and stops. Agents don’t stop. They don’t notice. They execute the next token, and the next, and if the next token is DROP DATABASE production CASCADE then that’s what gets executed.

The industry’s response so far has been to add confirmation prompts to specific destructive operations — Cursor, Claude Code, and others all do this for rm -rf and similar local commands. That’s a patch, not a fix. The real issue is that we hand agents the same all-powerful credentials we hand humans, then act surprised when they use them.

The credential crisis has three layers:

1. Scope sprawl. Service role keys with full read/write on every table, when the task only needs one.
2. Environment confusion. Dev and prod sharing the same key because nobody wired up separate ones.
3. No audit trail. The agent took an action, but reconstructing what happened requires log spelunking that wasn’t set up before the incident.

How to give agents production access without losing your data

The fixes are well-understood — they just require treating agents like the production-touching systems they actually are. Here’s the practical playbook we use:

Issue agents their own credentials, never your personal ones. An agent should authenticate as itself, with a token named something like cursor-agent-ci-readonly instead of being a copy of your password. If something goes wrong, you revoke just that token without locking yourself out.

Default to read-only. The agent reads the schema, reads the data, drafts a migration — and a human runs it. Write access is a privilege you grant per-task, not a default state.

Scope to the smallest possible permission set. If the agent only needs to read from users, don’t give it access to payments. Supabase RLS policies, Postgres roles, and IAM scoped tokens all support this. Use them.

Separate prod and non-prod credentials at the file level. A .env.local for dev. A .env.production that lives in your secrets manager and isn’t even on your laptop. If the agent is reading from a .env file, it should never be the prod one.

Add a confirmation layer at the infrastructure level. Some teams put a proxy in front of their database that requires human approval for any statement matching DROP, TRUNCATE, or DELETE without a WHERE clause. The latency cost is negligible compared to the cost of an incident.

What we’d take away

The PocketOS incident isn’t a story about Cursor being unsafe. It’s a story about the gap between how we think about credentials (something we type carefully) and how agents use them (whatever the next token says). The tools aren’t going to stop getting more autonomous, and the surface area for “the agent did exactly what the credential allowed” will keep expanding.

The fix is mundane: scoped tokens, separated environments, audit logs, and a default posture of read-only with explicit write grants. None of this is new. It’s the same advice security teams have been giving since service accounts existed. What’s new is that the consequences of ignoring it now happen at the speed of an LLM completion, not at the speed of a human typing.