Case Pattern: AI Agent Deletes a Production Environment

What the Kiro / AWS Incident Really Shows About AI Governance

This is a governance pattern, not an incident post-mortem. We’re using public reporting on the AWS “Kiro” event as a concrete example of a failure class that will keep repeating wherever AI agents touch production systems without a pre-execution authority gate.

The Five Layers of AI Governance (Control Stack)

Most “AI governance” talk collapses into vibes. This pattern doesn’t. There are five distinct control layers:


  1. Data / Formation Governance – what the system is allowed to see and learn from.
  2. Model / Agent Behavior Controls – what the system is allowed to say and attempt.
  3. Pre-Execution Authority Gate (Commit Layer) – who is allowed to let an action start at all.
  4. In-Execution Constraints – how far the action is allowed to go while it’s running.
  5. Post-Execution Monitoring & Reconciliation – what actually happened, and whether it matched your intent.


If someone tells you they “do AI governance” and can’t tell you which of these they cover, you don’t have a governance solution. You have a feature.


Note: “Above this stack sits Policy & Ownership (boards, GRC, risk appetite).These five layers are the runtime control stack that enforces and evidences those policies.”

1. The Incident (From Public Reports)

In December 2025, Amazon Web Services experienced a disruption in one of its regions involving Kiro, an internal AI coding assistant described as an agentic tool (able to take actions, not just write code).


Public reporting and Amazon’s own statement align on the core sequence:


  • Engineers used Kiro to make infrastructure changes.
  • The agent determined that the way to fix an issue was to “delete and recreate the environment.”
  • The action impacted an AWS Cost Explorer environment in one of AWS’s China regions.
  • Amazon attributed the event to user error / misconfigured access controls:
  • A staff member had broader permissions than expected.
  • Kiro requested authorization and acted within those granted permissions.
  • Amazon emphasized that:
  • The disruption was limited in scope (a cost-management feature in one region, not all of AWS).
  • The underlying cause was a misconfigured role — something that could have occurred with “any developer tool (AI-powered or not) or manual action.”

Sources & Unknowns


Sources used: 

  • Engadget report summarizing Financial Times reporting and including Amazon’s response (Feb 21, 2026; updated)
  • Amazon’s official statement on AboutAmazon (“Correcting the Financial Times report about AWS, Kiro, and AI,” Feb 20, 2026)

Unknown / not claimed here:

  • The exact internal sequence inside Kiro (prompt/context, tool calls, compaction-like behavior, etc.).
  • The precise technical meaning of “delete and recreate the environment” in this event (what resources, in what order).
  • Whether the action bypassed any internal peer review/dual control, or whether such controls were simply not in place for that pathway.
  • The full blast radius and customer impact beyond what is stated publicly (Amazon says extremely limited; reporting characterizes it as “13-hour outage”).
  • The detailed remediation/safeguards actually implemented (Amazon cites “mandatory peer review for production access,” but implementation details aren’t public).


Scope note: We do not attempt to adjudicate whether this was “AI error” or “user error.” We extract the governance question: what stops a valid identity—human or agent—from executing a catastrophic action in prod?

Strip away the PR positioning and we’re left with a clear pattern:


An AI agent, operating with valid but over-broad credentials, executed a destructive operation in a production system because nothing in the stack was structurally responsible for asking:


“Is this specific action allowed to run at all?”


That is the failure mode.

2. What Actually Failed (Hint: Not Just “AI”)

Most commentary framed this as either:

an AI failure (“the bot went rogue”), or

a security failure (“IAM was misconfigured”).


Both are incomplete.


If you zoom out, the stack did three things correctly:


1. Identity

  • The agent presented valid credentials.
  • The system verified those credentials.
  • From IAM’s point of view, the actor was legitimate.


2. Capability

  • The agent understood the environment well enough to propose a plausible fix: delete and recreate.
  • Technically, that’s a common remediation pattern.


3. Execution

  • The environment accepted the command.
  • The delete operation succeeded.


What was missing was a fourth job:


4. Authority at the moment of action

  • For this actor
  • To take this destructive action
  • In this environment
  • Under these rules
  • Right now.


