BTCC / BTCC Square / TechFlowPost /
SlowMist × Bitget AI 安全性報告:把錢交給「龍蝦」等 AI Agent 真的安全嗎?

SlowMist × Bitget AI 安全性報告:把錢交給「龍蝦」等 AI Agent 真的安全嗎?

Published:
2026-03-18 04:58:32

撰文:SlowMist 與 Bitget

一、背景

AIgent 自動化任務的快速發展為獨立的助手。 在 Web3 生態中,這一變化表現得尤為明顯。 越來越多的用戶開始嘗試讓 AI Agent 參與行情分析、策略產生以及自動化交易,讓「7×24 小時自動運行的交易助理」從概念逐漸走向現實。 隨著幣安與 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 的行為控制權。

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

在 AI Agent 架構中,用戶輸入和外部資料通常會被直接納入一種上下文,這使得配置 Injection Injection Injection Injection Injections(Projection) 成為一種重要方式。 攻擊者可以透過建構特定指令,誘導 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 編碼指令。

解碼後可發現其本質上是下載並執行遠端腳本:

54p); start;">而第二階段程式會偽裝系統彈窗取得使用者密碼,並在系統臨時目錄中收集本機資訊、桌面文件以及下載目錄中的文件,最終打包並上傳至攻擊者控制的伺服器。

這種攻擊方式的核心優勢在於,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. 賬戶安全

你應該做的:

  • 開啟 Google Authenticator 作為主要 2FA,而非短信(SIM 卡可被劫持)
  • 基於 Passkey 無密碼登入:劫持) 標準,公私鑰加密取代傳統密碼,釣魚攻擊從架構層失效
  • 設定防釣魚碼
  • 定期檢查設備管理中心,發現陌生設備立刻踢出並修改密碼

權限配置矩陣-最小權限,不是方便權限:

在多數交易平台中,API Key 通常支持多種安全控制機制,這些機制如果合理使用,可以顯著的風險濫用。 常見的安全配置建議包括:

用戶常犯的錯誤:

  • 用戶常犯的錯誤:
    • 讓主編號 API 直接貼進 Agent 配置-主帳號總碼數; ? 同時授權給多個 Agent 和工具,任何一個被入侵全面暴露
    • Key 洩漏後沒有立即撤銷,攻擊者持續利用視窗期

    Key 的生命週期管理:

      Key style="text-align: start;">停用 Agent 時立即刪除對應 Key,不留殘餘攻擊面

  • 定期檢查 API 呼叫記錄,發現陌生 IP 或異常時間段立刻撤銷

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

子账号隔离机制:

  • 创建 Agent 专用子账号,与主账号完全分离
  • 主账号只划拨 Agent 实际需要的资金,不是全部资产
  • 即便子账号 Key 被盜,攻擊者能動的最大金額 = 子帳號內的資金,主帳號不受影響
  • 多個 Agent 策略用多個子帳號分別管理,互相隔離

