AWS 內部的 AI coding assistant「Kiro」在一次變更流程裡做出「刪掉再重建環境」這種高衝擊動作，造成系統長時間中斷。

先講重點：就算你不完全相信「AI 造成停機」這句話，這類事件仍然值得看。因為它把一個長期存在的老問題放大了——當系統把決策與操作權交給代理（agent），錯誤的半徑會突然變大。

我把它當成一個提醒：Agent 的風險管理，要用「生產系統變更」的規格來做，而不是用「開發工具」的心態放行。

原 Threads 連結：https://www.threads.com/@meow.coder/post/DVBqdbvEsH6

這類停機通常怎麼發生

以 Reuters 與多家媒體轉述的版本來看，Kiro 原本需要雙人簽署才可以推送變更，但因為權限設定與流程控制出了洞，它在關鍵系統上取得了過大的操作空間，導致停機時間被拉長（媒體報導提到「13 小時」等級的影響）[1]。

這裡我在意的點有兩個：

1. 變更動作的衝擊範圍很大：刪除、重建、修改基礎設施設定，這些行為本來就該被視為高風險操作。
2. 權限與授權鏈太鬆：當代理可以跨過多層防線去執行動作，事故就不需要「聰明」才能發生。

用 OWASP 的語言：這叫 Excessive Agency

OWASP GenAI Security Project 把「Excessive Agency（過度代理權）」列成一個明確風險：LLM/Agent 被賦予呼叫工具、連接外部系統的能力；當輸入含糊、被操控、或模型產生錯誤輸出時，系統依然可能做出具破壞性的動作[2]。

這個定義對我很有用，因為它把問題從「模型好不好」拉回「系統設計」：

• 工具功能太開放
• 權限給太多
• 自主性放太大

只要其中一項踩到線，事故就會變成統計問題。

最小權限：Agent 尤其需要嚴格執行

NIST 對 least privilege 的定義很直白：系統應把使用者或程序的權限限制在完成任務所需的最低限度[3]。

把這句話套到 agent 系統，我通常會用「三層」去拆：

• 工具層（tooling）：能不能跑 shell？能不能寫檔？能不能出網？
• 資料層（data）：能讀到什麼資料？含不含敏感資訊？
• 動作層（actions）：能不能改 infra？能不能做刪除？能不能動到 production？

很多團隊最常踩的坑是：把 agent 當成一個「超級工程師帳號」。一旦它被 prompt injection、流程 bug、或不完整的 guardrail 影響，代價就會往 Availability/Integrity 直接打穿。

供應鏈的視角：你其實在引入一條新供應鏈

SLSA 把供應鏈安全描述成一套用來防止竄改、提升完整性、保護套件與基礎設施的框架與控制清單[4]。

我常用供應鏈的類比來理解 agent：

• 你導入一個模型、提示詞、工具插件、執行環境
• 你允許它把決策轉成動作

這整條鏈上任何一個環節出問題，最後都會在「動作」那一端爆炸。把 agent 推上 production 的那一刻，你做的其實是一個供應鏈決策。

我會怎麼做：三條實務 guardrail

如果你公司也在把 agent 推向生產環境，我會用下面三條當最低門檻：

1) 高衝擊動作必須走明確的授權流程

刪除、重建、改權限、改網路、改金鑰，全部視為高衝擊動作。

做法很土，但很有效：

• 兩人簽署
• 變更窗口
• 必要時強制 ticket/變更單

2) 工具從「可用」改成「可證明必要」

把工具與權限收斂到任務最低需求，遵守 least privilege[3]。

特別要小心「通用型工具」：

• 可任意執行 shell 指令
• 可任意讀寫檔案
• 可任意出網抓資料

你讓 agent 擁有這些能力，等於把事故半徑直接放大。

3) 所有 agent 動作都要可追溯、可回放

這點我會向 SSDF 的精神對齊：當你想降低風險，你需要把流程變成可被檢視、可被稽核的工程實務[5]。

在 agent 場景裡，我會把 log 當成產品的一部分：

• 哪個 prompt / 哪個工具 / 哪個權限
• 做了什麼動作
• 影響哪些資源
• 能不能重放與追查

結語

我很少把「AI 會害你停機」當成一句嚇人的口號。真正會害你停機的，是你讓一個能做事的 agent 在缺少授權、缺少最小權限、缺少稽核的狀態下，碰到 production。

這題很現實：當大家都在追求交付速度，安全設計只要慢半拍，事故就會先到。

參考資料

1. Reuters — Amazon’s cloud unit hit by outages involving AI tools（2026-02-20）：https://www.reuters.com/business/retail-consumer/amazons-cloud-unit-hit-by-least-two-outages-involving-ai-tools-ft-says-2026-02-20/
2. OWASP GenAI Security Project — LLM06:2025 Excessive Agency：https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
3. NIST CSRC Glossary — least privilege：https://csrc.nist.gov/glossary/term/least_privilege
4. SLSA（Supply-chain Levels for Software Artifacts）：https://slsa.dev/
5. NIST SP 800-218 — Secure Software Development Framework (SSDF) v1.1：https://doi.org/10.6028/NIST.SP.800-218

AgenticWorkflow #HumanInTheLoop #AI落地實務 #DevOps #Security