慢雾：將錢交給「龍蝦」等AI Agent真的安全嗎？

By: blockbeats|2026/03/18 18:00:12

原文標題：《SlowMist × Bitget AI 安全報告：把錢交給「龍蝦」等 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 場景中，資產操作往往具有高價值與不可逆性，一旦自動化系統被濫用或誤導，風險影響也可能被進一步放大。

基於這些背景，SlowMist 與 Bitget 聯合撰寫本報告，從安全研究與交易平台實踐兩個角度，對 AI Agent 在多個場景中的安全問題進行系統梳理。希望本報告能夠為用戶、開發者以及平台提供一些安全參考，幫助推動 AI Agent 生態在安全與創新之間實現更加穩健的發展。

二、AI Agent 的真實安全威脅｜SlowMist

AI Agent 的出現，使軟體系統從「人類主導操作」逐漸轉向「模型參與決策與執行」。這種架構變化顯著提升了自動化能力，但同時也擴大了攻擊面。

從當前的技術結構來看，一個典型的 AI Agent 系統通常包含用戶交互層、應用邏輯層、模型層、工具調用層（Tools / Skills）、記憶系統（Memory）以及底層執行環境等多個元件。攻擊者往往不會只針對單一模組，而是嘗試通過多層路徑逐步影響 Agent 的行為控制權。

慢雾：將錢交給「龍蝦」等AI Agent真的安全嗎？

1. 輸入操控與提示詞注入攻擊

在 AI Agent 架構中，用戶輸入和外部數據通常會被直接納入模型上下文，這使得提示詞注入（Prompt Injection）成為一種重要攻擊方式。攻擊者可以通過構造特定指令，誘導 Agent 執行原本不應觸發的操作。例如，在某些案例中，僅通過聊天指令即可誘導 Agent 生成並執行高危系統命令。

更複雜的攻擊方式是間接注入，即攻擊者將惡意指令隱藏在網頁內容、文件說明或程式碼註釋中。當 Agent 在執行任務過程中讀取這些內容時，可能會誤將其視為合法指令。例如，在外掛程式文件、README 文件或 Markdown 文件中嵌入惡意命令，就可能導致 Agent 在初始化環境或安裝依賴時執行攻擊碼。

這種攻擊模式的特點在於，它往往不依賴傳統漏洞，而是利用模型對上下文信息的信任機制來影響其行為邏輯。

-- 價格

2. 技能 / 插件生態的供應鏈投毒

在當前的 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

隨著 AI Agent 能力不斷增強，它們已經不再只是提供資訊或輔助決策，而是開始直接參與系統操作，甚至執行鏈上交易。

在加密交易場景中，這種變化尤為明顯。越來越多用戶開始嘗試讓 AI Agent 參與行情分析、策略執行以及自動化交易。當 Agent 可以直接調用交易介面、訪問帳戶資產並自動下單時，其安全問題也從「系統安全風險」進一步轉化為「真實資產風險」。當 AI Agent 被用於實際交易時，用戶應該如何保護自己的帳戶與資金安全？

基於此，本小節由 Bitget 安全團隊結合交易平台的實踐經驗，從帳戶安全、API 權限管理、資金隔離以及交易監控等多個角度，系統介紹在使用 AI Agent 進行自動化交易時需要重點關注的安全策略。

1. AI Agent 交易場景中的主要安全風險

2. 帳戶安全

AI Agent 出現後，攻擊路徑變了：

· 不需要登入你的帳號——只需要拿到你的 API Key

· 不需要你發現——Agent 7×24 小時自動運行，異常操作可以持續數天

· 不需要提現——直接在平台內交易把資產虧光，同樣是攻擊目標

API Key 的創建、修改、刪除都需要通過已登入的帳號完成——帳號被控意味著 Key 管理權被控。帳號安全等級直接決定了 API Key 的安全上限。

你應該做的：

· 開啟 Google Authenticator 作為主要 2FA，而非簡訊（SIM 卡可被劫持）

· 啟用 Passkey 無密碼登入：基於 FIDO2/WebAuthn 標準，公私鑰加密替代傳統密碼，釣魚攻擊從架構層失效

· 設置防釣魚碼

· 定期檢查裝置管理中心，發現陌生裝置立刻踢出並修改密碼

3. 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 或異常時間段立即撤銷

4. 資金安全

攻擊者拿到 API Key 後能造成多大損失，取決於這個 Key 能動多少錢。因此，在設計 AI Agent 的交易架構時，除了帳戶安全和 API 權限控制之外，還應通過資金隔離機制，為潛在風險設定明確的損失上限。

子帳號隔離機制：

· 創建 Agent 專用子帳號，與主帳號完全分離

