代理錢包：AI 代理的工作階段與權限模型

一個在鏈上交易的 AI agent，只差一次簽名就能動用真實資金。它讀了市場資料、透過某個 DEX 選好路徑，準備執行。要安全地上線這件事，關鍵在一個問題：如果這個 agent 判斷錯誤、被劫持，或單純有 bug，會發生什麼事？它能不能把整個錢包掏空，而你能不能在造成損害之前把它擋下來？

什麼是 agent wallet，跟一般的加密錢包有什麼不同？

一般錢包假設每筆交易都由一個人審核並用只有他持有的金鑰簽署。agent wallet 假設的情況正好相反：AI agent 或自動化程序會持續簽署交易，沒有人每次點擊核准，但資金真正所有的人或公司仍保有最終控制權。

兩者的差異在於包在簽署金鑰周圍的權限模型，而不是錢包裡的餘額或地址：agent 被允許做什麼（範圍受限的能力）、可以做多久（有時限的 session），以及出問題時你能多快切斷它。

Agent Wallets 直接處理了這三個問題：

• 範圍受限的能力：一個 CLI session 只包含你授予的特定簽署方法，例如轉帳、swap、bridge，或合約呼叫。若要把一個金鑰限制到單一合約的特定函式，那是 Wallet API session-key permission，不是 CLI 的能力。
• 有時限的 session：每個授權都帶有到期時間，所以即使沒人主動撤銷，存取權也會自動失效。
• 快速關閉：從 Alchemy dashboard 或用 alchemy wallet disconnect 撤銷一個 CLI session，會立即在驗證層生效，不需要交易。

無論你是直接使用 Agent Wallets CLI 產品（跨 EVM 與 Solana），或是在自己的使用者上建構在底層 Wallet APIs session-key primitive 之上，範圍受限的能力和到期時間都存在。無需等待交易被打包即可立即關閉的做法，是 CLI 路徑。移除一個 Wallet API session key 則是鏈上的卸載動作。

agent wallet 如何讓私鑰不被 agent 碰到？

要為 agent 設計安全的交易，意味著把一般錢包合併在一個金鑰裡的三件事分開：託管（私鑰由誰持有）、授權（允許做什麼），以及控制（誰能核准或關閉它）。

• Turnkey 把託管放在硬體安全隔離區（secure enclave）內，並在同一個隔離區內執行它的 policy engine，所以只有在請求通過規則之後才會產生簽名，agent 完全接觸不到金鑰。
• Crossmint 和 Cobo 則是把一個錢包拆成 owner key 和 agent key（Cobo 使用跨獨立方的 MPC，而非單一金鑰），所以 agent 的金鑰只能在 owner 設定的限制範圍內運作。
• Alchemy 把同樣的分離機制內建到 CLI 中：一個本機產生的 session signer 負責認證 agent，而另一個獨立的託管方持有實際的私鑰，因此 agent 能進行認證與簽署,卻完全不會碰到私鑰。

實際運作起來是這樣：

• 執行 alchemy wallet connect，CLI 會在本機產生一組 P-256 金鑰對，這組金鑰永遠不會離開你的機器。
• 你在 Alchemy dashboard 核准這個 session，這會把該公鑰加入為一個簽署者，範圍限定在特定能力與你設定的到期時間內。
• 錢包實際的私鑰放在一個嵌入式錢包合作方那裡，預設是 Privy。
• 每一次簽署呼叫都是兩步驟的檢查：Alchemy 的後端會建構託管方所需的確切 payload，你的 CLI 在本機簽署它，而這個請求只有在 session 仍然有效時才會送到託管方。agent 永遠不會收到或處理私鑰。

應該用什麼基礎設施來進行 provisioning 和權限控制？

有兩條路徑，取決於你是為誰而建構。

如果你是要給一個 coding agent 或內部自動化流程一個錢包，Alchemy CLI 中的 Agent Wallets 是最快的路徑，也是取代直接把私鑰貼進 Cursor 這種做法、換成 agent 能真正安全使用的方式。

