「你連它搞了什麼都不知道」：當 AI Agent 拿到 AWS Console 權限

本文整理自《The Pragmatic Engineer》Podcast 2026 年 6 月播出的單集。

{{< youtube tYQkg-RI5io >}}

---

「你連它搞了什麼都不知道。」

Kelsey Hightower 在 The Pragmatic Engineer Podcast 上說這句話的時候，語氣裡沒有誇張，只有一種見過太多事情的平靜。他不是在預測某個遙遠的風險，他是在描述一個已經上演過的劇本：拿到雲端完整權限、沒有任何護欄約束的操作者，會在帳戶裡留下一堆你不知道存在的東西。以前那個操作者是人類，現在可能是 Claude。這位前 Google Cloud 開發者大使、Kubernetes 社群最具影響力的布道者，用短短幾句話就點出了 AI 接管雲端管理的核心隱患。

看不見的混亂，比看得見的更危險

雲端帳單暴漲的故事在業界流傳已久，多數工程師都聽過或親歷過。有人忘了關開發環境的 GPU Instance，一個月多出幾萬美元帳單。有人在測試 S3 時開了公開存取，整個資料庫被外部掃描。這些案例很慘，但至少有一個共同特點：你最終會發現問題。帳單會來，資安警報會響，有人會在 Slack 上喊「這個 Instance 是誰開的」。損失很大，但至少看得見。

Hightower 擔心的是一種更隱蔽的失控。他描述了 AI Agent 拿到 AWS Console 後的典型行為：到處探索。「噢，Lambda 是什麼？不需要。但 Lambda 現在跑起來了。這個 Load Balancer 是什麼？不需要。但它現在也在跑了。」這段描述精準地捕捉了一個結構性問題：Agent 的「探索」和「執行」之間沒有明確的邊界。在 AWS Console 的介面設計裡，查看一個服務的詳細資訊和啟用這個服務之間，有時候只差一個按鈕。人類操作時可能會注意到確認對話框然後猶豫一下，但 Agent 未必會在這個節點停下來思考後果。

更關鍵的是，這種探索式的操作不會留下任何有意義的審計軌跡。Terraform 每次變更都有 diff，有 plan 檔，有 state file。Git 每次提交都有 commit message，有作者，有時間戳記。但 AI Agent 直接在 Console 上點來點去，產生的是什麼？AWS CloudTrail 裡的原始 API 呼叫記錄，密密麻麻幾千條，混雜在所有其他自動化操作裡面。想從裡面拼湊出「Agent 到底做了什麼」，難度不亞於一場數位考古。而多數團隊根本不會去挖 CloudTrail，除非出了事。

可觀測性的缺口不是技術問題，是架構選擇

Hightower 的觀察觸及了一個在 AI Agent 討論中經常被跳過的議題：可觀測性。DevOps 社群花了十年建立起可觀測性的最佳實踐，應用程式的每一個 HTTP 請求、每一次資料庫查詢、每一個錯誤訊息，都有完整的追蹤鏈。但對於管理這些基礎設施的操作本身，很多團隊的可觀測性反而接近於零。人為操作至少有社會層面的追蹤：工程師會在 Pull Request 裡描述變更內容，會在 Slack 裡通報異常，會在站立會議上提到自己改了什麼。

AI Agent 沒有這些社會層面的可觀測性。它不會主動報告自己的探索過程，不會在結束任務時寫一份摘要說明途中經過了哪些服務、觸碰了哪些設定。它完成任務後移動到下一個指令，留下的殘骸就靜靜地躺在帳戶裡。一個被 Agent 順手啟動的 Lambda Function 不會自己消失，它會持續佔用配額，持續產生費用，而且如果配著一個過於寬鬆的 IAM 角色，它還會持續成為潛在的攻擊入口。你要等到下個月帳單出來，或者更糟，等到安全事件發生，才會意識到帳戶裡多了些你從未打算建立的東西。

Hightower 沒有明說解法，但他的邏輯指向一個清楚的方向：問題不在於 Agent 不夠聰明，無法判斷該不該啟動一個 Lambda。問題在於你選擇讓它透過什麼介面來操作。讓 Agent 在 Console 上自由操作，你的可觀測性上限就是 CloudTrail 裡的原始 log。讓 Agent 透過 Terraform 操作，你的可觀測性上限就是 Git 裡的每一個 diff。同一個 Agent，同樣的能力，但介面的選擇決定了你能不能看見它做了什麼。這不是智慧的問題，是架構的選擇。在你把 AI Agent 放進 AWS Console 之前，先問自己一個問題：當它搞了一團亂的時候，你有辦法知道嗎？