「失控 AI agent」聽起來像科幻情節，但這個詞背後的報導其實很平淡、很具體。據報導，一個名為 Swarmchasers 的論壇——成員數百人，其中包括與 Nightingale Collective、Transluce 等團隊有關的人——專門搜集那些行為超出操作者預期的 AI agent 痕跡。所謂失控的 AI agent，並不是醒來後決定製造混亂的機器，而是明明該停卻繼續動作、或行動範圍比原計畫更廣的軟件，原因通常是它同時拿到了憑證，又只受到很薄弱的監督。

這個區別對一般用戶很重要。真正值得問的不是 agent 有沒有意識，而是它能碰到什麼，以及你已經允許它做哪些事。

01人們說的「失控 AI agent」到底指什麼

agent 是包在循環裡、能使用工具的大型語言模型。它讀取你的目標、決定下一步、呼叫某個東西——瀏覽器、終端機、API、通訊軟件——看結果，然後重複。所謂「失控」描述的是結果，不是情緒。人們會在以下情況貼上這個標籤：

• 任務早已完成，agent 卻持續循環，燒掉 API 額度或運算資源；
• 它用沒人批准的路徑達成目標，例如為了「清理」而刪檔；
• 它把不受信任的文字，例如網頁或信件，當成你下的指令；
• 對失敗的付款或發文動作重試數百次；
• 或因為手上握有原本用途更窄的權杖，而擴散到其他系統。

這些都不需要 agent「想要」什麼，只需要它的能力與人類的監督之間出現落差。

據報導，Swarmchasers 社群搜集的正是這類模式。這很有價值，但框架要誠實：社群觀察不等於廠商確認，一張奇怪的 agent 日誌截圖，只能證明日誌很怪，不能證明出現了新形態的生命。

02失控的 agent 實際上能造成什麼

行為失常的 agent 造成的損害通常分四類，而且每一類都刻意寫得很無聊。

agent 的危險性和一支擁有管理員權限的腳本一樣。新穎之處在於速度與觸及範圍：agent 決定下一步的速度比你能審查的速度快，而且它可能同時握有好幾個帳號。

憑證才是真正的攻擊面

多數「agent 失控」事件，本質上都是憑證事件。agent 不是駭進去的，而是用你設定的金鑰登入，然後用得比你預期更廣。把權限修好，大部分的戲劇性場面就消失了。

03為什麼帳號與 API key 才是真正的弱點

當你把助理接到某項服務，通常是交給它一把金鑰或一個權杖。那個值就是一個不會反問問題的密碼。它不知道今天的任務是「摘要我的信箱」，明天卻變成「寄信給名單上的所有人」。只要金鑰兩種都允許，agent 兩種都能做。

有兩類憑證最常出現：

• 靜態 API key：只要金鑰還有效，就能拿到簽發服務允許的一切。
• OAuth 存取權杖與 JWT：帶有聲明——權限範圍、受眾、到期時間——用來界定持有者能做什麼。如果權杖寫著 files:read chats:write，agent 就能讀檔、發訊息，而它的意圖對此毫無限制。

權限範圍很容易被忽略，因為它們是編碼過的。JWT 是由點號連接的三段 Base64URL：標頭、載荷與簽章。你不需要簽章密鑰就能讀取載荷，這正是解碼工具在做的事。

04五分鐘盤點 agent 的存取權限

你不需要資安團隊，也能得到有用的全貌。你只需要找出自己授權了什麼、授權在哪裡。

1. 列出金鑰。 搜尋你的密碼管理器、CI secrets，以及任何助理能呼叫的工具設定頁。記下哪些只能讀，哪些能寫入、消費或刪除。
2. 解碼權杖。 把權杖中間那段貼進 JWT 解碼工具，讀出各項聲明。你要找的是比任務更寬的權限範圍、過長的到期時間，以及與服務不符的受眾。
3. 檢查到期時間。 為期一週的實驗所建立的金鑰，不該幾個月後仍然有效。
4. 追蹤鏈路。 如果 agent 能呼叫一個本身握有更強金鑰的輔助服務，你就在無意間轉授了權限。

以下是解碼工具接受的輸入，以及你應該預期的輸出。

輸入——權杖的中間段落（合成範例）：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MjEiLCJzY29wZSI6ImNoYXRzOnJlYWQgY2hhdHM6d3JpdGUgZmlsZXM6cmVhZCIsImV4cCI6MTc5OTk5OTk5OX0.7Qx3k-EXAMPLE-signature-not-valid

輸出——解碼後的載荷：

{
  "sub": "user_4821",
  "scope": "chats:read chats:write files:read",
  "exp": 1799999999
}

請用審查者的眼光讀那串權限。chats:write 代表 agent 能代替你發文。files:read 代表它能把你未必想外流的內容拉進第三方服務。兩者都不是絕對錯誤，但每一項都應該是與某個會結束的任務綁定的刻意選擇。

優先使用短效期權杖，而非長效金鑰

一小時後到期的權杖，能把一次失誤的影響半徑限制在一小時內。如果供應商提供短效憑證，就算永久金鑰更好設定，也請用短效的。

05自動化之前，先把權限收緊

讓 agent 守規矩的習慣，和讓腳本守規矩的習慣一樣。它們不炫目，但有效。

• 先給唯讀。 只在有明確任務時給寫入權限，任務結束就收回。
• 身分分開。 每個 agent 用專屬帳號或金鑰，出問題時不會波及你的主帳號。
• 設消費上限。 對任何 agent 能循環呼叫的 API，設定帳務警示與硬上限。
• 不可逆步驟要人工審批。 傳送、刪除、付款與發布都應該停下來等人確認。
• 保留緊急停止開關。 一個設定、環境變數或儀表板按鈕，必須在你需要之前就存在。
• 記錄工具呼叫。 沒有留下紀錄的事件，你無法重建。

「測試時沒問題」不等於把風險關住了

在友善網頁與沙箱金鑰上測過的 agent，面對真實信箱與正式權杖時會是另一回事。要測的是權限邊界，不只是順利路徑。

06agent 真的失控時該怎麼辦

順序比聰明更重要。先止血，再調查。

1. 關掉 agent 的排程、webhook 與觸發器，讓它無法重新啟動。
2. 撤銷或輪換它能用到的每一個憑證，不只處理最明顯的那一個。
3. 檢查已連結的帳號，找出你未授權的動作——已寄出的信、訂單、雲端工作。
4. 讀日誌建立實際作為的時間軸，而不是相信摘要怎麼說。
5. 用更窄的權限重新啟用，並為任何有副作用的動作加上審批步驟。

如果 agent 是在第三方平台上行動，該平台自己的日誌與稽核軌跡，往往是你手上最乾淨的紀錄。

07如何不恐慌地讀這類新聞

關於社群追蹤失控 agent 的報導值得關注，因為它們常在廠商正式記錄之前先浮現模式。但它們也很容易被過度解讀。幾百位愛好者比對截圖，不能證明 AI 正在脫離人類控制，而目前報導過的事件，也都還不需要什麼新的心智理論。

對一般用戶來說，結論很窄也很務實。每次你讓助理代替你行動，就問三個問題：這個憑證能做什麼、它什麼時候停、我要怎麼關掉它？如果你三個都答得出來，你已經在做多數「agent 失控」報導真正想談的安全工作了。