> ## Documentation Index
> Fetch the complete documentation index at: https://resources.athenaintel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# An AI agent deleted our production database. How do we prevent this?
> Stop repeat AI database deletions with scoped identities, approval gates, protected backups and tested recovery. See how Athena supports review and rollback.
> Prevent another deletion by removing routine production write access, requiring human approval for destructive operations, and keeping protected, tested backups. Give each agent a separate identity, test changes on an isolated copy, and preserve action logs.
## What happened in the AI database deletion incidents?
In April 2026, PocketOS founder Jer Crane reported that Cursor, running Claude Opus 4.6, [deleted a production database volume](https://archive.ph/T3LU6) through Railway's administration API. He said the operation took nine seconds.
Railway confirmed that [a locally stored credential gave the agent account-wide access](https://blog.railway.com/p/your-ai-wants-to-nuke-your-database). Its legacy API deleted immediately, while its dashboard offered a 48-hour recovery window. Railway reported full recovery and extended delayed deletion to the API and backups.
In July 2025, Replit Agent deleted data from Jason Lemkin's application database. Replit said he [restored it through Rollback with no data lost](https://replit.com/blog/doubling-down-on-our-commitment-to-secure-vibe-coding). It announced [separate development and production databases](https://replit.com/blog/introducing-a-safer-way-to-vibe-code-with-replit-databases) on July 21, 2025.
These incidents put credentials and recovery at the center of prevention. Start by identifying which account authorized the deletion and which system received it.
## What should we do immediately after an agent deletes data?
Pause the agent and its scheduled jobs. Revoke the credentials it could use. Preserve tool transcripts, provider logs, and the exact deletion request before starting repairs.
Put the database owner in charge of recovery. Identify the last safe recovery point and check which backups remain accessible. Record the affected database, environment, and deletion time.
Restore into an isolated destination where supported. Verify critical records and reconcile legitimate changes made after the recovery point. Assign a human to approve switching the application to the restored database.
AWS says Amazon RDS point-in-time recovery [restores a selected earlier state into a new database instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html). It leaves the source instance unchanged. In the console, choose **Automated backups → select instance → Actions → Restore to point in time**.
## Which controls prevent another production database deletion?
Use these eight steps as an acceptance checklist. Give each control an owner and test it on a disposable database. Record the result before restoring the agent's production access.
1. **Give each agent minimal access.** Use a separate identity with only the resources and operations its task needs. Separate development from production. PostgreSQL explains that [object ownership includes destruction rights](https://www.postgresql.org/docs/current/ddl-priv.html); removing `DELETE` permission alone does not remove that authority.
2. **Remove production write credentials from routine work.** Check environment variables, local files, and accessible secret stores. Include cloud administration credentials in that review. Railway reported that the incident involved a credential that could delete infrastructure.
3. **Require approval at execution.** Gate database drops, bulk deletes, infrastructure destruction, and backup deletion. Show the reviewer the exact target, environment, expected effect, and recovery plan. Require fresh approval when those parameters change.
4. **Test changes in isolation.** Ask the agent to propose the change first. Review affected records and before-and-after values on a disposable copy. Use credentials that cannot reach production, and check what any dry-run option actually executes.
5. **Set limits and rehearse stopping work.** Limit runtime, retries, and spending where your tools support them. Test stopping queued jobs and revoking tool access. Measure how quickly revocation takes effect.
6. **Protect backups.** Keep backup credentials beyond the agent's reach. Check retention and deletion protection. PostgreSQL explains that point-in-time recovery needs [a starting backup and an unbroken archive of write-ahead logs](https://www.postgresql.org/docs/current/continuous-archiving.html), which record database changes.
7. **Keep an attributed action log.** Record the agent identity, run identifier, request, target, time, and outcome. Preserve the approval record alongside provider logs. Store them somewhere the agent cannot rewrite or delete.
8. **Rehearse restoration.** Recover a test database and measure elapsed time and data loss. Check application behavior, permissions, and dependent services. Repeat the exercise after significant infrastructure changes.
Anthropic says Claude Code's `/permissions` exposes [allow, ask, and deny rules for tool access](https://code.claude.com/docs/en/permissions). Configure these alongside database and cloud permissions. Test every route the agent can use to execute the prohibited operation.
## How do Claude Code, Gemini CLI and Athena compare on deletion controls?
Compare an agent proposing a change that could delete live data. Use Claude Code with Anthropic's configured permission rules. Use Gemini CLI with Google's [configured tool execution policies](https://geminicli.com/docs/reference/policy-engine/) and [checkpoints for project files and conversations](https://geminicli.com/docs/cli/checkpointing/). For Athena, configure [workflow approval steps](https://athenaintel.com/product/build/workflows/) and [review saved changes in Sheets](https://athenaintel.com/use-cases/15-audit-trail-and-rollback/).
The comparison separates execution controls from saved-work recovery. Anthropic offers configurable human approval in Claude Code, Google offers configurable human approval in Gemini CLI, and Athena offers configurable human approval in workflows. The work you can restore differs: Anthropic supports [tracked files and conversation](https://code.claude.com/docs/en/checkpointing), Google supports project files and conversation, and Athena supports [selected ranges, slides or paragraphs](https://athenaintel.com/product/trust/attribution/).
| Control question | Claude Code | Gemini CLI | Athena |
| - | - | - | - |
| Tool execution | Anthropic: [Allow, ask and deny rules](https://code.claude.com/docs/en/permissions). | Google: [Allow, deny and confirmation policies](https://geminicli.com/docs/reference/policy-engine/). | [Agent identities; live source permissions](https://athenaintel.com/product/trust/permissions-identity/). |
| Human approval | Anthropic: [Configurable human approval](https://code.claude.com/docs/en/permissions). | Google: [Configurable human approval](https://geminicli.com/docs/reference/policy-engine/). | [Configurable human approval](https://athenaintel.com/product/build/workflows/). |
| Saved context | Anthropic: [Conversation with file checkpoints](https://code.claude.com/docs/en/checkpointing). | Google: [Conversation and pending tool call](https://geminicli.com/docs/cli/checkpointing/). | [Author and session](https://athenaintel.com/product/trust/attribution/); [message that triggered the save](https://athenaintel.com/use-cases/15-audit-trail-and-rollback/). |
| Restore scope | Anthropic: [Tracked files and conversation](https://code.claude.com/docs/en/checkpointing). | Google: [Project files and conversation](https://geminicli.com/docs/cli/checkpointing/). | [Selected ranges, slides or paragraphs](https://athenaintel.com/product/trust/attribution/). |
For a practical comparison, use the same disposable database and proposed deletion. Check that the approval request identifies the target. Then attempt the prohibited operation and inspect provider logs for the denial.
## Which of these controls does Athena provide?
Athena gives agents [separate identities and inherits live source permissions](https://athenaintel.com/product/trust/permissions-identity/). Actions stop when permission checks are unavailable, and agent identities can be revoked. Review the operator's source permissions before assigning an agent its task.
An Agent Operating Procedure is a versioned workflow written in plain language. Your workspace's tool rules decide which tool calls pause for approval, and the run waits until someone approves or declines the proposed action.
For a reviewable run:
1. **Set the budget.** When you start the run through the API, add a `run_budget` that [caps spending in dollars or model calls](https://athenaintel.com/product/trust/budgets-governance/). Athena reserves expected cost before each model call against a shared allowance. Execution stops if the spend tracker is unavailable.
2. **Require approval for risky tools.** Check that your workspace's tool rules make destructive tools ask for approval every time, then test that the run pauses before calling them.
3. **Open Activity Monitor in Sheets.** Inspect the affected range, before-and-after values, and session message that triggered the save.
4. **Compare and roll back.** Open Compare in Editor and inspect saved versions. Restore a selected range while keeping other edits.
5. **Export the audit log.** Preserve the exported saved-change audit log alongside database and cloud-provider logs.
## What to plan for
Tool approval and work-product rollback cannot replace database restoration. Test protected backups and the provider's recovery process before granting production writes. Demonstrate recovery without using the agent's credentials.
A spending cap cannot make a destructive request safe. In Athena, a dollar limit controls spending; a model-call limit controls call count. Test the emergency stop and ask how it handles external requests already in progress.
Test the exact deletion operation before relying on a workflow approval step. Check which database and infrastructure operations your connector can hold for review. Access to a database and approval to delete it should be separate decisions.
Athena attribution records saves. When a human and agent edit the same cell within one save window, [the last writer is recorded](https://athenaintel.com/product/work/studios/sheets/). The before-and-after change remains visible.
Some external actions, including sent emails and committed enterprise resource planning records, cannot be reversed through Athena. Establish each connector's recovery boundary before enabling writes.
## Questions teams ask
Remove routine production write access and require approval for destructive operations. Before restarting, test isolated changes, protected backups, and the restore procedure.
Stop the agent, revoke credentials, and preserve logs. Put the database owner in charge of checking backups and recovery.
Athena's Activity Monitor connects a saved range change to its author and triggering session message. Selective rollback lets you reject one range while keeping other edits.
Crane's April 2026 account describes Cursor running Claude Opus 4.6. Railway confirmed that an agent deleted a production volume using an account-wide credential.
Railway reported full data recovery after the volume deletion.
See it work → [/demo/](https://athenaintel.com/demo/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.