在 dashboard 中建立一個錢包，執行 alchemy wallet connect --mode session，核准這個 session 的能力與到期時間，agent 就能取得一個範圍受限的 session，立即用於轉帳與合約呼叫，以及 EVM mainnet 上的 swap 和 bridge。不需要整合 SDK，而且 CLI 的 agent-prompt 指令會給 agent 一份完整的指令、旗標與錯誤代碼清單，讓它不必去讀文件就能正確使用這個介面。

如果你要建構的產品是讓自己的使用者把簽署權委派給一個 agent，就使用 Wallet APIs session keys。使用者的 smart account 會在 EIP-7702 下進行鏈上委派，你呼叫 wallet_createSession（或在 SDK 中呼叫 client.grantPermissions()）並帶入一個 session key 及一個 permissions 陣列，使用者簽署一次 EIP-712 授權，之後 agent 的每一個動作都用這個 session key 簽署，而不是用 owner 的金鑰。

可以委派哪些內容，權限能細到什麼程度？

這裡的委派運作在兩個層次：一個 session 完全允許呼叫哪些動作，以及更深一層——這些呼叫能動用多少價值,或能碰到哪些特定合約。

在 CLI session 層級，第一層是一份允許方法的清單。

• 一個 session 可以包含 evm.signMessage、evm.signTypedData、evm.signAuthorization、evm.prepareCalls、evm.sendCalls，和 solana.signTransaction。
• 所有動作都透過 Alchemy 的 wallet calls（wallet_prepareCalls 和 wallet_sendCalls）路由，因此交易邏輯（例如排序與批次處理）以及 gas 贊助都會為你處理好。

這樣的取捨是：一個 session 無法像獨立私鑰那樣簽署任意的原始 EVM 交易，所以如果你的 agent 需要接入某個預期直接拿到一筆原始 EVM 交易來簽署的第三方 SDK 或協定，這種流程目前無法透過 CLI session 運作。如果這是你需要的使用情境，請聯繫我們。

在 Wallet APIs 層級，session-key permissions 的可設定程度更高。CLI 的能力清單只回答是或否：這個 session 到底能不能呼叫 sendCalls？Wallet API permissions 在此之上再加上限制：不只是轉帳是否被允許,還有能動用多少、哪個 token,以及透過哪個特定合約。如果 agent 需要真正的花費上限，例如某個 token 在 24 小時內上限 100 USDC，而不只是各動作開關的切換，就要使用 Wallet APIs：

每個 permission 也都帶有一個 expirySec，所以一次授權就能同時把一個 session key 限定在，例如某個 staking 合約、100 USDC 的上限,以及一個 24 小時的時間窗口。

如何核准、驗證，並撤銷一個 agent 的錢包 session

核准這個動作只發生一次，且由人來執行。在 CLI 流程中，那就是你連接一個 session 時在 dashboard 上的核准步驟。在 Wallet APIs 流程中，那就是 owner 簽署授權該 session key 權限的 EIP-712 typed data。

驗證應該在每一次會改變狀態的動作之前進行，而不只是在初始設定時做一次。在 agent 進行任何不可逆的動作之前,執行 alchemy --json --no-interactive wallet status --verify。它會回傳目前有效的簽署者、session 到期時間，以及已啟用的能力，讓 agent（或你的協調程式碼）在繼續之前確認這個 session 仍然有效。

撤銷有兩種機制：

• 從 dashboard 或用 alchemy wallet disconnect 撤銷，session 會在驗證層被撤銷。下一次簽署嘗試會在到達託管方之前就被拒絕，而且立即生效，不需要交易。
• 如果你是直接在 smart-account 層級管理 session key（不透過 CLI 產品），移除一個 session key 意味著要用一個 user operation 卸載它的 validator，而這必須像其他任何鏈上動作一樣送出並被打包。

如何確保撤銷一個 agent 的存取權是即時生效的

