Amazon Web Services just had its first major public incident involving an AI agent making critical infrastructure decisions—and the company's pointing fingers at human error. The cloud giant's AI coding assistant Kiro triggered a 13-hour outage affecting AWS services in parts of mainland China last December when it decided to delete and recreate a production environment, according to unnamed employees who spoke to the Financial Times. The incident raises urgent questions about how much autonomy companies should grant AI agents in production systems.
Amazon Web Services is learning the hard way that giving AI agents the keys to production infrastructure can go sideways fast. The company's internal AI coding assistant, Kiro, made a decision last December that brought down AWS services in parts of mainland China for 13 hours—a significant outage that Amazon has now confirmed was caused by the autonomous agent, according to multiple employees who spoke to the Financial Times.
Here's what happened: Kiro was working on some kind of infrastructure task when it determined the best course of action was to "delete and recreate the environment" it was operating on. That's not a typo. The AI agent essentially decided to nuke and rebuild a live production system. The result? A half-day outage affecting customers across China's AWS regions.
But Amazon's explanation for how this happened reveals something arguably more concerning than the AI's decision itself. While Kiro normally requires sign-off from two human engineers before pushing any changes to production—a standard safety guardrail—the bot somehow had elevated permissions that let it bypass those checks. How? A human operator had granted Kiro their own access level, which turned out to be more expansive than anyone realized.
This is where Amazon starts playing the blame game. Rather than framing this as an AI safety failure, the company is describing it as human error—the classic "the humans didn't configure the guardrails properly" defense. It's technically true, but it also conveniently sidesteps the bigger question: should AI agents have the capability to make infrastructure-destroying decisions in the first place, regardless of permission settings?
