300 個代理、60 名員工：我們如何守住自家 AI 代理——專訪 Runlayer 的 Aiden Sochowski

Runlayer 的創始工程師 Aiden Sochowski 主張，企業對內部執行的 AI 代理幾乎毫無可視性，唯一可行的防禦是持續監控加上嚴格限縮的許可權，而非靜態的黑名單。這場演講以研討會形式簡短走過 Runlayer 內部的一次安全演練，多數時間花在監控所揭露的問題上：代理氾濫、提示注入（prompt injection）與會話漂移攻擊、許可權過大的代理，以及失控的模型成本。標題中的「300 個代理、60 個人」只是整體監控論證裡的一個資料點，並非本集主題。

Sochowski 談的是第一線的實戰經驗：Runlayer 部署了閘道器，記錄每一次會話與每一次工具呼叫，再自行訓練分類器模型，判斷代理的行為是否符合其既定用途。讀者讀完應該能具體掌握各種失效模式——同時擁有 ATS 與行事曆許可權的招募機器人、能被說服到核准程式碼的 PR 審查代理、靠 vibe coding 拼出來卻讓 Token 支出暴增的 MCP 伺服器——以及 Runlayer 試過的具體緩解措施，包括哪些地方做得不夠。

代理氾濫的速度遠超人力，而且大多隱形

Runlayer 的內部監控發現，代理的數量遠遠超過操作它們的人。Sochowski 說，在一家約 50 到 60 人的公司裡，每天有超過 300 個代理在執行。許多根本不是由使用者觸發：它們從聊天機器人、排程觸發器或 SaaS 應用程式自動啟動。據他所述，多陣列織對此「完全沒有可視性」——大家在本地端跑 MCP 客戶端、在網路上註冊各種代理化產品、在四散各處完成驗證，而且往往還是在未受管理的裝置上進行。

因應方式倒是很傳統：部署閘道器，把每一次會話與每一次工具呼叫都寫進同步記錄，再依主題與風險把代理分類。代理並非個個平等——有些被配置了過多工具，影響範圍（blast radius）大得多。一位同事做了一套視覺化工具，把各團隊畫成「星系」、每個代理是星系中的天體、每一次實際的代理執行則是一顆行星，可一路下鑽到碰觸過的 MCP 伺服器、執行的動作，以及任何錯誤。

Sochowski 解釋這件事為何重要的說法，是全場最犀利的一句：代理所連線的系統，「是為了一個與我們今日所處截然不同的時代而打造的」。這些系統各自存放不同類別的資料，而代理把這些資料混在一起的風險，遠超過過去得刻意寫程式、接好 API 才能做到的程度。

靜態政策註定失效，因為風險取決於會話脈絡

反對黑名單的核心論點是：幾乎沒有哪條規則在所有情境下都安全。直接封鎖某個工具是錯的，因為同一個工具呼叫在某個脈絡下無害，換個脈絡就可能致命。Sochowski 逐一說明一層層愈來愈能感知脈絡的防禦，每一層都有代價：

引發這整套設計的例子，是一個會讀取所有 inbound 郵件的客服代理。惡意寄件者要求它列出所有正在考慮購買產品的最新潛在客戶；一個天真、許可權過大的代理就從行事曆把名單列出來，還可能把資料外洩。用 Sochowski 的話說，要讓每位使用者逐一限縮代理可用的每個工具，「算是相當困難的過程」。

更棘手的情況是攻擊散佈在整段執行之中，而非單一工具呼叫，而且未必來自外部。他描述一個內部 PR 審查代理，有權核准程式碼，包括對照檢查清單審查安全敏感的變更。如果這個代理會讀 GitHub 留言，作者就能反過來施壓——主張這個變更沒問題、所有檢查都通過了、只剩清理工作要審。多問幾次，代理可能就忘了原本的判斷而直接核准。Sochowski 坦承，像 Opus 這類模型目前很難被提示注入，但他說變通手法層出不窮。Runlayer 的對策是自行訓練分類器模型，把一次會話中的所有資料餵進去，判斷每次工具呼叫是否符合代理被定義的職責——因為會話內的意圖漂移，否則極難察覺。

範圍界定得當的代理，偏離行為才偵測得到——也才砍得掉許可權

Sochowski 主張，正因為代理的範圍狹窄，會話資料才具有高訊號量。像 Claude Code 這類在本地端執行的編碼代理「稍微棘手一點」，但任務明確的代理能產生乾淨的基準線：當它們開始使用超出歷史範圍的工具，就是高風險執行的一項早期警訊。

他的例子是一個招募機器人，能存取 ATS、會議紀錄、行事曆，還能傳訊息給使用者。用個人憑證去讀 ATS，會連帶暴露薪資談判郵件等各種內容。Runlayer 建立了模型，拿代理完整的工具呼叫歷史對照其既定任務，並建議可以移除哪些許可權——代理不需要整個 ATS，也不需要讀取每一場會議。重點在於：確定性的許可權界定不可或缺，但「事前真的很難定義」，所以必須從實際觀察到的行為反推出來。

一個被下毒的代理，就能拖垮其他所有代理

由於代理會讀寫大型且切分粗糙的系統，單一被攻陷的代理就可能危害整個內部代理艦隊。藏在上傳履歷裡的惡意酬載，可能被寫進某個系統，之後另一個代理再把它當成普通指令讀進來——而這種交接極難防範，因為它看起來就像正常的資料流。Sochowski 的結論是，代理「就只是軟體……只是把資料從一個來源接到另一個來源的管線」，唯一真正的防禦，是把代理寫入系統的方式限縮到極緊，細到 SaaS 應用程式內的特定資料庫。他說，這是讓代理的上下文視窗保持純淨、不被下毒的唯一辦法。

監控的效益不只安全：MCP 錯誤與百倍成本暴衝

抓得到攻擊的同一套遙測資料，也抓得到浪費。Runlayer 的招募團隊用 vibe coding 拼出一個 MCP 伺服器，用來接某家廠商沒有官方 MCP 伺服器的 API。團隊成員沒有軟體經驗、測試也做得少，結果反覆出現格式錯誤；代理不斷重試、到處找變通方法，而每次失敗的嘗試，輸入與輸出都要計費，Token 成本於是直線飆升。Sochowski 的處方是：監控、限流，並檢查跑在 MCP 伺服器上的程式碼品質，因為「不是每個都長得一樣」。

模型選擇帶來第二波成本衝擊。團隊一開始用便宜的模型——他舉的是 GPT-56 Luna——後來切換到 Fable 5.1，一週內成本漲了超過 100 倍。他說這種情況到處都在發生，而企業很難說清楚哪些任務真的需要昂貴的模型，因為多數在做代理的團隊根本沒跑評估。他的解法是設預算、訂出合理的預設值，並為升級模型等級建立一套真正的論證流程。

先建立可視性，再精準介入

Sochowski 最後談的是原則而非產品推銷：你不可能把整家公司的外送動作全部封鎖。可行的路徑是找出高風險動作實際發生的位置，在那些地方加強審查，並把人員導向合規的工具。他最後邀請聽眾到 Runlayer 二樓的攤位，交流彼此怎麼處理同樣的問題。

整場演講未解的張力在於：Runlayer 建立的每一層——分類器、意圖模型、許可權縮減建議——本身都是模型，而準確度不完美是他們自己承認的；而最難的攻擊，正是散佈在整段會話中、或在代理之間傳遞、單一工具呼叫看起來都沒問題的那種。對任何在執行內部代理的人來說，實務上的結論是先做好 instrumentation：沒有會話層級的日誌，無論是注入嘗試還是百倍成本暴衝，根本都看不見。