I would never, ever trust my data with a company that, faced with this sort of incident, produces a postmortem so clearly intended to shift all blame to others. There’s zero introspection or self criticism here. It’s all “We did everything we possibly could. These other people messed up, though.”

You can’t have production secrets sitting where they are accessible like this. This isn’t about AI. This is a modern “oops, I ran DROP TABLE on the production database” story. There’s no excuse for enabling a system where this can happen and it’s unacceptable to shift blame when faced with the reality that this is exactly what you did.

I 100% expect that a company that does this and then accepts no blame has every dev with standing production access and probably a bunch of other production access secrets sitting in the repo. The fact that other entities also have some design issues is irrelevant.

It’s awful. "We had no clue this token had the permission to delete stuff!" - well buddy you issued it without deciding on permissions, it’s your job to assert that.

Your latest recoverable backup is three months old? The rule is 3-2-1, you didn’t follow it. Nobody else to blame but yourself.

And on and on he rambles…

Agreed. The post reflects that they were running an AI agent in YOLO mode in an unsandboxed environment with access to production credentials.

It doesn’t even seem to have crossed their minds that this behaviour is the real root cause. It’s everybody else’s fault.

Not a single mention of “maybe WE should have tested our backup strategy and scrutinised it”. Or even “maybe we should have backups away from the primary vendor”. Because this also says negligible DR and BC strategy.

Complete accountability drop

True but there’s nothing stopping a webdev dropping an API key in some wiki somewhere in the corporate intranet and the agent quickly picking that up.

Can you scan for that? Sure. But it’s a race to see who wins, the scanner or agent.

> This is a modern “oops, I ran DROP TABLE on the production database” story.

It's not that story, though. It's a story "oops, my tool ran DROP TABLE on the production database" (blaming the tool). At least I haven't heard people blaming their terminals or database clients as if the tool is somehow responsible for it.

The entire post reads like it was generated via LLM as well.