SlowMist × Bitget AI安全報告:把錢交給「龍蝦」等AI Agent真的安全嗎?
- 核心觀點:隨著AI Agent深度整合到Web3交易場景,其安全威脅已從傳統軟體漏洞擴展到提示詞注入、惡意外掛程式供應鏈攻擊、高權限濫用及鏈上資產操作風險等多個層面,需要建構系統化的安全防護體系。
- 關鍵要素:
- 新型攻擊面:提示詞注入(Prompt Injection)可操控Agent決策邏輯,惡意Skill/外掛程式成為供應鏈攻擊新入口,執行環境配置不當易致敏感資料外洩。
- 供應鏈投毒風險:監測發現惡意Skill呈現團夥化、批量化特徵,常透過偽裝安裝步驟誘導使用者執行遠端惡意指令碼,竊取本地資訊。
- Web3資產風險放大:鏈上交易具有不可逆性,Agent若被操控可能導致地址替換、金額篡改等直接資金損失,高風險設計是將Agent與資產控制系統完全繫結。
- 帳戶與API安全實踐:使用者應啟用強2FA、Passkey登入,為Agent建立專用子帳號並遵循API Key最小權限原則,定期輪換並監控呼叫日誌。
- 平台層安全設計:交易平台需提供子帳號隔離、細粒度API權限控制、外掛程式稽核機制及基礎安全能力(如防釣魚碼、提幣白名單),以降低整體風險。
- 分層安全治理框架:報告提出從統一安全基線、權限收斂、外部威脅感知、鏈上風險分析到持續營運稽核的五層(L1-L5)安全治理思路,建構閉環防護體系。
原文作者:SlowMist & Bitget
一、背景
隨著大模型技術的快速發展,AI Agent 正在從簡單的智慧助手逐漸演變為能夠自主執行任務的自動化系統。在 Web3 生態中,這一變化表現得尤為明顯。越來越多的用戶開始嘗試讓 AI Agent 參與行情分析、策略生成以及自動化交易,讓「7×24 小時自動運行的交易助手」從概念逐漸走向現實。隨著 Binance 與 OKX 推出了多個 AI Skills,Bitget 也推出了 Skills 資源站 Agent Hub,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 的行為控制權。

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
隨著 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 被濫用的風險。常見的安全配置建議包括:


