English version: The Authorization Gap: AI Agents Need More Than a Wallet
過去一年，幾乎每一場 Agentic Payment 的討論，最後都會繞回同一個問題：
AI Agent 到底要不要自己有錢包？
但我越想越覺得，這其實是錯的問題。
主流辯論的焦點都在錢包：要不要自帶錢包？要不要掌控私鑰？結算走鏈上還是走卡片軌道？這些都是真實的技術問題，但都還停在表面。
底下那件真正在發生的事，目前還沒人認真討論。
過去 60 年，所有支付系統都建立在同一個前提上：
想買東西的人，跟真正執行交易的人，是同一個主體。
你的信用卡是你的。
你的密碼是你的。
按下付款確認的手指也是你的。
Visa、Mastercard、PayPal、SWIFT，整個現代支付基礎設施，每一層都建立在這個假設上。
AI Agent 第一次打破了它。
當你授權一個 Shopping Agent 幫你訂飯店、買軟體、安排採購：
你是授權者。
Agent 是執行者。
這兩件事第一次被拆開了。一旦授權者與執行者不再是同一個人，過去半個世紀所有支付授權邏輯的底層假設，就開始失效了。
所以真正的問題不是 Agent 有沒有錢包。
而是：誰授權它？授權到哪裡？條件變了怎麼辦？出了事誰負責？
Wallet 解決的是 custody。
Mandate 解決的才是 delegation。
這不是錢包問題。
這是授權架構問題。
三種模式，三種不同的缺口
目前市場上，Agent Payment 大致正在往三個方向發展。
每一條都能解決部分問題。
但每一條，都留下了不同的缺口。
1. 自帶錢包模式（Agent-Owned Wallet）
以 Coinbase Agent Kit 為代表。
每個 Agent 擁有自己的鏈上地址，私鑰封存於 TEE（Trusted Execution Environment）安全執行環境，具備完全自主的簽署能力。
對於 DeFi 套利、做市、鏈上高頻交易這種場景，這是合理甚至必要的設計。因為在這些情境下，等人批准，本身就是不可接受的延遲。
問題不在架構，在規模。
500 個 Agent 意味著 500 把私鑰。金鑰一多，管理就會失控。輪換、撤銷、事故應變、風險隔離，每一件事都會變成營運與管理的負擔。
這種模式適合高自主、高頻交易的 Agent。但不太適合大部分企業流程型的 Agent。
2. 共享錢包模式（Shared Treasury Model）
這是目前最普遍的做法。
開發者維護一個共享資金池，Agent 透過 API Key、OAuth Token 或平台帳號取得認證，本身不持有任何金鑰。
對於 Coding Agent、Research Agent，或者所有支出只涉及 API 費用的場景，這個模式其實已經很好用。簡單、可控、容易管理。
但問題是：授權粒度太粗。
API Key 很適合回答：
「這是不是合法服務？」
「有沒有權限呼叫 API？」
但它回答不了另一個更重要的問題：「這個 Agent 現在到底被授權做到什麼程度？」或者更專業一點的問法：「這個 Agent 的授權邊界在哪？」
例如:
每天最多能花多少？
只能向哪些供應商付款？
授權什麼時候到期？
超過某個金額是不是要人工批准？
部門預算快超支時要不要自動停下來？
「你是誰」（Authentication）和「你被允許做什麼」（Authorization），其實是兩套完全不同的邏輯。但今天很多 Agent 基礎設施，還是把這兩件事混在一起。
3. Mandate 委託模式（Delegated Authorization）
目前我認為架構上最值得注意的方向，是 Google 提出的 AP2（Agent Payment Protocol）。
AP2 的重點不是給 Agent 錢包，也不是發 API Key，而是給它一份可驗證的授權文件：Mandate。
Mandate 本質上是一份帶有密碼學簽章的授權憑證，明確記載：
誰授權了這個 Agent（Principal）
它被允許執行哪類交易（Scope）
約束條件是什麼（Constraints：金額上限、白名單商家、有效期）
每一筆操作的密碼學可驗證紀錄（Auditability）
簡單說：Mandate = 誰授權 + 能做什麼 + 限制條件 + 可驗證紀錄
Agent 帶著 Mandate 行動，就像帶著一份可驗證的委託書。交易對手不需要信任任何中間平台說「這個 Agent 是被允許的」，可以自己驗證。
方向是對的。
但 AP2 解決的主要還是「授權格式」與「協議結構」問題。它定義了 Mandate 應該長什麼樣子。真正更困難的部分，其實在後面：
Mandate 要怎麼大規模發行？
授權撤銷如何即時生效？
多個平台如何共用同一份授權狀態？
Constraint 如何跨系統執行？
稽核紀錄如何讓第三方獨立驗證？
格式已經有了。但真正能在企業裡大規模運作的執行層，還沒出現。
KYA：AI 時代的新授權問題
目前對這個問題最有用的分析框架之一，來自 a16z crypto 提出的 KYA — Know Your Agent，可以理解為 AI 時代的 KYC。
KYC 問的是「這個人是誰」。
KYA 問的是四件事：
這個 Agent 是誰，它由誰建立？
是誰授權了它，哪個人類主體委託了它的行動？
它被授權做什麼，金額上限、授權範圍、允許的交易對手是哪些？
這份授權現在還有效嗎，有沒有被撤銷，有沒有被超出？
這裡真正重要的轉變是：未來的支付與商務系統，不再只需要驗證「身份」。
而是需要持續驗證「授權狀態」。
Skyfire 的 KYAPay 是目前落地最具體的 KYA 實作之一。它設計了三種 JWT Token：
KYA Token：記錄 Agent 身份與背後的人類擁有者
PAY Token：記錄這筆交易被授權了什麼
KYAPay Token：兩者合一，讓商家一次驗證就能確認身份與支付授權
所有 Token 以 ES256 橢圓曲線數位簽章簽署，含有效期、受眾綁定、唯一 ID。Skyfire 透過公開的 JWKS endpoint 發佈驗證公鑰，商家、支付服務商或稽核師都可以自己抓公鑰、本地驗證 Token 的真偽，不需要回頭打 Skyfire 的 API。
但這還不夠。
知道 Agent 是誰，和知道它被允許做什麼，是兩件事。後者需要 AP2 Mandate 這樣的授權範圍層來補上。KYAPay 與 AP2 目前是各自獨立的提案，並沒有整合實作。現有方案解決了部分問題，但完整的信任鏈還沒有人真正建起來。
我對這個方向的評估是：架構思路是對的，但它解決的是「在某個時間點發行一份格式良好的授權憑證」。
但真正困難的地方，其實是「授權生命週期管理」。因為 Agent 不是簽完一次就結束。它會一直跑。
今天的市場條件、明天的預算狀況、下週公司政策的調整，都會影響一個 Agent「現在還能不能做這件事」。
真正需要的，不是一張靜態的授權書。
而是一套能夠隨著環境變化即時更新的授權系統：
條件變了，授權跟著調整。
超出範圍了，立刻停下來。
情境改變了，人可以隨時介入修改規則。
這個動態調整的能力，目前沒有任何一個方案真正做到好。
缺的那一層：Mandate Engine
這也是我認為整個 Agentic Payment 生態裡，現在最關鍵、但仍然空缺的一層。
MoonPay 推動的 Open Wallet Standard（OWS），其實已經非常接近正確方向。它的 Policy Engine 處理了基本需求：單個 Agent 的每日消費上限、地址白名單、時間綁定的授權窗口、簽署前檢查。
OWS 的設計者只定義大框架，而在 Policies 子規格裡預留了一個擴展介面：Optional Custom Executables。
意思其實很明顯。
真正的企業授權邏輯，不可能只靠幾個靜態規則解決。因為真實世界的企業授權，根本不是「每日限額」這麼簡單。
真實的案例可能是：
採購 Agent 提交超過 $500 的訂單時，不應該直接失敗，而是停下來等主管批准。
DeFi 套利 Agent 不該只會「允許／拒絕」，它應該知道 gas fee 太高時先等待、條件到了再執行。
同一個部門可能同時有十幾個 Agent 在跑，每一個 Agent 只看得到自己這筆交易，不知道其他 Agent 今天已經花了多少。沒有共用的預算上限，等月底帳單出來才發現超支，已經太晚了。
所有授權與執行歷史，最後都需要能被外部稽核師獨立驗證，而不依賴平台運營者的內部記錄。
這些不是邊緣需求。這就是企業世界真正的運作方式。
這種「授權生命週期管理」的東西，在別的領域早就成熟了。
HashiCorp Vault 管的是密碼學金鑰和 API 憑證：誰能存取、什麼條件、何時撤銷；
Okta 管的是企業員工身份：誰能登入哪些系統、權限什麼時候到期。
兩個都解決了同一類問題：誰可以做什麼、什麼時候、規則變了怎麼辦。
現在我們需要的是同等級的工具，只是這次管的不是人，是 Agent。
AP2 的 Mandate 格式，最終需要一個 Engine。
一個真正的 Mandate Engine，需要做到什麼?
我認為至少有四件事。
1. 可驗證的授權執行
授權規則不能只存在平台內部。
第三方必須能獨立驗證：這個 Agent 是否真的依照授權範圍執行。
不能只靠平台自己說「我們有做到」。
2. 即時撤銷（Real-Time Revocation）
授權一旦被取消，所有正在執行的 Agent 都必須立刻停止。
不能依賴「下一次同步再更新」。
因為在 Agent 世界裡，幾分鐘的延遲，就可能代表真實金錢風險。
3. 可稽核的歷史紀錄
真正麻煩的時刻，是合規部門開始進場的時候。
銀行、企業法務、監管機構，最後一定會問同一件事：
「請證明過去六個月每一筆交易，都在授權範圍內。」
未來真正重要的，不只是支付成功。而是整條授權鏈能不能被驗證。
4. 協議中立（Protocol Neutral）
這層系統不能只綁定單一平台。
AP2、OWS、x402、卡片網路、銀行軌道，甚至未來新的 Agent 協議，都應該能接進同一套授權執行層。
否則每個平台最後都會變成自己的封閉授權孤島。
Stripe 的答案，以及它的邊界
Stripe Sessions 2026 剛剛落幕。它給出了目前最清晰的封閉式商業平台解方。
Stripe 這次在 Agentic Payment 推出三件事：
Agentic Network Tokens（與 Visa、Mastercard 合作的 Agent 專用數位憑證）
Issuing for Agents（程式化為 Agent 發行單次性虛擬卡）
Agent Guardrails（指定 Agent 身份、設定可執行範圍、設置人工確認關卡）
邏輯非常完整。
Stripe 的優勢也很真實。支付世界最困難的事情之一，本來就是整合。Visa、Mastercard、Klarna、Affirm，每一套都有自己的規格與授權流程。過去要分別整合，現在接 Stripe 一次，全部搞定。
這個價值是具體的，不是行銷說辭。
但它也代表另一種取捨。
Stripe 的答案，本質上是：「把 Agent 的授權問題交給我處理。」
在 Stripe 生態裡，這件事成立。
但 Stripe 的 Guardrails 與授權邏輯，主要存在 Stripe 的盒子內。你可以設定規則，但無法獨立驗證規則有沒有被確實執行。
更重要的是：一旦你的 Agent 跑到 Stripe 不覆蓋的場景、協議、或平台，你的約束設定就不存在了。
這不是在批評 Stripe 的設計選擇。
這是任何封閉平台在授權基礎設施上的結構性限制。提供可以獨立稽核的密碼學審計，在架構上意味著把內部控制邏輯暴露給外部驗證，但這樣做，平台就失去了它最核心的護城河。
Stripe 的答案是「信任我來管理你 Agent 的授權」。
在 Stripe 的覆蓋範圍內，這個答案有效。
超出它的範圍，問題還在。
為什麼這個缺口最終必須被填上
真正麻煩的時刻，不是 demo。
是 AI Agent 真的開始進入企業財務流程的時候。
那時候，合規、法務、稽核、銀行、監管機構都會開始進場。他們問的問題不會是「這個 Agent 用哪個錢包」。
他們真正會問的是：
誰授權它？
它的授權範圍是什麼？
有沒有超出授權？
系統怎麼偵測和阻止違規行為？
出事的時候誰負責？
今天，大部分系統其實都還沒有完整答案。
封閉平台提供的是「平台信任」。
協議標準提供的是「資料格式」。
但真正跨平台、可驗證、可撤銷、可稽核的「授權執行層」，現在還是空白。
法規壓力是這個問題最終被解決的強制力。不是因為有人覺得「應該做」，而是因為當 AI Agent 開始在企業財務流程中承擔真實責任，合規要求會逼著企業重新檢視「信任某家平台的黑盒子」這個答案。
這一層最終會出現。
問題是它以什麼形態出現：
各大平台自己的封閉授權系統，彼此不互通，每個都只在自己的邊界內有效；
還是一層開放的、密碼學可稽核的 Mandate Engine，讓整個生態系的信任不依賴於信任任何單一的運營者。
我的判斷是：監管壓力和企業採購決策會最終推向後者。
封閉版本已經有了。Stripe 給出了它的答案。
真正還沒出現的，是開放、可稽核、跨平台的那一版。
所以接下來要問的是：
開放版的 Mandate Engine 誰會先做出來？
開放路線跟封閉平台，最後是並存還是取代？
如果你正在 Agentic Payment 領域建設，或者正在研究這層基礎設施，我很想聽聽你的看法。