一個值得注意的品牌重整：Vertex AI 與 Agentspace 的整併

在談這篇的技術內容之前，有個平台層級的變化值得先說明：Google 在 2026 Cloud Next 大會上，把原本的 Agentspace 整併進統一的 Gemini Enterprise 產品線，Vertex AI 的部分能力也隨之被納入這個更完整的 Agent 平台敘事下。對企業來說，這代表「Vertex AI」與「Gemini Enterprise Agent Platform」這兩個名詞在近期會有一段並存、逐漸統一的過渡期——你在官方文件裡同時看到兩種說法都是正常的，不用覺得是文章寫錯。

這篇要談的核心問題：Agent 平台是一個新的權限彙聚點

當企業把多個 Agent、多個工具、多個資料來源都掛進同一個 Agent 平台時，這個平台本身就變成一個高價值的權限彙聚點——如果平台層級的權限設計沒做好，一個 Agent 可能意外取得存取另一個 Agent 專屬資料的能力，或是一個原本只該讀取內部知識庫的 Agent，被賦予了它其實不需要的工具呼叫權限。

三個該盤點的風險點

Agent 之間的權限隔離：平台上跑的多個 Agent，是否有明確的權限邊界？一個負責客服的 Agent，跟一個負責內部財務分析的 Agent，理論上不該共用同一組憑證或存取範圍。

工具（Tool）授權的最小化：每個 Agent 掛載的工具，是否都是它任務真正需要的？參考 Day7 的最小權限原則，同樣適用於 Agent 的工具授權設計——不該因為方便，就把整組工具箱都掛給每一個 Agent。

跨 Agent 資料流的可視性：當 Agent A 的輸出成為 Agent B 的輸入時，這條資料流是否有被記錄、被稽核？這正是 Day5 提過的 架A2 Agentic 權限分層與 blast radius 在多 Agent 協作場景下的具體展現，也會在主題二整個系列被更深入地展開。

這篇只是開胃菜

Agent 層的安全設計，包含更細緻的 Agent 間信任邊界、編排層風險、審計軌跡設計，這篇篇幅有限只能先點出平台層級的三個風險點。完整的 Agentic AI 攻防會在 9 月的第二個系列——《GCP Security 視角下的 Agentic AI 攻防 30 天》——整整 30 篇深入展開，這篇算是先埋一個伏筆。

這篇的檢查清單

• [ ] 平台上的多個 Agent 是否有明確的權限隔離，而非共用同一組憑證？
• [ ] 每個 Agent 掛載的工具是否都經過最小權限盤點，而非圖方便全部掛上？
• [ ] 跨 Agent 的資料流是否有被記錄與稽核？