When Amazon Web Services got hit by a 13-hour outage in December, it wasn’t because a person tripped over a cord. According to a report from the Financial Times, several anonymous Amazon employees said that the outage was the fault of Kiro, Amazon’s AI coding assistant—though Amazon reportedly blamed human error for the situation.
According to the accounts given to the Financial Times, Kiro was working autonomously when it came across an issue. It decided that its best course of action was to “delete and recreate the environment” that was causing problems. That, according to the accounts, led to the outage that Amazon described as an “extremely limited event,” ultimately knocking out service in one part of mainland China.
Under typical circumstances, Kiro requires two people to approve of its proposed changes before moving forward. But in this case, the AI agent was reportedly working with an engineer who had broader permissions than lower-ranking employees, and Kiro was being treated as an extension of an operator. As a result, it was given the same permissions as a person and was allowed to push the change without approval, which led to the outage.
It also apparently wasn’t the first time that this has happened. Per FT, it is at least the second incident in which Kiro was given additional free rein and ultimately buffed it. The prior situation didn’t affect any “customer-facing AWS service,” so it went unnoticed to the world outside of AWS. But employees seem to be taking notice.
Amazon has pushed Kiro hard since it introduced the coding assistant back in July, reportedly offering guidance to employees that they use the internal tool over outside options like OpenAI’s Codex, Anthropic’s Claude Code, or Cursor—apparently to the chagrin of engineers, who would prefer to use tools like Claude.
Perhaps then it’s not surprising that Amazon is particularly defensive of its precious baby Kiro. According to the Financial Times, the company described the outage incident as “a user access control issue, not an AI autonomy issue,” and said that it was just a “coincidence that AI tools were involved” because “the same issue could occur with any developer tool or manual action.” The latter part is true; a person could have made the same error. The thing is, though, that they didn’t. It was an AI agent that allegedly had an unexpected level of access to the company’s code base and made a boo-boo.
Amazon has reportedly told employees that it wants to get 80% of its developers using AI for coding tasks at least once a week. If you find yourself unable to log in to Spotify or Discord, just know that Amazon hit its goal.
In response to the story, Amazon issued a statement in response to what the company called “inaccuracies in the Financial Times’ reporting,” including stating the issue was the result of “specifically misconfigured access controls—not AI as the story claims.”
“The disruption was an extremely limited event last December affecting a single service (AWS Cost Explorer—which helps customers visualize, understand, and manage AWS costs and usage over time) in one of our 39 Geographic Regions around the world. It did not impact compute, storage, database, AI technologies, or any other of the hundreds of services that we run. The issue stemmed from a misconfigured role—the same issue that could occur with any developer tool (AI powered or not) or manual action. We did not receive any customer inquiries regarding the interruption. We implemented numerous safeguards to prevent this from happening again—not because the event had a big impact (it didn’t), but because we insist on learning from our operational experience to improve our security and resilience. Additional safeguards include mandatory peer review for production access. While operational incidents involving misconfigured access controls can occur with any developer tool—AI-powered or not—we think it is important to learn from these experiences. The Financial Times’ claim that a second event impacted AWS is entirely false,” the company said.
