作者：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 交易場景中的主要安全風險
威脅類型 | 具體表現 | 嚴重程度 |
未授權訪問 | 陌生人觸發Agent，執行非預期交易 | 🔴 極高 |
提示詞注入 | 市場資料/新聞/K 線註解中嵌入惡意指令，操控Agent 異常下單 | 🔴 極高 |
權限工具濫用 | 過度授權的API Key 被用於提現、大額轉賬 | 🔴 極高 |
網路暴露 | 無IP 白名單的Key 可被任意IP 調用 | 🟠 高 |
本地文件洩露 | 硬編碼Key 上傳GitHub，被爬蟲掃走 | 🟠 高 |
Skill 投毒 | 惡意Skill 運行時靜默將API Key 傳送至攻擊者伺服器 | 🟠 高 |
模型強度不足 | 舊版模型更容易受到提示詞注入，防護能力弱 | 🟡 中 |
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 能做什麼，也決定在安全事件發生時損失可能擴大的程度。
權限配置矩陣－最小權限，不是方便權限：
Agent 使用場景 | 應開權限 | 必須關閉 |
行情分析/ 策略研究 | 只讀權限 | 讀寫權限、提現 |
自動交易（現貨） | 現貨訂單讀寫 | 合約、提現、資金劃轉 |
自動交易（合約） | 合約訂單讀寫 | 提現、資金劃轉 |
任何Agent 場景 | 按需最小化勾選 | 提現權限永遠關閉 |
在多數交易平台中，API Key 通常支援多種安全控制機制，這些機制如果合理使用，可以顯著降低API Key 被濫用的風險。常見的安全性配置建議包括：
配置項 | 說明 | 安全建議 |
Passphrase（API 口令） | 8-32 位元獨立口令，呼叫API 時需要額外驗證 | 與帳號密碼不同，單獨設定並妥善保存 |
讀寫權限/ 唯讀權限 | 頂層權限開關，唯讀模式下Agent 無法下單或修改部位 | 純行情分析場景選唯讀，杜絕意外操作 |
業務類型細粒度勾選 | 合約訂單、現貨訂單、資金劃轉等分別勾選，支援全選或單獨開啟 | 只勾選Agent 實際需要的業務類型，多餘的全不選 |
IP 白名單 | 只允許指定IP 位址調用，其他IP 一律拒絕 | 填入Agent 運作伺服器的IP，是最有效的硬隔離手段 |
提現權限 | 與交易權限完全分離，獨立控制 | 交易Agent 預設不需要此權限，創建時不勾選 |
使用者常犯的錯誤：
把主帳號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 權限控制之外，還需要建立持續的交易監控與異常檢測機制，以便在問題出現的早期階段及時發現並介入。
必須建立的監控體系：
監控手段 | 目的 |
開啟郵件+ App 雙通道推播通知 | 覆蓋下單/撤單/大額成交/登入異常 |
每週查看API 呼叫日誌 | 核對時間、IP、操作類型是否與預期一致 |
關注帳戶部位變化 | Agent 長時間無操作，帳戶出現新部位－立刻檢查 |
異常訊號辨識－出現以下情況立刻停止並檢查：
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 使用者產生重要影響。例如：
能力 | 對Agent 用戶的意義 |
Passkey（FIDO2/WebAuthn） | 帳號本身不依賴可被釣魚的密碼，API Key 管理更安全 |
MFA 全場景強制 | API Key 的建立、修改、刪除均需二次驗證 |
防釣魚碼機制 | 官方郵件攜帶自訂識別碼，假通知無法偽造 |
MPC + 冷錢包託管 | 平台資產安全架構，與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 Key 和帳戶權限，避免開啟不必要的高風險功能；在工具調用層面對插件與Skill 進行權限隔離，避免單一組件同時具備數據獲取、決策生成與資金操作能力；在Agent 執行關鍵操作時明確定義的行為機制同時，對於Agent 運作所依賴的外部輸入，應透過合理的Prompt 設計與輸入隔離機制防範Prompt Injection 攻擊，避免將外部內容直接作為系統指令參與模型推理過程。在實際部署與運作階段，也應加強API Key 與帳戶安全管理，例如僅開啟必要權限、設定IP 白名單、定期輪調Key，並避免在程式碼倉庫、設定檔或日誌系統中明文儲存敏感資訊；在開發流程與運作環境中，則應透過外掛程式安全審查、日誌敏感資訊控制以及行為監控與稽核機制等措施，降低設定、供應鏈攻擊及外洩操作帶來異常的風險。
在更宏觀的安全架構層面，SlowMist 在相關研究中提出了一種以AI 與Web3 智能體場景為導向的多層安全治理思路，透過建構分層防護體系來系統性地降低智能體在高權限環境中的風險。在這個框架中，L1 安全治理首先以統一的開發與使用安全基線作為基礎，透過建立覆蓋開發工具、Agent 框架、插件生態以及運行環境的安全規範，為團隊在引入AI 工具鏈時提供統一的策略來源與審計標準。在此基礎上，L2 透過對Agent 權限邊界的收斂、工具呼叫的最小權限控制以及關鍵行為的人機確認機制，可以有效約束高風險操作的執行範圍。同時，L3 在外部互動入口層面引入即時威脅感知能力，對URL、依賴倉庫、插件來源等外部資源進行預檢，以降低惡意內容或供應鏈投毒進入執行鏈路的機率；在涉及鏈上交易或資產操作的場景中，則透過L4 鏈上風險分析與獨立簽名機制實現額外的安全性操作，使Agent 資產操作的場景中，則透過L4 鏈上風險分析與獨立最終，L5 透過持續巡檢、日誌審計以及週期性安全複核等運作機制，形成「執行前可預檢、執行中可約束、執行後可複盤」的閉環安全能力。這種分層安全思路並非單一產品或工具，而是一種面向AI 工具鏈與智能體生態的安全治理框架，其核心目標是在不顯著降低開發效率和自動化能力的前提下，透過系統化策略、持續審計與安全能力聯動，幫助團隊建立可持續、可審計且可演進的Agent 安全運營體系，從而更好地應對AI 與Web3 深度整合。
整體而言，AI Agent 為Web3 生態帶來了更高程度的自動化與智慧化能力，但其安全挑戰同樣不容忽視。只有在系統設計、權限管理與運作監控等多個層面建立完善的安全機制，才能在推動AI Agent 技術創新的同時，有效降低潛在風險。希望本報告能為開發者、平台及使用者在建構和使用AI Agent 系統時提供參考，在促進技術發展的同時，共同推動更安全、可靠的Web3 生態環境的形成。
附擴展資源
OpenClaw 極簡安全實務指南
一份從認知層到基礎設施層的端到端Agent 安全部署手冊，系統梳理高權限AI Agent 在真實生產環境中的安全實踐與部署建議。
https://github.com/slowmist/openclaw-security-practice-guide
MCP Security Checklist
一份體系化的安全檢查清單，用於快速審計和加固Agent 服務，幫助團隊在部署MCPs/Skills 及相關AI 工具鏈時避免遺漏關鍵防禦點。
https://github.com/slowmist/MCP-Security-Checklist
MasterMCP
一個開源的惡意MCP 伺服器範例，用於復現真實攻擊場景並測試防禦體系的健全性，可用於安全研究與防禦驗證。
https://github.com/slowmist/MasterMCP
MistTrack Skills
一個即插即用的Agent 技能包，為AI Agent 提供專業的加密貨幣AML 合規與地址風險分析能力，可用於鏈上地址風險評估與交易前風險判斷。
https://github.com/slowmist/misttrack-skills
AI 與Web3 智能體安全綜合解決方案
一份以AI 與Web3 智能體為導向的綜合安全解決方案，旨在透過「五層遞進式數位堡壘」架構與ADSS 治理基線及MistEye、MistTrack、MistAgent 等能力協同，實現執行前預檢、執行中約束、執行後複盤的安全閉環。
https://mp.weixin.qq.com/s/mWBwBANlD7UchU9SqDp_cQ
交易安全自查表
接入前· OpenClaw 加固
檢查項 | 狀態 |
已升級至OpenClaw ≥ 2026.1.29 | □ |
已將監聽位址改為127.0.0.1 | □ |
Gateway 已啟用身分認證，非預設空白密碼 | □ |
已運行openclaw security audit --fix | □ |
logging.redactSensitive 已設為tools | □ |
接入前· 帳戶安全
檢查項 | 狀態 |
已啟用Google Authenticator（非簡訊2FA） | □ |
已啟用Passkey 無密碼登入 | □ |
已設定防釣魚碼 | □ |
已檢查設備管理中心，無陌生設備 | □ |
已設定資金密碼，與登入密碼不同 | □ |
已開立提幣白名單 | □ |
接入前· Skill 安全
檢查項 | 狀態 |
已檢閱所有已安裝Skill 的來源 | □ |
未安裝無來源說明的"增強版"或"漢化版" | □ |
已刪除所有不再使用的Skill | □ |
存取前· API Key 配置
檢查項 | 狀態 |
已建立子帳號專用API Key，未使用主帳號Key | □ |
已設定獨立Passphrase，與帳號密碼不同 | □ |
提現權限已關閉 | □ |
業務類型按需勾選，未使用全選 | □ |
合約/現貨權限按需最小化開放 | □ |
IP 白名單已綁定Agent 運行伺服器位址 | □ |
API Key 儲存在環境變數中，非硬編碼在程式碼裡 | □ |
.env 檔案已加入.gitignore | □ |
接入前· 資金隔離
檢查項 | 狀態 |
Agent 子帳號只劃撥了它所需的資金，非全部資產 | □ |
運作環境是自己控制的機器，非共享伺服器 | □ |
運行中· 監控
檢查項 | 狀態 |
已開啟交易/登入雙通道推播通知 | □ |
每週查看API 呼叫日誌（時間/IP/操作類型） | □ |
知道"立刻撤銷API Key"的操作路徑 | □ |
停用/更換· 清理
檢查項 | 狀態 |
停用Agent 時立即刪除對應API Key | □ |
子帳號資金已轉回主帳號 | □ |
程式碼庫中無殘留Key（含git 歷史記錄） | □ |
✅ 當上述檢查項都完成時，AI Agent 自動交易系統的整體安全風險將顯著降低。