· 主帳號只劃撥 Agent 實際需要的資金，不是全部資產

· 即便子帳號 Key 被盜，攻擊者能動的最大金額 = 子帳號內的資金，主帳號不受影響

· 多個 Agent 策略用多個子帳號分別管理，互相隔離

資金密碼作為第二道鎖：

· 資金密碼 (Fund Password) 與登錄密碼完全分離，即便帳號被登錄，沒有資金密碼仍無法發起提現

· 資金密碼與登錄密碼設定為不同的密碼

· 啟用提幣白名單：只有預先添加的地址才能提現，新地址需要 24 小時審核期

· 修改資金密碼後系統自動凍結提現 24 小時——這是保護你的機制

5. 交易安全

在 AI Agent 自動交易場景中，安全問題往往不會表現為一次性的異常行為，而是可能在系統持續運行的過程中逐步發生。因此，除了帳戶安全與 API 權限控制之外，還需要建立持續的交易監控與異常檢測機制，以便在問題出現的早期階段及時發現並干預。

必須建立的監控體系：

異常信號識別——出現以下情況立刻停止並檢查：

· Agent 長時間無操作，但帳戶出現新訂單或倉位 API 調用日誌出現非

· Agent 伺服器 IP 的請求

· 收到從未設置過的交易對的成交通知

· 帳戶餘額出現無法解釋的變動

· Agent 反覆提示「需要更多權限才能執行」——先搞清楚為什麼，再決定是否授權

Skill 和工具來源管理：

· 僅安裝官方發布且經過審核渠道提供的 Skill

· 避免安裝來源不明或未經驗證的第三方擴展

· 定期審查已安裝的 Skill 清單，刪除不再使用的

· 警惕社群「增強版」、「漢化版」Skill——任何非官方版本都是風險

6. 資料安全

AI Agent 的決策依賴大量資料（帳戶資訊、持有、交易歷史、行情、策略參數）。如果這些資料被洩露或篡改，攻擊者可能推斷你的策略甚至操控交易行為。

你應該做的

· 最小資料原則：只向 Agent 提供執行交易必需的資料

· 敏感資料脫敏：日誌、除錯資訊不要讓 Agent 輸出完整帳戶資訊、API Key 等敏感資料

· 禁止上傳完整帳戶資料到公共 AI 模型（如公共 LLM API）

· 如果可能，分離策略資料與帳戶資料

· 關閉或限制 Agent 匯出歷史交易資料

使用者常見錯誤

· 把完整交易歷史上傳給 AI「幫我優化策略」

· Agent 日誌中列印 API Key / Secret

· 在公開論壇貼出交易記錄截圖（包含訂單 ID、帳戶資訊）

· 把資料庫備份上傳到 AI 工具做分析

7. AI Agent 平台層的安全設計

除了使用者側的安全配置之外，AI Agent 交易生態的安全性還在很大程度上依賴於平台層的安全設計。

一個成熟的 Agent 平台通常需要在帳戶隔離、API 權限控制、插件審核以及基礎安全能力等方面建立系統化的防護機制，從而降低使用者在接入自動化交易系統時面臨的整體風險。

在實際平台架構中，常見的安全設計通常包括以下幾個方面。

1、子帳號隔離體系

在自動化交易環境中，平台通常會提供子帳戶或策略帳戶體系，用於隔離不同自動化系統的資金和權限。通過這種方式，用戶可以為每個 Agent 或交易策略分配獨立的帳戶與資金池，從而避免多個自動化系統共享同一帳戶帶來的風險。

2、細粒度 API 權限配置

AI Agent 的核心操作依賴於 API 介面，因此平台在 API 權限設計上通常需要支持細粒度控制，例如交易權限劃分、IP 來源限制以及額外的安全驗證機制。通過這種權限模型，用戶可以僅向 Agent 授予完成任務所需的最小權限範圍。

3、Agent 插件與 Skill 審核機制

一些平台會對插件或 Skill 的發布與上架過程設定審核機制，例如程式碼審核、權限評估以及安全測試等，以減少惡意元件進入生態系統的可能性。從安全角度來看，這類審核機制相當於在插件供應鏈上增加了一層平台級過濾，但用戶仍然需要對所安裝的擴展元件保持基本的安全意識。

4、平台基礎安全能力

除了 Agent 相關的安全機制之外，交易平台本身的帳戶安全體系同樣會對 Agent 用戶產生重要影響。例如：

8. 專門針對 Agent 用戶的新型詐騙

假冒客服

「你的 API Key 存在安全風險，請立即重新配置。」然後給你釣魚連結。

→ 官方不會主動私訊索要 API Key。

投毒 Skill 套件

