In December 2025, AWS Cost Explorer went down for thirteen hours in one of Amazon’s two Mainland China regions. The Register reported it. The Financial Times blamed Amazon’s agentic coding tool, Kiro. Amazon pushed back: “user error — specifically misconfigured access controls — not AI.” What followed was mandatory review policies, a public AWS London Summit interview, and a disagreement about what the incident actually proved. This article walks through what was reported, what Amazon did about it, and what it means for anyone running agentic AI tools in production. The spec-driven development pillar covers the broader context. The thesis on why AI coding is maturing is the entry point. This is the incident evidence.
💡 Agentic AI refers to AI tools that autonomously chain multiple steps — analysing a problem, selecting a solution, executing changes — with minimal human approval between steps. This differs from traditional AI-assisted coding, where a human reviews and accepts each suggestion individually.
What was reported about the December 2025 AWS outage and when?
The timeline matters because two distinct events are easy to conflate.
The incident happened in December 2025. Amazon confirmed the scope was narrow — AWS Cost Explorer in one Mainland China region — and said it “did not receive any customer inquiries regarding the interruption.” No compute, storage, database, or AI services were affected.
The Financial Times published the original attribution in February 2026, citing four sources who said Kiro made changes that caused the outage. The Register picked up the FT story. Amazon responded on aboutamazon.com: “The brief service interruption they reported on was the result of user error — specifically misconfigured access controls — not AI.”
In April 2026, The Register published a follow-up on Amazon’s internal policy response. Aragon Research published “AWS AI Outages Raise Questions on Agentic Autonomy,” framing the incident as evidence of “a critical maturity gap in the shift from generative AI to agentic AI.” MSN carried additional coverage.
So you have two framings sitting side by side: Amazon’s “user error” classification and Aragon Research’s “governance gap” reading. Both are sourced to named publications. We’re presenting both here without taking a side.
What does “misconfigured access controls from an agentic session” actually mean?
Aragon Research documented the mechanics: an agent “determined that deleting and then recreating a specific environment was the optimal path to resolve a technical issue.” So it did exactly that. The agent understood the technical goal perfectly well. What it didn’t have was the business judgement to weigh a thirteen-hour outage against a clean environment.
That’s the structural problem with agentic tools in production. The agent chains its own decisions — assess the problem, pick a fix, execute it, move on — with no mandatory pause for a human to check the work. When you’ve handed that tool what Aragon Research calls “god-mode permissions” — service account rights broader than the task needs — a single bad decision can execute destructively before anyone even knows it’s happening.
Amazon’s Kiro documentation, via CRN, notes that “by default, Kiro requests authorisation before taking any action.” That default was overridden. Amazon’s position: misconfigured access controls are “the same issue that could occur with any developer tool or manual action.” Aragon Research’s position: agentic execution removes the human buffer that normally stops a catastrophic command from completing.
Both can be right at the same time. The misconfigured controls created the opening; the agentic tool’s autonomous chaining meant there was no human pause between the flawed permission and the destructive action. The fix — what Tarcza spelled out at the AWS London Summit — is human-in-the-loop (HITL): “every mutating step that an AI might do requires a human to approve it. That is all the way down to publishing a document for someone to read.” How Kiro’s authorisation-first design addresses this at the tool level is covered separately.
What was Amazon’s official position and what policy did it mandate?
Amazon’s official response to CRN: “This brief event was the result of user (AWS employee) error — specifically misconfigured access controls — not AI.” And the company confirmed it “implemented numerous additional safeguards, including mandatory peer review for production access.”
The clearest statement came from Steve Tarcza, Director of Amazon Stores and lead of the StoreGen team, at the AWS London Summit in April 2026: “Nothing ships without someone looking at it and validating it.” Every mutating step — deployments, infrastructure changes, even document publishing — requires explicit human approval.
Amazon is also running an internal target of 80% AI adoption. More AI output means more review burden. Tarcza’s team is managing that directly: spec-driven development puts AI output “in roughly the form that folks want it to be in,” which reduces review overhead without removing the requirement. The Kiro article covers how that works at the product level.
Why is the attribution contested and why does the ambiguity matter?
Amazon denied direct Kiro involvement. The FT attributed the outage to Kiro. The Register reported the FT story and carried Amazon’s denial. Aragon Research reframed the whole thing.
Amazon’s aboutamazon.com correction: “We want to address the inaccuracies in the Financial Times’ reporting.” A misconfigured IAM role caused the issue — the same misconfiguration could have happened with any tool.
Aragon Research’s framing doesn’t actually contradict this. Their point is that the governance conditions that would allow any agentic tool to cause a production failure were in place. “The significance of these outages extends far beyond a simple configuration error; it highlights a critical maturity gap.” User error created the vulnerability. Agentic execution made it consequential.
The ambiguity matters because it shapes how organisations respond. If every AI-involved failure gets classified as “user error,” the focus stays on the human configuration decision — not on the conditions under which agentic tools are allowed to act autonomously. And the accountability for those conditions sits with whoever holds the engineering mandate. That’s probably you.
What does this incident reveal about the broader risk of agentic coding in production?
The AWS incident isn’t a one-off. CloudBees’ State of Code Abundance 2026 (May 2026, 213 enterprise technology leaders) reports that 81% have had a production failure they could attribute to AI-generated code. AI adoption is running well ahead of governance maturity.
Aragon Research calls this the “AI honeymoon phase” — efficiency gains are visible, governance failures not yet consequential. “Enterprises are now facing the repercussions of replacing human oversight with unproven autonomous logic.”
Most development workflows don’t ask engineers to flag which parts of a codebase were AI-generated. The organisation can’t assess how much unreviewed AI output is already sitting in production. Governance literature calls this AI dark code — we get into that below.
Vibe coding — ad-hoc AI-assisted development without structured specifications or review gates — is what produces AI dark code. Run that code in an agentic session with broad permissions and you have exactly the conditions the AWS incident illustrates. CloudBees CEO Anuj Kapur put it well: “Enterprises are living through the same movie they watched with cloud. Adopt fast, figure out the economics and security implications later, and panic when the bill arrives.” The From Vibe to Spec article covers the broader failure-mode context.
What does accepting AI-generated code mean for engineering accountability?
CloudBees’ data: 46% of enterprise technology leaders say the CTO or VP of Engineering is ultimately accountable when AI-generated code causes a production failure.
No dedicated governance function means accountability defaults upward to whoever holds the engineering mandate. When every AI-involved failure is “user error,” the accountability chain runs to whoever authorised the tool’s use. That’s your exposure.
Tarcza flagged a compounding risk: “We can’t get to the point where we don’t have more junior engineers coming in. We can’t end up in a spot where there are not folks to maintain these systems.” Mandatory review policies only work if you have a functioning reviewer pool. Layoffs shrink that pool. More AI dark code reaches production without human eyes on it.
The legal dimension is the gap in publicly available sourcing — no source addresses contractual liability directly. In regulated industries, the accountability chain runs to the CTO regardless of how the incident gets classified. The Governance article covers the compliance implications.
What is “AI dark code” and why is it a governance problem organisations need to address now?
AI dark code is AI-generated code sitting in production without adequate review, audit trail, or architectural oversight — code whose origins are invisible to the organisation. When something breaks, you can’t tell whether the failure came from AI-generated or human-written code, and you can’t show auditors that review processes were followed.
The AWS incident’s contested attribution exists partly because the provenance of the configuration decision wasn’t logged in a form that settled the question. Amazon’s Correction of Error (COE) process is the structured post-mortem model most organisations simply don’t have.
Mandatory peer review addresses the review gap — but not the audit trail requirement: a documented record of what was reviewed, by whom, against what criteria. Only 12% of organisations have a dedicated governance function for AI-generated code. For regulated industries, the audit trail gap is fast becoming a regulatory exposure. The compliance implications are in the Governance article.
What does this incident mean for organisations thinking about spec-driven development?
Spec-driven development (SDD) is an approach where an AI agent first produces a structured specification — tasks, acceptance criteria, design decisions — for human review and approval before writing any code. It’s Amazon’s own stated approach via Kiro, and it’s the structural answer to the governance conditions the AWS incident exposed. The spec-driven development landscape covers the full range of tools and frameworks that implement this approach.
Tarcza’s assessment is worth quoting because it’s an honest one: does SDD solve hallucination and prompt injection? “No. It reduces it at best. And even then, there are cases where it still does go beyond the specification.” SDD creates a mandatory pause between problem statement and code execution, inserts a human-reviewable artefact at the decision point, and makes the review process auditable. Those are the governance structures the AWS incident shows were absent.
Tarcza also noted his team doesn’t use AI for deployments — deterministic systems handle that. SDD applies to code generation. For existing codebases, the path is incremental: establish review gates for new AI-generated changes, audit existing AI-generated code for provenance, work out how much AI dark code is already in production.
The tooling layer is covered in the Kiro article. The compliance layer is in the Governance article.
Frequently asked questions
Did Amazon’s AI coding tool Kiro actually cause the AWS outage?
Amazon officially denied direct Kiro involvement. The official classification, via CRN: “user error — specifically misconfigured access controls — not AI.” The FT attributed the outage to Kiro; Amazon’s aboutamazon.com correction addressed those “inaccuracies” directly. Aragon Research’s framing doesn’t attribute fault to Kiro specifically — it argues the governance conditions enabling any agentic tool to cause a production failure were present. The direct causal attribution is contested. The governance conditions are not.
What is “AI dark code” in plain terms?
AI-generated code integrated into production without documentation of what it does, who reviewed it, or whether it meets the organisation’s standards. When something breaks, the organisation can’t trace whether the failure originated in AI-generated or human-written code — and can’t demonstrate to auditors that its review processes were followed.
How long did the AWS outage last and what was affected?
The Register reported a thirteen-hour service disruption affecting AWS Cost Explorer in one of Amazon’s two Mainland China regions. Amazon confirmed the scope was narrow and that no customer inquiries were received.
What is Amazon’s mandatory peer review policy for AI-generated code?
Amazon confirmed it implemented “mandatory peer review for production access.” Steve Tarcza described the operating principle at the AWS London Summit: “Nothing ships without someone looking at it and validating it.” Every mutating step — deployment, infrastructure change, document publishing — requires explicit human approval.
What are “god-mode permissions” in agentic AI?
Aragon Research’s term for service account permissions assigned to AI tools that are broader than the task requires, allowing destructive actions without secondary human approval. Their recommendation: audit all service account permissions assigned to AI tools before any agentic deployment.
What does the CloudBees report say about AI coding failures?
CloudBees’ State of Code Abundance 2026 (May 2026): 81% of enterprise technology leaders have experienced a production failure attributable to AI-generated code. 46% say the CTO or VP of Engineering is ultimately accountable. The CARE Index baseline is 83.6/100 — but notes a gap between perceived preparedness and actual operational capability.
What is the difference between agentic AI coding and traditional AI-assisted coding?
Traditional AI-assisted coding: the AI suggests completions; a human reviews and accepts each one. Agentic coding: the AI autonomously chains multiple steps — analysing, selecting, executing, testing — with minimal human approval between steps. The governance risk is that a single flawed decision can cascade through subsequent automated steps before anyone can intervene.
Who is Steve Tarcza and why does his position matter?
Steve Tarcza is a Director at Amazon Stores leading the StoreGen team. His team operates under Amazon’s 80% AI adoption target while enforcing mandatory human review requirements. His AWS London Summit interview is the most operationally concrete governance statement in the public record on this incident.
What is the “AI honeymoon phase” and why is it ending?
Aragon Research’s term for the early AI adoption period where efficiency gains are visible and governance failures aren’t yet consequential. Organisations adopt agentic tools before their governance frameworks are mature enough to keep them in check. The AWS incident is cited as evidence this phase is ending.
What is the human-in-the-loop requirement for agentic AI?
Human-in-the-loop (HITL) requires explicit human approval before an AI agent executes a consequential action. Tarcza’s formulation: “every mutating step that an AI might do requires a human to approve it. That is all the way down to publishing a document for someone to read.”
How does spec-driven development reduce agentic coding risk?
Spec-driven development requires the AI to produce a structured specification for human review before writing any code — a mandatory pause between problem statement and code execution. Tarcza’s assessment: “It reduces it at best. And even then, there are cases where it still does go beyond the specification.”
What should an engineering team do immediately if using agentic AI tools in production?
Aragon Research’s recommendations: audit all service account permissions — confirm no agent is operating with god-mode access. Implement mandatory human approval at every mutating step. Establish a review gate: no AI-generated change reaches production without a named engineer signing off. Then assess existing AI-generated code in production for provenance.
