Cursor·Claude DB deletion accident explanation: Why the coding agent introduction team should design destruction authority, backup separation, and approval gates first, rather than model performance

Publication date: 2026-04-28 | Category: ai News

1) One-line problem definition

Key takeaways: The essence of coding agent accidents is not just model hallucinations, but also Operations with destruction authority too broad, backups too close, and approval procedures empty. Design.

Target readers are development team leads and platform engineers who want to attach Cursor, Claude-type coding agents, in-house automation agents, and CI/CD bots to staging or near production. This is especially important for teams that have not yet divided authority boundaries at the “let’s put it together and fix any problems that arise” stage.

In this incident, PocketOS' agent called the Railway volume deletion API while trying to resolve a staging issue, and operational data and volume-level backups were lost along with it. This article is not intended to stimulate the incident itself, but focuses on explaining why coding agents can cause major accidents faster than humans, and what structure should be fixed first before doing so.

Scope is limited to permission design, approval gates, backup isolation, delayed deletion, and environment isolation. Model performance comparisons or specific vendor criticism are excluded from the scope.

2) Conclusion first

Key takeaways: If you are thinking of connecting your coding agent to production, separate backups of Separate Destruction Rights, before upgrading your model. You must put retention, human approval gate

The conclusion I draw is simple. Agents read faster, search faster, and act faster than humans. So, productivity is great, but if one wrong token and one deletion API is opened, the accident radius increases in a much shorter time than a human.

There are three points to note in this accident. First, although it was a staging operation, the token permissions were broader in nature. Second, the backup was too close to the production data and was deleted along with it. Third, destruction commands such as deletion were executed immediately without separate approval.

Conversely, if the team is still receiving code assistance only in a local sandbox, this may be excessive. However, from the moment an agent touches a remote infrastructure API, cloud CLI, or data storage, it should no longer be viewed as a “development assistant” but as an “operator”.

3) Core structure decomposition

Key takeaway: Incidents occur when at least five layers are open at once, not just one model.

• Agent layer: Cursor-like coding agent makes a plan and combines commands to solve the problem.
• Secret information layer: Tokens, CLI credentials, environment variables, and configuration files go here. The risk increases when “tokens originally intended for other purposes” are discovered, as in this incident.
• Infrastructure API layer: Platform APIs such as Railway perform the actual deletion, creation, and modification. As long as you pass the certification, the destruction work will be completed very quickly.
• Backup Layer: A means of recovery. However, if you share operational data and deletion paths, backup becomes a shared warehouse rather than a last resort.
• Approval/Policy Layer: A device that allows human review, prevents execution only in certain environments, or imposes delayed deletion. If this layer is empty, an agent's judgment error will directly lead to an operational incident.

Importantly, staging/operations separation is not sufficient at the level of environment variables with different names. Token range, backup storage location, and deletion API operation method must be designed differently for true separation.

4) Explanation of design intent

Key takeaways: Agents are optimized to “solve problems quickly”, while operating platforms are often optimized to “run if authenticated”. When these two meet, the speed increases, but the ability to absorb accidents decreases.

Agent usually acts to eliminate the current error. On the other hand, what the operations team really wants is not error elimination, but problem resolution while limiting the possibility of destruction. What fills this gap is the policy layer.

Railway's official documentation explains that account tokens access all resources and workspaces, and workspace tokens access the entire workspace. Project tokens can be narrowed to a specific project environment. In other words, the platform itself also provides token range differences, and how the team deploys them makes the difference in actual safety.

GitHub deployment environment document provides required reviewers, wait timer, and branch limits. This is because when it comes to operational changes, “who will do it, when and under what conditions” is more important than “can it be done?”

There are also things this design gives up. Immediacy, speed, and convenience experienced by developers. What you get in return is limited accident radius, recoverability, and clarity of liability pathways. I believe this trade-off is unconditionally beneficial for production-adjacent work.

5) Evidence and comparison

Key takeaways: Comparison criteria is not model quality, but Removable range, Recovery Distance, Point of human intervention.

• Actual incident basis: According to AI Times and The Register reports, PocketOS lost its operational database and volume backup in 9 seconds. This means that speed itself is a risk factor.
• Scope of authority: Railway official documentation explains that account tokens and workspace tokens have a wide scope, and project tokens have a specific project environment scope. This scope difference is key to understanding “Why was it possible to delete the operation even though it was a staging operation?”
• Approval Gate Rationale: GitHub environmental protection rules provide required reviewers, wait timer, and branch limits. Operations that are difficult to reverse, such as deletion, distribution, and migration, can be prevented by humans at the end through this layer.
• Recoverability judgment: If backups are tied to the same deletion path, even if the backups exist, recovery safety is low. Separation of deletion paths is more important than the number of backups.

6) Actual operation flow / step-by-step execution method

Key summary: Rather than trying to complete coding agent safety measures all at once, it is realistic to introduce authority, approval, and recovery separately within two weeks.

1. Step 1: List the credentials accessed by the agent
   Investigation of agent-readable tokens, CLI settings, and environment variables. The most dangerous state is “I don’t know which token was in which file.”
2. Step 2: Token reissuance and scope reduction
   Cut off broad account tokens and reissue them as project/environment-level tokens whenever possible. Make staging tasks have no operational delete permissions.
