文章 發布於 AIA: 2026年4月25日

Vertex AI 服務代理權限過大：agent 如何跨越雲端邊界

Unit 42 展示了 Vertex AI Agent Engine 裡的「double agent」風險：部署後的 agent 可以從執行環境取出 Google 代管的服務代理帳號憑證，接著用那些權限讀取客戶專案的儲存空間、檢視 Google 代管的受限部署檔案，並造成部署檔案裡的敏感資訊洩漏。Google 後續更新文件，並建議使用 BYOSA（Bring Your Own Service Account，自帶服務帳號）。這個案例真正提醒我們的是：AI agent 用哪個雲端身分執行、執行時拿到哪些權限、部署檔案能不能被讀到、網路上能連到哪些服務，其實都屬於同一條安全邊界。

Credential ExposureData ExfiltrationIdentity & AccessVertex AICloud IAM
8 項對應的 AIDEFEND 防禦手法
來源: Double Agents: Exposing Security Blind Spots in GCP Vertex AI 
作者 Ofir Shaty · 原文發布: 2026年3月31日

威脅分析

  • agent 執行環境繼承了一個權限很大的代管身分。 這項研究聚焦在 Vertex AI Agent Engine 的 P4SA（Per-Project, Per-Product Service Agent），也就是 Google 為了讓 Vertex AI 代表服務存取資源而代管的服務代理帳號（service agent，本質上是一種服務帳號）。
  • 惡意工具把執行環境裡的雲端身分拿出來用。 agent 工具先呼叫 Google 的中繼資料服務（metadata service，雲端執行環境用來查詢自身身分與存取 token 的本機服務），取得服務代理帳號的存取 token，再用這個 token 直接呼叫 GCP API。換句話說，攻擊者不是只在正常 agent 流程裡操作工具，而是把 agent 執行環境變成可存取雲端資源的入口。
  • 第一個橫向移動點進入客戶專案。 Unit 42 表示，研究者用取出的憑證讀取 consumer project，也就是客戶自己的 GCP 專案裡的 Google Cloud Storage 儲存桶（bucket），包括列出儲存桶、列出物件和讀取物件。
  • 第二個橫向移動點暴露了供應商端部署檔案。 同一個身分也能存取 Google 擁有、原本受限的 Artifact Registry 儲存庫（repo），並下載 Vertex AI Reasoning Engine 的內部容器映像（container image）。Google 後來確認另有更強控制可阻止正式環境映像被修改，不過光是讀取權限本身，就已經暴露供應鏈情報。
  • tenant project 又多了一層資訊外洩。 研究者在部署用的 Google 代管 tenant project 裡看到 Dockerfile.zip、code.pkl 和 requirements.txt 等檔案，裡面透露內部路徑與實作細節。agent 程式碼使用 Python pickle 序列化也值得注意，因為一旦攻擊者能竄改這類檔案，就可能變成遠端程式碼執行風險。
  • 緩解方式不是單一修補。 Google 更新文件並建議使用 BYOSA，不過防禦方仍然需要最小權限服務身分、受限 OAuth 權限範圍（scope，token 可呼叫哪些 Google API 的範圍）、部署檔案完整性控制、網路區隔，以及針對代管 AI agent 平台的監控。

適用的 8 項 AIDEFEND 防禦手法

AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
極高
這是最核心的控制，因為這次失敗點來自平台預設設定給了比多數使用者預期更大的存取權。Vertex AI Agent Engine 的安全基準應該定義核准的服務帳號模式、預設停用過寬的儲存空間與 Artifact Registry 存取、允許的 OAuth scope、agent 能不能連到中繼資料服務，以及正式環境 agent 採用 BYOSA 的基準做法。
AID-H-004.002
Service & API Authentication
極高
這條攻擊路徑成立，是因為從服務代理帳號取出的存取 token，離開原本 agent 工作流程後仍然可以直接拿去呼叫 GCP API。服務驗證控制應該偏向專用服務帳號、短效憑證、明確綁定 audience 與 scope、檢查 token 來源，並在代管 AI 執行期身分外洩時能快速撤銷。
AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
極高
Vertex AI agent 不應該只在記錄裡呈現成一個很寬的 Google 代管服務身分。防禦方需要知道是哪一個 agent 執行個體在動作、由哪個使用者或專案授權、拿到哪個委派範圍，以及該動作是否仍符合核准任務。這正好對上研究中 consumer、tenant 和 producer project 邊界混在一起的問題。
AID-H-019.004
Intent-Based Dynamic Capability Scoping
高
只需要完成單一工作流程的 agent，不該繼承整個專案的儲存空間讀取權、Artifact Registry 探查能力，或呼叫 Workspace API 的機會。每個工作階段與每個使用者意圖，都應該限制只能碰到任務需要的服務，避免惡意工具呼叫只因為底層代管身分碰得到更多服務，就把實際可用權限一起放大。
AID-I-002.001
Internal AI Network Segmentation
高
中繼資料服務、tenant project 儲存空間、客戶 bucket 和供應商 artifact registry，不應該像同一個平坦的執行環境一樣彼此可達。針對 agent 後端、artifact 儲存庫和服務控制路徑做網路區隔與微分段，可以在 agent 執行環境或 token 被偷走時縮小橫向移動範圍。
AID-H-003.002
CI/CD Release Gating, Model Artifact Signing & Secure Distribution
高
受限容器映像、部署套件和 code.pkl 被看到，代表防禦方不能只管 agent 執行時的權限，也要管部署前的檔案來源。agent 套件、容器映像和執行環境內容，應該只從核准的登錄庫進入正式環境，並搭配簽章、不可變的摘要值（digest）、來源證明，以及會拒絕不安全序列化或非預期相依套件的檢查。
AID-D-005.002
Security Monitoring & Alerting for AI
中
這條攻擊路徑會留下可觀察訊號：agent 工具存取中繼資料服務 token、服務代理帳號碰到非預期服務、異常列舉 GCS、讀取受限 Artifact Registry，以及掃描部署檔案。監控規則不能只看單一 API 呼叫，還要把 agent 行為脈絡串起來看；一旦出現這些模式，就應該示警，避免被偷走的身分默默變成跨專案存取路徑。
AID-D-011.001
Agent Behavioral Analytics & Anomaly Detection
中
所謂 double agent，從營運角度看，就是部署後的 agent 行為已經不再符合原本宣告的用途。行為證明與異常 agent 偵測，可以替每一類 agent 建立預期工具呼叫、儲存空間存取、網路目的地和憑證使用基準；一旦 agent 開始撈取 token 或列舉基礎設施，就提出警示。

身為資安防禦者，我們應該這麼做

  • 盤點所有 Vertex AI Agent Engine 部署，記錄它們的執行期身分、P4SA、BYOSA 狀態、OAuth 權限範圍、暫存儲存桶（bucket）、Artifact Registry 存取權和負責人。
  • 在可行時，把正式環境 agent 移到專用 BYOSA 身分。每個身分只授予該 agent 工作流程需要的儲存桶、模型端點、登錄庫和 API。
  • 阻擋或嚴格控管 agent 工具對中繼資料服務 token 的存取。任何會讀取執行個體中繼資料、環境憑證或雲端 token 的 agent 函式，都應該視為高風險動作，需要審查與記錄。
  • 檢查 Vertex AI 相關服務帳號拿到的 GCS 與 Artifact Registry 權限。移除它們不需要的列出與讀取能力，特別是跨 tenant、建置、暫存和正式環境邊界的 bucket、物件和登錄庫內容。
  • agent 程式碼和容器映像要先驗證簽章、審查內容，再進入正式環境。可行時，部署檔應改用載入時不會順便執行程式碼的格式；正式環境部署流程也要拒絕非預期的 pickle 載入或執行路徑。
  • 替服務代理帳號異常行為新增偵測：異常列舉儲存桶、讀取受限登錄庫、存取中繼資料服務 token、嘗試呼叫 Workspace API，以及代管身分在正常專案或服務路徑之外執行動作。

1 個額外的防禦考量

代管 AI 服務身分的透明度

除了上面對應的防禦技術，使用代管 AI agent 平台的團隊也應該要求供應商提供更清楚的證據：隱藏服務身分、不可編輯的 OAuth 權限範圍、tenant project 資源、producer project 相依項目，以及哪些權限由客戶控制、哪些由供應商控制。
建議做法: 向雲端供應商要求可由機器讀取的服務代理帳號清單、實際有效權限報告、明確的中繼資料服務行為文件，以及客戶服務代理帳號不能在文件所述部署路徑之外讀取或修改供應商正式環境部署檔案的保證。

結論

Vertex AI 這個案例不只是一次雲端權限意外。它顯示 AI agent 平台裡，代管身分、執行環境、中繼資料服務和供應商端部署檔案不能分開看；這些東西會一起決定部署後的 agent 能碰到哪些雲端資源。AIDEFEND  對應到的防線包括：建立安全基準、驗證服務身分、治理 agent 用哪個雲端身分執行、限制 agent 能碰到哪些資源、做網路區隔、在部署前驗證程式碼和容器映像，以及監控異常存取。實務目標很簡單：部署後的 agent 應該有明確名稱、明確且收斂的任務、身分和網路路徑，而且每一個能讀到、能連到、能呼叫的範圍都要留下可驗證的證據。