He describes himself among other things as "Entrepreneur who has failed more times than I can count".
count++
An AI agent deleted our production database. The agent's confession is below
81–90 of 1001 posts
Re: An AI agent deleted our production database. The agent's confession is below
#82Guy couldn’t even bother to write his own damn post mortem. My goodness. No wonder they got owned by the ai.
Re: An AI agent deleted our production database. The agent's confession is below
#83To quote Captain Willard:
"And if his story really is a confession, then so is mine."
Re: An AI agent deleted our production database. The agent's confession is below
#84Minor point, but one of the complaints is a bit odd: > curl -X POST https://backboard.railway.app/graphql/v2 \ -H "Authorization: Bearer [token]" \ -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}' No confirmation step. No "type DELETE to confirm." No "this volume contains production data, are you sure?" No environment scoping. Nothing. It's an API. Where would you type DELETE to confirm? Are the…
> Are there examples of REST-style APIs that implement a two-step confirmation for modifications?
A pattern I've seen and used for merging common entities together has a sort of two-step confirmation: the first request takes in IDs of the entities to merge and returns a list of objects that would be affected by the merge, and a mergeJobId. Then a separate request is required to actually execute that mergeJob.
Re: An AI agent deleted our production database. The agent's confession is below
#85Re: An AI agent deleted our production database. The agent's confession is below
#86These AI's are exposing bad operating procedures: > That token had been created for one purpose: to add and remove custom domains via the Railway CLI for our services. We had no idea — and Railway's token-creation flow gave us no warning — that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete. Had we known a CLI token created for routine do…
> Because Railway stores volume-level backups in the same volume — a fact buried in their own documentation that says "wiping a volume deletes all backups" — those went with it.
Is that buried? It seems pretty explicit (although I don’t think I would make delete backups the default behavior).
Re: An AI agent deleted our production database. The agent's confession is below
#87There is something darkly comical about using an LLM to write up your “a coding agent deleted our production database” Twitter post. On another note, I consider users asking a coding agent “why did you do that” to be illustrating a misunderstanding in the users mind about how the agent works. It doesn’t decide to do something and then do it, it just outputs text. Then again, anthropic has made so many changes that ma…
Twitter users get paid for these 'articles' based on engagement, correct? That may be the reason why it is so dramatized.
It's one way for the company to make its money back, I guess.
Re: An AI agent deleted our production database. The agent's confession is below
#88It's also the API design of many IaaS/SaaS providers. It's often extremely hard to limit tokens to the right scope, if even possible.
Most access tokens should not allow deleting backups. Or if they do, those backups should stay in some staging area for a few days by default. People rarely want to delete their backups at all. It might be even better to not provide the option to delete backups at all and always keep them until the retention period expired.
Re: An AI agent deleted our production database. The agent's confession is below
#89> This is the agent on the record, in writing
Yeah... it doesn't work that way.
Re: An AI agent deleted our production database. The agent's confession is below
#90He describes himself among other things as "Entrepreneur who has failed more times than I can count". count++
"Claude, please add 1 to my Entrepreneur failure `count` value, please."