第一個接上 Gmail 的 agent demo 通常很好寫：把自己的 OAuth token 貼進環境變數就能跑。問題出在第二個使用者出現的那一天——每個人的 token 放哪、誰負責刷新、agent 怎麼不被授權讀到別人的信、出事時怎麼追溯是誰的意思。Firecrawl 的作者 Hiba Fathima 在 2026 年 10 月 1 日的整理中直說，這些身分 plumbing 花的時間比 agent 本身還長，而它已經長成一個獨立的產品類別（來源：Firecrawl）。
先把問題拆成四層，再挑工具
文章最有用的部分不是排名，而是把「agent 認證」拆成四個其實不同的問題：
- 入站 auth：誰可以呼叫你的 agent 或 MCP server，常見做法是 OAuth 2.1 加 PKCE 與動態 client 註冊。
- 出站委託 auth：agent 如何代表某個使用者去打 Gmail、Slack 這些第三方 API，需要 consent 流程、token vault、自動刷新和夠窄的 scope。
- agent 身分：agent 有沒有一個獨立於使用者的身分，可能是雲端 workload identity，也可能實際到只是自己的 email 地址。
- 授權與審批：細粒度的存取規則，加上對轉帳、刪資料這類高風險動作的人工批准。
作者點出的常見失敗模式值得記住：很多團隊給 MCP server 加了 OAuth 就以為安全，但 agent 打下游 API 時仍然共用一把 admin key。而且讓憑證不進入模型 context 和拿到憑證一樣重要——一次 prompt injection 能讀到 token，就能用它。這和我們之前談 agent 上線後要鎖住測試案例（參考）是同一種紀律：安全與可靠都不是 demo 階段自然長出來的。
九家平台，各有明確的適用場景
名單涵蓋 Composio、AgentMail、Auth0 for AI Agents、Arcade、Nango、WorkOS、AWS AgentCore Identity、Stytch Connected Apps 和 Keycard。對 builder 來說，比較實際的讀法是按你的缺口對號入座：
- 想最快接上使用者既有的 SaaS？Composio 提供 1,500 多個 toolkit，免費額度每月 100,000 次 tool call，OAuth consent 和 token 刷新都代管；但它的企業級控制（SSO、SCIM）只在 Enterprise 方案。
- 已經用 Auth0 或 Okta？Auth0 for AI Agents 是最短路徑，token vault、透過 CIBA 的非同步使用者批准、以及給 RAG 用的文件級權限都在同一個 tenant。
- 要自控整合邏輯？Nango 是開源、可自架的選項，覆蓋 1,000 多個 API 的預建 auth。
- 安全團隊會審你的 agent？Arcade 把授權放在 tool call 執行當下，憑證不會到達模型，並支援不可逆動作的人工批准 hook；但計費按 auth event 和 tool call 累加，話多的 agent 會很快碰到 Team 方案。
最特別的是 AgentMail：它不管理第三方 token，而是讓 agent 自己成為帳戶持有人，擁有真實的 email 地址，可以自行收驗證碼完成註冊，並透過 Sign in with AgentID 讓應用程式知道每個 agent 背後是哪個人。它回答的不是「agent 能碰什麼」，而是「agent 是誰、誰為它負責」。
一個務實的起點
如果你的 agent 只有一個使用者，這整個類別都可以先跳過。但只要產品要開給多人用，先問自己四層裡哪一層還是靠環境變數撐著——那通常就是第一個該補的洞，而不是一次導入整套平台。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。