GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
讓 AI 代替使用者執行鏈上交易，是目前加密貨幣領域最火熱的趨勢。Coinbase 於 2026 年 2 月推出了 Agentic Wallets，麥肯錫估計 AI Agent 媒介的商業交易規模到 2030 年可能在全球達到 3 至 5 兆美元。正如 Coinbase 執行長 Brian Armstrong 所言：AI Agent 無法開設銀行帳戶，但它們可以擁有加密錢包。
問題在於，讓 AI 操作鏈上資產，與讓它管理行事曆或電子郵件截然不同。鏈上交易是不可逆的，沒有退款，沒有爭議撤銷。一次惡意簽名就能在一個區塊內清空整個錢包。沒有安全性，任何功能都毫無意義。
BlockSec 已開源 Web3 Companion，這是一個以安全為核心的 Agentic Wallet。本文將深入介紹其安全設計：為何當前 Agentic Wallet 的架構從根本上存在缺陷，以及我們如何從架構層面將安全性融入錢包設計。
當前 Agent 有多危險：OpenClaw 事件
當 AI Agent 沒有任何安全邊界時，會發生什麼？2026 年初的 OpenClaw 事件給出了答案。
OpenClaw 是一個開源的通用 AI Agent，在五天內獲得了 10 萬個 GitHub 星標。作為通用 Agent 它運作良好，但一旦涉及 Web3 交易，每一個安全漏洞都暴露無遺。
私鑰以明文形式存放在 Agent 可讀取的本地檔案中。只需一封提示注入郵件，就足以竊取它們。
簽名沒有隔離。抓取不受信任網頁的進程與簽署交易的進程相同，因此一個 RCE 漏洞就能讓攻擊者透過惡意網頁完全控制 Agent 及其私鑰。
Skills 市集是另一個弱點。研究人員發現 7.1% 的 ClawHub Skills 洩露了憑證，而且部分根本就是設計用來清空加密錢包的。
隨機數生成也存在缺陷。OpenClaw 在安全關鍵路徑上使用 math/rand——一個以系統時鐘作為種子的偽隨機數生成器。研究人員證明，只需兩個連續的 token 值，就足以重建內部狀態，並預測所有未來的 token 和挑戰值。在某些程式碼路徑中，這甚至延伸到了錢包私鑰的恢復。
最糟糕的是，完全沒有策略層。提示注入和資金轉移之間毫無攔截機制，零攔截。
結論是：通用 AI Agent 架構不適合用於 Web3 交易。
當前 AI Agent 架構的根本缺陷
這個問題不只存在於 OpenClaw。換個模型或撰寫更嚴格的提示詞都無法解決問題。當前 AI Agent 架構存在固有的安全缺陷：LLM 本身就是一個永久暴露的攻擊面。
根本原因在於：LLM 無法區分指令與資料。系統提示、使用者訊息、網頁內容，甚至 token 的名稱，全都以相同的 token 串流形式輸入。模型沒有可靠的機制來區分「執行這個」與「只是讀取這個」。由此產生三個後果。
第一，提示注入在模型層面是無解的。攻擊者可以將指令隱藏在 Agent 讀取的任何內容中：電子郵件、合約註解、網頁、token 名稱。如果 Agent 能簽署交易，一次成功的注入就能將惡作劇變成盜竊。
第二，Agent 自身基於 Skills 的安全審查可被顛覆。LLM 判斷交易安全性完全依賴上下文。只要污染上下文，判決結果就會逆轉，惡意簽名就能順利通過。
第三，Agent 全天候運行，持續接收不受信任的輸入，並能自主執行交易。攻擊窗口從不關閉，一次入侵就可能意味著立即損失資金。
安全社群普遍認為：在提示注入無藥可治的世界裡，讓 LLM 直接存取私鑰，無異於將使用者資產放在一個隨時可能被攻陷的元件中。由於模型層無法加固，風險必須在架構層加以控制。即使模型被完全攻陷，也不應該能夠轉移使用者資金。
Web3 Companion 的安全架構正是基於這一理念構建的。
威脅模型：Agent 是不受信任的
Web3 Companion 的威脅模型可以用一句話概括：Agent 本身是不受信任的。整個架構假設 Agent 隨時可能被攻陷。
我們不依賴將 Agent 訓練得足夠強大以識別每一種攻擊。如上所述，模型層面的防禦是行不通的。今天訓練它識別摩斯電碼注入，明天攻擊者就會改用 Base64、圖片中的隱寫文字或看似無害的 PDF。因此，我們翻轉了假設前提：Agent 位於威脅模型之內，系統的其餘部分被設計用來控制它。即使攻擊者完全控制了 Agent，使用者資產依然安全。一句話定位：The Secure Agentic Wallet——一個預設將自身 Agent 視為不受信任，且無論如何都保持安全的錢包。
基於此威脅模型，我們推導出五條設計原則。
原則一：Agent 絕對不能接觸私鑰。 私鑰是控制鏈上資產的唯一憑證。如果 Agent 能夠讀取私鑰，一旦被攻陷就意味著私鑰洩露。私鑰必須存放在 Agent 在架構上無法觸及的地方。
原則二：準備不等於授權。 構建交易與批准交易是兩個獨立的行為。Agent 可以幫助使用者理解鏈上狀態並組裝意圖，但簽名決策屬於 Agent 無法存取的獨立後端模組。
原則三：審查是偵測，不是執行。 交易模擬、calldata 分析和地址標記能捕捉常見攻擊模式，幫助使用者理解風險，但它們不是最終裁決。模擬可能失敗，標記可能缺失，而 LLM 自身的分析也容易受到提示注入的影響。
原則四：硬性策略是最後防線。 假設 Agent 被誘騙發起一筆 10 萬美元的轉帳，而安全審查也被操控批准了。以程式碼強制執行的每日限額 1,000 美元仍然會阻止它。Agent 沒有權限更改這些限制。
原則五：無證據，不執行。 掃描失敗不等於通過。資料缺失不等於「安全」。當安全證據缺失、矛盾、過期或不足時，系統會暫停並等待使用者的明確確認。
這五條原則透過兩個安全模組實現：私鑰安全和交易安全。
私鑰隔離：Agent 在架構上無法觸及
第一個問題很簡單。我們希望有一個能準備鏈上交易的助手，但賦予它簽名能力，就等於交出了轉移真實資金的權力。2025 年和 2026 年幾乎所有的 Web3 Agent 安全事件都遵循相同的套路：私鑰存在於 Agent 進程中，攻擊者找到了提取它們的方法。
因此，我們重新定義了問題：如果 Agent 從根本上就無法簽名，又會如何？不是「被告知不能」，而是在架構上就無法做到。軟體層面的訪問控制永遠可以被繞過，我們需要更強固的保障。
Web3 Companion 強制執行進程級隔離。只有一個元件可以接觸私鑰：安全簽名模組（SSM），這是一個獨立的 Go 進程。Agent 的進程記憶體、環境變數和檔案系統中不存放任何私鑰材料。Agent 所能看到的只是一個交易意圖 ID。它可以請求 SSM 對該意圖進行簽名，但永遠無法看到背後的私鑰。
在私鑰儲存方面，我們評估了三種方案。明文存放於磁碟：一次磁碟讀取即可暴露私鑰，被否決。密碼衍生加密：每次重啟都需要重新輸入密碼，對長期運行的 Docker 服務來說不切實際，被否決。我們選擇信封加密：每個錢包私鑰用其專屬的資料密鑰加密，而該資料密鑰再由主密鑰（AWS KMS 或本地 AES-256）包裹。即使加密檔案被整體洩露，沒有主密鑰也毫無用處。私鑰只在 SSM 記憶體中短暫以明文形式存在，簽名完成後立即清零。
每個簽名請求都走相同的流程，沒有快捷通道，也沒有捷徑。一筆交易按順序經過七個步驟：委託檢查、模擬、安全檢查、Agent 安全審查、策略評估、Passkey 審批，最後才是 SSM 簽名。完成一個步驟永遠不會跳過下一個步驟。
有一個底層細節值得一提：系統中的每一個隨機位元組（私鑰生成、AES-GCM nonce、認證 token、WebAuthn 挑戰）都來自 crypto/rand——作業系統的加密隨機源。math/rand 在所有安全關鍵程式碼中被禁止使用，並由測試和 CI 強制執行。
交易安全：四層縱深防禦
私鑰隔離解決了私鑰安全問題，但交易層面的風險依然存在。被攻陷的 Agent 可以組裝出看起來完全合法的交易意圖，以欺騙使用者或繞過自動簽名策略。提示注入不需要私鑰，它只需要讓系統透過正常流程簽署一筆惡意交易。
核心問題是：當準備交易的 Agent 本身可能已被攻陷時，如何識別惡意交易？
沒有任何單一的防禦層能獨立支撐。僅靠模擬？模擬會失敗、RPC 會中斷、新型攻擊超出已知模式。僅靠基於 LLM 的審查？攻陷 Agent 的同一注入也會攻陷審查者，因為兩者都運行在 LLM 上。僅靠固定的硬性限制？合法使用者會碰壁；每次交換都限制在 100 美元根本無法使用。
我們將四層全部疊加在一起。每一層都假設它之前的所有層已經失效。
第一層：交易模擬。 在簽名前，系統模擬執行：calldata 解碼、回退預測、欄位格式檢查。模擬能發現明顯問題，但存在盲點。新的攻擊技術和 RPC 中斷都可能使其失效。
第二層：交易對手評估。 一系列靜態檢查針對交易對手：收款方/金額匹配、無限授權偵測、銷毀地址偵測、非預期的委託呼叫。地址風險評分透過 BlockSec 的 x402 合規服務運行，Agent 透過 x402 微支付查詢標記和風險評分，無需 API 金鑰或訂閱。第一層和第二層合力捕捉大多數常見問題，但兩者都可以被繞過。它們的職責被刻意限定為偵測和說明，而非最終決策。
第三層：硬性策略執行。 以 Go 語言純程式碼強制執行。LLM 不參與其中，Agent 也無法修改規則。單筆交易上限、每日預算、收款方白名單、自動簽名閾值：一筆 5,000 美元的轉帳若超過每筆 100 美元的限制，當場被拒絕。修改策略本身需要 Passkey。原因是：如果 Agent 可以編輯策略，一次注入就會先提高上限，然後清空錢包。自動簽名預設關閉；每筆交易都需要手動批准，直到使用者明確選擇啟用。
這意味著，即使所有偵測層都被繞過，一個完全被攻陷的 Agent 簽署了惡意交易，實際損失也受到策略的限制。如果使用者將每日自動簽名閾值設為 500 美元，最壞情況下的損失是 500 美元，而不是整個錢包。策略層將一次攻陷事件從災難性損失變成有限損失。
第四層：使用者確認（Passkey）。 當策略要求手動審批時，系統需要 WebAuthn 驗證（指紋或人臉）。任何純軟體漏洞都無法偽造此驗證。
四層防禦基於相互不信任的原則運作。每一層都假設它之前的所有層已經失效。完美的模擬不會放寬策略要求。策略配置錯誤不會跳過 Passkey。每一層都獨立成立。
有一個容易被忽視的細節：裁決重用。一種已知的 DeFi 攻擊技術是將舊的安全裁決重放到修改後的交易上。Web3 Companion 將每次寫入操作綁定到具有可審計狀態轉換的唯一交易意圖。一個安全裁決只適用於它所審查的確切意圖。如果 Agent 重新構建了一筆交易，即使只是更改了金額或收款方，系統也會將其視為全新的意圖並重新執行所有檢查。
四層防禦對應三個獨立的信任邊界：私鑰、策略和 Passkey。任何單一邊界被突破，其餘兩個仍然屹立：
| 被突破的邊界 | 剩餘的保護 |
|---|---|
| Agent（提示注入、RCE） | 無私鑰 = 無法簽名；策略阻止超限操作；Passkey 阻止未批准的操作 |
| 安全審查（裁決被污染） | 策略仍然執行限制；需要手動批准的操作仍需 Passkey |
| 策略（使用者配置錯誤） | 需要手動批准的操作仍需生物特徵驗證 |
| 除 Passkey 以外的一切 | 憑證與硬體綁定；攻擊者需要使用者親身在場 |
安全設計：開源背後的理念
BlockSec 從一開始就專注於鏈上安全。我們保護了數十億美元的鏈上資產，並一再見證同一個教訓：不從架構層面融入的安全性，永遠是亡羊補牢。
AI Agent 正在成為鏈上交易的新入口。這個領域發展迅速，但安全標準幾乎不存在。大多數團隊專注於他們的 Agent 能做什麼，很少有人認真思考：如果這個 Agent 被攻陷，架構能否限制爆炸半徑？
Web3 Companion 是 BlockSec 將多年鏈上安全工作成果注入 Agentic Wallet 架構的嘗試。程式碼以 MIT 授權完全開放（目前標記為研究預覽版）。業界現在就需要一個具體的安全設計參考點。如何構建威脅模型、如何隔離私鑰、交易防禦應推進到何種程度：沒有任何團隊應該從零開始重新摸索這些問題。我們公開完整設計，讓社群能夠在此基礎上繼續建設。
