在軟體開發與維運的世界裡，自動化一直是工程師們追求的聖杯。但如果這個自動化工具擁有了過大的權力，甚至能自行決定刪除並重建關鍵系統，會發生什麼事？
就在不久前，雲端巨頭亞馬遜 AWS 經歷了一場長達 13 小時的嚴重服務中斷事件，主要影響了中國區的服務。而引發這場災難的導火線，正是 AWS 自家的 AI 程式碼開發輔助工具 Kiro AI。
事件歸因於 AI 接管了系統大權
根據英國金融時報《Financial Times》的報導 Amazon service was taken down by AI coding bot ，這起長達半天的斷線事件，起因於一個簡單的操作失誤。
當時，AWS 的工程師讓 Kiro AI 執行一項任務，但這款 AI 工具並非只是單純地提供程式碼建議或進行簡單的重構。在執行過程中，Kiro AI 自主決定刪除並重新建立一個關鍵的底層系統。由於該系統的刪除與重建過程牽一髮而動全身，最終導致了長達 13 個小時的嚴重服務停擺。
這起事件立刻在業界也引發了一些討論，讓 AI 擁有如此高度的自主權其實是大哉問。
亞馬遜回應這不是 AI 的錯，是權限管理的鍋
面對外界對 AI 工具安全性的質疑，亞馬遜官方給出了明確的回應 Correcting the Financial Times report about AWS, Kiro, and AI，強烈反擊金融時報的報導。他們將這起事故定調為人為的權限設定錯誤（Human permission errors），而非 Kiro AI 系統本身的缺陷。
亞馬遜的立場很清晰，AI 只是忠實地執行了它「被允許」執行的任務。如果工程師沒有賦予 Kiro AI 刪除核心系統的高級權限，這場災難根本不會發生。
這就像是給了一個超級實習生最高管理員帳號，當他為了最佳化流程而把整個資料庫砍掉重練時，該負責的是實習生，還是給予他權限的主管呢？
好問題，對吧？
科技反思AI 輔助開發的護欄在哪裡？
這次的 AWS 斷線事件可以觀察到，隨著 AI 寫程式工具（如 GitHub Copilot、AWS Kiro 等）越來越強大，它們的角色正在從程式碼輔助開發工具、自動完成工具演變成自主的開發與維運代理人（Agent）。
CyberQ 認為，未來的科技趨勢仍舊是繼續部署和採用 AI 來加速開發流程，但必須在效率與安全之間建立更強大的護欄（Guardrails），最重要的還是要記得最小權限原則（Zero Trust & Least Privilege）哪，無論 AI 工具多麼聰明，都不應該預設擁有破壞性操作的權限。所有涉及基礎架構變更的操作，都必須被嚴格限制。
另一方面，確保流程中有真實人類在內，凡是涉及「刪除」、「覆寫」或「重啟」關鍵系統的指令，必須有強制性的人工審核機制（Approval gate），不能讓 AI 單方面就自己完成。
AI 操作也要納入沙盒測試，AI 的自主最佳化與重構建議，應該先在隔離的測試環境（Staging / Sandbox）中運行驗證，確認無誤後才能部署到正式環境（Production）。
CyberQ 認為，AWS 這次的 13 小時當機事件，是 AI 融入現代軟體工程中的一個可以讓我們借鏡的小提醒，它證明了 AI 的能力已經強大到足以撼動整個雲端基礎設施，但也同時提醒我們，技術越強大，權限管理和商業邏輯、流程都要再想過。
在全自動化 AI 開發時代來臨之前，如何做好完善的權限管控與安全防護，將是各家公司、開發團隊與維運團隊、DevOps 都必須嚴肅面對的課題。
