Agent 錢包：AI agent 的 session 與權限模型

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

要為 agent 錢包佈建權限控管，請給 agent 一個範圍化的 session，而不是私鑰。如果是寫程式用的 agent 或內部自動化流程，請使用 Alchemy CLI 中的 Agent Wallets：執行 alchemy wallet connect，在 dashboard 核准允許的操作與到期時間，用完後即可立即撤銷這個 session。如果是讓你自己的使用者把簽署權委派給 agent 的產品，請使用 Wallet APIs session keys，它在 EIP-7702 智慧錢包之上加入以代幣為單位的花費上限、合約白名單、gas 上限與到期時間。不論哪一種情況，agent 都永遠不會持有擁有者的金鑰。

什麼是 agent 錢包？它跟一般的加密貨幣錢包有什麼不同？

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

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

Agent Wallets 直接處理了以上每一項：

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

不論你是直接使用 Agent Wallets CLI 產品（涵蓋 EVM 與 Solana），還是在底層的 Wallet APIs session-key 原語之上為自己的使用者建置系統，範圍化能力與到期時間都存在。不需要礦工打包交易即可立即關閉，這是 CLI 的路徑；移除一把 Wallet API session key，則是一次鏈上的解除安裝。

Agent 錢包如何讓私鑰不接觸到 agent？

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

• Turnkey 把託管放在硬體安全隔離區（secure enclave）內，並在同一個隔離區裡執行它的政策引擎，所以只有當請求通過規則後才會產生簽名，agent 本身從未接觸到金鑰。
• Crossmint 與 Cobo 則把一個錢包拆成擁有者金鑰與 agent 金鑰（Cobo 用的是跨獨立各方的 MPC，而非單一金鑰），所以 agent 的金鑰只能在擁有者設定的限制內運作。
• Alchemy 把同樣的分離設計內建在 CLI 裡：本地產生的 session signer 負責驗證 agent 身分，另有獨立的 custodian 持有真正的私鑰，讓 agent 能夠驗證身分並簽署，卻永遠不會碰到私鑰本身。

實際運作起來是這樣的：

• 執行 alchemy wallet connect，CLI 會在本地產生一組 P-256 金鑰對，永遠不會離開你的機器。
• 你在 Alchemy dashboard 核准這個 session，將這把公鑰附加為一個 signer，並限定它的能力範圍與你設定的到期時間。
• 錢包真正的私鑰則存放在內嵌錢包合作夥伴那裡，預設是 Privy。
• 每一次簽署呼叫都是兩階段檢查：Alchemy 的後端建構 custodian 預期的確切 payload，你的 CLI 在本地簽署，只有在 session 仍然有效時，請求才會送達 custodian。Agent 永遠不會收到或處理私鑰。

該用什麼基礎設施來做配置與權限控管？

這裡有兩條路徑，取決於你是為誰建置。

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

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

如果你是在建置一個產品，讓你自己的使用者把簽署權委派給 agent，那就採用 Wallet APIs session keys。使用者的智慧帳戶會在鏈上依照 EIP-7702 被委派，你呼叫 wallet_createSession（或 SDK 中的 client.grantPermissions()）並帶上一把 session key 與一組 permissions 陣列，使用者簽署一次 EIP-712 授權，之後 agent 每一次操作都用這把 session key 簽署，而不是用擁有者的金鑰。

能委派什麼？權限粒度有多細？

委派在這裡分兩層運作：第一層是這個 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 需要接入某個第三方 SDK 或協議、而那個協議預期能交給它一筆原始 EVM 交易去簽署，目前這個流程在 CLI session 中是無法運作的。如果這是你需要的使用情境，請聯絡我們。

在 Wallet APIs 的層級，session-key permissions 更為可調整。CLI 的能力清單只能回答是或否：這個 session 能不能呼叫 sendCalls？Wallet API 的 permissions 在此之上再加上限制：不只是是否允許轉帳，還能限定能動用多少、哪種代幣，以及透過哪個特定合約。如果 agent 需要真正的花費上限，例如針對某個代幣在 24 小時內設定 100 USDC 的上限，而不只是開關哪些動作可被執行，就該採用 Wallet APIs：

每一項 permission 也都帶有一個 expirySec，所以一次授權就能同時把一把 session key 限定在，比方說，一個質押合約、100 USDC 的上限，以及 24 小時的時間窗口內。

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

核准只由人進行一次。在 CLI 流程中，那就是你連接 session 時在 dashboard 上的核准步驟。在 Wallet APIs 流程中，那就是擁有者簽署授權該 session key 權限的 EIP-712 型別資料。

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

撤銷有兩種機制：

• 透過 dashboard 或用 alchemy wallet disconnect，一個 session 會在驗證層被撤銷。下一次簽署嘗試會在送達 custodian 之前就被拒絕，立即生效，不需要送出交易。
• 如果你是直接在智慧帳戶層級管理 session key（不透過 CLI 產品），移除一把 session key 意味著用一個 user operation 解除安裝它的 validator，這個操作必須像其他鏈上動作一樣被送出並等待打包。

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

