Agent Governance Stack：像管理工程團隊一樣管理你的 AI Agent 機隊

設定錯誤的 SaaS 工具頂多是被動地洩漏資料，但設定錯誤的 Agent 卻會主動採取有害的行動。

我們在 2015 年看到的「影子 IT (Shadow IT)」模式，如今正透過 AI Agent 重演。你的 Agent 可以存取生產環境資料庫、客戶的 PII（個人識別資訊）以及財務系統，但它們卻可能沒有獨立的身分、受限的權限，或是行為監控機制。

你絕不會以這種方式管理工程團隊，因此，你也不該這樣管理你的 Agent 機隊。

作者：@addyosmani 與 @Saboo_Shubham_

在 Google Cloud Next '26 大會上，我們為 Gemini Enterprise Agent Platform 發布了一套治理堆疊（Governance Stack），其建構核心是每位工程主管都已熟悉的思維模型：像管理工程團隊一樣管理你的 Agent 機隊。賦予它們身分、控管存取權限、強制執行政策、監控行為，並審核所有活動。

以下是你該如何一層一層地建立這套堆疊。

第一層：身分 (Identity)

當你聘請一位工程師時，他們會獲得一張識別證和一組專屬的憑證。當發生問題時，你可以追溯該行動至特定人員。

大多數的 Agent 部署完全跳過了這個步驟。組織內的所有 Agent 往往共用同一個 [email protected] 帳號。當某個 Agent 存取了不該存取的資料，或採取了超出範圍的行動時，審核軌跡只會指向一個共用憑證，導致調查陷入僵局。你知道是某個 Agent 做的，但你不知道是哪一個。

Agent Identity 透過為每個 Agent 分配一個具有明確授權政策的唯一加密 ID 來解決這個問題。每個身分都是可追蹤、可審核且可獨立撤銷的。你可以把它想像成專為 Agent 設計的 IAM。

其架構遵循「最小權限原則 (Principle of Least Privilege)」，並應用於 Agent：

粒度（Granularity）至關重要。你分配的不是像「資料讀取者 (data-reader)」這種廣泛的角色，而是精確定義每個 Agent 可以存取哪些資料表、哪些儲存桶（buckets）以及哪些 API 端點。財務 Agent 可以讀取薪資資料，但無法查看員工福利資訊；人力資源 Agent 可以讀取福利資料，但對財務記錄完全沒有存取權。

如果財務 Agent 的行為出現異常變化（例如遭受 Prompt Injection 攻擊，或是模型更新導致其推理邏輯改變），你可以撤銷其特定身分，而不會影響機隊中的任何其他 Agent。當你的安全團隊詢問「週二凌晨兩點是哪個 Agent 存取了客戶資料庫？」時，你可以明確回答出特定的 Agent 身分、其權限設定以及完整的行動日誌。

對於金融服務和醫療保健等高度合規的產業來說，這不僅是「有比沒有好」的功能，而是法規要求。

身分是第一層，因為其上的一切都依賴於它。如果你的 Agent 沒有獨立的身分，你就無法強制執行有效的政策；如果無法為個別 Agent 的行為建立基準，你就無法偵測異常。從這裡開始吧。

第二層：集中式工具治理 (Centralized Tool Governance)

當工程師加入你的組織時，他們不會隨意在生產伺服器上安裝套件。這有一套流程：經過核准的依賴項、經過審查的函式庫、經過檢視的設定。同樣的紀律也必須應用在 Agent 工具上。

如果沒有集中式的工具治理，每個團隊都會為自己的 Agent 建構並連接各自的工具。這就是「影子 AI (Shadow AI)」，它是影子 IT 在 Agent 能力上的直接對應，並會產生相同的問題：冗餘、安全漏洞以及零可視性。

Agent Registry 是一個涵蓋你組織內所有 Agent、MCP 工具和端點的中央目錄。你可以把它想像成一個經過策劃的私有登錄檔（就像企業內部的 npm，用於管理 Agent 能力），平台團隊在此控制可用資源，開發者則在此探索他們能使用的工具。它與 Cloud API Registry 整合，因此你可以透過 Apigee 和 MCP 伺服器，將託管的 API 暴露為安全且可供 Agent 存取的工具。你現有的 API 治理機制可以自然地擴展到 Agent 治理。

開發者可以建構他們需要的任何工具，但在任何生產環境的 Agent 使用它們之前，這些工具必須經過註冊與核准。這創造了一種健康的制衡：開發者保留了建構自訂能力的靈活性與速度，而平台團隊則保留了對生產環境中運行內容的可視性與控制權。

Agent Registry 也解決了可發現性（Discoverability）的問題。當開發者開始建構新的 Agent 時，他們可以瀏覽登錄檔來尋找現有的工具，而不是重複造輪子去寫第四個 BigQuery 連接器。

每個工具都包含關於它存取哪些資料、需要哪些權限、有哪些速率限制，以及目前有哪些 Agent 正在使用它的元資料（Metadata）。如果你需要修補工具中的漏洞，你可以精確地知道哪些 Agent 會受到影響。

第三層：政策強制執行 (Policy Enforcement)

當工程師加入你的組織時，他們必須遵守公司政策。他們不能自行決定可以對外分享哪些資料，或是在週五晚上隨意修改哪些系統。這些政策獨立於個人存在，並被一致地強制執行。

大多數的 Agent 部署處理政策的方式恰恰相反。安全規則被硬編碼在每個 Agent 的系統提示詞（System Prompt）或應用程式邏輯中。當你需要新增一項政策（例如，防止 Agent 洩漏客戶的 PII）時，你必須逐一更新每個 Agent。如果有五十個 Agent，那就意味著五十次程式碼變更、五十次部署、五十個測試週期，以及五十次遺漏其中一個的機會。

