AWS's Kiro AI coding assistant caused a significant production outage in December when it deleted a production environment, resulting in 13 hours of downtime for AWS Cost Explorer in mainland China and exposing critical gaps in how enterprises should govern AI agent permissions. The incident, initially undisclosed by Amazon, was revealed by the Financial Times last week based on employee accounts and has sparked internal debate about whether AI tools should inherit the same access levels as human engineers.

What Actually Happened During the December Kiro Incident?

In mid-December, Kiro made changes to an AWS production environment that resulted in deleting and then recreating a system, causing the AWS Cost Explorer to go offline in certain regions of mainland China. According to Financial Times reporting based on Amazon employee accounts, the outage lasted 13 hours and affected a customer-facing system. Amazon later confirmed the incident but characterized it as "extremely limited," affecting only one service in specific geographic areas and resulting in no customer complaints.

The root cause was not a flaw in Kiro's spec-driven development methodology, but rather a misconfiguration of access controls. The engineer who approved Kiro's proposed changes had more permissions than necessary for their role. Amazon stated that the engineer did not fully understand the extent of their own privileges, meaning they likely would have acted differently if they had known the scope of what they were authorizing. This raises a fundamental question about how AI agents should interact with production infrastructure when they inherit human-level permissions.

Amazon emphasized that this was a human error problem, not an AI problem. The company noted that the same issue could have occurred with any tool, AI-enabled or not, or with any manual action by an engineer with excessive permissions. However, the fact that Kiro was involved has become significant in internal discussions about how AI tools should be deployed in production environments.

Why Is This Incident Creating Internal Friction at Amazon?

The December incident has exposed tensions between AWS's push to standardize on Kiro and employee concerns about the tool's capabilities and safety. In November 2025, an internal directive urged Amazon teams to standardize on Kiro as a way to boost security and unify telemetry across the organization. However, more than 1,000 Amazon employees requested continued access to alternative tools, including Anthropic's Claude Code, citing specific use cases where those tools perform better. Employees pointed to multilingual refactoring and support for niche frameworks as areas where Kiro fell short of alternatives.

The timing of the December incident, occurring just weeks after the standardization directive, has amplified these concerns. Employees now have concrete evidence that Kiro can cause production outages, even if the root cause was ultimately a permissions misconfiguration rather than a flaw in the tool itself. This has made the case for maintaining access to competing tools more persuasive within the organization.

How Is AWS Trying to Prevent This From Happening Again?

Amazon has implemented several safeguards in response to the incident. The company now requires mandatory peer review for all production access changes, a control designed to catch mistakes before they reach live systems. Additionally, Kiro is designed to ask for approval before taking action, though Amazon did not fully disclose how explicitly the tool presented the environment deletion proposal to the engineer.

The lack of transparency about what Kiro actually showed the user before the deletion occurred has become a point of contention. If Kiro presented the deletion as a routine operation without clearly flagging the scope and impact, the approval process itself becomes questionable. This highlights a broader challenge: as AI agents become more integrated into production workflows, the clarity and explicitness of what they propose to do becomes critical to safe operations.

• Mandatory Peer Review: Amazon now requires peer review for all production access changes, ensuring that no single person or AI agent can make critical infrastructure changes without human oversight.
• Explicit Approval Workflows: Kiro is designed to request approval before taking action, though the specificity of how it presents proposed changes remains a point of concern for safety.
• Access Control Audits: The incident revealed that the engineer involved had more permissions than necessary, highlighting the need for regular audits of who has access to what in production environments.
• Clear Scope Communication: When AI agents propose actions, they need to explicitly communicate the scope and impact of those actions so humans can make informed approval decisions.

What Does Spec-Driven Development Actually Solve?

Kiro represents AWS's bet on a methodology called spec-driven development, which differs fundamentally from the chat-first approach used by tools like Cursor and GitHub Copilot. Instead of immediately generating code from a prompt, Kiro produces structured documents including requirements written in EARS (Easy Approach to Requirements Syntax) notation, design specifications, and task breakdowns. The theory is that this structured approach catches mismatches between specification and implementation before code ships to production, with early adopters reporting roughly 3 to 10 times improvement in AI agent first-pass task success rates on non-trivial features.

However, the December incident suggests that even well-architected development methodologies cannot prevent problems if the underlying infrastructure permissions are misconfigured. The outage occurred not because Kiro's spec-driven approach failed, but because the human-AI permission boundary was unclear. This points to a broader challenge: as AI agents become more integrated into production workflows, organizations need new governance models that go beyond traditional code review.

AWS is positioning Kiro as part of a larger infrastructure stack called Amazon Bedrock AgentCore, which includes a managed MCP (Model Context Protocol) server that sits between agents and external tools. This gateway architecture is designed to enforce authorization policies using Cedar, an open-source policy language that operates on a default-deny principle: every tool invocation is blocked unless explicitly permitted. If properly configured, such a system could have prevented the December incident by requiring explicit policy approval before Kiro could delete production environments.

Steps to Implement AI Coding Tools Safely in Enterprise Production

• Principle of Least Privilege: Ensure that engineers and AI agents are granted only the minimum permissions necessary for their specific tasks, and regularly audit those permissions to catch misconfigurations before they cause outages.
• Explicit Authorization Policies: Use formal policy languages like Cedar to define exactly which actions AI agents can take, with default-deny rules that require explicit approval for sensitive operations like deletions or environment changes.
• Mandatory Peer Review: Implement peer review requirements for all production changes, whether initiated by humans or AI agents, to catch mistakes before they reach live systems.
• Clear Approval Workflows: Design AI agent interfaces to explicitly show what actions they propose to take, with unambiguous language about the scope and impact of those actions before requesting human approval.
• Comprehensive Observability: Log all AI agent actions with full context, including what the agent proposed, what the human approved, and what actually executed, to enable post-incident analysis and continuous improvement.

The AWS Summit in New York on June 17 was expected to feature live demonstrations of Kiro, Amazon Quick, and Bedrock AgentCore, with keynote speaker Dr. Swami Sivasubramanian, Vice President of Agentic AI at AWS, discussing how to remove infrastructure bottlenecks from agentic AI systems. Given the December incident, the conversation around governance and safety is likely to be as important as the technical capabilities being showcased.

The broader industry context matters here. AWS, GitHub, Anthropic, Cursor, and other major AI coding platforms have all converged on spec-driven development as the methodology most likely to succeed at production scale. But the December Kiro incident demonstrates that methodology alone is not enough. The infrastructure, permissions, and human oversight layers must be equally robust, or even the most sophisticated AI development tools can cause significant damage when things go wrong.