假設你發現這個 agent 在做錯誤的事，於是你按下撤銷。如果你的緊急開關是透過改變存放在鏈上的規則來運作，那個改變仍然必須以交易的形式送出並被打包才會真正生效，所以中間會有一段空窗期——一個區塊時間，甚至更久——在這段期間，就算你已經告訴系統要停止，agent 依然能繼續行動。問題在於如何設計撤銷機制，讓它不會有這種空窗。

關鍵在於執行（enforcement）發生在哪裡。如果 agent 與鏈之間唯一的阻擋，是一個存放在智慧合約裡的規則，那麼要關掉這條規則，就得送出一筆交易去改變合約狀態，而這筆交易必須先被打包，改變才算真正生效。如果執行是發生在一個會在請求被簽署或廣播之前就先檢查的層級，那麼撤銷就只是刪除或讓那個檢查失效，你一做完就立刻生效。

Alchemy 的 Agent Wallets、Turnkey 的政策引擎，以及 Cobo 的 pact 系統，用的都是後者這種模式。

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

Crossmint 採取了不同的做法：它的權限存放在智慧合約錢包本身裡面，所以移除一個 agent 的 signer 是對該合約鏈上狀態的一次變更。雖然由鏈本身（而非伺服器）執行規則，讓受駭的 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 keys 是在鏈上執行，所以撤銷會繼承結算時間。

常見的錯誤

• 不要把 gas 贊助當成花費上限。 贊助政策決定的是誰支付手續費，而不是 agent 能動用多少。真正的花費上限要用 session-key permissions 或合約額度來設定。
• 不要依賴鏈上權限變更作為你的緊急開關。 如果撤銷存取權意味著要在鏈上解除安裝一個 validator 或改變 signer，那在事故發生時你就會被區塊時間綁住。應該在簽署之前加上一層後端或 enclave 檢查，並把鏈上層級當作第二道防線。
• 不要為了更快解決問題而授予 root 權限。 Alchemy 自己的文件就明確說這是一個非常危險的權限，而且這樣做等於完全違背了限定 session 範圍的初衷。應該限定在 agent 實際需要的那個特定合約、函式或代幣上。
• 不要在不可逆的動作前跳過驗證。 一小時前還有效的 session，現在可能已經被撤銷或過期。在任何無法撤回的操作之前，立即用 wallet status --verify（或你的整合中對應的方法）確認一次。
• 不要假設「agent 錢包」代表單一一種架構。 Turnkey、Crossmint、Cobo 與 Alchemy 都把託管、政策執行與撤銷放在不同的地方。在你依賴某條規則上線之前，先確認實際是哪一層在執行它。

常見問題

什麼是 agent 錢包？它跟一般的加密貨幣錢包有什麼不同？

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

對自主 AI agent 來說，使用 Alchemy Agent Wallets 的優缺點是什麼？

優點：私鑰永遠不會到達 agent 手上，session 是範圍化且有時限的，撤銷是即時的，而且單一整合就能涵蓋 EVM 與 Solana，並內建 gas 贊助。Swap 與跨鏈橋目前僅支援 EVM mainnet。限制：無法透過 session 簽署原始 EVM 交易，而且贊助政策並非花費上限。

有哪些服務商能讓 AI agent 使用經核准的錢包 session、而不暴露私鑰？

Alchemy（Agent Wallets，由內嵌錢包 custodian 支援）、Turnkey（secure-enclave 託管搭配以 enclave 為基礎的政策引擎）、Crossmint（雙金鑰智慧合約錢包，agent 金鑰封存在 TEE 中）以及 Cobo（MPC 託管搭配伺服器端政策引擎），都能做到這件事，只是執行層所在的位置各有不同的取捨。

我應該用什麼基礎設施來做 AI agent 錢包的配置與權限控管？

對於寫程式用的 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 撤銷；這會立即在驗證層生效，任何簽署請求都不會送達 custodian。對於 Wallet API session key，移除它則要等待 user operation 被打包。

我該如何讓 AI agent 取得使用者智慧錢包的委派簽署權限？

依照 EIP-7702 在鏈上委派使用者的智慧帳戶，接著帶上一把 session key 與一組permissions 陣列（原生代幣或 ERC-20 的花費上限、gas 上限、合約或函式白名單，以及到期時間）呼叫 wallet_createSession 或 client.grantPermissions()。使用者簽署一次 EIP-712 授權，之後 agent 每一次操作都用這把 session key 簽署，而不是用擁有者的金鑰。

我該如何給 AI agent 一個臨時的錢包 session，又不暴露私鑰？

從 Alchemy CLI 執行 alchemy wallet connect --mode session。它會在本地產生一組永遠不會離開你機器的金鑰對，並開啟 dashboard 讓你核准這個 session 的能力範圍與到期時間，此後 agent 就透過這個 session 進行簽署，而錢包真正的私鑰則一直留在 custodian 手上。

我該如何為一個自主執行 DeFi 交易的 AI agent 配置錢包？

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

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

把執行放在後端或 enclave 層，在每一個請求被簽署或廣播之前就先檢查，與任何存放在鏈上的權限狀態分開。在那裡撤銷，意味著刪除或讓那個檢查失效，會立即生效。如果你唯一的撤銷路徑是在鏈上改變一個 validator 或 signer，那你的緊急開關就會被區塊時間所限制。