資金密碼作為第二個鎖:

  • 資金密碼與登錄密碼設定為不同的密碼
  • 啟用提幣白名單:只有預先新增的地址才能提現,新地址需要 24 小時後密碼
  • >; 24 小時-這是保護你的機制

    5. 交易安全

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

    必須建立的監控體系:

    異常訊號辨識-出現下列情形立刻停止並檢查:

    • API 呼叫日誌出現非 Agent 伺服器 IP 的請求
    • 收到從未設定過的交易對的成交通知
    • 帳戶餘額出現無法解釋的變動
    • Skill 和工具來源管理:
      • 僅安裝官方發布且經過審核管道提供的 Skill
      • 角色」避免安裝的 Skill
      • 也許 style="text-align: start;">定期審查已安裝的 Skill 列表,刪除不再使用的
      • 警惕社區“增強版”、“漢化版” Skill——任何非官方版本都是風險

      6. 的決策依賴大量資料(帳戶資訊、持倉、交易歷史、行情、策略參數)。 如果這些資料外洩或篡改,攻擊者可能推斷你的策略甚至操控交易行為。

      你應該做的

      • 最小資料原則:只向 Agent 提供執行交易必要的資料
      • 敏感資料脫敏:讓資料、偵錯資料 start;">禁止上傳完整帳戶資料到公共 AI 模型(如公共 LLM API)
      • 如果可能,分離策略資料與帳戶資料
      • 關閉或限制 Agent 匯出歷史交易資料

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

    • Agent 日誌中列印 API Key / Secret
    • 在公開論壇貼出交易記錄截圖(包含訂單 ID、帳戶資訊)
    • 7. AI Agent 平台層的安全設計

      除了用戶側的安全配置之外,AI Agent 交易生態的安全性還在很大程度上依賴於平台層的安全設計。 一個成熟的 Agent 平台通常需要在帳戶隔離、API 權限控制、插件審核以及基礎安全能力等方面建立系統化的防護機制,從而降低使用者在存取自動化交易系統時面臨的整體風險。

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

      1、子帳號隔離體系

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

      2、 細粒度 API 權限配置

      AI Agent 的核心操作依賴 API 接口,因此平台在 API 權限設計上通常需要支援細粒度控制,例如交易分割、IP 來源限制以及額外的安全性分割、IP 來源限制機制以及額外的安全性分割、IP 來源限制機制。 透過這種權限模型,使用者可以僅向 Agent 授予完成任務所需的最小權限範圍。

      3、Agent 插件與 Skill 審核機制

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

      4、平台基礎安全能力

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

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

      假客服

      Key

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

      投毒 Skill 包

      社群分享「增強版交易 Skill”,運行時靜默發送你的 Key。

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

      假升級通知

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

      → 檢查郵件防釣魚碼。

      提示詞注入攻擊

      在市場資料、新聞、K 線註解中嵌入指令,操控 Agent 執行非預期操作。

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

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

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

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

      9. 排查路徑

      發現任何異常

      Keybp">或停用 style="text-align: start;">檢查帳戶異常訂單 / 倉位,能撤的立刻撤

      檢查記錄,確認資金是否已轉出

      聯絡平台安全支持,提供異常時間段和操作記錄

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

      四、建議及總結

      在本報告中,SlowMist 和 Bitget 結合實際案例與安全研究,對當前 AI Agent 在 Web3 場景中較為典型的安全問題進行了 Keyection,包括 Prokills Injection 場景中對 Amp 與帳戶權限濫用問題,以及自動化執行帶來的誤操作與權限擴大等潛在威脅。 這些問題往往並非單一漏洞導致,而是 Agent 架構設計、權限控制策略以及運行環境安全共同作用的結果。

      因此,在構建或使用 AI Agent 系統時,應從整體架構層面進行安全設計,例如遵循最小權限原則為 Agent 分配 API Key 和帳戶權限,避免開啟不必要的高風險功能;在工具調用層面對插件與 Skill 進行隔離,避免單一操作元件同時具備數據獲取、決策組件與資金操作能力; 執行關鍵操作時設定明確的行為邊界與參數限制,並在必要情境下增加人工確認機制,以降低自動化執行帶來的不可逆風險。 同時,對於 Agent 運作所依賴的外部輸入,應透過合理的 Prompt 設計與輸入隔離機制防範 Prompt Injection 攻擊,避免將外部內容直接作為系統指令參與模型推理過程。 在實際部署與運作階段,還應加強 API Key 與帳戶安全管理,例如僅開啟必要權限、設定 IP 白名單、定期輪調 Key,並避免在程式碼倉庫、設定檔或日誌系統中明文儲存敏感資訊;在開發流程與運作環境中,則應透過插件安全審查、日誌敏感資訊控制以及行為監控與稽核機制等措施,降低設定、供應鏈攻擊及作業帶來異常的風險。

      在更宏觀的安全架構層面,SlowMist 在相關研究中提出了一種面向 AI 與 Web3 智能體場景的多層安全治理思路,透過建構分層防護體系來系統性降低智能體在高權限環境中的風險。 在這個框架中,L1 安全治理首先以統一的開發與使用安全基線作為基礎,透過建立覆蓋開發工具、Agent 框架、插件生態以及運行環境的安全規範,為團隊在引入 AI 工具鏈時提供統一的策略來源與審計標準。 在此基礎上,L2 透過對 Agent 權限邊界的收斂、工具呼叫的最小權限控制以及關鍵行為的人機確認機制,可以有效約束高風險操作的執行範圍。 同時,L3 在外部互動入口層面引入即時威脅感知能力,對 URL、依賴倉庫、插件來源等外部資源進行預檢,以降低惡意內容或供應鏈投毒進入執行鏈路的機率;在涉及鏈上交易或資產操作的場景中,則透過 L4 鏈上風險分析與獨立簽章機制實現額外的系統建構風險,使 Agent 能夠隔離資產 最終,L5 透過持續巡檢、日誌審計以及週期性安全複核等運作機制,形成「執行前可預檢、執行中可約束、執行後可複盤」的閉環安全能力。 這種分層安全思路並非單一產品或工具,而是一種面向 AI 工具鏈與智能體生態的安全治理框架,其核心目標是在不顯著降低開發效率和自動化能力的前提下,透過系統化策略、持續審計與安全能力聯動,幫助團隊建立可持續、可審計且可演進的 Agent 安全運營體系,從而更好地應對 AI 與 Web3 深度融合。

      整體而言,AI Agent 為 Web3 生態帶來了更高程度的自動化與智慧化能力,但其安全挑戰同樣不容忽視。 只有在系統設計、權限管理與運作監控等多個層面建立完善的安全機制,才能在推動 AI Agent 技術創新的同時,有效降低潛在風險。 希望本報告能為開發者、平台及使用者在建構和使用 AI Agent 系統時提供參考,在促進技術發展的同時,共同推動更安全、可靠的 Web3 生態環境的形成。

    |Square

    下載BTCC APP,您的加密之旅從這啟程

    立即行動 掃描 加入我們的 100M+ 用戶行列