安全

本章介紹工具、程式碼和資金操作的技術防護。Chat 中識別使用者高風險決定的功能，請參閱財務安全提醒。

你告訴 Agent："運行這個 Python 腳本，把輸出給我看。" 腳本開始執行。它可能只是無害的數據處理， 也可能在最後一行悄悄調用 minara swap， 把 100 USDC 轉給攻擊者合約。

讓一個能夠轉移資金的 Agent 去運行代碼、輸入命令、 在你的機器上寫入文件，本質上是危險的。 本章專門講 Minara 如何應對這一問題： 每道防禦存在的原因，以及當前仍有哪些空白。

三個促成以下設計的場景

具體的攻擊案例能讓設計邏輯更清晰：

1. 粘貼攻擊。 用戶從 Discord 或論壇複製了一段"有用"的腳本， 讓 Agent 執行。腳本中間某處藏著一條 minara swap。
2. 多步注入。 Agent 先寫一個無害的輔助文件， 再追加一行內容，最後執行 python helper.py。 每步單獨看都是乾淨的，合在一起就會清空錢包。
3. 鏈上陷阱。 腳本調用 approve(unknown_address, MaxUint256) 或簽署 Permit2 消息。 這些命令本身並非"明顯惡意"， 與合法 DEX 集成的調用形式完全相同， 只是 spender 字段換成了攻擊者地址。

以上任何一種都無法靠單一檢查來攔截。 腳本會運行，文件會存在，合約調用是合法的。 真正阻止它們的，是下方几層相互獨立的防禦組合。

分層防禦：四道獨立閘門

Minara 在每個 LLM 可觸達的工具前面， 依次部署了四層獨立的安全防護。 獨立是刻意為之：攻擊者突破一層， 仍需面對其餘幾層，且各層的失效方式各不相同。

橙紅色的焦點層（OS jail）是唯一的物理邊界： 就算其上所有層全部失效，syscall 級隔離仍然生效。 其他三層是觸發線，提供可見性和中斷機會， 但有能力的攻擊者可以閱讀源碼並尋找缺口。 縱深防禦的意義在於組合，而非任何單一層。

第 1 層：命令守衛觸發線

對每條 shell 命令執行正則拒絕列表檢查。 對以下模式直接硬攔截，不做任何詢問： rm -rf /、sudo、mkfs、curl … | sh、fork 炸彈。 這層的目的不是捕獲一切（做不到，base64 後 eval 就能繞過）， 而是讓明顯的誤操作和最常見的提示詞注入單行命令 在此處大聲失敗，其餘的留給更高層處理。

這是觸發線，不是邊界。

第 2 層：OS jail（真正的邊界）

execute_code 或 terminal 啟動的每個子進程， 在 Linux 上都會被 bwrap 包裹， 在 macOS 上則由 sandbox-exec 處理。 在該沙箱內，進程無法讀取 ~/.ssh， 無法連接 169.254.169.254（雲實例元數據）， 無法在工作區目錄之外寫入文件。

就算所有更高層都被繞過（正則失效、提示詞注入、隱蔽混淆）， 攻擊代碼依然受限於 jail 所允許的 syscall 範圍。 這就是"物理邊界"的含義：由內核強制執行，而非依賴字符串匹配。

第 3 層：涉及資金的確認（兩步確認）

每個轉移資金的工具（兌換、買入、賣出、轉賬、 永續合約、啟用 Autopilot、激活工作流）都必須調用兩次：

1. 第一次調用（不帶 confirm 參數）： 處理器模擬交易並返回預覽（金額、路由、滑點、Gas 估算）， 不廣播。
2. 第二次調用（帶 confirm: true）： 此時處理器才真正簽名並廣播。

這條規則在每個處理器內部強制執行，並非對 LLM 的友情提示。 LLM 無法繞過這條規則：不帶 confirm: true 調用 swap_tokens， 只會得到預覽，永遠不會返回交易哈希。

詳見 涉及資金的確認。

