Agent 身份與授權實作課：當 Agent 開始替你登入、付錢、簽合約
今日主題：Agent 身份與授權實作課
2026-10-21 | 資料來源：Scalekit、LoginRadius、Apideck、Coinbase x402、Chainalysis、Google AP2
過去三週，我們談了 Agent 怎麼思考（從 ReAct 到 Reflexion 的自我修正迴路）、怎麼動手（tool use 與 function calling）、怎麼守住邊界（沙箱隔離、人類在迴路、提示注入防禦）。今天回頭補一塊地基：Agent 憑什麼替你做這些事？
傳統 API 世界的答案是 API key：誰持有金鑰，誰就是主人。但這個假設在 Agent 時代崩了三處：金鑰會被寫進 prompt、日誌、工具描述裡到處流傳；一支全權限的 key 等於把整間公司的鑰匙交給一個偶爾會幻覺的程式；更根本的是，key 證明的是「持有」，不是「身份」——伺服器無從知道，這次呼叫到底代表哪一位使用者、為了哪一個任務。產業正在把答案換成：身份基礎的安全（identity-based），以及可以轉交、可以縮小的授權鏈。兩條主線並行：MCP 的 OAuth 2.1 授權層，管「登入與授權」；x402 與 AP2，管「付錢」。
一、API key 為什麼不夠用
Scalekit 的工程部落格把對比寫得很直白。API key 是持有即身份（possession-based）：任何拿到 key 的程式都能假裝是你。它的毛病是結構性的：
- 靜態又太廣：沒有作用域、沒有時效，發不出一張「只準查三筆訂單、十分鐘後失效」的限時許可。
- 容易外洩：日誌、前端程式碼、錯誤訊息、prompt 上下文都可能把它帶走，而且很難輪換、很難即時撤銷。
- 沒有發現機制：Agent 第一次遇到一個陌生服務，不知道該去哪裡要授權；API key 沒有標準的「請先到這裡報到」流程。
OAuth 2.1 恰好補上這三塊：驗的是身份、發的是帶作用域的短期 token、有標準的端點發現流程。這也是 MCP 規格選它的原因。
二、MCP 的答案：OAuth 2.1 授權層
MCP 在 2025 年 3 月的規格更新中把授權標準化：走 HTTP 傳輸的遠端伺服器，授權一律走 OAuth 2.1。2025 年 6 月 18 日的修訂版更把話說死：支援授權本身是選配，但一旦支援，就必須完整實作這套流程，不準自創簡化版。本機 STDIO 傳輸則豁免，用環境變數放憑證即可——畢竟 key 不出本機。
完整流程如圖一：
1. 401 挑戰：Agent 連上 MCP server，伺服器回 HTTP 401，並在 WWW-Authenticate 標頭附上 resource_metadata 的 URL。這是啟動整套流程的鑰匙——如果伺服器對未授權請求照常回 200，client 永遠不會開始跑 OAuth，這是最常見的實作錯誤。
2. 發現授權伺服器：Agent 讀取 /.well-known/oauth-protected-resource（RFC 9728），知道該去哪一家授權伺服器報到。
3. 動態註冊：讀取授權伺服器的 metadata（RFC 8414），用動態客戶端註冊（RFC 7591，DCR）替自己領一組客戶端身份。
4. 授權碼＋PKCE：跑標準授權碼流程，使用者在授權伺服器上按同意，Agent 拿到帶 scope 的 access token。PKCE 是強制要求，因為 MCP client 大多是公開客戶端（桌面應用、助理程式），要防授權碼被中途攔截。
5. 帶 token 上工：之後每個請求都在標頭帶 bearer token；token 過期時伺服器一樣回 401（帶 error=invalid_token），client 就知道該刷新或重新授權——千萬別把「token 過期」包成工具層錯誤塞在 HTTP 200 裡面回，client 會直接卡死。
Scope 怎麼設計，LoginRadius 的指南給了實務建議：按「資源 × 動詞 × 敏感度」三維切分，只給任務需要的最小權限；token 效期壓短（例如一小時內）、支援即時撤銷、留下客戶可見的稽核日誌；企業場景再疊上 SSO（Entra ID、Okta、Google Workspace）。
三、授權可以轉交：委託鏈
想像這個場景：你的助理 Agent 叫了一個專門的訂票子 Agent 去買機票。子 Agent 憑什麼花你的錢、代表你下單？Apideck 的部落格點出這正是 MCP 沒覆蓋到的缺口：MCP 規範了 client 對 server 的授權，但沒有規範 agent 之間的授權轉交——每個 agent 各自獨立認證，沒有標準方式表達「我是被 A 派來的，而且權限比 A 更小」。
實務上的做法是授權鏈（delegation chain）：使用者授權給 Agent A（scope：可訂票、單筆上限），A 轉委託給 B 時，只能把權限往下縮（attenuation），不能放大；每一跳都留下可稽核的紀錄，出了事可以一路追回源頭。
這個思想在支付場景已經長成完整協定，就是 Google 的 AP2（Agent Payments Protocol）。AP2 用三種「授權書」（Mandate）表達委託，每一份都是密碼學簽署、防竄改、可驗證的數位物件：
- Intent Mandate：使用者簽署的條件——「幫我盯這班機，低於 300 歐元就買」。
- Cart Mandate：對具體購物車與價格的確認，鎖定品項與金額。
- Payment Mandate：向支付網路證明「這筆交易有 agent 介入」，讓銀行與收單方能正確評估風險。
AP2 支援兩種模式：即時模式（人在場，一步一簽）和委託模式（Human Not Present，人不在場，Agent 依預先簽好的條件自動執行）。2026 年 4 月，Google 已把 AP2 捐給 FIDO Alliance，走向平台中立的社群治理。
四、Agent 也要會付錢：x402
授權解決了「憑什麼」，還剩「錢怎麼付」。傳統結帳流程假設螢幕前有人：看價格頁、輸卡號、等收據。一天打上千通 API 的程式沒有介面做這些事。Coinbase 在 2025 年 5 月推出的 x402 協定，把 HTTP 規格裡從 1990 年代就閒置的 402 Payment Required 狀態碼真正用起來：
1. Agent 呼叫 API，沒帶付款資訊。
2. 伺服器回 HTTP 402，標頭裡用機器可讀的格式寫明：多少錢、什麼幣、哪條鏈、付到哪個地址。
3. Agent 用錢包簽一筆穩定幣（USDC，在 Base 鏈上）微支付，重試請求。
4. 第三方 facilitator 在鏈上驗證並結算，伺服器回傳真正的 API 回應。
整個過程不需要帳號、不需要 API key、不需要事先訂閱。Tavily 已經把即時搜尋 API 掛上 x402：每次呼叫 0.01 美元，免註冊直接用。
規模正在快速長大。Chainalysis 2026 年加密貨幣地理報告（北美章）統計：一年內 Agent 經 x402 發出超過 1.38 億筆支付，其中 87% 金額落在 0.0001～0.1 美元之間，最常見的是 1～10 美分——信用卡網路根本處理不了這種金額。最大宗用途是模型推論，其次是資訊服務（程式碼審查、金融情報、資料搜尋 API）。更有意思的是行為變化：Agent 錢包從注資到第一次花費的中位數，從 2025 年底的 73 天，降到 2026 年第三季的 18 分鐘——錢包開好就上工，兩年前那種「先儲值放著」的人味已經消失了。
AP2 和 x402 是互補的，不是競爭的：AP2 只管授權、不管錢怎麼結算；x402 只管結算、不管授權。AP2 的 Mandate 證明「使用者真的同意這筆花費」，x402 完成鏈上扣款。Google 和 Coinbase、MetaMask 合作的 A2A x402 擴充，就是把這兩層接起來的橋：一份 Mandate 在上遊證明意圖，下遊走卡片或走鏈上 USDC 都行。
五、實作起手清單
1. 遠端 MCP server 走 OAuth 2.1＋PKCE：規格已經寫死，不要自創簡化版；本機 STDIO 才用環境變數。
2. 401 要帶 resource_metadata：未授權、token 過期一律回 401，不要把授權錯誤包在 HTTP 200 的工具回應裡。
3. Scope 按最小權限設計：資源 × 動詞 × 敏感度；token 短效期、可即時撤銷、留稽核日誌。
4. 轉委託只能縮權、不能擴權：每一跳留紀錄，稽核軌跡要能一路追回使用者。
5. 要讓 Agent 花錢，先想授權再想結算：需要可稽核的意圖證明就看 AP2 Mandate；微支付場景直接掛 x402 middleware，一行程式碼就能開始收費。
結語
Agent 的能力邊界，最終是由「它能證明什麼」決定的。API key 證明持有，OAuth 證明身份與授權，Mandate 證明意圖，x402 證明付款。把這四種證明接起來，Agent 才能從 demo 走進 production：替你登入、付錢、簽合約——而且每一筆都有據可查。這也是為什麼身份與授權是 Agent 基礎設施裡最不性感、卻最不能跳過的一層。
---
資料來源
- Scalekit 工程部落格：API key vs OAuth 2.1 在 agentic workflow 的對比（https://www.scalekit.com/blog/api-stack-mcp-ai-agentic-workflows）
- LoginRadius：MCP 授權深度解析（https://www.LoginRadius.com/blog/engineering/what-is-mcp-authorization）
- Apideck：Agent Auth——OAuth 不是為此而生的（https://www.apideck.com/blog/agent-auth-oauth-ai-agents）
- eco.com：x402 協定解說（https://eco.com/support/en/articles/14839402-x402-protocol-explained?ref=blockhead.co）
- Blockhead／Chainalysis：一年 1.38 億筆 x402 支付（https://www.blockhead.co/2026/10/15/ai-agents-have-made-138-million-payments-over-x402-most-of-them-under-10-cents/）
- Tavily on x402（https://www.tavily.com/blog/tavily-on-x402）
- Zinc：AP2 解說（https://www.zinc.com/blog/what-is-ap2）
- inriver：AP2／MPP／x402 支付協定比較（https://www.inriver.com/resources/ap2-mpp-x402-payment-protocols-agent-commerce/）
沒有留言:
張貼留言