GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
讓 AI 代替使用者執行鏈上交易，是當前加密貨幣領域最熱門的趨勢。Coinbase 於 2026 年 2 月推出了 Agentic Wallets，麥肯錫預測 AI Agent 媒介的商業交易規模到 2030 年可能在全球達到 3 至 5 兆美元。正如 Coinbase CEO Brian Armstrong 所言：AI Agent 無法開設銀行帳戶，但可以擁有加密貨幣錢包。
問題在於，讓 AI 操作鏈上資產，與讓它管理行事曆或電子郵件截然不同。鏈上交易不可逆，沒有退款，沒有爭議撤銷。一個惡意簽名就能在一個區塊內清空整個錢包。沒有安全保障，任何功能都毫無意義。
BlockSec 已開源 Web3 Companion，這是一個以安全為首要考量的 Agentic Wallet。本文將深入介紹其安全設計：為何當前 Agentic Wallet 架構存在根本性缺陷，以及我們如何從架構層面將安全性內建於錢包之中。
當前 Agent 有多危險：OpenClaw 事件
當 AI Agent 沒有任何安全邊界時，會發生什麼事？2026 年初的 OpenClaw 事件給出了答案。
OpenClaw 是一個開源通用 AI Agent，在五天內累積了 10 萬顆 GitHub Star。它作為通用 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 許可證開源（目前標記為研究預覽版）。業界現在就需要一個具體的安全設計參考點。如何構建威脅模型、如何隔離私鑰、交易防禦應推進到何種程度——沒有任何團隊應該從零開始重新摸索這些問題。我們公開完整設計，讓社群能夠在此基礎上繼續構建。
