安全

本章介绍工具、代码和资金操作的技术防护。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。
• 审计与覆盖：查看决策、授予工作流豁免、紧急关闭开关。