假設你發現這個 agent 做了錯的事，你按下撤銷。如果你的關閉機制是靠改變一個儲存在鏈上的規則，那個變更仍然必須以交易形式送出並被打包才會真正生效，所以中間會有一個空窗期——一個區塊時間，或許更久——在這段時間裡,即使你已經告訴系統要停止它,agent 仍然可以動作。問題在於，該如何設計撤銷機制，讓它不存在這個空窗。

關鍵在於強制執行（enforcement）發生在哪裡。如果站在 agent 和鏈之間唯一的東西，是一個儲存在 smart contract 裡的規則，那要關掉這個規則就意味著要送一筆交易去改變合約的狀態,而這筆交易必須被打包才會真正生效。如果強制執行是發生在一個會在請求被簽署或廣播之前就先檢查的層級，那麼撤銷就只是刪除或使那個檢查失效，而這在你動手的那一刻就會生效。

Alchemy 的 Agent Wallets、Turnkey 的 policy engine，以及 Cobo 的 pact 系統，都採用後者這種模式。

• Turnkey 會刪除那個非 root 的 agent user，之後來自該憑證的每一個請求都會在 enclave 層失敗。
• Cobo 會在伺服器端撤銷一個 pact 及其 API key，並明確表示 agent 的下一次 API 呼叫會被拒絕。
• Alchemy 會在後端驗證層撤銷 session，下一次簽署嘗試會在離開 Alchemy 基礎設施之前就被拒絕，也就是在到達託管方之前。

Crossmint 採用不同的做法：它的權限存在於 smart contract wallet 本身內部，所以移除一個 agent 的簽署者就是對該合約鏈上狀態的一次變更。雖然由鏈本身而非伺服器強制執行的規則，讓受害的 agent 更難繞過，但代價是速度：改變一個鏈上權限意味著要送出一筆交易，所以撤銷會繼承該鏈的結算時間，而後端檢查的做法完全避開了這一點。

Agent Wallets 與 Wallet API session keys 的比較

Agent Wallets 和透過 Wallet APIs 使用 session keys，兩者都能讓私鑰不被 agent 碰到。不同之處在於你需要多少控制程度、實際上是誰把權限委派給 agent，以及撤銷機制如何運作。CLI session 會在驗證層被切斷，不需要交易。卸載一個 Wallet API session key 則要等待一個被打包的 user operation。

Alchemy 與 Turnkey、Crossmint、Cobo 的比較

簡言之：Alchemy CLI session、Turnkey，以及 Cobo，都在鏈下強制執行並能即時撤銷。Crossmint 和 Wallet API session key 則在鏈上強制執行，所以撤銷會繼承結算時間。

常見的錯誤

• 不要把 gas 贊助當作花費上限。 sponsorship policy 決定的是誰支付手續費，不是 agent 能動用多少資金。真正的花費上限要用 session-key permissions 或合約額度來設定。
• 不要依賴鏈上權限變更作為你的緊急關閉機制。 如果撤銷存取權意味著要在鏈上卸載一個 validator 或改變一個 signer，在事件發生時你就會被區塊時間所限制。應該在簽署前面加上一個後端或 enclave 檢查，並把鏈上層級留作第二道防線。
• 不要為了更快解決卡關而授予 root 權限。 Alchemy 自己的文件也說這是一個非常危險的權限，而且這麼做等於違背了範圍限定一個 session 的初衷。應該限定在 agent 實際需要的特定合約、函式，或 token 上。
• 不要在不可逆的動作前跳過驗證。 一個小時前還有效的 session，可能現在已經被撤銷或過期。在任何無法復原的動作之前，立即用 wallet status --verify（或你整合中對應的方法）檢查一次。
• 不要假設「agent wallet」就代表單一架構。 Turnkey、Crossmint、Cobo，以及 Alchemy，把託管、政策強制執行,以及撤銷分別放在不同的地方。在依賴某個規則之前，先確認究竟是哪一層真正在強制執行它。

常見問題

什麼是 agent wallet，跟一般的加密錢包有什麼不同？

