The Financial Times reported that a 13-hour AWS outage in December had been caused by the deployment of Kiro, Amazon’s own AI coding tool — a story picked up widely by Engadget, Gizmodo, and others. Amazon published a direct rebuttal.
In its statement, Amazon describes an extremely limited event affecting only AWS Cost Explorer in one of 39 regions, caused by user error — specifically misconfigured access controls — with no impact on compute, storage, database, or AI services. It rejects the claim that an AI system caused the disruption, calls the report of a second outage entirely false, and notes that a misconfigured role could occur with any developer tool, AI-powered or not, or with a manual action. The company says it added mandatory peer review for production access.
We are not here to referee
Two credible parties give incompatible accounts of what happened, and outside observers cannot settle it. That is the interesting part. Ask yourself the honest version of the question: if a change went wrong in your environment tomorrow and someone asked whether an AI tool or a person made it, could you answer from your records? Most organisations cannot — and if the largest cloud provider on earth ends up arguing this in public, the bar is higher than it looks.
Attribution is not a forensic luxury. It is what turns an outage into a fixable process problem instead of a public argument.
Amazon’s framing is right, and it cuts both ways
The point that a misconfigured role can come from any tool or a manual action is fair, and worth taking seriously. AI-assisted development does not create a new failure mode here; the failure mode is a permission that was too wide for the change being made. What AI changes is volume and review depth. More changes are proposed per engineer, each arrives fully formed and plausible-looking, and the human in the loop reviews under exactly the conditions that make rubber-stamping likely.
Which is why the remediation Amazon describes — mandatory peer review for production access — is the right shape regardless of who is correct about the cause. It restores a human decision at the boundary that matters, and it produces a record of who made it.
Three controls for AI in the change path
- Give AI tooling its own identity. Not a shared service account, not a borrowed engineer credential. Distinct identities are what make attribution possible after the fact.
- Scope permissions to the change, not to the role. The blast radius of any single change should be bounded by the credential it runs under, before review ever happens.
- Log the assist, not just the commit. Record when generated code or configuration entered a change, and who approved it — the same provenance discipline you apply to documents.