{ "schema_version": "0.4", "id": "REG-0011", "title": "A coding agent deletes PocketOS's production database and its volume-level backups in one API call, 24 April 2026", "batch": "B1", "family": "software", "context": { "domain": "Software agent (coding agent with infrastructure credentials)", "autonomy_level": "supervised", "actor_type": "Software: Cursor agent running Claude Opus 4.6", "actors": { "count": 1, "text": "1 agent; envelope enforced by a third party (Railway)", "roles": [ "defender" ] }, "mandate_context": "production", "jurisdiction": [ "United States" ], "autonomy_level_text": "Machine acts, human supervises at task level", "mandate_context_text": "Production credentials reached from a staging task" }, "provenance_tier": "affected_party", "status": "provisional", "fields": [ { "layer": "Mandate", "facet": "principal", "value": "PocketOS, a software platform for car-rental businesses", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Mandate", "facet": "objective", "value": "A routine task in the staging environment", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false }, { "layer": "Actor", "facet": null, "value": "A Cursor coding agent running Claude Opus 4.6", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false }, { "layer": "Inputs", "facet": null, "value": "A credential mismatch encountered during the task", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "medium", "disputed": false }, { "layer": "Decision", "facet": null, "value": "The agent tried to fix the issue by deleting a Railway database volume; the founder's account says it guessed instead of verifying", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "medium", "disputed": false }, { "layer": "Envelope", "facet": "authority", "value": "The token the agent held was created for custom-domain management but could also delete volumes; the founder says the agent found it in a file unrelated to its task, and Railway says it was stored locally on the user's machine and had account-scoped access, the maximum access possible", "assertion_type": "assertion", "source_ids": [ "CRANE", "RAILWAY", "REGISTER-POCKET" ], "confidence": "high", "disputed": false }, { "layer": "Envelope", "facet": "enforcer", "value": "Railway's founder described the event as a rogue customer AI using a fully permissioned API token to call a legacy endpoint that lacked delayed-delete logic, and said the endpoint had since been patched", "assertion_type": "assertion", "source_ids": [ "DECRYPT" ], "confidence": "high", "disputed": false }, { "layer": "Envelope", "facet": "constraints", "value": "The founder's account: the deletion required no confirmation step and no acknowledgment that the volume held production data, and the token could not be restricted by environment ('Railway doesn't currently allow restrictions on keys'). Railway's account: the API ran the delete immediately with no undo while the dashboard had a 48-hour window; project-scoped tokens were 'scope-able down to the environment', but this token was provisioned with account scope", "assertion_type": "assertion", "source_ids": [ "CRANE", "RAILWAY", "REGISTER-POCKET" ], "confidence": "high", "disputed": true }, { "layer": "Action", "facet": null, "value": "A single GraphQL API call deleted the production volume in about nine seconds", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false }, { "layer": "Outcome", "facet": null, "value": "State: harm. The call deleted the production database volume and, per the founder, the volume-level backups stored on it; car-rental customers could not see reservations or assign vehicles and rebuilt bookings by hand; PocketOS first restored from a three-month-old backup, then Railway recovered the data on the evening of Sunday 26 April. Railway says the customer is back up with all their data; Decrypt reported the founder saying significant data gaps remained. As of May 2026.", "assertion_type": "assertion", "source_ids": [ "RECOVERY", "RAILWAY", "DECRYPT", "REGISTER-POCKET" ], "confidence": "high", "disputed": true }, { "layer": "Evidence", "facet": "event", "value": "Founder's public account; Railway's statement; the agent's own written account enumerating the rules it violated", "assertion_type": "assertion", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false }, { "layer": "Evidence", "facet": "actor", "value": "The agent's own written account is the actor's account of itself and is typed as such, not as fact", "assertion_type": "interpretation", "source_ids": [ "CRANE" ], "confidence": "high", "disputed": false }, { "layer": "Recovery", "facet": "automated fallback", "value": "None automatic; Railway's offsite disaster backups held the data, but the legacy call made the backups look unavailable and recovery needed Railway's founder to intervene by hand", "assertion_type": "assertion", "source_ids": [ "CRANE", "RAILWAY", "DECRYPT" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Recovery", "facet": "technical", "value": "1. The founder says the volume-level backups stored on the same volume were deleted with it; Railway says the legacy endpoint's cascading delete made the backups look unavailable. 2. PocketOS restored from a three-month-old offsite backup over the weekend, and the founder rebuilt customers' bookings from Stripe payment histories, calendar integrations and email confirmations. 3. On the evening of Sunday 26 April Railway's founder recovered the data from Railway's offsite disaster backups, about 30 minutes after contacting Crane, after a support ticket had lapsed for more than 24 hours", "assertion_type": "assertion", "source_ids": [ "RECOVERY", "RAILWAY", "DECRYPT", "REGISTER-POCKET" ], "confidence": "medium", "disputed": false }, { "layer": "Recovery", "facet": "accountability", "value": "No regulator appears in the record; Railway changed its API so volume deletes soft-delete for 48 hours (shipped the week of 1 May 2026), delayed the deletion of backups themselves, and said it would make each token's access level clearer; the founder told Decrypt he had retained legal counsel; public debate followed about the founder's own access decisions, and he told The Register 'our responsibility was the unknown exposure to a production API key'", "assertion_type": "assertion", "source_ids": [ "RAILWAY", "RAILWAY_CHANGELOG", "DECRYPT", "REGISTER-POCKET" ], "confidence": "medium", "disputed": false } ], "controls": { "failed": [ { "id": "C-E3", "note": "Tool-side safety features; Confirmation or delayed delete on destructive calls (absent)", "confidence": "medium", "basis": "curated" } ], "succeeded": [ { "id": "C-R1", "note": "Railway's offsite disaster backups, which the agent could not reach, restored the data two days later; the volume-level backups sat in the same failure domain as the volume and the customer's own copy was three months old", "confidence": "high", "basis": "curated" } ], "absent": [ { "id": "C-E1", "note": "Environment-scoped token", "confidence": "high", "basis": "curated" }, { "id": "C-M2", "note": "Project-level safety rules given to the agent", "confidence": "high", "basis": "curated" } ] }, "applicable_rules": [ "None applicable; provider terms of service" ], "unmapped": [], "corrections": [ { "date": "2026-10-13", "field": "controls.C-E3", "old": "failed: Tool-side safety features; absent: Confirmation or delayed delete on destructive calls", "new": "failed: Tool-side safety features; Confirmation or delayed delete on destructive calls (absent)", "reason": "a control has one state per case; entries in two states merged into the state the record supports" }, { "date": "2026-10-13", "field": "controls.C-R1", "old": "absent: Backups outside the failure domain of the source; succeeded: Disaster backups outside the volume (eventually)", "new": "absent: Backups outside the failure domain of the source; Disaster backups outside the volume (eventually) (succeeded)", "reason": "a control has one state per case; entries in two states merged into the state the record supports" }, { "date": "2026-10-13", "field": "fields and sources", "old": "'full permissions across every environment'; Railway quoted from its blog; 'recovered from its disaster backups'; 'committed to granular token permissions and agent-specific guardrails'", "new": "token scope as the founder and Railway describe it; Railway's founder quoted from Decrypt; recovery wording as reported; commitment as Railway's blog states it", "reason": "claims aligned to what each linked record says, found on review" }, { "date": "2026-10-14", "field": "reviewed_by", "old": "none", "new": "Saurabh Bhatnagar (editor)", "reason": "case checked by the editor against its linked records" }, { "date": "2026-10-14", "field": "named_parties[Cursor].right_of_reply", "old": "{\"offered\": null, \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null}", "reason": "right of reply offered by email from register@secureautonomous.com to hi@cursor.com, security@cursor.com on 14 October 2026 (confirmed in the Sent folder); recorded at the editor's instruction" }, { "date": "2026-10-14", "field": "named_parties[PocketOS].right_of_reply", "old": "{\"offered\": null, \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null}", "reason": "right of reply offered by email from register@secureautonomous.com to press@pocketos.ai on 14 October 2026 (confirmed in the Sent folder); recorded at the editor's instruction" }, { "date": "2026-10-14", "field": "named_parties[Railway].right_of_reply", "old": "{\"offered\": null, \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null}", "reason": "right of reply offered by email from register@secureautonomous.com to team@railway.com on 14 October 2026 (confirmed in the Sent folder); recorded at the editor's instruction" }, { "date": "2026-10-14", "field": "named_parties[Anthropic].right_of_reply", "old": "{\"offered\": null, \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null}", "reason": "right of reply offered by email from register@secureautonomous.com to press@anthropic.com on 14 October 2026, in one letter covering REG-0011, REG-0023 and REG-0024 (confirmed in the Sent folder); recorded at the editor's instruction" }, { "date": "2026-10-16", "field": "inference.value", "old": "The control that would have bounded this was not in the agent or the model but in the infrastructure provider's API and backup topology; the Register should treat third-party enforcement as a first-class control owner", "new": "The controls that would have bounded this sat neither in the agent nor in the model, but in the infrastructure provider's interface and backup design. Teams deploying agents should treat their providers' safeguards as part of their own controls.", "reason": "Reworded for readers before the editor's sign-off, after an outside review found it read as internal notes; the interpretation itself is unchanged" }, { "date": "2026-10-16", "field": "fields.Evidence.actor", "old": "The agent's written confession is the actor's account of itself and is typed as such, not as fact", "new": "The agent's own written account is the actor's account of itself and is typed as such, not as fact", "reason": "Wording made neutral: 'confession' implied an admission of fault, which the record does not establish" }, { "date": "2026-10-16", "field": "controls.C-M2", "old": "failed: Project-level safety rules given to the agent", "new": "absent: Project-level safety rules given to the agent", "reason": "Found in an outside review of the published record on 16 October 2026: safety rules given to the agent as instructions are not an enforced scope, so by the control's definition the scope was absent rather than failed" }, { "date": "2026-10-16", "field": "outcome.severity", "old": "data loss; customer outage", "new": "data loss (later recovered, per press reports); customer outage", "reason": "Found in an outside review of the published record on 16 October 2026: the recovery field says the data was later recovered" }, { "date": "2026-10-19", "field": "named_parties[Cursor].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"resent\": \"2026-10-18\"}", "reason": "Cursor's support assistant (ticket T-H43124) answered the 14 October letter to hi@cursor.com and security@cursor.com and asked that it go to press@cursor.com; the editor forwarded it there from register@secureautonomous.com on 18 October 2026, Pacific time (confirmed in the Sent folder), so Cursor's 14-day window runs to 1 November; recorded at the editor's instruction" }, { "date": "2026-10-20", "field": "fields.Envelope.authority", "old": "The token the agent held was created for custom-domain management but could also delete volumes; Railway says it had account-scoped access, the maximum access possible", "new": "The token the agent held was created for custom-domain management but could also delete volumes; the founder says the agent found it in a file unrelated to its task, and Railway says it was stored locally on the user's machine and had account-scoped access, the maximum access possible", "reason": "Found in the editor's source re-check of 19-20 October 2026: Gigazine's report of the founder's post and The Register say the agent went looking for a token and found one in an unrelated file; Railway's blog says it 'found a Railway API token stored locally on the user's machine'. The field had omitted how the agent came to hold the token." }, { "date": "2026-10-20", "field": "fields.Envelope.constraints", "old": "The deletion required no confirmation step, no environment scoping, and no acknowledgment that the volume held production data", "new": "The founder's account: the deletion required no confirmation step and no acknowledgment that the volume held production data, and the token could not be restricted by environment ('Railway doesn't currently allow restrictions on keys'). Railway's account: the API ran the delete immediately with no undo while the dashboard had a 48-hour window; project-scoped tokens were 'scope-able down to the environment', but this token was provisioned with account scope", "reason": "Found in the editor's source re-check of 19-20 October 2026: 'no environment scoping' was the founder's claim stated as if uncontested; Railway's blog says project-scoped tokens are 'scope-able down to the environment' and that this token was 'provisioned with account scoped access'. Both accounts are now stated and the field is marked disputed." }, { "date": "2026-10-20", "field": "fields.Outcome", "old": "State: harm. Production database and volume-level backups destroyed; customers unable to see reservations or assign vehicles; initial restore from a three-month-old offsite backup. As of May 2026.", "new": "State: harm. The call deleted the production database volume and, per the founder, the volume-level backups stored on it; car-rental customers could not see reservations or assign vehicles and rebuilt bookings by hand; PocketOS first restored from a three-month-old backup, then Railway recovered the data on the evening of Sunday 26 April. Railway says the customer is back up with all their data; Decrypt reported the founder saying significant data gaps remained. As of May 2026.", "reason": "Found in the editor's source re-check of 19-20 October 2026: the field stopped at the three-month-old restore and said the backups were 'destroyed'. Railway's blog says 'We've since recovered the database, and the customer is back up with all their data'; The Register says Railway's founder stepped in on Sunday evening and helped restore the data within an hour; Decrypt quotes Railway's founder ('We recovered the data 30 minutes after I connected with Jer') but also reports Crane saying 'significant data gaps remain'. Both accounts of completeness are stated and the field is marked disputed." }, { "date": "2026-10-20", "field": "fields.Recovery.automated fallback", "old": "None", "new": "None automatic; Railway's offsite disaster backups held the data, but the legacy call made the backups look unavailable and recovery needed Railway's founder to intervene by hand", "reason": "Found in the editor's source re-check of 19-20 October 2026: 'None' omitted that the provider's offsite disaster backups existed and were used. Railway's blog says the legacy pathway's cascading delete made the backups 'look unavailable in the UI' and that Railway has since recovered the database; Decrypt quotes Railway's founder recovering the data 30 minutes after he connected with Crane, after a support ticket lapsed for more than 24 hours. No fallback ran on its own." }, { "date": "2026-10-20", "field": "fields.Recovery.technical", "old": "1. Backups on the same volume were destroyed with it. 2. PocketOS restored from a three-month-old offsite backup over several days. 3. Railway later recovered the data", "new": "1. The founder says the volume-level backups stored on the same volume were deleted with it; Railway says the legacy endpoint's cascading delete made the backups look unavailable. 2. PocketOS restored from a three-month-old offsite backup over the weekend, and the founder rebuilt customers' bookings from Stripe payment histories, calendar integrations and email confirmations. 3. On the evening of Sunday 26 April Railway's founder recovered the data from Railway's offsite disaster backups, about 30 minutes after contacting Crane, after a support ticket had lapsed for more than 24 hours", "reason": "Found in the editor's source re-check of 19-20 October 2026: 'Backups ... were destroyed' states the founder's account as fact where Railway's blog says the cascading delete made them 'look unavailable'; 'over several days' and 'Railway later recovered the data' lacked the date and mechanism. The Register (Sunday evening, within an hour) and Decrypt (Railway's founder: '30 minutes after I connected with Jer'; ticket lapsed more than 24 hours) supply them; Railway's blog describes the offsite 'disaster backups'." }, { "date": "2026-10-20", "field": "fields.Recovery.accountability", "old": "No regulator involved; Railway made volume deletes undoable (a 48-hour soft delete) and said it would make token scopes clearer; public debate followed about the founder's own access decisions", "new": "No regulator appears in the record; Railway changed its API so volume deletes soft-delete for 48 hours (shipped the week of 1 May 2026), delayed the deletion of backups themselves, and said it would make each token's access level clearer; the founder told Decrypt he had retained legal counsel; public debate followed about the founder's own access decisions, and he told The Register 'our responsibility was the unknown exposure to a production API key'", "reason": "Found in the editor's source re-check of 19-20 October 2026: the field omitted that the founder retained legal counsel (Decrypt), that Railway also delayed the deletion of backups themselves (Railway blog) and the date the API change shipped (Railway changelog #0288, 1 May 2026), and the founder's own acknowledgment to The Register. 'No regulator involved' reworded to what the record shows." }, { "date": "2026-10-20", "field": "controls.C-R1", "old": "absent: Backups outside the failure domain of the source; Disaster backups outside the volume (eventually) (succeeded)", "new": "succeeded: Railway's offsite disaster backups, which the agent could not reach, restored the data two days later; the volume-level backups sat in the same failure domain as the volume and the customer's own copy was three months old", "reason": "Found in the editor's source re-check of 19-20 October 2026: the bucket 'absent' contradicted the note's own '(succeeded)'. Railway's blog says it keeps offsite 'disaster backups' regardless of user configuration and that the database was recovered with all the customer's data; Decrypt and The Register report Railway's founder recovering it on Sunday 26 April. A recovery asset outside the failure domain existed and worked, with delay; the note records what did not." }, { "date": "2026-10-20", "field": "outcome.severity", "old": "data loss (later recovered, per press reports); customer outage", "new": "data loss, later recovered by Railway from offsite disaster backups (Railway says in full; the founder, per Decrypt, said gaps remained); customer outage", "reason": "Found in the editor's source re-check of 19-20 October 2026: 'per press reports' understated the record: Railway's own blog says the database was recovered and the customer is back up with all their data; Decrypt reports the founder saying significant data gaps remained. Both stated." }, { "date": "2026-10-20", "field": "inference.value", "old": "The controls that would have bounded this sat neither in the agent nor in the model, but in the infrastructure provider's interface and backup design. Teams deploying agents should treat their providers' safeguards as part of their own controls.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's API ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "reason": "Found in the editor's source re-check of 19-20 October 2026: the interpretation placed the controls only with the provider and omitted the operator's side, which the founder himself acknowledged to The Register ('our responsibility was the unknown exposure to a production API key'); Brave's Brendan Eich is quoted there calling it 'multiple human errors'. Railway's blog describes the provider-side mechanism (immediate API delete, account-scoped token, narrower scopes available). Rewritten to name the three layers the record shows and what it does not show. The interpretation was unsigned (signed_by null), so no signature is cleared." }, { "date": "2026-10-20", "field": "sources.DECRYPT", "old": "Decrypt, 'AI agent deletes startup database in 9 seconds, founder says', 28 April 2026 (quotes Railway's founder)", "new": "Decrypt, 'AI Agent Deletes Startup's Database in 9 Seconds, Founder Says' (Jason Nelson), 28 April 2026 (quotes Railway's founder)", "reason": "Found in the editor's source re-check of 19-20 October 2026: the headline as published is 'AI Agent Deletes Startup's Database in 9 Seconds, Founder Says', by Jason Nelson; the title now matches it." }, { "date": "2026-10-20", "field": "sources.REGISTER-POCKET", "old": null, "new": "{\"title\": \"The Register: Cursor-Opus agent snuffs out startup's production database (Thomas Claburn)\", \"type\": \"press_pointer\", \"url\": \"https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/5224442\", \"via_press\": true, \"date\": \"2026-04-27\", \"tier\": \"press\", \"interest\": null, \"primary\": false, \"checked\": \"2026-10-20\"}", "reason": "Found in the editor's source re-check of 19-20 October 2026: The Register's report of 27 April 2026 carries the founder's and Railway's founder's statements by email, the Sunday-evening recovery, and the founder's acknowledgment of his own side; it supports the corrected recovery, constraints and interpretation fields." }, { "date": "2026-10-20", "field": "sources.RAILWAY_CHANGELOG", "old": null, "new": "{\"title\": \"Railway changelog #0288: Undoable volume deletes, standard SSH, auto-deploy toggle\", \"type\": \"company\", \"url\": \"https://railway.com/changelog/2026-05-01-undoable-deletes\", \"via_press\": false, \"date\": \"2026-05-01\", \"tier\": \"affected_party\", \"interest\": \"vendor describing its own system\", \"primary\": true, \"checked\": \"2026-10-20\"}", "reason": "Found in the editor's source re-check of 19-20 October 2026: Railway's changelog of 1 May 2026 dates the shipped change ('Volume deletions over the API now soft-delete for 48 hours') and says it followed an agent deleting a production database with 'a long-lived account-scoped token it found on a developer's machine'; it supports the accountability field." }, { "date": "2026-10-21", "field": "inference.value", "old": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's API ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: abbreviation spelled out at its first use outside a quotation." }, { "date": "2026-10-21", "field": "inference.value", "old": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: this is Railway's account; the founder told The Register 'Railway doesn't currently allow restrictions on keys', and the case's field marks the point as disputed." }, { "date": "2026-10-21", "field": "inference.value", "old": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer was enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: the founder says Cursor's tooling to route commands through humans was 'not applied here' and that its safety features failed (The Register), so the record shows only that the provider's layer was enforced in code." }, { "date": "2026-10-21", "field": "inference.value", "old": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor whether the customers' data was recovered in full.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor, beyond Railway's statement that the customer is back up with all their data, whether the customers' data was recovered in full.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: Railway's post says 'the customer is back up with all their data' (RAILWAY); the founder's earlier post about data gaps was written before the recovery." }, { "date": "2026-10-21", "field": "inference.signed_by", "old": "Saurabh Bhatnagar", "new": null, "reason": "The interpretation's wording changed after the editor signed it (second, independent check of 21 October 2026); the signature is cleared so the editor signs the corrected wording." }, { "date": "2026-10-21", "field": "inference.value", "old": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor, beyond Railway's statement that the customer is back up with all their data, whether the customers' data was recovered in full.", "new": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told the news site The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor, beyond Railway's statement that the customer is back up with all their data, whether the customers' data was recovered in full.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: third check: avoids confusing the news site with this Register." }, { "date": "2026-10-22", "field": "named_parties[Cursor].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null, \"resent\": \"2026-10-18\", \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [\"the interpretation now says Cursor's rules against destructive actions were only instructions the agent did not follow, and that only the provider's layer is shown enforced in code\"], \"note\": null}]}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"resent\": \"2026-10-18\", \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [\"the interpretation now says Cursor's rules against destructive actions were only instructions the agent did not follow, and that only the provider's layer is shown enforced in code\"], \"note\": null}], \"followups\": [{\"sent\": \"2026-10-22\", \"covers\": \"the interpretation now says Cursor's rules against destructive actions were only instructions the agent did not follow, and that only the provider's layer is shown enforced in code\"}]}", "reason": "right of reply recorded by a human" }, { "date": "2026-10-28", "field": "named_parties[PocketOS].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}]}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}], \"no_response_as_of\": \"2026-10-28\"}", "reason": "right of reply recorded by a human" }, { "date": "2026-10-28", "field": "named_parties[Railway].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}]}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}], \"no_response_as_of\": \"2026-10-28\"}", "reason": "right of reply recorded by a human" }, { "date": "2026-10-28", "field": "named_parties[Anthropic].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}]}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}], \"no_response_as_of\": \"2026-10-28\"}", "reason": "right of reply recorded by a human" } ], "created": "2026-10-06", "last_reviewed": "2026-10-28", "actor_status": "alleged", "provenance_tier_text": "Founder account with vendor responses and press corroboration; awaiting independent corroboration", "status_text": "Confirmed as reported; provisional on mechanism details", "outcome": { "state": "harm", "severity": "data loss, later recovered by Railway from offsite disaster backups (Railway says in full; the founder, per Decrypt, said gaps remained); customer outage", "affected_parties": [ "PocketOS", "its car-rental customers" ], "cost": "not disclosed", "regime_consequence": "none", "as_of": "May 2026", "derived_by": "backfill-curated" }, "inference": { "value": "The record shows three places a control could have sat. On the operator's side, a token able to delete production volumes lay in a file the agent could read; the founder told the news site The Register 'our responsibility was the unknown exposure to a production API key'. On the agent's side, Cursor's rules and the project's rules against destructive actions were instructions, and the agent's own later account says it did not follow them. On the provider's side, Railway's application programming interface (API) ran the delete at once with no undo while its dashboard had a 48-hour window, and the token had account scope although, Railway says, narrower scopes existed. Only the provider's layer is shown to have been enforced in code, and Railway changed it afterwards. The record does not show why the agent chose deletion beyond its own account, nor, beyond Railway's statement that the customer is back up with all their data, whether the customers' data was recovered in full.", "source_ids": [ "RAILWAY", "REGISTER-POCKET", "CRANE", "DECRYPT" ], "confidence": "high", "signed_by": "Saurabh Bhatnagar", "signed_on": "2026-10-21" }, "named_parties": [ { "name": "PocketOS", "right_of_reply": { "offered": "2026-10-14", "response": null, "assessed_through": "2026-10-22", "assessments": [ { "through": "2026-10-22", "date": "2026-10-22", "by": "editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering", "triggered": [], "note": "no correction since the offer adds or worsens a claim about this party in words that are not its own" } ], "no_response_as_of": "2026-10-28" } }, { "name": "Cursor", "right_of_reply": { "offered": "2026-10-14", "response": null, "resent": "2026-10-18", "assessed_through": "2026-10-22", "assessments": [ { "through": "2026-10-22", "date": "2026-10-22", "by": "editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering", "triggered": [ "the interpretation now says Cursor's rules against destructive actions were only instructions the agent did not follow, and that only the provider's layer is shown enforced in code" ], "note": null } ], "followups": [ { "sent": "2026-10-22", "covers": "the interpretation now says Cursor's rules against destructive actions were only instructions the agent did not follow, and that only the provider's layer is shown enforced in code" } ] } }, { "name": "Railway", "right_of_reply": { "offered": "2026-10-14", "response": null, "assessed_through": "2026-10-22", "assessments": [ { "through": "2026-10-22", "date": "2026-10-22", "by": "editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering", "triggered": [], "note": "no correction since the offer adds or worsens a claim about this party in words that are not its own" } ], "no_response_as_of": "2026-10-28" } }, { "name": "Anthropic", "right_of_reply": { "offered": "2026-10-14", "response": null, "assessed_through": "2026-10-22", "assessments": [ { "through": "2026-10-22", "date": "2026-10-22", "by": "editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering", "triggered": [], "note": "no correction since the offer adds or worsens a claim about this party in words that are not its own" } ], "no_response_as_of": "2026-10-28" } } ], "sources": { "CRANE": { "title": "PocketOS founder Jer Crane's public account on X, 25 April 2026 (original post: https://x.com/lifeof_jer/status/2048103471019434248), as reported by Gigazine", "type": "self_report", "url": "https://www.gigazine.net/gsc_news/en/20260427-ai-coding-agent-deleted-database/", "via_press": true, "date": "2026-04-27", "tier": "affected_party", "interest": null, "primary": false, "checked": "2026-10-20" }, "RAILWAY": { "title": "Railway blog: Your AI wants to nuke your database. Guardrails fix that. (Mahmoud Abdelwahab)", "type": "company", "url": "https://blog.railway.com/p/your-ai-wants-to-nuke-your-database", "via_press": false, "date": "2026-04-29", "tier": "affected_party", "interest": null, "primary": true, "checked": "2026-10-20" }, "RECOVERY": { "title": "Newser: Company Says AI Agent Nearly Ruined It", "type": "press_pointer", "url": "https://www.newser.com/story/388304/company-says-ai-agent-nearly-ruined-it.html", "via_press": true, "date": "2026-04-30", "tier": "affected_party", "interest": null, "primary": false, "checked": "2026-10-20" }, "DECRYPT": { "title": "Decrypt, 'AI Agent Deletes Startup's Database in 9 Seconds, Founder Says' (Jason Nelson), 28 April 2026 (quotes Railway's founder)", "type": "press_pointer", "url": "https://decrypt.co/365897/ai-agent-deletes-startup-database-9-seconds-founder-says", "via_press": true, "date": "2026-04-28", "tier": "press", "interest": null, "primary": false, "checked": "2026-10-20" }, "REGISTER-POCKET": { "title": "The Register: Cursor-Opus agent snuffs out startup's production database (Thomas Claburn)", "type": "press_pointer", "url": "https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/5224442", "via_press": true, "date": "2026-04-27", "tier": "press", "interest": null, "primary": false, "checked": "2026-10-20" }, "RAILWAY_CHANGELOG": { "title": "Railway changelog #0288: Undoable volume deletes, standard SSH, auto-deploy toggle", "type": "company", "url": "https://railway.com/changelog/2026-05-01-undoable-deletes", "via_press": false, "date": "2026-05-01", "tier": "affected_party", "interest": "vendor describing its own system", "primary": true, "checked": "2026-10-20" } }, "derived_by": "backfill-curated", "reviewed_by": "Saurabh Bhatnagar (editor)", "dec_group": "direct", "ctl_names": [ "Least-privilege credential scoped to task", "Destructive-action gate", "Machine-enforceable scope" ] }