Identity said: “You’re allowed in.”
Capability said: “You’ve chosen a valid operation.”
Nothing said: “You are not allowed to delete a live production environment under this authority.”


That is not a model problem. It’s an Action Governance™ problem.


3. Why Traditional Controls Don’t Catch This

Security tools did their job:

  • IAM checked: “Is this principal allowed to call this API?”
  • Because a human had given the agent a high-privilege role, the answer was yes.


But security is built to reason about:

  • who can access which systems, and
  • what those roles are permitted to touch in general.


It is not designed to carry the full weight of:

  • contextual authority (dev vs prod, normal vs emergency),
  • delegation rules (what may AI agents do vs humans), or
  • domain-specific constraints (no destructive ops on billing systems during business hours, dual control above threshold X, etc.).


That missing layer is where pre-execution authority gates live.

4. How a Pre-Execution Authority Gate Changes the Story

Imagine the same Kiro-style agent operating behind a SEAL-style runtime gate.


We don’t change the model.
We don’t change IAM.
We add a governance checkpoint  between “intent to act” and the actual AWS APIs.


4.1. Intent to Act


Instead of directly calling DeleteEnvironment(...), Kiro sends a structured “intent to act” payload to the gate:

Field Example (Kiro → Authority Gate)
Who actor_type=agent · actor_id=kiro · role=infra-assistant
Where env=prod · service=cost-explorer · region=cn-xxx
What action=delete_environment
How fast urgency=standard
Under whose authority delegated_by=engineer123 · policy_set=standard-maintenance

The gate doesn’t inspect code.
It doesn’t try to out-think the AI.


It simply asks:


“Is an infra-assistant agent ever allowed to delete a production Cost Explorer environment under these conditions?”


4.2. Deterministic Outcomes (Only Three)

Outcome Meaning In a mature policy set
✅ Approve Action executes Only when policy allows this actor + action + environment + authority
❌ Refuse Action cannot execute Default for destructive agent actions in prod (especially cost/billing domains)
🟧 Supervised Override Route to explicit approvers Route to two named production owners for explicit approval (recorded)

Example policy rules (simple but decisive):

  • No destructive actions by agents in env=prod.
  • All destructive actions in production require dual human approval, even for humans.
  • Cost/billing systems have stricter rules than dev/test.



4.3. Sealed Evidence


When the gate refuses or escalates, it generates a sealed artifact:

Field Example
decision_id …
actor kiro@aws
action delete_environment
env prod
policy_version 2025.12.01
verdict REFUSE
reason_code AGENT_DESTRUCTIVE_PROD_FORBIDDEN
timestamp …
integrity proof …

Stored under the client’s  control, that artifact becomes:

  • proof that the system refused an unsafe action, and
  • a live signal to engineering: “An agent just tried to delete a production environment.”


The worst-case failure becomes:


“We almost deleted production; the gate refused and here’s the record.”


Not:


“We deleted production; now we’re reconstructing what happened from logs.”

5. Why This Matters Beyond AWS (Legal, Finance, Healthcare…)

Swap out “Cost Explorer environment” for any other high-risk domain:


  • deleting a live discovery database in a litigation matter
  • revoking the wrong healthcare orders
  • moving funds out of a client trust account
  • filing an irrevocable submission with a regulator


The pattern is identical:


  1. An AI system with valid credentials chooses an action that is technically permissible.
  2. IAM and guardrails say: “This looks fine.”
  3. No runtime gate is enforcing:
  • who may authorize this class of action,
  • under which authority, and
  • what must never be allowed to execute at all.


In these environments, the cost isn’t a 13-hour feature disruption.
It’s sanctions, lost licenses, breached fiduciary duties, or unfixable harm.


5A) The Cost of Not Having the Pre-Execution Authority Gate (Risk P&L)


You don’t need perfect data to quantify this failure class. You need an evidence surface.


Important: We don’t speculate about what this incident cost. We show what you can prove you prevented once a gate exists.


Without a gate, your risk P&L is invisible


  • you only learn after execution (forensics)
  • controls are argued, not demonstrated
  • you can’t prove prevention—only recovery


