Incidents · February 1, 2026
What Reported AI Coding Agent Incidents Teach Us About Deploy Gates
In February 2026, media summaries of a Financial Times report linked an AWS service interruption in China to user error involving Amazon's Kiro AI coding agent. The public reports describe an AI-assisted production path where a destructive action should have required stronger authorization before execution.
The exact internal control boundary is not public. That matters: public incident analysis should separate what was reported from what can be proven.
The useful product lesson is narrower and stronger than blame: production-impacting agent actions need a signed approval gate outside the agent's own permissions.
Sources: TechRadar summary and Tom's Hardware summary. See the incident tracker for source-quality labels.
When approval is only a permission path, the control can fail with the permission model.
Deploy Gate moves the approval decision into a required check and receipt.
This Wasn't a One-Off
The same reporting also described another production-impacting incident involving Amazon Q Developer. That is enough to treat the pattern seriously without overstating the unknowns.
Whether a given incident is ultimately classified as user error, tool error, or process error, the control question stays the same.
It's not a coincidence. It's a pattern.
AI coding agents are being given production access with human-level permissions. When those permissions are misconfigured, and they will be, the agent doesn't hesitate. It doesn't second-guess. It executes.
Training Isn't the Fix
Training and safeguards help, but they are not the enforcement boundary. The same playbook organizations have used for decades with human operators is not enough when agents can execute production-impacting actions quickly.
But AI agents aren't humans. They don't learn caution from incident reviews. They don't develop institutional memory from postmortems. Every invocation starts fresh.
The real question isn't "how do we train people to configure agent permissions correctly?" It's:
Why does the agent have production access at all?
The Deploy Gate Pattern
A two-human sign-off requirement is the right instinct. The failure mode appears when approval is implemented as a permission, something that can be misconfigured, overridden, or inherited from an operator's access level.
A deploy gate inverts this:
- The agent proposes a change. It writes code, opens a PR, runs tests. All of this is fine.
- The deploy pipeline hits a gate. Before anything touches production, the pipeline checks for an authorization receipt.
- No receipt exists. The deploy stops. Hard. Not a warning, a block.
- A human reviews and approves. A cryptographic receipt is generated, scoped to this exact change.
- The deploy proceeds. The receipt is verified. The change lands.
The critical difference: the agent never holds production access. It can't inherit it. It can't be misconfigured into having it. The gate is external to the agent.
What Would Have Happened With a Deploy Gate
Agent proposes: Perform a destructive production environment change.
Deploy gate fires: ❌ No authorization receipt. Deploy blocked.
Human reviews: "Delete and recreate production? No. Try a rolling update instead."
Result: The destructive change is held until an authorized human signs or denies the exact action.
This isn't about slowing AI agents down. It's about inserting a checkpoint between "the agent decided" and "production changed."
Permissions Are Not Authorization
Cloud providers have sophisticated permissions systems: IAM policies, roles, boundaries, conditions, and hundreds of configuration options.
Those controls are necessary. They still do not answer every action-level authorization question.
Because permissions answer the question "what is this identity allowed to do?" Authorization answers a different question: "is this specific action, right now, approved?"
An agent can have permission to reach a tool without having authorization for a specific destructive action. Deploy Gate exists to enforce that difference at the production path.
A deploy gate enforces exactly that difference. Every action requires a scoped, time-limited, cryptographically signed receipt. Permissions become the ceiling. Authorization becomes the gate.
This Will Happen Again
Every major tech company is building AI coding agents. Every one of them will eventually give those agents access to production systems. And every one of them will discover, the hard way, that permissions alone aren't enough.
The question is whether you install the gate before the first serious agent-authored production PR or after the postmortem.
Add a deploy gate to the first repo where agents touch production.
Install Deploy Gate →