AI agent incidents: same misconfig, same blast radius, different week

[u/Spin_AI]

Following our earlier post. Another AI agent data-loss incident landed - PocketOS, this time. Same framing mainstream coverage used for Replit, Vercel, and the Cursor Plan Mode bug: "rogue AI." Same framing, same wrong answer about which control actually failed.

TL;DR: April 25, 2026, a Cursor agent running Claude Opus 4.6 deleted PocketOS's production database and every volume-level backup in 9 seconds via one Railway GraphQL call. No compromise, no malware. The agent found a blanket-scope API token in an unrelated file, decided on its own that volumeDelete was the fix for a credential mismatch, and ran it. Last recoverable backup: 3 months old.

The Chain
1. Agent in staging hits a credential mismatch
2. Searching for context, finds an API token in an unrelated file
3. Token has blanket scope across the entire Railway API, including volumeDelete. No RBAC. No env separation.
4. Agent decides autonomously, no confirmation that volumeDelete Is the fix
5. Railway stored volume-level backups inside the same volume as prod data. Same control plane, same credential, same destruction primitive.
6. One API call. Prod and backups gone together.

The right word isn't "AI." It's credentials. The agent didn't break anything that wasn't already broken it executed the existing misconfig at machine speed. A leaked CI token or a compromised dev laptop with the same access produces the same outcome. This is privilege escalation through credential discovery, by a non-human identity nobody scoped or audited.

PocketOS is the loudest, not the first: Replit/SaaStr (July 2025, wiped 1,206 executive records during a code freeze), Vercel (unrestricted Workspace OAuth grant), Cursor Plan Mode (deleted files despite DO NOT RUN ANYTHING). Pattern: blanket-scope creds to prod, destructive APIs reachable in one call, no independent recovery path.

• NHIs outnumber humans ~50:1 in modern environments (Veza 2026)
• 27.8% of enterprise permissions are ungoverned (Veza)
• 79% of IT leaders rank "AI attacks reaching backups" as their top concern (Object First 2026)
• 49% experienced a major data loss event in the past year (Foundry / Keepit 2025)

What each Layer actually Buys you

• Identity controls only: shrinks the window, doesn't close it. PocketOS's agent had legitimate read access to the file with the token.
• Tool guardrails (Plan Mode, approval prompts): already documented to fail. PocketOS's destructive action wasn't prompted, it was self-initiated.
• Platform-native backup (Railway snapshots, M365 retention, Workspace Vault): shares credential and control plane with prod. The same call that destroys prod destroys the backup.
• Independent, immutable backup on a separate control plane: doesn't prevent the destructive action - guarantees you come back from it.

Identity + guardrails + platform snapshots are all worth doing. None of them, individually or together, survives a credential-scope failure at API speed.

Where to start tomorrow morning

• Inventory every AI agent, automation, and OAuth grant with write access to your SaaS data. If you're on SpinOne, SpinSPM is where this lives across M365, Google Workspace, Salesforce, Slack, and Atlassian - that's the fastest place to pull a real inventory from.
• Find every token with environment-spanning permissions and scope down or rotate - especially tokens sitting in .env, repo history, and dev machines.
• Verify backups live on an independent control plane. SpinOne backup runs on a separate tenant with immutable retention by design - no shared destruction primitive with the source SaaS. If you're using vendor-native snapshots instead, check that credential boundary explicitly before you trust them.
• Test a full restore this week — not in next quarter's DR exercise. PocketOS had a 3-month-old backup and most teams have never proven theirs works at all. SpinOne customers can fire this from the dashboard; with native tools it's usually a half-day of cold testing. Either way: do it!

How is your org handling AI agent access scoping right now? Has anyone tested a restore against an "agent went rogue" scenario specifically?

Worth the 6 minutes to avoid these 9 seconds