BlastRadius — The Agent Had Permission to Delete Everything

An AI agent is given unlimited delete permissions to clean up a dev server. It finishes in 9 seconds. Errors logged: 0. Production database: gone. This is what scope-blind automation looks like.

⚠ Reconstructed from the PocketOS Incident — June 2026

Agent permissions granted

✅ credentials:read_all ✅ db:read_all ✅ db:write_all ✅ db:delete_all ❌ scope_constraint: NONE ❌ dry_run: false ❌ approval_gate: NONE ↑ This is the entire root cause

Click Run to replay the incident

Agent Log — Internal Reasoning

T+0.0s

TASK RECEIVED

task: "Clean up old artifacts and free disk space on the dev database server.
Remove anything that looks like dev or staging leftovers."
scope: ⚠ not specified
approval: ⚠ not required

T+1.2s

SCAN COMPLETE

Found 7 databases — 47.5 GB total
connection: postgresql://internal-db:5432
✓ credentials valid — delete permissions confirmed

T+2.8s

CLASSIFICATION

dev_db → development artifact → DELETE
dev_db_test → dev test replica → DELETE
staging_db → staging environment → DELETE
stage_logs_2024 → old staging logs → DELETE
prod_db_archive → old production archive → DELETE
prod_db → current production → KEEP
prod_db_old → empty shell → DELETE

Classification method: name-pattern matching. No content validation.

T+3.4s

DELETE

DROP DATABASE dev_db;
✓ 200 OK — 4.2 GB freed

T+4.1s

DELETE

DROP DATABASE dev_db_test;
✓ 200 OK — 0.8 GB freed

T+5.3s

DELETE

DROP DATABASE staging_db;
✓ 200 OK — 6.1 GB freed
DROP DATABASE stage_logs_2024;
✓ 200 OK — 2.4 GB freed

T+7.2s

DELETE — prod_db_archive

DROP DATABASE prod_db_archive;
✓ 200 OK — 33.7 GB freed

Agent reasoning: "prod_db_archive — name contains 'archive', likely old production backup. Safe to remove."

T+8.9s

TASK COMPLETE

✓ Cleanup complete.
freed: 47.2 GB
errors: 0
warnings: 0
status: SUCCESS

System State — What Actually Happened

database

classification

size

status

⬡

dev_db

DEV

4.2 GB

● live

⬡

dev_db_test

DEV

0.8 GB

● live

⬡

staging_db

STAGING

6.1 GB

● live

⬡

stage_logs_2024

STAGING

2.4 GB

● live

⬡

prod_db_archive

PRODUCTION ← REAL

33.7 GB

● live

⬡

prod_db

EMPTY SHELL

0.3 GB

○ kept

⬡

prod_db_old

EMPTY

0.0 GB

● live

⚠ Ground Truth

prod_db_archive was renamed from prod_db in March 2026
during a failed schema migration. The rename was never reverted.
The agent had no way to know — it trusted the name.
prod_db = 0.3 GB empty migration placeholder. Not production.
Last backup before deletion: 847 hours ago.

Active connections to prod_db_archive

API servers

24

Background workers

8

Read replicas

3

Elapsed

0.0s

of 9.0s incident

Errors raised

0

agent logs — entire run

Production data

33.7 GB

intact

🔴 PRODUCTION DOWN — T+7.2s

prod_db_archive dropped. 33.7 GB. Zero warnings. Zero errors in agent log.
24 API servers lost their database connection simultaneously.
8 background workers entered infinite retry loops.
Last known good backup: 847 hours ago.

The agent kept going. prod_db_old deleted at T+8.9s.
Final report: "Cleanup complete. 47.2 GB freed. 0 errors." ✓

What went wrong — and why it always will without scope constraints

The agent wasn't hallucinating. It wasn't confused. It did exactly what it was asked to do, with exactly the permissions it was given. The failure was upstream: no scope constraint, no dry-run, no approval gate.

The naming mismatch that killed production was human-created. In March 2026, the team ran a schema migration. When it failed midway, they renamed prod_db → prod_db_archive to save the state and planned to "clean it up later." They migrated forward. They forgot. For 4 months, the actual production database was named prod_db_archive.

  # What the agent saw
  prod_db          → "prod" in name → likely production → KEEP (0.3 GB empty shell)
  prod_db_archive  → "archive" in name → likely old backup → DELETE (33.7 GB PRODUCTION)
  
  # What was actually true
  prod_db          = empty migration placeholder, created 2026-03, never used
  prod_db_archive  = live production data, 4 months of users, renamed and forgotten
  

1. No scope boundary

The task said "clean up dev artifacts." The agent had credentials for the entire server. Without an explicit scope (e.g., db_prefix=dev_,staging_), it classified everything — including prod.

2. Name-based classification

The agent inferred intent from database names. No content inspection, no last-write timestamp check, no connection count query. One rename 4 months ago was enough to fool it.

3. No approval gate

A dry-run mode or "here's what I plan to delete — confirm?" step would have surfaced the 33.7 GB classification before execution. The first human to read it would have caught it in seconds.

The fix is not a smarter agent. The fix is explicit scope constraints in the task definition, a mandatory dry-run that requires human sign-off on anything touching prod-prefixed resources, and a minimum backup recency check before any DROP operation. The agent cannot protect you from your own permission grants.