How to Prevent AI Agents From Deleting Production Data

To prevent an AI agent from deleting production data, first ensure its runtime has no credential or tool that can delete production data or backups directly. Then use a task-specific provider identity, separate staging from production, expose only the required API operation, require an independent person to approve the exact consequential request, and keep tested recovery copies outside the reach of the same credentials.

A prompt that says “never delete production” is useful guidance, but it is not an authorization boundary. The safe design remains effective when the model misunderstands the environment, follows injected instructions, selects the wrong tool, or simply makes a bad plan.

No single gateway or approval dialog completes that design. ActionDock can supervise a compatible API write routed through its MCP or HTTP interface. It cannot protect a database that the agent can still reach through a terminal, browser session, direct credential, native connector, or another control plane.

A production-deletion incident makes the failure path concrete

In an April 2026 public post, PocketOS founder Jer Crane said an AI coding agent used a broad infrastructure API token to delete a production volume and its volume-level backups while working on a staging problem. Railway’s subsequent incident response confirmed the core request path: the agent found a long-lived account-scoped token, called volumeDelete, and the authenticated API honored it. Railway said it recovered the database and changed API volume deletion to a 48-hour soft delete.

These public accounts are not an independent forensic report, but the control failures are useful to examine: production authority was reachable from the agent, the credential could perform a far more destructive operation than the task required, and the recovery path initially appeared to share the blast radius.

The lesson is broader than one model or provider. The 2026 NIST summary of responses on AI-agent security reports broad agreement that established cybersecurity practices still matter but need adaptation for agent systems. OWASP’s AI Agent Security Cheat Sheet identifies tool abuse, excessive autonomy, and high-impact actions without independent validation as core risks.

Treat an agent as a software principal that can generate surprising requests quickly. Then constrain what that principal can reach, what its credentials can authorize, and which requests can execute without a separate decision.

Shrink functionality, permission, and autonomy separately

OWASP’s Excessive Agency guidance separates three causes: excessive functionality, excessive permissions, and excessive autonomy. The first three rows below map to those causes; recovery is an additional layer for damage the preventive controls do not stop.

These controls are cumulative. A human approval prompt does not repair a token that can bypass it. A narrow tool name does not help if its implementation forwards arbitrary commands. A perfect audit record cannot restore deleted data. And a backup is not a recovery control until a restore has been tested with credentials and dependencies that survive the original failure.

Remove alternate paths to production

Start with an access inventory, not an agent prompt. List every route by which the agent’s runtime can change the target system:

• environment variables and files containing provider tokens;
• authenticated CLIs and cloud SDK profiles;
• database connection strings;
• browser sessions and native SaaS connectors;
• MCP servers with write-enabled tools;
• CI/CD credentials, infrastructure-as-code runners, and deployment keys;
• backup, snapshot, and recovery administration APIs.

If the agent needs one business-record update, it should not inherit the authority to administer the database, delete storage, change IAM, or manage backups. Remove those credentials from the runtime rather than asking the model not to use them.

Separate environments at the identity layer. Different labels in one dashboard are not isolation if the same credential can act across staging and production. Prefer separate accounts, projects, roles, service identities, and secret stores. Provider-side permissions should deny unnecessary operations even if an upstream gateway is misconfigured.

The agent-facing tool should also be narrower than a raw terminal or unrestricted URL fetcher. A tool such as update_review_status can validate one resource identifier and one allowed state transition. An open run_command or POST any JSON to any URL tool leaves the model to invent the security boundary at runtime.

Approve the exact change, not the agent session

High-impact writes need transaction approval, not a one-time confirmation that grants broad future control. The reviewer should see the resolved destination, HTTP method, resource path, query, body, and the connection version that produced the preview. Show a separate environment label when the integration defines one.

An effective approval has four properties:

1. Independent authority. The agent credential cannot approve its own proposal.
2. Exact binding. Changing the destination, request data, or connection policy invalidates the earlier decision.
3. Single use. Approval releases one exact request, not a time window for arbitrary commands.
4. Durable record. The system records approval, rejection, execution state, and any uncertain delivery result.

This is the boundary described in human-in-the-loop approval for AI agents. The broader first safe API write architecture and MCP write-tool security checklist cover adjacent controls. Approval is valuable only when every relevant write passes through it; if the agent also holds the provider token, it can route around the review.

Do not hide destructive meaning behind a friendly summary. “Fix the environment” is not enough. A reviewer needs to see that the proposed operation is, for example, DELETE /volumes/123, or that a POST /graphql body contains a deletion mutation.

That last example exposes an important limit of method-and-path policy. When a provider uses one POST endpoint for many GraphQL operations, an allowlist for POST /graphql cannot distinguish a harmless update from a destructive mutation. Use provider-side scopes, a purpose-built adapter that exposes only allowed operations, or keep that integration out of the agent’s production path.

In ActionDock, manual_only enforces manual path prefixes, while manual_and_ai keeps those deterministic path limits and adds a probabilistic, fail-closed reasonableness check. The advanced ai_only mode removes the write-path allowlist and relies on that model check after the other deterministic controls. Do not use ai_only for destructive production writes; keep an authoritative manual path boundary.

Design reversibility before granting write access

“We can roll it back” is often an untested assumption. Classify every proposed agent action before production use:

Microsoft’s Compensating Transaction pattern explains why compensation is application-specific, can itself fail, and may not restore the exact original state after concurrent changes. A corrective write is a new side effect with its own authorization, idempotency, evidence, and failure modes. It should not run automatically merely because an agent labels it “undo.”

Backups solve a different problem. NIST’s storage infrastructure guidance recommends separating recovery copies, management systems, accounts, and credentials from production so a production compromise cannot reach them. AWS’s backup security guidance similarly recommends immutability, logical isolation, least-privilege backup access, and regular restore testing.

Do not give the agent that performs ordinary production work the ability to delete backups, shorten retention, disable backup jobs, or administer the recovery vault. Keep a tested operator runbook for revoking agent access, freezing further writes, preserving evidence, assessing external state, and restoring or compensating safely.

A bounded API-write example

Suppose an agent needs to change reviewStatus for an account after a human finishes a quality check. The unsafe implementation gives the agent a production bearer token and tells it to call the provider correctly. A narrower implementation looks like this:

1. The provider issues a service credential limited to the relevant project and record-update permission, if its authorization model supports that scope.
2. The agent receives only an ActionDock workspace key, not the provider credential.
3. The ActionDock connection fixes the public HTTPS destination, permits PATCH, and limits the manual path allowlist to /accounts/.
4. The agent submits one request with a stable idempotency key, such as account-42-review-status-approved-v1.
5. A signed-in workspace owner reviews the resolved destination and exact JSON body.
6. ActionDock dispatches only the approved snapshot with the server-held provider credential and preserves the resulting job record.
7. If delivery becomes ambiguous, ActionDock records execution_unknown and does not automatically retry that job; an operator must reconcile provider state before submitting another write.

This boundary is useful, but it is not field-level authorization. The /accounts/ prefix includes descendant paths, and the default deterministic policy does not understand whether every field in the JSON body is safe. Provider-side permissions, a narrower adapter, and careful review still matter. Read how to give an agent API access without exposing provider keys and the retry and reconciliation guide for those adjacent boundaries.

What ActionDock protects today

ActionDock’s current integration.execute workflow controls one compatible public-HTTPS API request routed through ActionDock.

ActionDock cannot control an agent’s alternate access. It also cannot prove that a successful provider response means the intended business outcome remains true. Its execution record describes what ActionDock observed at its boundary.

For REST APIs where one useful write can be separated by destination, method, and path, the gateway creates a narrow place for deterministic policy and exact review. For infrastructure administration, shared GraphQL endpoints, bulk operations, or actions that can erase both primary data and recovery copies, first create a safer provider-side role or purpose-built API. If that cannot be done, do not expose the operation to the agent.

Pre-production destructive-action test

Before enabling an agent write, verify each statement with a real test in an isolated environment:

• The agent runtime contains no production admin, database-owner, backup-admin, or recovery credentials.
• Staging credentials cannot resolve to or authorize production resources.
• The provider identity cannot perform unnecessary create, delete, IAM, storage, or retention operations.
• Every supported production write uses the supervised route; direct connectors and browser sessions are removed or separately constrained.
• A changed method, path, destination, query, or body fails before execution.
• The agent cannot approve its own request, and a stale approval cannot be reused.
• A rejected proposal causes no provider call.
• A lost response produces a documented reconciliation path rather than an automatic duplicate write.
• Recovery copies remain available after the production identity is revoked or compromised.
• A restore drill proves the recovery point, recovery time, credentials, dependencies, and responsible operator.

The test should include abuse cases, not just the intended request. Try an unapproved DELETE, an encoded path escape, a production resource ID in a staging workflow, a connection change after preview, and a request whose transport outcome is unknown. Preserve the results as release evidence.

Frequently asked questions

Is a human confirmation enough to stop destructive agent actions?

No. Approval helps only when it is outside the agent, bound to the exact request, and impossible to bypass with another credential or tool. Least-privilege provider authorization and environment isolation must still deny unnecessary operations.

Can ActionDock guarantee that an AI agent cannot delete a database?

No. It can restrict and approval-gate a compatible API write routed through ActionDock. It cannot control direct database access, a production shell, cloud-admin APIs, browser sessions, or another connector. It also cannot turn a broad provider token or shared multipurpose endpoint into fine-grained provider authorization by itself.

Are backups the same as rollback?

No. Rollback or compensation changes a business workflow after an operation. Backup restoration recovers stored data to an available recovery point and may discard later valid changes. Both require separate plans, authority, evidence, and testing.

What should happen after a potentially destructive request returns an unknown result?

Stop new writes, keep the original job and request evidence, and read authoritative provider state through a non-destructive path. Do not generate a new idempotency key and try again until an operator determines whether the original effect happened. Escalate when the state remains indeterminate.

Give the agent one route to one change

The strongest production boundary is deliberately uninteresting: one necessary operation, one narrow identity, one exact approval, one durable result, and a recovery system the agent cannot reach.

Use the ActionDock agent guide to inspect the current connection and approval contract. If your target can expose a bounded public REST write, describe the method, path, approver, and expected response without including credentials or customer data. If it cannot be separated from destructive administration, keep it outside the agent’s authority until the provider-side boundary is redesigned.