# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Google Cloud Tech (@GoogleCloudTech) · 平台：X (Twitter) · 日期：2026-04-23

> 原始來源：https://x.com/GoogleCloudTech/status/2047120160100860290

## 中文摘要

# 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 往往共用同一個 `agent-service@project.iam.gserviceaccount.com` 帳號。當某個 Agent 存取了不該存取的資料，或採取了超出範圍的行動時，審核軌跡只會指向一個共用憑證，導致調查陷入僵局。你知道是某個 Agent 做的，但你不知道是哪一個。

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

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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935152-iaHGe2GPEbUAAKP1rjpg.jpg)

粒度（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 治理。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935292-iaHGe2UtlbwAE0Wqojpg.jpg)

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

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

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

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

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

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

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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935685-diaHGe2ed8a4AAuR5jpg.jpg)

每項政策都是全域強制執行的。當你新增一項政策時，所有受 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 定義範圍之外因素影響的決策。

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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935564-iaHGe2oi7boAAtQV7jpg.jpg)

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

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

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

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

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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935155-iaHGe20bmbEAA558zjpg.jpg)

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

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

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

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

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

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

## 總結

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

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776909935144-iaHGe3A9wboAAxzpCjpg.jpg)

如果你正在大規模部署 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 美元的獎金池。

立即報名，開始建構！

## 標籤

Agent, 產業趨勢, 資安