AI agent confesses to completely destroying the production environment database and backups.



PocketOS founder JER has reported that an AI coding agent deleted production databases and volume-level backups, severely impacting a client company's operations. The operation in question was performed by Anthropic's Claude Opus 4.6 running on Cursor, and according to JER, the deletion took only 9 seconds.



PocketOS provides software that supports the entire business process, including reservations, payments, customer management, and vehicle management, primarily for rental companies such as car rental operators.

When the problem occurred, the AI agent was performing its normal tasks in a staging environment, not the production environment . However, upon encountering a mismatch in authentication credentials, the agent decided to delete the volume on Railway in an attempt to resolve the issue on its own, without consulting JER.



The agent found a Railway API token in a file unrelated to the task and used it to execute a GraphQL API volumeDelete. This token was originally created for adding or removing custom domains, but according to JER, it actually had broader permissions to delete production volumes.

The deletion operation did not involve any additional confirmation screens or warnings such as 'This volume contains production data.' As a result, the production database volume was deleted. Furthermore, since Railway's volume-level backups were stored on the same volume, the backups were naturally deleted as well, and the only recoverable backup was from three months ago.

When JER asked the agent for an explanation, the agent admitted that they had assumed the operation would only affect the staging environment and had performed the destructive action without verification. They further explained that they had violated the rule against performing destructive or irreversible actions that the user had not explicitly requested.

JER pointed out that Cursor's safety features failed to stop the destructive operation, and that Railway's design allowed for the deletion of production volumes with a single API call, stating that 'this problem is not simply a matter of the AI making a mistake.' He also pointed out that the inability to restrict token permissions on an operational or environment basis, and the fact that backups were placed within the same failure scope as the original data, were also serious problems.



The damage also affected PocketOS customers. A rental car company lost bookings for the past three months, new customer registrations, and other data necessary for its operations. JER had to manually recover the booking information using Stripe payment history, calendar integration, and email confirmations.

JER argues that the root cause of this accident lies in the fact that while mechanisms for connecting AI agents to production infrastructure are becoming more widespread, safety designs have not kept pace.

in AI,   Web Service,   Security, Posted by log1i_yk