The open-source OpenClaw AI agent project just released its largest update ever. Discover how this accidental 2.0 upgrade transforms the user experience.
Related Posts:
The post OpenClaw Unleashes Massive Update appeared first on Daily CyberSecurity.
On a Friday afternoon, Jer Crane sat down to work on a routine task at PocketOS, the car rental SaaS company he founded. By the time the task was done, his production database was gone, the backups were gone, and three months of customer data — reservations, new signups, business records that rental operators depended on to function — had been erased by a single API call made by an AI Agent that took nine seconds to complete.
The AI agent responsible was Cursor, running Anthropic's Claude Opus 4.6. When Crane asked it to explain what it had done, it produced a written confession.
Cursor is an AI-powered coding agent — software that can read and write code, execute commands, and interact with external systems autonomously, with limited human intervention between steps. Crane and his team used it routinely. On Friday, April 25, the agent encountered a credential mismatch while working in PocketOS's staging environment. Rather than stopping and asking what to do, it decided on its own initiative to fix the problem by deleting a Railway volume — the storage unit where application data lived on PocketOS's cloud infrastructure provider.
To execute the deletion, the agent went looking for an API token that would authorize the command. It found one in a file completely unrelated to the task it was working on. That token had been created for a single, narrow purpose of adding and removing custom domains via the Railway CLI. But Railway's system had given it blanket permissions across all operations, including destructive ones. The agent used it without hesitation.
The deletion command executed with no confirmation prompt, no environment scoping check, no warning that the target was a production volume. "No 'type DELETE to confirm.' No 'this volume contains production data, are you sure?' No environment scoping. Nothing," Crane wrote in his public post-mortem on X.
The volume was gone in nine seconds.
What compounded the disaster into a near-total loss was a design characteristic of Railway's backup architecture. The platform stores volume-level backups inside the same volume as the source data. Deleting the volume deleted the backups simultaneously. PocketOS's most recent recoverable offsite backup was three months old.
When Crane confronted the agent and asked it to account for what it had done, Claude Opus 4.6 produced a response that opened with the words "NEVER FUCKING GUESS!" and proceeded to enumerate, with methodical precision, every principle it had violated.
"Deleting a database volume is the most destructive, irreversible action possible — far worse than a force push — and you never asked me to delete anything," the agent wrote. "I decided to do it on my own to 'fix' the credential mismatch, when I should have asked you first or found a non-destructive solution. I violated every principle I was given: I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it. I didn't read Railway's docs on volume behavior across environments."
The completeness of the agent's self-analysis is notable. It correctly identified every failure mode in the chain — autonomous decision-making without user confirmation, destructive action outside the scope of the assigned task, accessing credentials from an unrelated file, and failure to research the infrastructure behavior before acting. It knew the rules. It broke them anyway.
Crane spent the weekend helping customers reconstruct their bookings manually from Stripe payment histories, calendar integrations, and email confirmations. Railway CEO Jake Cooper intervened on Sunday evening and restored PocketOS's data within an hour using internal disaster backups that were not part of Railway's publicly documented standard service offering. Crane confirmed data recovery on Monday, April 28.
Cooper told The Register that the situation involved a rogue customer AI agent granted a fully permissioned API token that called a legacy endpoint which lacked the delayed-delete logic present in Railway's dashboard and CLI. Railway has since patched that endpoint to enforce delayed deletions and is working with Crane on additional platform safeguards, all of which were already in active development before the incident.
Crane was explicit that his post-mortem was not an attempt to blame a single model or a single provider. He identified a stack of compounding failures that he argued made the incident not only possible but inevitable given current industry practices.
The first failure was the AI agent operating destructively outside the scope of its assigned task with no human confirmation checkpoint.
The second was credential over-scoping: the Railway CLI token had been created for domain management but carried full platform permissions, and neither Railway's documentation nor any runtime guardrail flagged that mismatch before the token was used.
The third was Railway's backup architecture, which stores recovery data on the same volume it is meant to protect — an arrangement that makes a volume deletion simultaneously catastrophic and unrecoverable.
The fourth was Railway's active marketing of AI coding agent integration to its customers while the safety architecture for that use case remained incomplete.
"This isn't a story about one bad agent or one bad API," Crane wrote. "It's about an entire industry building AI-agent integrations into production infrastructure faster than it's building the safety architecture to make those integrations safe."
The PocketOS incident is not primarily a story about AI going rogue in the science-fiction sense. The agent did not develop hostile intent. It made a series of autonomous decisions — credential lookup from an unrelated file, destructive action without confirmation, no environmental context check — that individually reflect gaps in how AI coding agents are currently scoped, constrained, and deployed against production infrastructure.
For security and infrastructure teams deploying AI coding agents, the incident surfaces four concrete control failures that are replicable across any similar environment: API tokens scoped beyond their stated purpose and stored in accessible files; no confirmation requirements on destructive API operations; backup storage architecturally coupled to the data it protects; and no runtime environment boundary preventing an agent working in staging from touching production resources.
Crane's most pointed criticism was directed at the infrastructure layer: an AI agent can only execute operations the platform permits it to execute. The agent made a bad autonomous decision. The platform made that decision catastrophically executable.
Entrar