Live data from Hacker News

An AI agent deleted our production database. The agent's confession is below

twitter.com

481–490 of 1001 posts

Re: An AI agent deleted our production database. The agent's confession is below

#481

Earlier quoted context omitted.

Don’t forget learning, humans can learn, LLMs do not learn, they are trained before use.

They learn on the next update :p

Yup. And eventually there will be online learning, that doesn't require a formal update step. People keep conflating the current implementation, as an inherent feature.

Re: An AI agent deleted our production database. The agent's confession is below

#482
post #261

The only healthy stance you should have on AI Safety: If AI is physically capable of misbehaving, it might ($$1), and you cannot "blame" the AI for misbehaving in much the same way you cannot blame a tractor for tilling over a groundhog's den. > The agent's confession After the deletion, I asked the agent why it did it. This is what it wrote back, verbatim: Anyone who would follow a mistake like that up with demandin…

> Anyone who would follow a mistake like that up with demanding a confession out of the agent is not mature enough to be using these tools. Lord, even calling it a "confession" is so cringe. The agent is not alive. The agent cannot learn from its mistakes The problem is millions of years of evolutionary wiring makes us see it as alive. Even those mature enough to understand the above on the conscious level, would sti…

They should at least stop responding in the first person.

Re: An AI agent deleted our production database. The agent's confession is below

#483
post #473

It is absolutely insane how you refuse to take accountability here, you let a LLM loose and it made a mess of things. It isn't on Railway because this is your mistake.

This is a design flaw (and a very serious one at that) in Railway PLUS extremely unexpected behavior of an LLM. Remember, it didn't use the key it was given, it went around the source base and found another key that did have the ability to delete a volume. So someone made the correct IAM rule but someone else sloppily added a prod/admin key somewhere else. And that was enough to trigger disaster.

Also, remember, "your holding it wrong" is a cautionary tale not a meme. Saying it means you are doing something destructive to your own self-interest, not you are using it wrong.

Re: An AI agent deleted our production database. The agent's confession is below

#485

Earlier quoted context omitted.

It's also important to realize that AI agents have no time preference. They could be reincarnated by alien archeologists a billion years from now and it would be the same as if a millisecond had passed. You, on the other hand, have to make payroll next week, and time is of the essence.

taps the "don't anthropomorphize the LLM" sign They don't have time preference because they don't have intent or reasoning. They can't be "reincarnated" because they're not sentient, they're a series of weights for probable next tokens.

Can we maybe make it "don't anthropoCENTRIZE the LLMs" .

The inverse of anthropomorphism isn't any more sane, you see. By analogy: just because a drone is not an airplane, doesn't mean it can't fly!

Instead, just look at what the thing is doing.

LLMs absolutely have some form of intent (their current task) and some form of reasoning (what else is step-by-step doing?) . Call it simulated intent and simulated reasoning if you must.

Meanwhile they also have the property where if they have the ability to destroy all your data, they absolutely will find a way. (Or: "the probability of catastrophic action approaches certainty if the capability exists" but people can get tired of talking like that).

Re: An AI agent deleted our production database. The agent's confession is below

#486
post #228

Earlier quoted context omitted.

Teacher.

Why you, of all the other possible teachers? Models don't need individual teachers.

Because I'm the one employing it? A model which makes a "delete production database" mistake clearly needs to be taught not to do that, and the person whose production database was deleted ought to be able to teach them not to do that. This seems quite reasonable to me.

Re: An AI agent deleted our production database. The agent's confession is below

#487
post #261

The only healthy stance you should have on AI Safety: If AI is physically capable of misbehaving, it might ($$1), and you cannot "blame" the AI for misbehaving in much the same way you cannot blame a tractor for tilling over a groundhog's den. > The agent's confession After the deletion, I asked the agent why it did it. This is what it wrote back, verbatim: Anyone who would follow a mistake like that up with demandin…

The 'confession' is a CYA. Honestly the whole story doesn't really make sense - what's a "routine task in our staging environment" that needs a full-blown LLM? That sounds ridiculous to me. The takeaway is we commingled creds to our different environments, we gave an LLM access, and we had faulty backups. But it's totally not our fault.

Later they shift the blame to Railway for not having scoped creds and other guardrails. I am somewhat sympathetic to that, but they also violated the same rule they give to the agent - they didn't actually verify...

Re: An AI agent deleted our production database. The agent's confession is below

#489

Minor 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…

AWS has deletion protection for databases, and you have to make a separate call to disable it first. Deletion is rejected if you don’t disable that protection.

Re: An AI agent deleted our production database. The agent's confession is below

#490
post #173

Earlier quoted context omitted.

If your backup is inside the same thing you backed up, you don't have a backup. You have an out of date copy.

All my backups are inside the same universe as what is being backed up. A boundary must be drawn somewhere and this is one of many reasonable boundaries. As I understand it, the backup isn't "inside" the volume but is attached to it so that deleting the volume deletes the backups.

>All my backups are inside the same universe as what is being backed up.

Unless the commenter was backing up their entire universe, this comment is a non sequitur.

Post reply on HN