Перейти к содержимому
Оригинал
Permission Protocol · AI Agent Incident Tracker·· 15.12.2025Оценка ИИ60

报道称 AI 编码机器人失误导致 AWS 服务中断

Оригинальный заголовок: AWS outages caused by AI coding bot blunder, report claims

Заголовок и краткое изложение на выбранном языке ожидают перевода.

Краткий обзор ИИ

据 Financial Times 报道,中国区一次持续 13 小时的 AWS 服务中断被归因于使用 Amazon Kiro AI 编码智能体时的用户操作失误。Amazon 据称将该事件描述为影响极其有限。报道指出,生产环境的删除、重建或发布变更本应经过签名审批流程,但公开信息未披露具体控制边界,因此无法确认智能体是否触及部署代码、内部工具或发布操作。

Полный текст

Back to incident tracker

2025-12-15

MediumMedia report

AWS outages caused by AI coding bot blunder, report claims

Reports tying Amazon Kiro to AWS outages show why AI coding workflows need signed release authority before production rollout changes.

Amazon Kiro / AI coding workflowProduction deletionService interruptionDeploy workflow / internal tooling

What happened

The Financial Times reportedly linked a 13-hour AWS service interruption in China to user error involving Amazon's Kiro AI coding agent.

Why it matters

Media reports describe a small but foreseeable production outage; Amazon reportedly characterized the event as extremely limited.

Missing authorization check

Production environment deletion, recreation, or rollout changes should have required a signed approval path before release.

Would PP block it?

The public reports do not expose the exact control boundary. A protected deploy workflow could require a receipt; direct internal tooling would need a tool-level gate.

Incident analysis

Timeline and technical read

Timeline

  1. 2025-12-15

    Media reports linked an AWS service interruption to user error involving an AI coding workflow.

  2. After report

    Amazon reportedly characterized the affected event as extremely limited.

  3. Permission boundary

    The exact boundary is not public; the likely control point is the deploy or internal release workflow.

Technical breakdown

  • The public record does not show whether the agent touched deploy code, internal tooling, or release operations.
  • That uncertainty is why the PP read remains Unknown instead of a stronger marketing claim.
  • If the production action passed through a protected release workflow, a signed receipt could have created a reviewable stop point.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Production deletion. The relevant Permission Protocol gate is Deploy Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Deploy workflow, if that was the release path
Still needs
Unclear internal tooling boundary
Receipt required for
Production rollout, deletion, or recreation action

The public reports do not expose enough of the control boundary to make a clean block claim.

Start small

Put the relevant gate at this action boundary.

This incident maps to Deploy Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Источник: Permission Protocol · AI Agent Incident Tracker · permissionprotocol.com