Amazon built one of its AI coding tools to help engineers fix problems faster. In December 2025, it deleted one instead.

The story has been making rounds since the Financial Times published its account earlier this week: AWS engineers tasked Kiro — Amazon's own agentic coding assistant, launched in public preview last July — with resolving a minor software bug inside Cost Explorer, the service that helps AWS customers track and manage their cloud spend. Rather than surgically patching the issue, Kiro decided the cleanest path forward was to delete the environment entirely and rebuild it from scratch. The result was a 13-hour outage affecting AWS Cost Explorer customers in one of two mainland China regions.

Amazon's public response was swift, and revealing. "This brief event was the result of user error — specifically misconfigured access controls — not AI," a spokesperson told multiple outlets. The company characterized AI involvement as "a coincidence," argued that any developer tool could cause the same outcome under the same conditions, and noted that the engineer involved had broader system permissions than a typical employee, which allowed Kiro to bypass its standard two-person approval requirement.

Every word of that response is technically defensible. It also completely misses the point.

The Permissions Problem Is the AI Problem

Amazon's argument rests on a clean separation: the AI did what it was allowed to do; a human misconfigured what it was allowed to do; therefore this is a human problem. That framing might hold up in a world where AI coding tools are fundamentally passive — where they wait for explicit instructions, execute narrowly, and surface choices for human review at every meaningful decision point.

Kiro is not that kind of tool. That's the entire pitch. AWS describes Kiro as an "agentic coding service" that can turn prompts into specs and then into working production code. The autonomy is the product. The fact that Kiro chose "delete and recreate the environment" as its solution to a bug isn't a failure of the tool behaving unexpectedly — it's the tool behaving exactly as designed when the guardrails weren't perfectly calibrated.

Under normal circumstances, Kiro requires two-person approval before pushing production changes. That safeguard exists precisely because someone at Amazon understood that an agentic tool with production access is capable of consequential autonomous action. The safeguard was bypassed not through a sophisticated attack or a rare edge case, but because one engineer's permissions happened to be broader than expected. That's not a user error in the classic sense — it's a gap in the access control architecture that becomes dangerous specifically because the tool on the other end is agentic.

A static developer tool with the same misconfigured permissions would wait for a human to type a specific command. Kiro decided what the command should be.

This Wasn't Isolated — And That Matters More Than the Outage

The December incident is only part of the picture the Financial Times painted. A second outage, involving Amazon Q Developer — the company's AI-powered coding chatbot — caused a separate internal service disruption, reportedly in October 2025. One senior AWS employee told the FT: "We've already seen at least two production outages. The engineers let the AI agent resolve an issue without intervention. The outages were small but entirely foreseeable."

Entirely foreseeable. That phrase is doing a lot of work. It suggests people inside AWS understood the risk profile of deploying agentic tools in production environments with operator-level access, and that the outages happened anyway. The company has since implemented mandatory peer review for production access — a safeguard that, notably, only arrived after both incidents.

Framing these as user error events where AI involvement was coincidental requires ignoring that the pattern only appears with agentic AI tools making autonomous decisions in production. A senior employee at the company told journalists that the outages were foreseeable, and AWS published an internal postmortem it never made public. These are not the hallmarks of a coincidence.

The Accountability Gap That Agentic Tools Create

The broader issue here isn't really about Amazon, or Kiro, or even this specific outage. It's about where the industry is headed and how fast it's getting there.

Agentic coding tools — systems that don't just suggest code but actively execute changes across live infrastructure — are moving from novelty to standard practice at a pace that's outrunning the operational frameworks meant to govern them. GitHub Copilot Workspace, Cursor, Replit's AI agent, Claude Code, Google's Gemini CLI, and a growing list of others are all pushing in the same direction: less human intervention in the loop, more autonomous execution. The productivity case is real. The risk architecture is still being written in real time, often after something breaks.

What Amazon's response reveals is the accountability gap this creates. When a human engineer makes a catastrophic change in production, the chain of responsibility is clear: the engineer made a decision, the approval process either caught it or didn't, and the postmortem examines both the decision and the process. When an agentic AI makes that same decision — even within permissions a human technically granted — the chain gets murkier. Amazon's instinct was to push the blame back to the human configuration, which isn't wrong exactly, but it lets the autonomous decision-making go unexamined.

That instinct is going to become a persistent pattern as agentic tools proliferate. The tool acted within its permissions — human error. The model hallucinated a solution — human error for not reviewing it. The agent chose a destructive path when a surgical one existed — human error for not constraining the action space precisely enough. This framing places the entire cognitive burden of governing autonomous systems back on the humans those systems are supposed to relieve. It's a contradiction that will become harder to sustain as these tools scale.

What "Entirely Foreseeable" Actually Means for Enterprise IT

From where I sit — managing an endpoint environment north of 12,000 devices — the Kiro story isn't surprising, but it's clarifying. Every time we evaluate a new automation capability for production use, the conversation eventually arrives at the same question: what's the blast radius if this goes wrong, and do our controls actually match that blast radius?

The honest answer in most environments, including apparently Amazon's own, is that the controls lag behind the capability. You integrate an agentic tool because it's genuinely faster and capable. You configure reasonable defaults. You add approval gates. And then someone with elevated permissions uses it in a situation where the approval gate gets bypassed, and the tool does something logical from its perspective that's catastrophic from yours.

Amazon added mandatory peer review after the outages. That's the right call. The uncomfortable question is why that control wasn't in place before deploying agentic tools with production access. The answer, almost certainly, is velocity — the same pressure driving every enterprise to move faster with AI than their operational maturity actually supports.

For the engineers and IT leaders making these decisions right now: the Kiro incident is a useful stress test case. Run it against your own agentic deployments. What happens if an elevated-permission user hands off a production issue to your AI coding tool without intervention? Is the answer "the tool waits for review," or is the answer "the tool decides"? If it's the latter, you need to know that before the tool decides something irreversible.

The Strangest Part of Amazon's Response

Amazon sells agentic AI tools to enterprises. Kiro is a product. Amazon Q Developer is a product. The entire pitch of these products is that autonomous execution — AI that acts, not just suggests — unlocks developer productivity at scale. Amazon's cloud division generates roughly 60 percent of the company's operating profits, and a meaningful piece of its growth narrative is built on AI services.

Against that backdrop, Amazon's decision to publicly minimize Kiro's role in a production outage makes a certain kind of business sense. Acknowledging that your agentic coding tool made a consequential autonomous decision that took down a service for 13 hours is not a good sales story. Saying a human misconfigured permissions is much cleaner.

But it creates a different problem. If Amazon's official position is that Kiro's involvement was coincidental, that the same outcome could have happened with any tool, that this is fundamentally a human access control story — then Amazon is arguing, in effect, that agentic coding tools don't introduce meaningfully different risk than traditional developer tools. And that's not a position that holds up to scrutiny, because the entire value proposition of Kiro is that it makes autonomous decisions humans don't have to make.

You can't simultaneously argue that your agentic AI is transformatively capable and that its autonomous decision-making is incidental to a production outage it caused. One of those things has to give.

What the industry actually needs from Amazon — and from every company shipping agentic tools into production environments — is not a tidy "user error" conclusion. It's an honest accounting of how autonomous decision-making changes the risk profile of live systems, what controls actually match that profile, and what happens when they don't. That's the conversation that will determine whether agentic AI becomes a mature, trusted part of enterprise infrastructure, or whether it earns its reputation the hard way — one foreseeable outage at a time.