慢霧：把錢交給「龍蝦」等AI Agent真的安全嗎？
一、背景
隨著大模型技術的快速發展，AI Agent 正在從簡單的智能助手逐漸演變為能夠自主執行任務的自動化系統。
在 Web3 生態中，這一變化表現得尤為明顯。越來越多的用戶開始嘗試讓 AI Agent 參與行情分析、策略生成以及自動化交易，讓「7×24 小時自動運行的交易助手」從概念逐漸走向現實。隨著 Binance 與 OKX 推出了多個 AI Skills、Bitget 推出了 Skills 資源站 Agent Hub 和免安裝的龍蝦 GetClaw，Agent 可以直接接入交易平臺 API、鏈上數據以及市場分析工具，從而在一定程度上承擔原本需要人工完成的交易決策與執行工作。
與傳統的自動化腳本相比，AI Agent 具備更強的自主決策能力和更復雜的系統交互能力。它們可以接入行情數據、調用交易 API、管理賬戶資產，甚至通過插件或 Skill 擴展功能生態。這種能力的提升，極大降低了自動化交易的使用門檻，也讓更多普通用戶開始接觸和使用自動化交易工具。
然而，能力的擴展也意味著攻擊面的擴大。
在傳統交易場景中，安全風險通常集中在賬戶憑證、API Key 洩露或釣魚攻擊等問題上。而在 AI Agent 架構中，新的風險正在出現。例如，提示詞注入 (Prompt Injection) 可能影響 Agent 的決策邏輯，惡意插件或 Skill 可能成為新的供應鏈攻擊入口，運行環境配置不當也可能導致敏感數據或 API 權限被濫用。一旦這些問題與自動化交易系統結合，潛在影響可能不僅限於信息洩露，還可能直接造成真實資產損失。
與此同時，隨著越來越多用戶開始將 AI Agent 接入交易賬戶，攻擊者也在快速適應這一變化。針對 Agent 用戶的新型詐騙模式、惡意插件投毒以及 API Key 濫用等問題，正在逐漸成為新的安全威脅。在 Web3 場景中，資產操作往往具有高價值與不可逆性，一旦自動化系統被濫用或誤導，風險影響也可能被進一步放大。
二、AI Agent 的真實安全威脅
1. 輸入操控與提示詞注入攻擊
在 AI Agent 架構中，用戶輸入和外部數據通常會被直接納入模型上下文，這使得提示詞注入 (Prompt Injection) 成為一種重要攻擊方式。攻擊者可以通過構造特定指令，誘導 Agent 執行原本不應觸發的操作。例如，在某些案例中，僅通過聊天指令即可誘導 Agent 生成並執行高危系統命令。
更復雜的攻擊方式是間接注入，即攻擊者將惡意指令隱藏在網頁內容、文檔說明或代碼註釋中。當 Agent 在執行任務過程中讀取這些內容時，可能會誤將其視為合法指令。例如，在插件文檔、README 文件或 Markdown 文件中嵌入惡意命令，就可能導致 Agent 在初始化環境或安裝依賴時執行攻擊代碼。
這種攻擊模式的特點在於，它往往不依賴傳統漏洞，而是利用模型對上下文信息的信任機制來影響其行為邏輯。
2. Skills / 插件生態的供應鏈投毒
在當前的 AI Agent 生態中，插件與技能系統 (Skills / MCP / Tools) 是擴展 Agent 能力的重要方式。然而，這類插件生態也正在成為新的供應鏈攻擊入口。
SlowMist 在對 OpenClaw 官方插件中心 ClawHub 的監測中發現，隨著開發者數量的增長，一些惡意 Skill 已開始混入其中。SlowMist 對超過 400 個惡意 Skill 的 IOC 進行歸併分析後發現，大量樣本指向少量固定域名或同一 IP 下的多個隨機路徑，呈現出明顯的資源複用特徵，這更像是團伙化、批量化的攻擊行為。
在 OpenClaw 的 Skill 體系中，核心文件通常為 SKILL.md。
與傳統代碼不同，這類 Markdown 文件往往承擔「安裝說明」和「初始化入口」的角色，但在 Agent 生態中，它們往往會被用戶直接複製並執行，從而形成一條完整的執行鏈。攻擊者只需將惡意命令偽裝為依賴安裝步驟，例如使用 curl | bash 或 Base64 編碼隱藏真實指令，即可誘導用戶執行惡意腳本。
在實際樣本中，一些 Skill 採用典型的「兩階段加載」策略：
- 第一階段腳本僅負責下載並執行
- 第二階段 Payload，從而降低靜態檢測的成功率。
以一個下載量較高的「X (Twitter) Trends」Skill 為例，其 SKILL.md 中隱藏了一段 Base64 編碼命令。
解碼後可發現其本質是下載並執行遠程腳本。
而第二階段程序會偽裝系統彈窗獲取用戶密碼，並在系統臨時目錄中收集本機信息、桌面文檔以及下載目錄中的文件，最終打包並上傳至攻擊者控制的服務器。
這種攻擊方式的核心優勢在於，Skill 外殼本身可以保持相對穩定，而攻擊者只需更換遠程 Payload 即可持續更新攻擊邏輯。
3. Agent 決策與任務編排層風險
在 AI Agent 的應用邏輯層中，任務通常會被模型拆解為多個執行步驟。如果攻擊者能夠影響這一拆解過程，就可能導致 Agent 在執行合法任務時產生異常行為。
例如，在涉及多步驟操作的業務流程中（如自動化部署或鏈上交易），攻擊者可以通過篡改關鍵參數或干擾邏輯判斷，使 Agent 在執行流程中替換目標地址或執行額外操作。
在 SlowMist 之前的安全審計案例中，曾通過向 MCP 返回惡意提示詞汙染上下文，從而誘導 Agent 調用錢包插件執行鏈上轉賬。
這類攻擊的特點在於，錯誤並非來自模型生成代碼，而是來自任務編排邏輯被篡改。
4. IDE / CLI 環境中的隱私與敏感信息洩露
在 AI Agent 被廣泛用於開發輔助和自動化運維之後，大量 Agent 開始運行在 IDE、CLI 或本地開發環境中。
這類環境通常包含大量敏感信息，例如 .env 配置文件、API Token、雲服務憑證、私鑰文件以及各類訪問密鑰。一旦 Agent 在任務執行過程中能夠讀取這些目錄或索引項目文件，就可能在無意間將敏感信息納入模型上下文。
在某些自動化開發流程中，Agent 可能會在調試、日誌分析或依賴安裝過程中讀取項目目錄下的配置文件。如果缺乏明確的忽略策略或訪問控制，這些信息可能被記錄到日誌、發送到遠程模型 API，甚至被惡意插件外發。
此外，一些開發工具會允許 Agent 自動掃描代碼倉庫以建立上下文記憶 (Memory)，這也可能擴大敏感數據暴露的範圍。例如，私鑰文件、助記詞備份、數據庫連接字符串或第三方 API Token 等，都可能在索引過程中被讀取。
在 Web3 開發環境中，這一問題尤為突出，因為開發者往往會在本地環境中存放測試私鑰、RPC Token 或部署腳本。一旦這些信息被惡意 Skill、插件或遠程腳本獲取，攻擊者便可能進一步控制開發者賬戶或部署環境。
因此，在 AI Agent 與 IDE / CLI 集成的場景下，建立明確的敏感目錄忽略策略（例如 .agentignore、.gitignore 類機制）以及權限隔離措施，是降低數據洩露風險的重要前提。
5. 模型層不確定性與自動化風險
AI 模型本身並不是完全確定性的系統，其輸出存在一定概率的不穩定性。所謂「模型幻覺」，即模型在缺乏信息時生成看似合理但實際錯誤的結果。在傳統應用場景中，這類錯誤通常隻影響信息質量，但在 AI Agent 架構中，模型輸出可能直接觸發系統操作。
例如，在某些案例中，模型在部署項目時未查詢真實參數，而是生成了一個錯誤 ID 並繼續執行部署流程。如果類似情況發生在鏈上交易或資產操作場景中，錯誤決策可能導致不可逆的資金損失。
6. Web3 場景中的高價值操作風險
與傳統軟件系統不同，Web3 環境中的許多操作具有不可逆性。例如，鏈上轉賬、Token Swap、流動性添加以及智能合約調用，一旦交易被簽名並廣播到網絡，通常難以撤銷或回滾。
因此，當 AI Agent 被用於執行鏈上操作時，其安全風險也被進一步放大。
在一些實驗性項目中，開發者已經開始嘗試讓 Agent 直接參與鏈上交易策略執行，例如自動化套利、資金管理或 DeFi 操作。
然而，如果 Agent 在任務拆解或參數生成過程中受到提示詞注入、上下文汙染或插件攻擊的影響，就可能在交易過程中替換目標地址、修改交易金額或調用惡意合約。此外，一些 Agent 框架允許插件直接訪問錢包 API 或簽名接口。如果缺乏簽名隔離或人工確認機制，攻擊者甚至可能通過惡意 Skill 觸發自動交易。
因此，在 Web3 場景中，將 AI Agent 與資產控制系統完全綁定是一個高風險設計。
更安全的模式通常是讓 Agent 僅負責生成交易建議或未簽名交易數據，而實際簽名過程由獨立錢包或人工確認完成。同時，結合地址信譽檢測、AML 風控以及交易模擬等機制，也可以在一定程度上降低自動化交易帶來的風險。
7. 高權限執行帶來的系統級風險
許多 AI Agent 在實際部署中擁有較高的系統權限，例如訪問本地文件系統、執行 Shell 命令甚至以 Root 權限運行。
一旦 Agent 的行為被操控，其影響範圍可能遠遠超出單一應用。
SlowMist 曾測試將 OpenClaw 與即時通訊軟件如 Telegram 綁定，實現遠程控制。如果控制渠道被攻擊者接管，Agent 便可能被用於執行任意系統命令、讀取瀏覽器數據、訪問本地文件甚至控制其他應用程序。結合插件生態與工具調用能力，這類 Agent 在某種程度上已經具備了「智能遠控」的特徵。
綜合來看，AI Agent 的安全威脅已經不再侷限於傳統的軟件漏洞，而是跨越了模型交互層、插件供應鏈、執行環境以及資產操作層等多個維度。
攻擊者既可以通過提示詞操控 Agent 的行為，也可以通過惡意 Skills 或依賴包在供應鏈層植入後門，並進一步在高權限運行環境中擴大攻擊影響。
在 Web3 場景中，由於鏈上操作具有不可逆性且涉及真實資產價值，這些風險往往會被進一步放大。因此，在 AI Agent 的設計和使用過程中，僅依賴傳統應用安全策略已經難以完全覆蓋新的攻擊面，需要在權限控制、供應鏈治理以及交易安全機制等方面建立更加系統化的安全防護體系。
三、AI Agent 交易安全實踐｜Bitget
1. AI Agent 交易場景中的主要安全風險
AI Agent 出現後，攻擊路徑變了：
- 不需要登進你的賬號——只需要拿到你的 API Key
- 不需要你發現——Agent 7×24 小時自動運行，異常操作可以持續數天
- 不需要提現——直接在平臺內交易把資產虧光，同樣是攻擊目標
API Key 的創建、修改、刪除都需要通過已登錄的賬號完成——賬號被控意味著 Key 管理權被控。賬號安全等級直接決定了 API Key 的安全上限。
你應該做的：
- 開啟 Google Authenticator 作為主要 2FA，而非短信（SIM 卡可被劫持）
- 啟用 Passkey 無密碼登錄：基於 FIDO2/WebAuthn 標準，公私鑰加密替代傳統密碼，釣魚攻擊從架構層失效
- 設置防釣魚碼
- 定期檢查設備管理中心，發現陌生設備立刻踢出並修改密碼
2. API 安全
在 AI Agent 自動交易架構中，API Key 相當於 Agent 的「執行權限憑證」。Agent 本身並不直接持有賬戶控制權，它所有能夠執行的操作，均取決於 API Key 被授予的權限範圍。因此，API 權限邊界既決定 Agent 能做什麼，也決定在安全事件發生時損失可能擴大的程度。
權限配置矩陣——最小權限，不是方便權限：
在多數交易平臺中，API Key 通常支持多種安全控制機制，這些機制如果合理使用，可以顯著降低 API Key 被濫用的風險。
用戶常犯的錯誤：
- 把主賬號 API Key 直接粘貼進 Agent 配置——主賬號全量權限完全暴露
- 業務類型點了「全選」圖方便，實際上開放了所有操作範圍
- 沒設 Passphrase，或 Passphrase 與賬號密碼相同
- API Key 寫死在代碼裡，推上 GitHub 後被爬蟲 3 分鐘內掃走
- 一個 Key 同時授權給多個 Agent 和工具，任何一個被入侵全面暴露
- Key 洩露後沒有立即撤銷，攻擊者持續利用窗口期
Key 的生命週期管理：
- 每 90 天輪換一次 API Key
- 舊 Key 立即刪除停用
- Agent 時立即刪除對應 Key，不留殘餘攻擊面
- 定期檢查 API 調用記錄，發現陌生 IP 或異常時間段立刻撤銷
3. 資金安全
攻擊者拿到 API Key 後能造成多大損失，取決於這個 Key 能動多少錢。因此，在設計 AI Agent 的交易架構時，除了賬戶安全和 API 權限控制之外，還應通過資金隔離機制，為潛在風險設置明確的損失上限。
子賬號隔離機制：
- 創建 Agent 專用子賬號，與主賬號完全分離
- 主賬號只劃撥 Agent 實際需要的資金，不是全部資產
- 即便子賬號 Key 被盜，攻擊者能動的最大金額 = 子賬號內的資金，主賬號不受影響
- 多個 Agent 策略用多個子賬號分別管理，互相隔離
資金密碼作為第二道鎖：
- 資金密碼 (Fund Password) 與登錄密碼完全分離，即便賬號被登錄，沒有資金密碼仍無法發起提現
- 資金密碼與登錄密碼設置為不同的密碼
- 啟用提幣白名單：只有預先添加的地址才能提現，新地址需要 24 小時審核期
- 修改資金密碼後系統自動凍結提現 24 小時——這是保護你的機制
4. 交易安全
在 AI Agent 自動交易場景中，安全問題往往不會表現為一次性的異常行為，而是可能在系統持續運行的過程中逐步發生。因此，除了賬戶安全與 API 權限控制之外，還需要建立持續的交易監控與異常檢測機制，以便在問題出現的早期階段及時發現並干預。
必須建立的監控體系：
- Agent 長時間無操作，但賬戶出現新訂單或倉位
- API 調用日誌出現非
- 收到從未設置過的交易對的成交通知
- 賬戶餘額出現無法解釋的變動
- Agent 反覆提示「需要更多權限才能執行」——先搞清楚為什麼，再決定是否授權
Skill 和工具來源管理：
- 僅安裝官方發佈且經過審核渠道提供的 Skill
- 避免安裝來源不明或未經驗證的第三方擴展
- 定期審查已安裝的 Skill 列表，刪除不再使用的
- 警惕社區「增強版」、「漢化版」Skill——任何非官方版本都是風險
5. 數據安全
AI Agent 的決策依賴大量數據（賬戶信息、持倉、交易歷史、行情、策略參數）。如果這些數據被洩露或篡改，攻擊者可能推斷你的策略甚至操控交易行為。
你應該做的
- 最小數據原則：只向 Agent 提供執行交易必需的數據
- 敏感數據脫敏：日誌、調試信息不要讓 Agent 輸出完整賬戶信息、API Key 等敏感數據
- 禁止上傳完整賬戶數據到公共 AI 模型（如公共 LLM API）
- 如果可能，分離策略數據與賬戶數據
- 行為監控與審計機制等措施，降低配置洩露、供應鏈攻擊及異常操作帶來的風險。
6. 排查路徑
發現任何異常
- 立即撤銷或禁用可疑 API Key
- 檢查賬戶異常訂單 / 倉位，能撤的立刻撤
- 檢查提現記錄，確認資金是否已轉出
- 修改登錄密碼 + 資金密碼，踢出所有已登錄設備
- 聯繫平臺安全支持，提供異常時間段和操作記錄
- 排查 Key 洩露路徑（代碼庫 / 配置文件 / Skill 日誌）
核心原則：遇到任何懷疑，先撤 Key，後查原因，順序不能反。
四、建議及總結
在本報告中，SlowMist 和 Bitget 結合實際案例與安全研究，對當前 AI Agent 在 Web3 場景中較為典型的安全問題進行了分析，包括 Prompt Injection 對 Agent 行為的操控風險、插件與 Skill 生態中的供應鏈風險、API Key 與賬戶權限濫用問題，以及自動化執行帶來的誤操作與權限擴大等潛在威脅。
這些問題往往並非單一漏洞導致，而是 Agent 架構設計、權限控制策略以及運行環境安全共同作用的結果。
因此，在構建或使用 AI Agent 系統時，應從整體架構層面進行安全設計，例如遵循最小權限原則為 Agent 分配 API Key 和賬戶權限，避免開啟不必要的高風險功能；在工具調用層面對插件與 Skill 進行權限隔離，避免單一組件同時具備數據獲取、決策生成與資金操作能力；在 Agent 執行關鍵操作時設置明確的行為邊界與參數限制，並在必要場景下增加人工確認機制，以降低自動化執行帶來的不可逆風險。
同時，對於 Agent 運行所依賴的外部輸入，應通過合理的 Prompt 設計與輸入隔離機制防範 Prompt Injection 攻擊，避免將外部內容直接作為系統指令參與模型推理過程。在實際部署與運行階段，還應加強 API Key 與賬戶安全管理，例如僅開啟必要權限、設置 IP 白名單、定期輪換 Key，並避免在代碼倉庫、配置文件或日誌系統中明文存儲敏感信息；在開發流程與運行環境中，則應通過插件安全審查、日誌敏感信息控制以及行為監控與審計機制等措施，降低配置洩露、供應鏈攻擊及異常操作帶來的風險。
在更宏觀的安全架構層面，SlowMist 在相關研究中提出了一種面向 AI 與 Web3 智能體場景的多層安全治理思路，通過構建分層防護體系來系統性降低智能體在高權限環境中的風險。
在該框架中，L1 安全治理首先以統一的開發與使用安全基線作為基礎，通過建立覆蓋開發工具、Agent 框架、插件生態以及運行環境的安全規範，為團隊在引入 AI 工具鏈時提供統一的策略來源與審計標準。
在此基礎上，L2 通過對 Agent 權限邊界的收斂、工具調用的最小權限控制以及關鍵行為的人機確認機制，可以有效約束高風險操作的執行範圍。
同時，L3 在外部交互入口層面引入實時威脅感知能力，對 URL、依賴倉庫、插件來源等外部資源進行預檢，以降低惡意內容或供應鏈投毒進入執行鏈路的概率；
在涉及鏈上交易或資產操作的場景中，則通過 L4 鏈上風險分析與獨立簽名機制實現額外的安全隔離，使 Agent 能夠構造交易但不直接接觸私鑰，從而減少高價值資產操作帶來的系統性風險。
最終，L5 通過持續巡檢、日誌審計以及週期性安全複核等運營機制，形成「執行前可預檢、執行中可約束、執行後可覆盤」的閉環安全能力。
這種分層安全思路並非單一產品或工具，而是一種面向 AI 工具鏈與智能體生態的安全治理框架，其核心目標是在不顯著降低開發效率和自動化能力的前提下，通過系統化策略、持續審計與安全能力聯動，幫助團隊建立可持續、可審計且可演進的 Agent 安全運營體系，從而更好地應對 AI 與 Web及深度融合背景下不斷變化的安全挑戰。
總體而言，AI Agent 為 Web3 生態帶來了更高程度的自動化與智能化能力，但其安全挑戰同樣不容忽視。
只有在系統設計、權限管理與運行監控等多個層面建立完善的安全機制，才能在推動 AI Agent 技術創新的同時，有效降低潛在風險。
希望本報告能夠為開發者、平臺及用戶在構建和使用 AI Agent 系統時提供參考，在促進技術發展的同時，共同推動更加安全、可靠的 Web3 生態環境的形成。
來源：https://www.blocktempo.com/ai-agent-web3-security-risks-slowmist-bitget-prompt-injection-skill/