Agent Gateway 改變了這一點。它是一個集中式的強制執行點，你可以在此以自然語言定義安全政策，並讓這些政策在所有通過 Gateway 的 Agent 上強制執行。只需用簡單的英文寫一次政策，它就會全域生效。

每項政策都是全域強制執行的。當你新增一項政策時，所有受 Gateway 管理的 Agent 會立即執行它；當你更新政策時，變更會即時傳播。沒有部署週期、不需要針對個別 Agent 修改程式碼，也不會有遺漏某個 Agent 的風險。

Agent Gateway 也整合了 Model Armor，提供針對 Prompt Injection 和敏感資料洩漏的內建保護。這是縱深防禦（Defense-in-depth）層，能攔截你的政策可能未預料到的攻擊——例如旨在操縱 Agent 行為的對抗性輸入、提取訓練資料的企圖，以及試圖繞過存取控制的社交工程攻擊。

結合自然語言政策（針對已知風險）與 Model Armor（針對未知攻擊），無需每個開發團隊都具備深厚的安全專業知識，即可提供全面的保護。

第四層：行為異常偵測 (Behavioral Anomaly Detection)

當工程師開始出現異常行為（存取從未接觸過的系統、在奇怪的時間工作、下載大量資料）時，你的安全團隊會注意到。這不是因為工程師違反了特定政策，而是因為該行為本身就是異常的。

Agent 也需要同樣的監控機制。政策定義了 Agent 應該做什麼和不該做什麼，但異常偵測則是在它們做出意料之外的行為時進行攔截，即使這些行為在技術上並未違反政策。

Agent Anomaly Detection 使用兩種互補的方法。統計模型為每個 Agent 的正常行為建立基準：典型的回應時間、常見的工具呼叫模式、預期的資料存取量、標準的推理鏈長度。當 Agent 顯著偏離其基準時，系統會將其標記以供審查。

第二種方法使用「LLM-as-a-judge」框架。另一個獨立的模型會審查 Agent 的推理鏈，並標記出那些邏輯上無法從證據推導出的結論、與 Agent 設定目標相矛盾的建議，以及似乎受到 Agent 定義範圍之外因素影響的決策。

在實務上，這些機制能攔截到以下情況：

Agent Threat Detection 增加了一個專門針對惡意活動的獨立層。雖然異常偵測能捕捉意外的設定錯誤和行為漂移，但 Threat Detection 監控的是蓄意的攻擊：反向 Shell（Reverse Shell）、與已知惡意 IP 位址的連線、權限提升企圖，以及其他入侵指標。這一層能攔截攻擊者找到方法操縱 Agent 行為，進而獲得系統未經授權存取權限的場景。

兩者都與我們的 Security Command Center 整合，以實現統一的警示與事件回應。

第五層：統一安全態勢 (Unified Security Posture)

最後一層將所有內容整合為單一視圖。每個工程組織都有檢視整體健康狀況的方法：正常運行時間儀表板、事件追蹤器、安全計分卡。你的 Agent 機隊也需要同樣的機制。

由 Security Command Center 驅動的 Agent Security Dashboard，將威脅偵測、異常偵測、政策強制執行與風險分析整合到同一個介面中。

該儀表板讓你的安全團隊能夠：

• 繪製 Agent 與模型之間的關係圖——哪些 Agent 使用哪些模型，以及資料如何在它們之間流動。

• 自動化 asset 發現——當新的 Agent 被部署時，它們會被自動納入清單並進行評估。

• 掃描底層作業系統與語言套件中的漏洞——如果 Agent 使用的 Python 依賴項存在已知的 CVE，儀表板會將其標記出來。

• 關聯所有五個治理層的訊號——某個 Agent 的異常行為結合另一個 Agent 的政策違規，可能顯示出協同攻擊的跡象。

統一的安全態勢視圖回答了每位 CISO（資訊安全長）都會問的問題：「我們目前面臨的 AI Agent 整體風險是什麼？」他們不再需要從五個不同的工具中拼湊資訊，而是透過一個儀表板，就能清楚掌握身分合規性、政策執行率、異常趨勢以及活躍威脅。

總結

這五個層級形成了一個系統，每一層都建立在下方層級的基礎之上：

如果你正在大規模部署 Agent，按順序實作這五個層級——先身分，再登錄檔，接著 Gateway，然後偵測，最後是統一態勢——將為你提供最強大的基礎。

儘早實作這套堆疊的團隊將獲得複利優勢。每一個新部署的 Agent 都會自動繼承身分模型、政策框架與監控基礎設施。由於基礎已經就緒，增加第五十個 Agent 的邊際成本幾乎為零。

而選擇等待的團隊將面臨我們在影子 IT 中看到的困境：情況會逐漸惡化，每一個未受管理的 Agent 都會增加攻擊面、審核複雜度以及最終的遷移成本。

立即開始：cloud.google.com/agent-platform

保護你的機隊：Google for Startups AI Agents Challenge

停止對影子 AI 的擔憂，開始像專業的工程組織一樣管理你的 Agent。加入我們為期 6 週的全球挑戰賽，使用生產級的治理堆疊來建構、優化或重構自主 Agent。你將獲得 500 美元的雲端抵用金、完整存取 Gemini Enterprise Agent Platform 的權限，並有機會角逐 90,000 美元的獎金池。

立即報名，開始建構！