How to stop an AI agent from deleting your production database

Short answer: do not rely on the agent's judgement or its instructions. Make the delete impossible from where the agent stands. That means four boundaries: the agent holds no production database credential, its key belongs to staging and cannot reach production, any destructive operation you do allow is a named action behind a human approval, and backups live where no agent credential can reach. Add a halt switch for when something goes wrong anyway.

How it actually happens

The public incidents follow the same shape. What follows is drawn from public reporting, not from an account by the company. In the PocketOS incident of 25 April 2026, a coding agent working in staging hit a credential mismatch, went looking for authority it had not been given, found a token, and used a single API call to delete the production volume along with the backups stored inside it. Nine seconds. The system prompt told it never to run destructive operations.

Three things were true, and each is a design choice you control:

1. A production-capable credential was reachable from the agent's environment.
2. Nothing separated staging from production at the credential level.
3. Nothing outside the agent could refuse a destructive call before it ran.

A better prompt would not have changed any of them.

Boundary 1: no production credential in the agent's reach

List everything the agent's process can read: environment variables, .env files, cloud CLI profiles, kubeconfigs, MCP config, CI secrets mounted into its container. Any credential in that list that can drop a table, delete a volume, or rotate a key is a credential the agent has.

• Give the agent a read-only database role for exploration and diagnosis.
• Remove admin connection strings and cloud provider tokens from its environment entirely.
• Where the agent genuinely needs to perform a write, move the write behind a named operation (Boundary 3) rather than granting the permission.

Boundary 2: staging keys that cannot reach production

The PocketOS agent was working in staging. The damage was in production. The boundary this calls for is a credential that belongs to one environment and cannot be promoted. That is a design rule, not a claim about what would have happened there.

With Anlyon, a key belongs to exactly one environment and resolves its environment from the credential. There is no fallback that quietly promotes a staging key. A staging agent calling actions.invoke() gets staging's action definitions and staging's secrets, so even the same action name points at your staging API.

This is logical isolation, enforced row scoping in shared storage, not separate infrastructure. See staging and production isolation for the full argument.

Boundary 3: destructive operations as approved actions

Some destructive operations are legitimate: deleting a customer's data on request, dropping a tenant, purging a test environment. Do not grant the agent the permission to do them. Expose each one as an endpoint on your own internal API, which holds the database credential, and define it as an Anlyon action that requires approval.

await ops.secrets.put('ADMIN_API_TOKEN', { value: process.env.ADMIN_API_TOKEN! });

await ops.actions.create({
  name: 'delete-tenant',
  description: 'Permanently delete one tenant and all of its data.',
  method: 'DELETE',
  urlTemplate: 'https://admin.internal.example.com/tenants/{{input.tenantId}}',
  headers: { Authorization: 'Bearer {{secret:ADMIN_API_TOKEN}}' },
  inputSchema: {
    type: 'object',
    properties: { tenantId: { type: 'string', pattern: '^ten_' } },
    required: ['tenantId'],
  },
  requiresApproval: true,
});

What this buys you:

• One tenant, not the database. The action can delete exactly one tenant by id. The input is schema-checked and percent-encoded into one path segment, so it cannot become a different endpoint.
• A person decides first. The invocation parks and returns pendingApproval: true. On approval, Anlyon sends the request snapshot the approver reviewed. Destination bindings are checked again at dispatch.
• The credential never leaves. The admin token is in the vault. The agent cannot read it, and the action's host is fixed, so input cannot send it anywhere else.
• A record. Who asked, who approved, and what was sent, on the invocation.

For operations that should never be automated at all, do not define an action. The agent cannot call what does not exist.

Boundary 4: backups the agent cannot reach

The PocketOS backups were deleted with the volume because they were stored inside it. Keep backups in a separate account or project, with credentials that no agent, CI job, or production service holds, and with deletion protection or retention locks where your provider offers them. Test a restore. A backup you have not restored is a hypothesis.

Boundary 5: a switch that stops it

When an agent misbehaves, you want to stop it without a redeploy and without finding which of its credentials to revoke. Keep an operator key with environments:halt in your on-call runbook:

const operator = new Client({ apiKey: process.env.ANLYON_OPERATOR_KEY! });

await operator.environment.halt({ reason: 'agent attempted destructive operation' });

Halting stops the agent acting and stops anything leaving the environment. What you send still queues, so nothing is lost. It stops new dispatch. It does not recall a request another server already accepted. See the kill switch post for what a halt can and cannot stop.

Checklist

1. Inventory every credential the agent's process can read. Remove any that can destroy data.
2. Give the agent a read-only database role by default.
3. Separate staging and production at the credential level, not just by convention.
4. Expose the destructive operations you do allow as narrow endpoints, define them as actions, and require approval.
5. Move backups out of reach of every agent credential, and test a restore.
6. Put a halt switch in the on-call runbook.

Related

• An agent deleted a production database in nine seconds: the PocketOS incident in detail.
• AI agent tool permissions: least privilege, layer by layer.
• Docs: Environments and halt · Approvals · Actions

Free during Early Beta Access, no credit card. Start building →