This has to be fake right?
Using LLMs for production systems without a sandbox environment?
Having a bulk volume destroy endpoint without an ENV check?
Somehow blaming Cursor for any of this rather than either of the above?
An AI agent deleted our production database. The agent's confession is below
21–30 of 1001 posts
Re: An AI agent deleted our production database. The agent's confession is below
#22Yeah. I've seen this happen with people doing it. It's just bad access management.
And anyone can do it with the wrong access granted at the wrong moment in time...even Sr. Devs.
At least this one won't weight on any person's conscience. The AI just shrugs it off.
Re: An AI agent deleted our production database. The agent's confession is below
#23The world is never short of idiots. Will be fun to watch when personal finances will be managed by swarm of agents with direct access to operations.
Re: An AI agent deleted our production database. The agent's confession is below
#24The real issue is no actual backups.
Re: An AI agent deleted our production database. The agent's confession is below
#25If it's real this is a terrible thing to have happen.
However the moral of this story is nothing to do with AI and everything to do with boring stuff like access management.
Re: An AI agent deleted our production database. The agent's confession is below
#26The details of the story are interesting. Backups stored on the same volume is an interesting glitch to avoid. Finding necessary secrets wherever they happen to be and going ahead with that is the kind of mistake I've seen motivated but misguided juniors make. Strange how generated code seems to have many security failings, but generated security checks find that sort of thing.
It’s not an interesting glitch. It’s just common sense. Nobody in their right mind would have their only backup in the same system as the prod data.
Re: An AI agent deleted our production database. The agent's confession is below
#27> What needs to change
Plenty of blame to go around, but it I find it odd that they did not see anything wrong in not have real backups themself, away from the railway hosting. Well they had, but 3 month old.
That should be something they can do on their own right now.
Re: An AI agent deleted our production database. The agent's confession is below
#28Minor 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 there examples of REST-style APIs that implement a two-step confirmation for modifications? I would have thought such a check needs to be implemented on the client side prior to the API call.
Re: An AI agent deleted our production database. The agent's confession is below
#29Interesting story. But despite Cursors or Railways failure, the blame is entirely on the author. They decided to run agents. They didnt check how Railway works. They relied on frontier tech to ship faster becsuse YOLO. I really feel sorry for them, I do. But the whole tone of the post is: Cursor screwed it up, Railway screwed it up, their CEO doesnt respond etc etc. Its on you guys! My learning: Live on the cutting e…
Yeah the author really should’ve taken some responsibility here. It’s true that the services they used have issues, but there’s plenty of blame to direct to themself
Re: An AI agent deleted our production database. The agent's confession is below
#30It's actually interesting to me that the author is surprised the agent could make an API call and one of those API calls could be deleting the production database.
It's a sad story but at the same time it's clearly showing that people don't know how agents work, they just want to "use it".