社群分享「增強版交易 Skill」，執行時靜默發送你的 Key。

→ 只裝官方審核渠道的 Skill。

假冒升級通知

「需要重新授權」，點進去是仿冒頁面。

→ 檢查郵件防釣魚碼。

提示詞注入攻擊

在市場數據、新聞、K 線註釋中嵌入指令，操控 Agent 執行非預期操作。

→ 設定子帳號資金上限，即使被注入，損失有硬性邊界。

偽裝成「安全檢測工具」的惡意腳本

聲稱可以檢測你的 Key 是否洩露，實際上在竊取 Key。

→ 通過官方平台提供的日誌或訪問記錄功能檢查 API 呼叫情況。

9. 排查路徑

發現任何異常

↓

立即撤銷或禁用可疑 API Key

↓

檢查帳戶異常訂單 / 倉位，能撤的立刻撤

↓

檢查提現記錄，確認資金是否已轉出

↓

修改登錄密碼 + 資金密碼，踢出所有已登錄設備

↓

聯繫平台安全支援，提供異常時間段和操作記錄

↓

排查 Key 洩露路徑（程式庫 / 配置文件 / Skill 日誌）

核心原則：遇到任何懷疑，先撤 Key，後查原因，順序不能反。

四、建議及總結

在本報告中，SlowMist 和 Bitget 結合實際案例與安全研究，對當前 AI Agent 在 Web3 情境中較為典型的安全問題進行了分析，包括 Prompt Injection 對 Agent 行為的操控風險、插件與 Skill 生態中的供應鏈風險、API Key 與帳戶權限濫用問題，以及自動化執行帶來的誤操作與權限擴大等潛在威脅。

這些問題往往並非單一漏洞導致，而是 Agent 架構設計、權限控制策略以及運行環境安全共同作用的結果。

因此，在构建或使用 AI Agent 系统时，應從整體架構層面進行安全設計，例如遵循最小權限原則為 Agent 分配 API 金鑰和帳戶權限，避免開啟不必要的高風險功能；

在工具呼叫層面對插件與 Skill 進行權限隔離，避免單一組件同時具備數據獲取、決策生成與資金操作能力；

在 Agent 執行關鍵操作時設定明確的行為邊界與參數限制，並在必要場景下增加人工確認機制，以降低自動化執行帶來的不可逆風險。

同時，對於 Agent 運行所依賴的外部輸入，應通過合理的 Prompt 設計與輸入隔離機制防範 Prompt Injection 攻擊，避免將外部內容直接作為系統指令參與模型推理過程。在實際部署與運行階段，還應加強 API 金鑰與帳戶安全管理，例如僅開啟必要權限、設定 IP 白名單、定期輪換金鑰，並避免在程式庫、配置檔案或日誌系統中明文存儲敏感信息；

在開發流程與運行環境中，則應通過插件安全審查、日誌敏感信息控制以及行為監控與審計機制等措施，降低配置洩露、供應鏈攻擊及異常操作帶來的風險。

在更宏觀的安全架構層面，SlowMist 在相關研究中提出了一種面向 AI 與 Web3 智能體場景的多層安全治理思路，通過構建分層防護體系來系統性降低智能體在高權限環境中的風險。

在該框架中，L1 安全治理首先以統一的開發與使用安全基線作為基礎，通過建立覆蓋開發工具、Agent 框架、插件生態以及運行環境的安全規範，為團隊在引入 AI 工具鍊時提供統一的策略來源與審計標準。

在此基礎上，L2 通過對 Agent 權限邊界的收斂、工具呼叫的最小權限控制以及關鍵行為的人機確認機制，可以有效約束高風險操作的執行範圍。

同時，L3 在外部交互入口層面引入實時威脅感知能力，對 URL、依賴庫、插件來源等外部資源進行預檢，以降低惡意內容或供應鏈投毒進入執行鏈路的機率；

在涉及鏈上交易或資產操作的場景中，則通過 L4 鏈上風險分析與獨立簽名機制實現額外的安全隔離，使 Agent 能夠構造交易但不直接接觸私鑰，從而減少高價值資產操作帶來的系統性風險。

最終，L5 通過持續巡檢、日誌審計以及周期性安全複核等運營機制，形成「執行前可預檢、執行中可限制、執行後可複盤」的閉環安全能力。

這種分層安全思路並非單一產品或工具，而是一種面向 AI 工具鏈與智能體生態的安全治理框架，其核心目標是在不顯著降低開發效率和自動化能力的前提下，通過系統化策略、持續審計與安全能力聯動，幫助團隊建立可持續、可審計且可演進的 Agent 安全運營體系，從而更好地應對 AI 與 Web3 深度融合背景下不斷變化的安全挑戰。