在 Google Cloud 保護代理式企業

根據調查，企業最擔心的問題分別是敏感資料暴露 (52%) 與法規遵循 (50%) (資料來源：Cloud Security Alliance，2025 年 12 月)。不過，隨著企業轉向自主運作的代理式 AI，新的關鍵攻擊向量也跟著出現：

• 安全漏洞遭攻擊的平均時間大幅縮短至負七天，意即在軟體修補程式發布前，不肖人士通常早已利用零時差漏洞發動攻擊(資料來源：Mandiant M-Trends 趨勢報告)
• 在現代雲端環境中，非人類 Workload Identity 的數量已達人類身分的 82 倍 (資料來源：2026 年 Google Cloud Next 大會)
• 目前有 42% 運作中的企業 AI 代理具備敏感權限，而且權限過高 (資料來源：2026 年 Google Cloud Next 大會)
• 要抵禦這類機器級攻擊，必須確保整個 AI 堆疊的安全，同步保護基礎架構、資料、模型和自主式代理

如果開發人員或業務單位繞過 IT 審查，擅自部署未經授權的模型、外部 API 或第三方代理技能，就會發生影子 AI 問題：

• 在公開市集上架的代理技能中，超過 15% 已知涉及惡意活動 (資料來源：2026 年 Google Cloud Next 大會)
• 68% 的組織都在執行自行託管模型，而這類模型深植於第三方軟體，往往不易察覺 (資料來源：Wiz，State of AI in the Cloud 2026)
• 組織可以使用 Wiz AI-APP 偵測影子 AI，只需 15 分鐘即可透過 API 連線，並動態生成 AI 物料清單 (AI-BOM)。搭配使用 Gemini，還能透過集中式 Agent Registry 將所有運作中的代理、自訂 MCP 伺服器和外部工具編入目錄，方便統一管理

不需要。雖然人才短缺是公認的挑戰，但設有正式 AI 治理架構的組織，培訓員工使用 AI 安全防護工具的機率高出 3 倍 (資料來源：Cloud Security Alliance，2025 年 12 月)。另外，現在已有 53% 的組織是由安全團隊來主導 AI 防護工作 (資料來源：Cloud Security Alliance，2025 年 12 月)。Google Cloud 更是直接將安全防護整合至平台架構：基礎設定已透過企業基礎藍圖自動完成；執行階段互動由 Model Armor 原生管理；像 CodeMender 和 Wiz Green Agent 這類自主偵測與修復代理，則能直接在開發工作流程中，測試及生成符合慣例的程式碼修補程式。

想保障自主式代理的安全，光靠靜態服務帳戶並不夠。目前非人類身分的數量已達人類身分的 82 倍，更有 42% 的運作中代理權限過高 (資料來源：2026 年 Google Cloud Next 大會)，因此 Google Cloud 打造了身分優先安全防護堆疊：

• 代理身分：專屬的一等主體身分類型，與人類使用者不同。系統會為其佈建加密編譯的執行階段憑證，這些憑證經過嚴格驗證，而且只在代理的生命週期內有效
• 最小權限控管機制：透過 Privileged Access Manager (PAM) 限制代理的能力，落實即時 (JIT) 存取措施，不再保留常設權限
• 主體存取邊界 (PAB)：設下嚴格的資源防護邊界，限制執行中代理身分的最大影響範圍

安全 AI 架構 (SAIF) 是 Google 設計的概念架構，旨在確保以安全、負責任的方式部署 AI。這個架構將零信任安全原則落實於 AI 系統，強制執行三項防護措施：透過二進位授權驗證 SLSA 第 3 級建構作業來源資訊；在 Cloud Build 自動執行「政策即程式碼」檢查，以及持續偵測威脅。在代理式環境中，SAIF 的實作劃分為四個生命週期階段，也就是設計架構、清點資產、攔截威脅和防禦 (資料來源：《安全實現 AI 創新》電子書，第 6 章)

Model Context Protocol (MCP) 是一項開放標準，能讓自主式 AI 代理連結外部資料來源、企業工具與商業 API。不過，未妥善管理的自訂 MCP 整合，會將未經審核的高風險端點帶到正式環境，造成安全隱憂。為此，Google Cloud 透過 Google Cloud 代管 MCP 伺服器 (例如 BigQuery 適用的 MCP 伺服器) 來確保代理式工具的安全。這項機制可將代理與企業資料庫的互動方式標準化，除了強制執行範圍嚴格受限、可供稽核的 IAM 權限，也能以經過強化的企業代管連線，取代自訂 API wrapper (資料來源：2026 年 Google Cloud Next 大會)。

