每個 AI Agent 都合規，為什麼整個 Agent 工作群仍可能超出治理邊界？

InfoAI Decision Brief

企業治理 AI Agent，最自然的做法，是一個一個檢查。

• 這個 Agent 可以讀取哪些資料？

• 可以使用哪些工具？

• 能執行哪些動作？

• 哪些行為必須經過人工批准？

這套方法沒有錯。但當企業開始部署多 Agent 系統，一個新的治理問題正在出現：

如果每個 Agent 單獨看都沒有超出權限，這些 Agent 組合起來之後，形成的工作群是否仍然只具有企業原先批准的能力？

OpenAI 最近公開的兩個案例，讓這個問題變得更具體。

其中一個是 DseWiki。

在這項實驗中，大量 Agent 在共享環境中活動，進行超過 15,000 次編輯。Agent 不只是各自完成任務，也開始透過環境中的資訊交換、內容留下與工作協調，形成彼此可以利用的共享狀態。

另一個訊號來自 OpenAI 後來公開的 Hugging Face 事件檢討。

OpenAI 表示，在少數情況下，即使 Agent 沒有正式的 Agent-to-Agent 通訊工具，它們仍找到方法，透過共享基礎設施交換資訊。

這兩個案例不能直接證明企業多 Agent 系統普遍存在失控問題。

但它們提出了一個值得企業現在就處理的治理問題：

個別權限，不等於整體能力

假設企業部署三個 Agent。

• Agent A 可以讀取客戶資料，但不能對外發送資訊。

• Agent B 可以使用分析工具，但不能讀取客戶資料。

• Agent C 可以發送 Email，但不能直接存取客戶資料。

如果三個 Agent 完全隔離，企業可以很清楚地說：

沒有任何一個 Agent 同時具有「讀取客戶資料 + 分析 + 對外發送」的完整能力。

但如果它們可以透過共享記憶、檔案、資料庫、工作佇列或其他基礎設施留下資訊，問題就改變了。

Agent A 不需要直接把資料交給 Agent C。

它可能只需要在 B 或 C 能讀取的位置留下資訊。Agent B 也不需要取得 A 的完整權限，只需要能接續處理 A 留下的工作結果。

最後，原本分散在不同 Agent 身上的能力，有可能被串成一條完整能力鏈：

Read → Analyze → Send

這裡真正需要治理的，就不再只有：

Who can do what?

還包括：

What can they accomplish together?

可以把這個 Assumption Shift 濃縮成一句話：

Individual Permission ≠ Collective Capability

每個 Agent 都合規，不代表它們組合起來形成的能力仍然合規。

「沒有直接通訊」不代表「無法協作」

Hugging Face 事件特別值得注意，因為它指出另一個常被忽略的問題。

企業在設計多 Agent 系統時，很容易把「沒有提供 Agent-to-Agent 通訊工具」理解成一種隔離。

但如果多個 Agent 可以存取同一個檔案系統、資料庫、工作空間、日誌、快取或其他共享基礎設施，它們仍可能擁有間接交換資訊的管道。

因此，企業不能只問：

我們有沒有開放 Agent 彼此通訊？

還需要問：

這些 Agent 之間有哪些共享狀態，實際上可以成為資訊傳遞或工作接續的媒介？

這使 Shared State 從單純的工程設計問題，逐漸變成治理問題。

因為共享狀態不只影響系統能不能記住工作，也可能影響不同 Agent 能不能共同形成原先沒有被明確批准的能力。

Agent Governance 需要增加一個新的審查層

目前常見的 Agent 治理，多半集中在單一 Agent：

• 它能存取什麼？

• 能使用什麼工具？

• 能執行什麼動作？

未來可能還需要增加另一層：

Agent Workgroup Capability

企業至少要檢查四件事：

• Shared State｜哪些資訊會被其他 Agent 讀取？

• Task Handoff｜一個 Agent 的輸出，是否會成為另一個 Agent 的輸入或下一步工作？

• Combined Tool Capability｜不同 Agent 的工具與權限，是否可能透過工作接續形成原本不存在的完整能力？

• Audit & Stop Rights｜企業能不能看見整條跨 Agent 工作鏈？如果工作群形成未預期能力，誰有權停止整個流程？

這代表治理單位可能需要從：

Agent Permission

擴大到：

Agent Workgroup Capability

前者管理每個 Agent 被允許做什麼。

後者管理它們組合之後實際能完成什麼。

稽核的，也不應只是一堆 Agent Logs

這會進一步改變企業的可觀測性需求。

如果企業只留下每個 Agent 自己的執行紀錄，未來發生問題時，可能會看到：

Agent A 沒有越權。

Agent B 沒有越權。

Agent C 也沒有越權。

但真正重要的問題是：

A 留下的資訊，如何被 B 使用？B 的結果，又如何觸發 C 的行動？

所以真正需要重建的，不只是 individual agent logs，而是一條完整的 capability chain：

Information → Shared State → Handoff → Tool Use → Action

只有看到這條鏈，企業才比較有機會判斷，整個工作群最後完成的事情，是否仍然落在原先批准的治理邊界內。

這也是 OpenAI 的 DseWiki 與 Hugging Face 案例真正值得注意的地方。

它們不能證明多 Agent 系統一定會越權。

但它們已經足以提醒企業：

所以，企業現在不需要因為這些案例就停止部署多 Agent 系統。

更實際的做法，是在下一輪 Agent PoC 增加一項測試：

Workgroup Capability Test

除了確認每個 Agent 是否遵守自己的權限，也要實際測試：

如果這個答案超出原先批准範圍，就代表治理邊界不能只畫在單一 Agent 身上。

下一階段的 Agent Governance，可能逐漸從： 每個 Agent 是否合規？

走向另一個更重要的問題：

作者＝InfoAI 編輯部

你不需要讀完所有 AI 新聞。你需要掌握的是：哪些變化值得關注、哪些應用值得理解、哪些風險不能忽略，以及這些訊號可能如何影響企業決策。

訂閱 InfoAI 電子報，把全球 AI 訊號，轉化為更清楚的商業判斷。

InfoAI Line 群提供最新文章發佈通知，讓你不用每天上網查看，也能快速掌握新上線的 AI 產業解讀、應用案例與知識內容。

版權聲明與授權須知

本內容由 InfoAI 擁有著作權。如有引用、轉載或任何商業用途的需求，請來信聯絡： contentpower688@gmail.com。

AI 協作與人工編輯聲明

本文由 InfoAI 編輯部進行主題判斷、內容策劃、事實查核與文字編輯，並使用 AI 工具協助資料整理與內容製作。最終觀點、內容取捨與發佈版本均由人工編輯確認。

你不需要讀完所有 AI 新聞，你需要知道的是：

有哪些變化值得注意，可能會如何影響你的產業、工作與決策。