把 API key 放進環境變數，對單一內部工具或許夠用；當幾十個 Agent 代表不同員工呼叫 GitHub、Jira 與內部系統時，就很難回答「是哪個 Agent、代表誰、拿哪個權限做了什麼」。Google Cloud 8 月 23 日更新 Agent Identity Auth Manager 文件，主攻的正是這個缺口。
它把外部工具憑證集中到受管保管庫，Agent 透過自己的身分取得 API key 或 OAuth Token。我要下的判斷是：這比每個團隊自行存 OAuth refresh token 更容易治理，但仍只是身分與憑證層，無法自動補上業務授權。
它管理三種常見情境
第一是 API key，適合只能用金鑰驗證的外部服務。第二是雙方 OAuth，Agent 用自己的客戶端身分做機器對機器存取。第三是三方 OAuth，Agent 代表使用者操作 GitHub、Jira 等服務，由使用者登入同意並留下可撤銷的授權。
Agent Development Kit 可在工具呼叫前向保管庫取憑證並附加標頭，減少開發者自己處理交換與更新 Token 的程式碼。與AWS AgentCore Identity方向相似，兩者都把憑證生命週期從 Agent 業務邏輯抽離；實際支援的雲端、工具與區域則不同。
SPIFFE 身分解決了什麼
Google 為每個 Agent 指派 SPIFFE 身分與短效 X.509 憑證。呼叫 Google Cloud 時可用 mTLS；跨 Agent Gateway 的流程再搭配 DPoP，把 Token 綁定到持有者，降低 Token 被偷走後在別處重播的風險。
這使稽核紀錄能標出 Agent 本身，以及它是否代表某位使用者。企業也可用 IAM、Principal Access Boundary 與 VPC Service Controls 限縮資源範圍。這比共用服務帳號更接近AI-SPM需要的可追責資產模型。
導入前先看三個限制
Auth Manager 目前標示為 Preview，支援環境集中在 Gemini Enterprise 與 Gemini Enterprise Agent Platform Runtime。正式採用前要確認區域、SLA、稽核欄位與預覽條款，不要把文件更新解讀成所有 Google Cloud 執行環境都已全面可用。
第二，憑證安全不等於操作正當。Agent 即使合法取得某位員工的 Jira Token，也可能因提示注入刪錯專案。工具端仍要做最小 scope、交易前確認、速率限制與不可逆動作的人工核准。
第三，撤銷與離職流程要測。建立 auth provider 後，實際演練使用者撤回同意、Agent 被停用、憑證到期、工具端權限改變與事故調查，確保舊工作階段不會繼續操作。
我不建議第一天就遷移所有金鑰。先選一個低風險外部工具，確認身分、同意、續期、撤銷與稽核都能閉環，再把Agent 間協作納入。若連 Agent 所有人與用途都未登記，先解決Agent 安全的系統問題。
常見問題
Agent Identity Auth Manager 已正式上線嗎？
截至 2026 年 8 月 24 日，官方文件仍標示 Preview。正式環境要確認預覽條款、支援區域、SLA 與你的執行平台。
用了 Auth Manager 就不用 Secret Manager 嗎？
不能直接這樣推論。Auth Manager 聚焦 Agent 對外工具的 API key 與 OAuth 流程；其他應用程式祕密、資料庫憑證與既有工作負載仍可能需要原本的祕密管理方案。
SPIFFE 身分能阻止提示注入嗎？
不能。它能強化身分、憑證綁定與稽核，但提示注入仍可能誘導已授權 Agent 做錯事。工具權限、資料驗證與高風險核准仍不可少。