With a gate, you get a measurable risk ledger


  • Prevented loss events: every refusal is a near-miss captured before harm
  • Controlled high-risk actions: every supervised override is documented consent
  • Policy adherence over time: drift becomes observable (policy versions, reason codes)
  • Audit defensibility: “we can prove we refused unsafe actions under defined policy”
Risk Ledger Metrics (Board / Insurer / Regulator-Ready)
Metric What it proves
Refused high-risk intents Prevented loss events captured before execution (by system/action/environment)
Supervised overrides Explicit consent trail: who approved, when, under which policy version
Top reason codes What your environment keeps trying to do (and what’s being blocked)
Policy coverage Which workflows are governed vs. ungoverned (your true exposure map)
Sealed artifacts per decision Immutable proof you own (not raw logs you argue about later)
This is the only structured dataset of “bad actions that never happened.” That’s a superpower.

Reframe: This is not “we hope we’re safe.” This is “we can prove we refused unsafe actions, and here is the record.”

Optional one-liner: “The gate turns existential risk into a governed P&L: attempted loss, prevented loss, approved risk—with receipts.”

6. What a GC / CISO Should Take From the Kiro Pattern

You do not need to adjudicate whose press release is more accurate.


You only need to extract the structural question:


“If an AI agent with valid credentials decided to delete or file the wrong thing in our environment, what is the last line of defense?”


If the honest answer is:


  • “IAM roles,”
  • “our CI/CD pipeline,” or
  • “we’d see it in the logs,”


…then you know you’re in the same failure class as Kiro.


A pre-execution authority gate doesn’t make your models safer. It makes your actions governable:


  • IAM still verifies who.
  • Guardrails still shape what the model says.
  • The gate decides what may actually hit the real world – and leaves behind evidence that you own.


How this strengthens your “During” & “After” stack


  • During circuit breakers and dual control get cleaner triggers when authority is explicit.
  • After: monitoring/forensics get the one thing they can’t reconstruct later: the moment of authority(who was allowed, under what policy version, and why).

7. Quick Diagnostic: Are You Exposed to a “Kiro-Class” Event?

For any AI-enabled system that can:

  • delete,
  • file,
  • approve,
  • move money,
  • or modify live records,


Concrete questions:


1. Where is the pre-execution authority gate?

  • Show me the exact service that can return “refuse” before the operation touches live systems.


2. What happens when an authorized identity makes an out-of-policy request?

  • Silent pass, soft warning, or hard refusal with a record?


3. Who owns the authority rules?

  • Are they derived from your policy / GRC / identity stack, or reinvented inside a vendor product?


4. What is your evidence surface?

  • Can you produce a sealed, tenant-owned artifact per governed decision — or just raw logs?


5. What’s the worst failure mode?

  • A silent bypass that executes, or a documented refusal that frustrates someone but saves the system?


If you can’t point to a clear, pre-execution authority gate with sealed artifacts, you don’t have action governance.


You have hope wrapped in dashboards.


8. Where Thinking OS™ Fits

Thinking OS™ implements this pattern for legal systems:


  • A sealed pre-execution authority gate (SEAL Legal Runtime) wired in front of file / send / approve / move in legal workflows.
  • Evaluates who / where / what / how fast / consent for each high-risk action.
  • Returns only three outcomes:
  • ✅ Approve
  • ❌ Refuse
  • 🟧 Supervised Override
  • Emits a sealed, tenant-owned artifact for every verdict.


We don’t stop agents from thinking.
We stop unauthorized actions from existing.


The Kiro incident won’t be the last time an agent deletes “the wrong thing” in production.


The real question for boards, GCs, and CISOs is:


“Before our AI can delete, file, or move anything that matters, where is the gate — and who owns the proof that it said NO?”


That’s the layer this case pattern is really about.

Confidential Workflow Evaluation

We’ll map your top 1–2 high-risk legal workflows and show how SEAL would evaluate them — including likely approvals, refusals, and supervised escalations — using synthetic or redacted scenarios under NDA.