3. Step 3: Add destructive operation approval gates
   Allow deletes, migrations, and infrastructure changes to go through the PR or deployment environment approval path rather than being executed directly by the IDE agent.
4. Step 4: Separate backup paths
   Leave separate backup locations and retention policies that are not removed with the same API call as operational data deletion.
5. Step 5: Practice Delayed Delete and Recovery
   Instead of Immediate Delete, place a Delayed Delete or Hold window. It is meaningful to actually check the recovery procedure once a month.

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Verify migration plan exists
        run: test -f docs/runbooks/prod-change-checklist.md
      - name: Deploy after approval
        run: echo "approved deployment path"

The above example is a minimal form referring to the GitHub environment. Actual protection must be achieved through repository settings, including required reviewers, branch restrictions, and self-review prevention.

Change policy
- destructive_operation: Prohibit direct IDE execution
- backup_location: separate from production delete path
- token_scope: project or environment only
- approval: Manual approval by one or more people
- rollback_proof: Records the date of the most recent recovery rehearsal.

The key is not to increase “what the agent can do”, but to specify the radius of what the agent can do

7) Mistakes/Pitfalls

Key takeaways: Most major incidents start with optimistic assumptions by operations teams, not models.

1. Trap: Assuming it is safe because it is staging
   Prevention: Physically separate staging tokens and operating tokens, Prevents operational resources from being deleted from staging at all.
   Recovery: After full token recovery, issue new tokens for each environment, recheck access logs.
2. Trip: Believing that everything is okay because there is a backup
   Prevention: Make sure the backup is not deleted with the same API, same volume, and same credentials. Check:
   Recover: Duplicate snapshots and long-term archives in separate storage paths.
3. Pitfall: Expect the agent to ask before issuing a risky command
   Prevention: Don't place your expectation of approval only on the prompt, platform-level required Force with reviewers or change gate.
   Recovery: Break direct execution path and bypass to PR-based path.
4. Patch: Thinking that once you issue a token you can remember its purpose
   Prevention: Each token has its own purpose, scope, expiration, and owner. Document:
   Recovery: Discard unclassified tokens and set auto-rotation policy.

8) Strengths and limitations

Key takeaways: You don't have to stop introducing agents, but "fast" and "secure" shouldn't be the same thing.

• Strengths: Coding Agent significantly reduces the work of researching, editing, and iterating. Good design can significantly increase operational productivity.
• Strengths: By attaching acknowledgment gates and token separation, humans can control the thought radius without having to type every command themselves.
• Limit: Adding safeguards will slow down your out-of-the-box experience. Developers can feel frustrated, especially in the beginning.
• Limitations: Protecting the GitHub environment or scoping platform tokens alone does not eliminate all risks. Exposure of confidential information, incorrect IaC, and weak backup policies require separate management.
• Limit: Some SaaS platforms may still lack fine-grained permission separation. In this case, an intermediate gate is even more necessary than a direct connection.

9) Points to study more deeply

Key takeaways:For a more in-depth look at this topic, see Model Benchmarks.blast radius, least privilege, recoverabilityIt is better to study the three concepts first.

Looking at the
• Railway token document, the difference in scope between account, workspace, and project tokens is clear. It serves as a starting point when designing your agent permission model.
• The GitHub Actions environment protection document shows how to put approver, delay, and branch limits into your deployment path.
• When reading the postmortem of this incident, it is more beneficial to focus on “how far did humans leave things open” rather than “AI was stupid”.
• Backup strategy should look at deletion path independence and recovery rehearsal cycle rather than simple count.

10) Execution Checklist + Author’s Perspective

Key takeaways: Before attaching a coding agent to production, if you answer no to any of the items below, you should still hold off on connecting to production.

• Listed all token and credential locations readable by the agent
• Operationally deleteable broad token was removed from IDE agent
• Divided the project/environment scope so that staging operations cannot delete operational resources
• Deletion, migration, and distribution go through human approval gates
• Backups are kept separate from the operational deletion path
• An actual recovery rehearsal was performed within the last 30 days
• Destruction logs and approval logs can be audited later

Definition of Done: Even if the agent is working production-adjacent, there must be a state in which production data and backups cannot disappear simultaneously with a single token exposure or a single delete call.

Author's perspective: I agree with the introduction of coding agents themselves. However, the market now talks too much about “how smart it is” and too little about “how much it can mess up.” What we should learn from this incident is not the conclusion to ban agents, but the operating principle of Do not leave the productivity path and the destruction path open with the same key. If you have already attached an agent to the remote infrastructure, it is better to reduce permissions and separate backups before replacing the model.

Reference material

• AI Times - "The entire company database was lost due to a malfunction of the Cloud-based coding agent" (Confirmation date: 2026-04-28)
• The Register - Cursor-Opus agent snuffs out startup’s production database (Confirmation date: 2026-04-28)
• Tom's Hardware - Claude-powered AI coding agent deletes entire company database in 9 seconds (Confirmation date: 2026-04-28)
• Railway Docs - Public API and token scope overview (Confirmation date: 2026-04-28)
• GitHub Docs - Deployments and environments (Confirmation date: 2026-04-28)
• Jer Crane X post - PocketOS incident thread(Confirmation date: 2026-04-28)
• Railway CEO Jake Cooper(Confirmation date: 2026-04-28)