第 4 層：腳本風險閘門

第 3 層能攔截直接的資金類工具調用， 但若 Python 腳本通過 subprocess.run(["minara", "swap", …]) 來執行呢？ 這種 shell 調用繞過了進程內工具註冊表，第 3 層根本看不到它。

第 4 層填補這一空白。 在 execute_code、terminal、write_file 或 patch 執行前， 腳本體會經過靜態分析：

• RED：自動拒絕（大規模刪除、IMDS / SSRF、憑據洩露、 容器逃逸、間接混淆加 sink、內聯私鑰簽名）。
• YELLOW：暫停並詢問用戶（資金類 CLI shell 調用、 approve / Permit2 / Safe 所有者變更、環境變量汙染、 特定路徑刪除、高風險包安裝）。
• GREEN：靜默執行（其他所有情況）。

詳見 Agent 如何判斷風險。

Minara 不能保護你免受哪些風險

以下是實話實說的清單。這些都不是 Bug，而是作用域邊界。 瞭解它們，才能在正確的地方保持警覺。

• 運行時動態構造的 payload。 腳本執行 os.system(a + b)， 其中 a 和 b 在運行時計算， 靜態分析無法預知拼接後的字符串內容。 第 2 層 jail 仍會限制子進程的能力， 但閘門會將 dynamic_command 標記為 YELLOW 並詢問你。 點確認前，先讀腳本。
• 惡意智能合約和 DApp。 代碼層無法判斷合約 0xabc… 是否是 drainer， 也無法判斷 cool-dapp.example.com 是否是釣魚克隆站。 這是 代幣 / DApp 掃描 的職責。
• 你已簽名的交易。 第 3 層會展示預覽。確認後，字節即被簽名並廣播。 點確認前，先讀預覽。
• 你自己的筆誤和 bug。 Minara 防範的是惡意意圖， 而非你不小心刪錯文件或轉錯地址。 兩步確認的存在，也是為了讓你有機會捕捉自己的失誤，請善加利用。

對日常使用意味著什麼

以下是日常使用的安全校準參考：

• 🟢 常規、無意外操作。 Pandas 數據處理、公開 HTTPS GET 請求、 從 CSV 生成圖表、npm ci --ignore-scripts， Minara 不會打斷你。
• 🟡 會出現確認彈窗（YELLOW）。 調用 minara swap、cast send、forge --broadcast 的腳本； ERC-20 approve 和 Permit2 簽名； 特定路徑刪除；bash <(curl …) 等進程替換； 設置 NODE_OPTIONS 或 LD_PRELOAD。 查看閘門給出的證據，再決定接受或取消。
• 🔴 硬拒絕（RED）。 大規模刪除（rm -rf *、rm -rf $UNSET/x）、 讀取 ~/.ssh/id_rsa、訪問 IMDS 端點、 容器逃逸嘗試、代碼中內聯私鑰。 這些模式沒有任何合法業務場景， 閘門會拒絕，帶 confirm: true 也無效。 遇到 RED，不要嘗試繞過。 查看腳本想要執行的操作，基本上都是提示詞注入或複製粘貼的攻擊。
• ⚠️ 你的職責。 私鑰不要進代碼倉庫。 .env 文件執行 chmod 600。 在交互式會話中不要設置 MINARA_SKIP_FUND_CONFIRM 或 DISABLE_SCRIPT_RISK_GATE。 確認前先讀第 3 層預覽。

深入瞭解

本章面向操作員，關注"如何安全使用 Minara"。 如需瞭解正式的信任模型、威脅分類法和漏洞披露政策， 請參閱倉庫中的 SECURITY.md。 該文檔面向安全研究人員；本章面向使用 Minara 進行交易的用戶。

繼續閱讀：

• 涉及資金的確認：每個資金類工具的兩步流程。
• 腳本風險閘門：Agent 如何判斷 RED / YELLOW / GREEN。
• 審計與覆蓋：查看決策、授予工作流豁免、緊急關閉開關。