把 API key 放進環境變數，對單一內部工具或許夠用；當幾十個 Agent 代表不同員工呼叫 GitHub、Jira 與內部系統時，就很難回答「是哪個 Agent、代表誰、拿哪個權限做了什麼」。Agent Identity Auth Manager 集中管理這些對外憑證；IAM 更新紀錄已在 2026 年 8 月 22 日列出正式可用，不應再沿用較早的 Preview 描述。
它把外部工具憑證集中到受管保管庫，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需要的可追責資產模型。
用「查自己的工單」走完一次授權
以假設的企業內部情境來看，這並非 Google 導入案例：員工請代理整理自己在 Jira 負責的待辦事項，只需讀取工單，不允許關閉工單或修改專案。這時使用者委派授權較符合需求，因為要查的是「這位員工有權看的資料」，應沿用他的權限邊界，避免共用管理員帳號。
先由開發者或平台管理員在外部工具建立適當的 OAuth 應用程式，確認回呼網址與最小讀取範圍，再依三方 OAuth 文件建立對應的認證提供者。這部分是服務設定；員工不應收到一封要求把公司金鑰貼進聊天的郵件。
員工第一次使用時，依工具的同意流程登入並核准所需範圍。接著代理在呼叫工具前取得適合這位使用者的憑證，把它附在 API 請求，工具再檢查憑證與原有權限。同意畫面授權成功，不代表來源系統原本禁止的工單突然可讀；如果來源權限不足，應回報受限，而不是改用另一位同事的憑證補查。
假設查到三筆到期工單，合格輸出應能讓員工回到來源核對工單編號、負責人與期限。若只回一句「你的工作都很急」，認證雖成功，任務仍沒有完成。反過來，代理整理得再好，也不能因為文字提到「建議關閉」就呼叫關閉工單的動作；讀取需求與寫入授權要分開。
驗收時最好準備兩個權限不同的測試使用者。相同提示應得到各自可讀的資料，而不是兩個人都看到第一位登入者的內容。這是應用程式需要證明的使用者隔離，不是安裝 Auth Manager 後就能略過的檢查。
撤銷授權後，還要查什麼？
把測試使用者的同意撤回，再用原有工作階段重新發出請求；同時測試新登入和排程中的待執行工作。記錄哪一次開始遭拒、是否要求重新授權，以及是否有錯誤重試。不要自行假定所有已簽發 Token、快取及排程會在同一瞬間失效，各層的生命週期要分別核對。
撤權也不會自動刪掉先前已產生的摘要。若摘要存在聊天紀錄、資料庫或共享報表，應另外套用公司的保存與刪除規則；「以後不能再抓資料」與「過去抓到的內容已清除」是不同結果。
遇到錯誤時，先定位失敗發生在取憑證、員工同意，還是外部工具拒絕請求。Google 排錯文件提供對應的認證問題檢查方向。回報可以附上時間、代理身分、提供者資源與已遮蔽的錯誤訊息，但不要留下 access token、refresh token 或完整敏感工單內容。
導入前先看三個限制
第一，正式可用不等於每個環境都能直接套用。架構文件描述的是代理執行環境、ADK、憑證保管庫與外部端點之間的流程。正式採用前仍要核對支援區域、使用的執行平台與 IAM 設定，不能把某個 API 已正式可用，解讀成所有工具均已自動整合。
第二，憑證安全不等於操作正當。Agent 即使合法取得某位員工的 Jira Token，也可能因提示注入刪錯專案。工具端仍要做最小 scope、交易前確認、速率限制與不可逆動作的人工核准。
第三，撤銷與離職流程要測。建立 auth provider 後，實際演練使用者撤回同意、Agent 被停用、憑證到期、工具端權限改變與事故調查，確保舊工作階段不會繼續操作。
我不建議第一天就遷移所有金鑰。先選一個低風險外部工具，確認身分、同意、續期、撤銷與稽核都能閉環，再把Agent 間協作納入。若連 Agent 所有人與用途都未登記，先解決Agent 安全的系統問題。
常見問題
Agent Identity Auth Manager 已正式上線嗎？
是。Google 的 IAM 更新紀錄列出，Auth Manager 與 Agent Identity APIs 已於 2026 年 8 月 22 日正式可用。支援區域、工具端權限與部署設定仍要核對，GA 不代表取消這些條件。
用了 Auth Manager 就不用 Secret Manager 嗎？
不能直接這樣推論。Auth Manager 聚焦 Agent 對外工具的 API key 與 OAuth 流程；其他應用程式祕密、資料庫憑證與既有工作負載仍可能需要原本的祕密管理方案。
SPIFFE 身分能阻止提示注入嗎？
不能。它能強化身分、憑證綁定與稽核，但提示注入仍可能誘導已授權 Agent 做錯事。工具權限、資料驗證與高風險核准仍不可少。