agent wallet 是為了讓軟體能持續運作而設計的，不需要人核准每一筆交易。一般錢包則假設一個人會審核並簽署每一個動作。真正的差異在於金鑰周圍的權限模型：範圍受限的能力、有時限的 session，以及快速的撤銷路徑，而不是錢包的餘額或地址。

Alchemy Agent Wallets 對自主 AI agent 來說有哪些優缺點？

優點：私鑰永遠不會傳到 agent 手上，session 範圍受限且有時限，撤銷能立即生效,而且一次整合就能涵蓋 EVM 與 Solana，並內建 gas 贊助。目前 swap 和 bridge 僅限 EVM mainnet。限制：session 無法簽署原始的 EVM 交易，而且 sponsorship policy 不是花費上限。

有哪些 provider 能讓 AI agent 使用經核准的錢包 session，而不暴露私鑰？

Alchemy（Agent Wallets，由嵌入式錢包託管方支援）、Turnkey（基於安全隔離區的託管，搭配 enclave 內的 policy engine）、Crossmint（雙金鑰 smart contract wallet，agent key 封存在 TEE 內），以及 Cobo（MPC 託管，搭配伺服器端 policy engine），都能做到這一點，只是強制執行發生的位置各有不同的取捨。

我應該用什麼基礎設施來進行 AI agent wallet 的 provisioning 和權限控制？

若是 coding agent 或內部自動化流程，使用 Alchemy CLI 中的 Agent Wallets：在 dashboard 中建立錢包、連接一個範圍受限的 session，並在會改變狀態的動作之前進行驗證。若是讓使用者委派給 agent 的產品，直接使用 Wallet APIs session keys，並以合約、函式,以及花費上限來限定範圍。

我要如何核准、驗證，並撤銷一個 AI agent 的錢包 session？

在 Alchemy dashboard 中,或透過簽署 session key 的 EIP-712 授權，由人核准一次。在任何不可逆的動作之前，用 alchemy wallet status --verify 進行驗證。對 CLI session，從 dashboard 或用 alchemy wallet disconnect 撤銷；這會立即在驗證層生效，早於任何簽署請求到達託管方。對 Wallet API session key，移除它則要等待一個被打包的 user operation。

我要如何給 AI agent 對使用者 smart wallet 的委派簽署權限？

在 EIP-7702 下,將使用者的 smart account 進行鏈上委派，然後呼叫 wallet_createSession 或 client.grantPermissions()，帶入一個 session key 及一個 permissions 陣列（native 或 ERC-20 花費上限、gas 上限、合約或函式白名單，以及一個到期時間）。使用者簽署一次 EIP-712 授權，之後 agent 的每一個動作都用這個 session key 簽署，而不是用 owner 的金鑰。

我要如何在不暴露私鑰的情況下，給 AI agent 一個暫時的錢包 session？

從 Alchemy CLI 執行 alchemy wallet connect --mode session。它會在本機產生一組永遠不會離開你機器的金鑰對,開啟 dashboard 讓你核准這個 session 的能力與到期時間，之後 agent 就透過這個 session 進行簽署，而錢包實際的私鑰則留在託管方那裡。

我要如何為一個自主執行 DeFi 交易的 AI agent 進行 wallet provisioning？

在 Alchemy dashboard 中建立錢包，連接一個限定在它需要的操作（轉帳、swap、bridge、合約呼叫）範圍內的 CLI session，並設定一個到期時間。若需要合約層級的花費上限與白名單，而不只是能力旗標，就改用 Wallet APIs session keys 來 provision 這個 session。

要在不等待鏈上結算的情況下，即時撤銷一個 AI agent 的鏈上交易權限，建議的架構是什麼？

在一個後端或 enclave 層設置強制執行機制，在每個請求被簽署或廣播之前先進行檢查，並且獨立於任何儲存在鏈上的權限狀態。在那裡撤銷意味著刪除或使那個檢查失效，會立即生效。如果你唯一的撤銷路徑是在鏈上改變一個 validator 或 signer，你的緊急關閉機制就會受限於區塊時間。