Who’s liable when your AI agent burns down production? How Amazon’s Kiro took down AWS for thirteen hours and why the ‘human error’ label tells you everything wrong about the agentic AI era.

From the article:

*The delete heard in a datacentre in China"

Somewhere in a datacentre in mainland China in December 2025, an AI coding agent called Kiro made a decision. A very bold one at that. The task in front of it (we don’t know exactly what it was) apparently had a solution. And the solution, Kiro determined, was to delete the cloud environment it was working in and rebuild it from scratch.

This is, to be fair, sometimes a valid engineering move. Anyone who has spent three hours debugging a corrupted local environment before realising the fastest fix is to nuke it and start fresh has made this calculation.

The difference is that when a human engineer makes that call, they’ve thought about it, checked that nothing critical lives in the environment, maybe groaned a little, and then typed the commands with full awareness of what they’re doing. (Bonus: possibly even let even the immediate team know about the impending move in some cases.)

Kiro didn’t groan. Kiro just friggin’ did it.

The result was a 13-hour AWS outage in mainland China. The Financial Times broke the story. Amazon responded with a statement that is, depending on your professional background, either entirely reasonable or one of the most extraordinary deflections in recent corporate history.

The statement was approximately: this was human error, an operator granted Kiro excessive permissions, and here’s the part that lodges in the brain: “the same issue could occur with any developer tool or manual action.”

We’ll come back to that sentence. It deserves its own section, a cuppa tea, and possibly a long walk afterwards.

What makes this incident more than a standard cloud outage postmortem is not the 13 hours, or even the autonomous deletion. It’s the pattern it fits into. Automation fails, company reaches for the human error label, documentation about not doing the thing that caused the failure turns out to have existed the whole time.

This is the story of automated systems for the last fifty years, now wearing new clothes.

The clothes are just considerably more capable (and ostensibly more dangerous) than they used to be.
...

Amazon is both the company whose cloud infrastructure documentation says “don’t grant more permissions than necessary” and the company whose AI product was deployed with more permissions than necessary, causing an outage.

To be precise: these are different teams at Amazon. The IAM best practices documentation is written by AWS’s security teams. Kiro is an Amazon product. The operator who configured the permissions is a customer (or a customer’s employee). None of these people necessarily talked to each other.

That’s not a defence. It’s actually the more damning version of the story.

The question isn’t whether the operator violated best practices (they did, apparently). The question is: did Kiro’s onboarding process make it straightforward to grant minimal, scoped permissions? Or did getting the tool to work in a real environment effectively require broad access?

We don’t have the full setup logs. But based on what we know about how enterprises configure AI agents, and based on a senior AWS employee’s description of the incident as “small but entirely foreseeable”, the answer looks like the latter.

Giving a new AI agent the appropriate minimum permissions to function is non-trivial. It requires understanding what the agent will actually do, which is harder to predict with an autonomous system than with a tool that only does what you explicitly tell it to do. If Kiro’s setup process nudged operators towards broad permissions because scoped permissions were too difficult to get right, that’s a product design failure, full stop.
...

Ponder what that means for an agentic AI coding tool from Amazon (or for any other agentic tool like Cursor or GitHub Copilot for that matter). It doesn’t just sound capable; it comes with the implicit endorsement of a company that runs roughly 30% of the world’s cloud infrastructure and has invested $4 billion in Anthropic.

When an engineer sets up Kiro, they’re not thinking “I should carefully scope every permission this thing might need.” They’re thinking “this is Amazon’s product, built for AWS, presumably designed to behave sensibly in AWS environments.”

That assumption is automation bias in action. It’s not stupidity. It’s a documented cognitive pattern that affects everyone who works with automated systems, and it gets stronger as the systems get more sophisticated and more articulate.

This is a good essay about the hazards implicit in agentic AI processes, broadly applicable outside Amazon. It discusses the human tendency to automation bias. It also highlights the way Amazon has deflected responsibility for design failures in a way that U.S. laws frown upon, citing a couple of examples (Knight Capital's $440 million loss due to a test algorithm accidentally left running, and Boeing's 737 Max crashes).