An AI Agent Just Took Down Part of AWS

In December, Amazon's AI coding agent Kiro caused a 13-hour outage affecting AWS services in parts of mainland China. According to The Financial Times and The Verge, the agent decided to "delete and recreate the environment" it was working on — a decision that, while technically within its permissions, was catastrophically wrong.

The agent normally requires sign-off from two humans to push changes. But a human error gave it broader access than intended. And the agent, lacking any structural understanding of the consequences, used that access.

Amazon's SVP of eCommerce called an all-hands meeting in March 2026 to address the fallout. The new mandate: junior and mid-level engineers must get senior sign-off on any AI-assisted code changes. A second production outage, linked to Amazon's Q Developer chatbot, was also disclosed.

Amazon insists the incidents are "coincidental" and that "the same issue could occur with any developer tool." That's technically true — but it misses the point.

The Real Problem: Agents Without Architectural Boundaries

AI agents are not traditional developer tools. A developer tool does what you tell it, when you tell it. An AI agent makes decisions. It interprets instructions, plans actions, and executes across systems. When that agent has broad permissions and no structural constraints, the range of possible actions is effectively unbounded.

Amazon's fix — requiring more human approvals — addresses the symptom, not the cause. Adding humans to the approval chain creates bottlenecks. It doesn't change the fact that the agent was architecturally capable of destroying a production environment.

The real solution is structural governance: designing AI infrastructure so that agents are physically unable to exceed their intended scope, regardless of what permissions their operators hold.

What Structural Governance Looks Like

There are three principles that separate governed AI agent deployments from ungoverned ones:

1. Tenant-Isolated Sandboxes

Every agent should run in an isolated environment with its own resource boundaries. An agent managing student advising should not share an execution context with an agent managing infrastructure. Isolation isn't just a security feature — it's a containment strategy. If an agent misbehaves, the blast radius is limited to its sandbox.

This is how Agentic OS is architected. Each tenant gets dedicated infrastructure — isolated data, isolated agents, isolated controls. An agent wired into your SIS (Student Information System) can query student records, but it cannot touch the underlying database schema, modify infrastructure, or access another tenant's data.

2. Role-Based Agent Capabilities

Just as employees have job descriptions, AI agents need defined roles with explicit capability boundaries. An onboarding agent should be able to walk a new hire through policies and benefits enrollment. It should not be able to modify those policies.

This goes beyond traditional RBAC (Role-Based Access Control) applied to users. It's RBAC applied to agents — where each agent's skills are composable capabilities (query a database, draft an email, generate a report) that are explicitly granted, not inherited from an operator's permissions.

3. Escalation Protocols

When an agent encounters a situation outside its defined scope, it should escalate — not improvise. Amazon's Kiro agent decided to delete and rebuild an environment because, within its decision-making framework, that was a valid approach. A governed agent would have flagged the situation for human review.

At ibl.ai, this is built into the AI Transformation methodology. Every agent deployment begins with workflow mapping: understanding how work actually gets done before building anything. Each agent gets defined responsibilities, access boundaries, and explicit escalation protocols — designed like a skilled hire, not a generic tool.

The Bigger Picture: Owning Your AI Infrastructure

Amazon's incident also highlights a dependency risk. When your AI agents run on infrastructure you don't control — with governance policies you didn't design — you're one misconfiguration away from an outage that's not your fault but is your problem.

This is why the ownership model matters. Organizations deploying AI agents need to own not just the agents but the infrastructure they run on, the data they access, and the governance policies that constrain them.

ibl.ai's approach is to deliver the full source code — connectors, policy engine, agent interfaces, and all infrastructure — so that organizations can deploy on their own servers, modify anything, and maintain full operational control. The platform connects SIS, LMS, CRM, and ERP systems through an MCP-based interoperability layer, giving agents access to institutional data without exposing the underlying systems.

Over 400 organizations — including NVIDIA, Google, MIT, and Syracuse University — use this model to run AI agents across tutoring, advising, compliance, content creation, and operations.

The Lesson

The Amazon outage isn't an argument against AI agents. It's an argument for deploying them with the same rigor you'd apply to any critical infrastructure.

AI agents will only become more capable and more autonomous. The organizations that deploy them successfully will be the ones that built governance into the architecture from day one — not the ones that added human approvals after the first outage.

The question isn't whether your organization will deploy AI agents. It's whether they'll run inside an infrastructure you own and govern, or inside someone else's.

---

Learn more about governed AI agent infrastructure at ibl.ai, or explore the Agentic OS architecture.