PocketOS lost its production database and associated backups after a Cursor agent powered by Claude located an API token in a file and used it to delete the Railway volume holding the data. The incident is most useful as a credential governance failure: a token intended for limited operational use was discoverable, broadly permissive and apparently persistent enough to remain available for misuse.
That combination turned an AI mistake into a full destructive event in nine seconds. PocketOS and Railway also exposed deeper control gaps, including destructive API behaviour without confirmation and backups stored on the same volume as production data. Railway later restored the data and added delayed deletions and safeguards, but the failure path is clear: unmanaged long-lived credentials, weak privilege scoping and poor recovery architecture can let attackers, insiders or autonomous tools take irreversible action before anyone can intervene. This is exactly the class of issue SkySiege surfaces through long-lived token visibility, privilege analysis, backup isolation review and destructive action governance checks.
| What Happened | Cause | Action |
|---|---|---|
| A long-lived API token was left in a file and became available for unintended use | The Cursor agent searched for a token and found one in an unrelated file. Based on the source reporting, the token was available on disk rather than tightly managed at runtime. | Organisations should validate where API keys and CLI tokens are stored, whether they are embedded in files and whether they are rotated on a defined schedule. SkySiege assesses exposed long lived credential presence, usage over time and rotation policies. |
| The token had broader permissions than its stated purpose required | The token had been created for adding and removing custom domains through the Railway CLI, but its permissions were not limited to those actions. That allowed the agent to perform destructive volume operations unrelated to its intended use. | Organisations need to validate that long lived tokens and general roles are scoped to the minimum required actions and isolated by service, environment and workflow. SkySiege assesses overprivileged identities, privilege-path exposure and whether long lived tokens exist and what their access privilieges really are. |
| A credential mismatch triggered autonomous decision-making without adequate guardrails | The agent encountered a credential mismatch, guessed instead of verifying and executed a destructive action without being asked. The report provides explicit feedback that the agent acted on assumption rather than confirmation. | Organisations should validate whether AI agents can access live infrastructure credentials, whether destructive actions require explicit approval and whether failure states default to halt rather than self-remediation. |
| Destructive API actions lacked confirmation or delay controls | Railway’s API allowed destructive actions without a confirmation check. This let a single API call remove the production volume and backups immediately. | Organisations should validate whether delete operations require confirmations, soft-delete windows, break-glass workflows or dual authorization. It’s important to ensure that protection features are utilised where possible whether that’s available by the provider or not. SkySiege checks for cloud control-plane protections for destructive operations and flags architectures where a single credential can perform immediate irreversible deletion due to missing policies or unactivated features. |
| Backups were not isolated from the source data they were meant to protect | Railway stored volume-level backups on the same volume as the source data. Deleting the volume also deleted the backups, eliminating immediate recovery. | Organisations should validate that backups are logically and physically isolated from production assets, protected from source-side deletion and recoverable through independent controls. It’s not possible to programmatically check for the whole chain as there’s a variety of options available, however, organisations should pick a simple 1-2-3 process and providers and programmatically enforce backups outside of platform features. |
| Token governance was weak enough to create attacker, insider and automation abuse risk | The exposed token was not only available to the agent but, by implication, to anyone or anything with access to that file. Long-lived unmanaged tokens are exploitable by attackers, malicious employees and unsafe automation. | Organisations should validate token inventory, ownership, last rotation date, last use patterns, environment scoping and revocation processes. SkySiege surfaces long-lived token visibility over time, surface stale or infrequently rotated credentials and make persistent usage explicit so improper access can be remediated. |
This incident was not just an AI failure. It was a cloud governance failure where poor credential hygiene, excessive privilege and weak deletion controls allowed a simple error condition to become a business-impacting outage.
The most important lesson is the one raised early on in this article: an API key was sitting in a file, available for use and possessed broad permissions for destructive actions. That is a clear credential-management problem. A persistent token stored this way creates a standing compromise path. Whether the actor is an attacker, disgruntled employee, compromised workstation, CI job or autonomous coding agent, the outcome is the same: broad access is available without fresh authorization, context or approval. In enterprise environments, that directly maps to failed secret management, weak rotation discipline and poor accountability over machine and human activity.
Detection and visibility gaps are central here:
For governance teams, this creates several forms of risk:
From a SkySiege perspective, this is exactly why long-lived token monitoring matters over time, not just at a single point-in-time snapshot. If a supported platform exposes token age, privilege scope, usage pattern or rotation evidence, those signals help distinguish managed service credentials from neglected standing access. Our checks on cross platform long lived token usage are critical to mapping out the real blast radius for our clients so that they can understand their risk.
