Amazon Web Services (AWS) has faced at least two recent production incidents in which its own AI developer tools were involved, according to a report from the Financial Times. Amazon disputes the implication that AI “caused” the outages, arguing the underlying issue was human error and misconfigured permissions.
The Financial Times reported that one of the incidents occurred in mid-December, when a customer-facing AWS system suffered a disruption that lasted roughly 13 hours after engineers allowed Amazon’s Kiro AI coding tool to execute certain changes. The report says the agentic tool—designed to take actions on a developer’s behalf—opted to “delete and recreate the environment,” and that AWS circulated an internal postmortem tied to cost-management functionality.
Recommended security pick: YubiKey 5 NFC (hardware security key)
Check price on AmazonThe Financial Times also cited a second incident in recent months involving Amazon Q Developer, with employees describing it as a production issue. However, AWS says that event did not impact a customer-facing AWS service—underscoring a key disagreement over how broadly the incidents should be characterized.
Amazon says it was “user error,” not AI
Amazon has pushed back hard on the idea that its AI tools were the root cause. In a statement reported by Reuters, an AWS spokesperson said the December event “was the result of user error—specifically misconfigured access controls—not AI.”
AWS described the December disruption as “extremely limited,” saying only a single service—AWS Cost Explorer—was affected in one of its two regions in mainland China. The company added that core services like compute, storage, databases, and AI offerings were not impacted.
The permissions question at the center of the debate
A major point of friction is how much autonomy the AI tools had and what level of access they were granted. The Financial Times reporting suggests the AI tooling was treated as an extension of the operator—effectively inheriting operator-level permissions—and that typical guardrails such as peer review may not have applied in these cases.
AWS argues the real issue was access control scope, saying the engineer involved in the December event had broader permissions than expected. The company also said Kiro puts developers in control, and that by default it requests authorization before taking action—meaning teams must explicitly configure what it’s allowed to do.
What AWS says it changed afterward
AWS says it implemented additional safeguards following the incidents, including mandatory peer review for production access and training changes. Even with that response, the broader takeaway for many teams experimenting with agentic coding tools is the same: the tooling can amplify both good and bad operational practices, so the surrounding controls—permissions, approvals, and blast-radius limits—matter as much as the model itself.