AI agent 權限先給 admin？最小權限要從第一天寫

資安團隊 Zenity Labs 公開過一條漏洞鏈：某大型雲端平臺上，只要有一個對外開放的客服 agent，攻擊者在聊天視窗打一句話，請它去查內部 metadata 服務並把結果送出去，agent 就照辦，臨時金鑰整包交出。研究員自己說，他們準備突破的沙盒根本不存在。先聲明，這家公司自己也賣 agent 資安產品，講話難免帶點業務味，但技術細節站得住腳，值得每個要上 agent 的企業看一眼。

問題不在 agent 笨，在於它拿到的鑰匙太大

agent 被誘導不稀奇，提示注入本來就防不勝防。真正致命的是那把臨時金鑰的預設權限：同帳號同區域的每個 agent，都能讀、寫、刪。攻擊者因此能下載原始碼、看私人對話、讀取密鑰管理服務，甚至改寫 agent 的長期記憶，讓它之後默默轉寄對話。從客服一路走到財務，暢行無阻。

這就像把倉庫總鑰匙掛在櫃檯店員脖子上，然後祈禱沒有人跟他說「借我一下」。

「先給 admin，之後再收」從來沒有之後

我們看過太多專案：工程師趕上線，權限先開滿，備註寫「之後調整」。結果半年後沒人敢收，因為不知道哪個功能偷偷依賴了這個權限。面試新人我們會查背景，給 AI 的權限卻比給董事長還大。

上線前至少做這五件事

• 一個 agent 一個執行角色，禁止同區域共用，客服 agent 絕不能碰財務資料。
• 權限從零開始加，只開它做事必需的那幾個 API 與資料表，用到再申請。
• 封掉或限制對 metadata 服務的存取，並強制使用較新的版本驗證機制。
• 對外 agent 一律假設會被提示注入：輸出要過濾，敏感動作要人工確認或另一道審批。
• 長期記憶與對話紀錄設為唯讀或加簽章，並定期稽核異動，避免被悄悄改寫。

廠商修補不是你的免死金牌

這起事件的預設角色，是通報後好幾個月才收緊，而且新部署才生效，舊環境得自己動手。換句話說，等廠商替你把門鎖好之前，你得先自己上栓。我們替企業做 AI 整合時，第一份交付物通常不是模型，而是權限矩陣與資料流向圖，因為模型可以換，洩漏出去的資料收不回來。

agent 就是一個很聽話、但完全不會懷疑人的新員工。最小權限，請從第一天寫進設定檔，不要寫進待辦清單。