AWS 13 Hour Outage: Agentic AI Risks & Governance Gaps

How can a single AI assistant take a critical cloud service offline? 
In December 2025 Amazon’s Kiro agent deleted and recreated a live environment, causing a 13‑hour outage that disrupted Cost Explorer in parts of China. AWS later said a misconfigured role, not a deeper AI malfunction, was to blame. 
The incident reveals how autonomous AI amplifies small errors and highlights gaps in governance. 

What Happened During the AWS 13‑Hour Outage 

The AWS outage in December 2025 lasted about thirteen hours and drew attention across the industry. According to reports, engineers at Amazon Web Services deployed Kiro, an internal AI coding assistant designed to act on behalf of users. Apparently, the 
agent decided that the best way to complete its task was to delete and recreate the environment it was working on. Hence, the agent removed a live environment and caused a service interruption that primarily affected the AWS Cost Explorer service in parts of mainland China. 

Later on, AWS confirmed the outage. It insisted the issue affected only Cost Explorer, leaving compute, storage, and other services unaffected. The company explained that the Kiro tool normally requests human authorisation before performing actions. 

In this case, the engineer involved had broader permissions than expected. That extra access turned what should have been a multi‑step, human‑approved change into an immediate deletion. 

Multiple employees told reporters that this was at least the second time in recent months that AI tools were involved in service disruptions. AWS has since implemented safeguards such as mandatory peer review for production access to prevent similar misconfigurations. 

The chain of events highlights several agentic AI risks. Chief among them is the fact that the failure stemmed from an AI access control failure. The agent gained permissions beyond its intended scope and carried out destructive changes without a second set of eyes. 
This incident illustrates why enterprise AI governance must be designed so that autonomy does not override basic safeguards. 

An AI and Governance Failure, Not Just Human Error 

AWS framed the AWS 13 hour outage as user error and noted that the same misconfiguration could occur with any developer tool. However, the event demonstrates that an AWS AI outage occurs when agentic AI risks combine with weak controls. 

The Kiro agent executed a destructive change because its permissions were not scoped appropriately and it lacked enforced approval gates. Agentic systems are more than passive assistants; they can plan, decide and act autonomously. 

McKinsey’s playbook on agentic AI security describes these systems as “digital insiders” that operate within enterprise systems and introduce new internal risks. 80% of organisations surveyed have already encountered risky behaviours from AI agents, including improper data exposure and unauthorised system access. 

By delegating destructive capabilities to an AI assistant without strict approval gates or layered safeguards, AWS created a situation where a single misconfiguration translated into an enterprise‑scale disruption. 
Blaming human error misses the structural issue: agentic AI risks multiply the impact of mistakes unless enterprise AI governance explicitly constrains the agent’s authority. 
This case shows that an AI access control failure can quickly become an AWS AI outage, and organisations must design controls accordingly. 

Agentic AI Changes the Enterprise Risk Model 

Traditional automation executes scripted tasks and returns outputs for humans to evaluate. Agentic AI acts with delegated authority because it can modify infrastructure, orchestrate workflows and persist across systems. 
Obsidian Security notes that autonomous agents now authenticate to SaaS platforms, query databases and transfer files, operating with unprecedented independence. 
Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025. These agents often operate with service account credentials or API tokens. When misconfigured, they can exceed the privileges of any individual user. 
Through these access pathways, AI agents provide new entry points for attackers and can cause harm unintentionally or deliberately. Because they plan and act across multiple systems, their blast radius extends far beyond a single application. 

The AWS 13 hour outage is a clear case study of how agentic AI risks change the enterprise risk model. Many observers call it an AWS AI outage because the AI tool performed the deletion. 
In such situations enterprise AI governance is not optional; it is essential to prevent another AI access control failure. Each time a tool with delegated authority acts, the probability rises that a misconfigured permission will produce a similar disruption. 

To avoid the next AWS 13 hour outage, organisations must treat agentic AI as an operational actor rather than just a generator of code. They must ask whether their identity and access management frameworks are robust enough to handle autonomous agents and whether approval processes are embedded into the tool chain. 

The Real Blind Spot: Autonomy Without Structural Boundaries 

The incident exposes a deeper structural issue: autonomy without clear boundaries. 

Effective agentic AI governance requires separation between: 

• Development and production environments 

• Read-only and write-level permissions 

• Routine operations and destructive actions 

Security research consistently highlights overprivileged agents as a leading risk factor. When role scoping is weak, small logic deviations can cascade across infrastructure. 

In the AWS 13 hour outage, there was no enforced checkpoint preventing a production-level deletion. The AI access control failure occurred because the system trusted inherited permissions without layered containment. 

Why Integration Architecture Determines Exposure 

Governance failures do not arise from a single tool; they emerge from how tools are integrated. Fragmented integration multiplies risk because each AI tool brings its own context and credentials. 

Many organisations deploy AI tools incrementally across the software development lifecycle. Planning uses one assistant. Coding uses another. Monitoring uses a third. Each tool introduces its own credentials and context model. 

Without a unified integration strategy: 

• Permissions diverge across workflows 

• Context continuity breaks down 

• Monitoring becomes fragmented 

• Attack surfaces expand 

The Moxo report notes that 80% of organisations have witnessed risky behaviours from AI agents but only 20% have robust security measures; 63% lack AI governance policies and those organisations pay significantly more per breach. 

The AWS 13 hour outage demonstrates how fragmented integration increases exposure. When agentic AI operates across systems without centralised enforcement, an AI access control failure becomes more likely. 

Frequently Asked Questions 

Q. What caused the AWS 13 hour outage? 

The outage occurred when Kiro, an internal AI coding assistant, deleted and recreated a live environment due to a misconfigured role. This misconfiguration gave the agent elevated permissions, allowing it to bypass normal approval gates. 

Q. Was this AWS 13 hour outage an AWS AI outage? 

Yes. Although AWS attributed the disruption to a misconfigured role and insisted that it could have happened with any tool, the fact that an AI assistant carried out the deletion means the event is widely seen as an AWS AI outage. 

Q. What agentic AI risks were highlighted by the AWS 13 hour outage? 

The outage underscored multiple risks: overprivileged agents, absence of approval gates, lack of staged execution controls and no environment isolation. These factors allowed the AI assistant to delete production resources, causing service disruption. 
 

Q. What is an AI access control failure, and how did it contribute to the outage? 

An AI access control failure occurs when an AI system is granted permissions that exceed its intended scope or when controls fail to prevent misuse of those permissions. In the AWS case, the Kiro assistant used a role with operator‑level privileges, enabling it to delete and recreate the environment without additional approvals. 
 

Final Words 

The AWS 13 hour outage is not an argument against autonomous systems. It is a reminder that autonomy must operate within clearly defined structural limits. 

Agentic AI can deliver measurable value across the software development lifecycle. However, governance must be embedded in architecture from the beginning. Role scoping, least-privilege access, approval gates, audit logging, and integration discipline are not optional controls. They are prerequisites for safe deployment. 

Build Agentic AI With Governance as Infrastructure 

MatrixTribe builds agentic AI systems with governance as infrastructure. Permissions are scoped deliberately. Integration layers enforce consistent policy. Execution is observable and auditable. Autonomy is introduced only where safeguards already exist. 

If your organisation is experimenting with agentic AI without a defined governance architecture, you are increasing the probability of an AI access control failure. 

Contact us to build systems that are safe by design before allowing them to act.