在多租戶或多代理環境中，如果某位使用者的私密對話內容、權杖或企業敏感資料，意外外洩至其他人的工作階段，就會導致工作階段洩漏問題。Google Cloud 透過 Agent Development Kit (ADK)，消除了工作階段洩漏的情形 (資料來源：《安全實現 AI 創新》電子書，第 2 章)：

• 租戶隔離：ADK 運用原生的 session_id 和 user_id primitives 參數，強制執行嚴格的使用者界限，並將各個執行環境區隔開來
• 憑證隔離：下游驗證權杖各自獨立，因此代理無法在不同的使用者工作階段，沿用憑證或保留對話狀態

可以。現在許多組織都採用多模型策略，平均會執行 2.6 種不同的模型 (資料來源：Cloud Security Alliance，2025 年 12 月)。Google Cloud 透過 Gemini 打造集中式執行控制層，協助管理多個模型。無論是使用第一方 Gemini 模型、開放原始碼模型或第三方模型，組織都能享有一致的執行階段防護機制，包括 Model Armor 的提示詞清理功能，以及 semantic governance policy。至於多雲端資產 (包括 AWS Bedrock、Databricks 和非代管開放原始碼) 方面，則可運用 Wiz Security Graph，釐清所有雲端服務供應商環境中的安全漏洞與攻擊路徑 (資料來源：2026 年 Google Cloud Next 大會)。

不會，CodeMender 採用隱私權優先的本機執行架構 (資料來源：《安全實現 AI 創新》電子書，第 4 章)：

• 使用本機 CLI 處理作業：CodeMender 掃描引擎會直接在開發人員的安全環境中，透過本機指令列介面運作
• 採用隔離沙箱機制：系統會在組織自有基礎架構的獨立沙箱中，建構應用程式並主動驗證漏洞攻擊。
• 不使用機密資料訓練模型：組織擁有的原始碼和智慧財產會受到嚴格保護，絕不會用於訓練 Google 基礎模型。合併任何程式碼修補程式前，開發人員都能透過標準的 IDE/CLI 工作流程與人工介入迴路 (HITL) 審核機制全面把關

企業若需執行高風險的商業邏輯，同時確保核心基礎架構不外洩，就能採用自備容器 (BYOC) 參考架構：

• 採用容器沙箱機制：將高風險的自主式代理 (例如庫存或物流的對接系統) 部署於 Cloud Run 的獨立容器
• 嚴格區分權限：部署期間的基礎架構權限，必須與執行階段的執行權限完全區隔開來
• 引進人工介入迴路 (HITL) 機制：Agent Development Kit (ADK) 設置了預先設定好的暫停點，只要作業涉及高風險動作 (例如啟動訂單履行 API 或撥付資金)，執行前一律得經過真人明確核准

Google Cloud 採用雙重防護執行階段解決方案，能在不增加延遲時間的前提下清理酬載：

1. 控管存取權 (IAM 邊界)：由 Agent Gateway 原生強制執行，會使用 Identity-Aware Proxy (IAP)，以加密編譯的方式進行驗證，確認呼叫端的數位身分無誤後才轉送連線
2. 控管意圖 (語意邊界)：Model Armor 就像內嵌 Proxy，能即時過濾使用者、使用者代理程式和模型互動，有效遏阻提示詞注入攻擊、防範越獄行為，並遮蓋敏感 PII。在應用程式層，Agent Development Kit (ADK) 會強制執行輸入驗證機制 (例如 BeforeToolCallback)，防堵鎖定 BigQuery 資料表的間接 SQL 注入攻擊。

防範資料外洩的關鍵，是在網路、應用程式與模型層全面建構縱深防禦機制：

• 私人拓撲：AI 工作負載會在集中管理的 Shared VPC 上執行，並由 VPC Service Controls (VPC-SC) 隔離，為整個代理生態系統外圍築起一道大型安全防線
• 即時清理：Model Armor 會掃描提示詞輸入內容和模型輸出內容，自動清除並遮蓋當中的敏感客戶資料與 PII
• 無權杖驗證：Agent Identity 驗證管理工具會代表使用者處理下游複雜的 OAuth 握手流程，安全傳遞權杖，而不會將原始憑證洩漏給代理
• 機密運算：在模型處理工作期間加密記憶體，以保護使用中的資料