One URL that wipes your whole database
AI agents love scaffolding a quick "reset everything" or "delete all rows" endpoint for testing. If that route ships in your repo, one unauthenticated HTTP request can erase real customer data.
What can go wrong
A destructive cleanup route is an API path that runs deleteMany(), truncate, or a wipe helper on a whole table without checking who called it.
The happy-path demo needs a fresh database. The agent adds /api/reset, /api/admin/wipe, or a bulk-delete handler and forgets to remove it before handoff.
Anyone who guesses the path (or reads it in your client bundle) can trigger a full wipe. No exploit chain required: one GET or POST, data gone.
It happened for real
Builder horror threads in 2026 repeat the same shape: "I destroyed months of work in seconds" when a leftover admin wipe endpoint was reachable without auth (sorceress vibe-coding Reddit decode, 2026). The ASA Standard checklist lists exposed /api/reset and /api/seed routes as a top vibe-coding failure class (ASA exposed debug/admin routes).
How to check yours
Seatbelt flags this automatically. Repo scans hard-flag risky-shortcuts when they find wipe routes, bulk-delete handlers tied to real data, or table-clearing SQL outside migration files.
Ask your agent: "List every route or server action that deletes more than one row, truncates a table, or resets the database. Confirm each one requires an admin session."
Manual check: search your repo for paths like /api/reset, /api/seed, /admin/wipe, and handlers named clearDatabase or wipeAll. If any exist in production code, delete the file or gate it behind admin auth you actually test.
Fix direction
Delete the route file. Do not leave a "production disabled" stub: the file still ships in your artifact and scanners still find the path.
Paste into your agent: "Find and remove every unauthenticated wipe or reset endpoint. If we need admin cleanup, put it behind verified admin auth and document who may run it."