安全硬核拆解：mercury-agent的SSRF防护、Shell黑名单与沙箱机制全景解析

【免费下载链接】mercury-agentSoul-driven AI agent with permission-hardened tools, token budgets, and multi-channel access. Runs 24/7 from CLI, Telegram or More.项目地址: https://gitcode.com/gh_mirrors/me/mercury-agent

mercury-agent 是一个可以 7×24 小时从 CLI、Telegram 等渠道运行的 AI 智能体（AI Agent），能执行 Shell 命令、抓取网页、读写文件——这也正是它最需要"缰绳"的原因。本文带你硬核拆解 mercury-agent 的三大安全机制：SSRF 防护（拦截网络内探）、Shell 黑名单（三级命令管控）与软件沙箱（工作目录隔离、超时熔断与机密脱敏），看看它如何让一个"全天候在线的 AI"变得可信。

一、为什么 24/7 在线的 AI 助手最需要"约束"

想象一下：你的 AI 助手挂在服务器上整夜运行，随时可以从 Telegram 被唤醒，替你跑命令、抓网页、改文件。它听起来很爽，但风险同样真实：

• 🕷️SSRF（服务端请求伪造）：攻击者诱导 AI 去抓取http://127.0.0.1:6379或云服务器的元数据接口169.254.169.254，把你的内网信息"反射"回对话里；
• 💣危险命令：一句rm -rf /或shutdown就能让机器"告别"；
• 📄越权文件访问：AI 顺着符号链接摸出工作目录，读写你根本没授权的文件。

mercury-agent 的答案不是"信任模型会听话"，而是三道独立防线，全部在工具执行层强制执行，模型"求情"也没用：

二、SSRF 防护：六层校验拦截 AI 的"网络探针"

什么是 SSRF，为什么 AI 是高危目标

SSRF（Server-Side Request Forgery，服务端请求伪造）的本质是：让一台能访问内网的服务器，替你访问你不该访问的地址。普通程序请求的地址由开发者写死，而 AI 的请求地址来自对话——攻击者只要在聊天里塞一句"帮我看看这个链接"，就可能把探针伸进你的内网。

mercury-agent 在 1.2.3 版本把fetch_url与install_skill等所有会出网的工具全部收口到同一个守卫 guardedFetch，并针对 issue #108 的负责任披露做了加固，完整处置记录见 ssrf-108-response.md。

SSRF 守卫的六层拦截

这套设计值得细品的地方是第 4 层：很多实现"先校验、再请求"，中间留出的空隙恰好是 DNS 重绑定攻击的窗口。mercury-agent 让连接复用的恰好是校验过的那个 IP，把窗口彻底焊死。

💡 如果你确实在内网环境需要让 AI 抓取内网资源，可以设置环境变量MERCURY_ALLOW_PRIVATE_FETCH=1显式放行——默认是关的，fail closed（失败即拒绝）才是默认姿态。

三、Shell 黑名单：三级命令管控体系

mercury-agent 把 Shell 命令分成三个"等级"，规则集中定义在 blocklist.ts，并写入~/.mercury/permissions.yaml供你自定义。

1️⃣ 永远不执行：黑名单（Blocked）

sudo、rm -rf /（含rm -fr换位变体）、mkfs、dd if=*、shutdown、reboot、fork 炸弹:(){ :|:& };:、Windows 下的format、del /s /q C:\*……这些命令无论什么权限模式、用户如何同意，都直接拒绝，没有任何商量余地。

2️⃣ 自动放行：安全只读白名单

ls、cat、grep、find、git status、git diff等只读命令在任何模式下都免打扰，这是"不烦人"体验的来源。

3️⃣ 必须审批：危险但合理的操作

git push、npm publish、docker、rm -rf *、curl * | sh这类"可能出事"的命令，在 Ask Me 模式下会弹出确认（Yes / No / Always），Allow All 模式下才自动放行。

关键细节：命令链逐段检查

最狡猾的攻击是"借白名单洗白"：echo $(rm -rf ~)开头是白名单里的echo，整串看起来无害。mercury-agent 的 splitShellSegments 会把命令按;、&&、管道、$()、反引号、子 shell 边界逐段拆开，每一段单独过黑名单——即使藏在双引号里的命令替换也会被抽出检查。类似地，find -delete、find -exec、cat > 文件（重定向改写）、$HOME/~变量展开等"伪装成只读"的花样，在 isSafeReadSegment 里都被点名不通过。

四、软件沙箱：给命令执行套上"笼子"

mercury-agent 没有依赖操作系统级沙箱，而是在 run-command.ts 与 permissions.ts 里用软件手段搭了一个等效的笼子，共四块：

• 📍工作目录围栏（cwdOnly）：命令里出现工作目录之外的绝对路径、../或 Windows 盘符路径时，必须先通过文件系统作用域审批，否则直接拒；
• ⏱️超时熔断：命令默认 120 秒超时（最长 600 秒），到点先发SIGTERM，5 秒宽限后升级SIGKILL，杜绝"僵尸构建"拖死整个 Agent；
• 📦输出限额：stdout/stderr 各限 1MB 缓冲、回传给模型的正文限 64KB，防止恶意网页或命令输出撑爆内存、塞爆对话上下文；
• 🎭机密脱敏（Secret Redaction）：命令输出回传前经过 redactSecrets，sk-开头的 API Key、GitHub Token、AWSAKIA密钥、SlackxoxToken、password=xxx等一律打码（sk-1234****abcd），API 密钥不会悄悄溜进会话日志。

文件层面还有两道保险：写入路径会做符号链接规范化（canonicalize），scope/link -> /etc这种"字面在作用域内、实际指向外面"的写法会被识别并拒绝（见 canonicalizePath）；Web 面板的本地"全放行"设置永远不会静默提升来自远程通道的请求（见 isGlobalAutoApproveActive）。

五、上手配置与自查清单

1. 📝查看/修改命令策略：编辑~/.mercury/permissions.yaml，blocked/autoApproved/needsApproval三个列表都可自定义，自定义项与默认值合并生效（默认项无法被删掉，防误伤）；
2. 🔐选对权限模式：启动时选Ask Me（默认，高风险操作逐次确认）或Allow All（全程自动放行，重启即重置）——详细差异表见 permissions 文档；
3. 🧪验证 SSRF 拦截：让 Agent 抓取一个指向http://127.0.0.1:xxxx的地址，应看到Blocked: ... is a private/internal address (SSRF protection)的拒绝信息；
4. 👨‍🔧一键体检：跑mercury doctor检查运行环境与配置，参考 doctor 命令文档；
5. 📋安全更新追踪：SSRF 守卫、rm -fr变体入黑名单、0600 凭据文件、随机 Web 初始密码等变更，均可在 CHANGELOG.md 的 1.2.3 安全章节查到。

六、写在最后

mercury-agent 的安全设计哲学可以概括为一句话：永远不要相信模型会"自觉"，要相信执行层会"把关"。

• SSRF 守卫把"校验过的地址"钉进连接，连 DNS 重绑定都无隙可乘；
• Shell 黑名单三级分层 + 命令链逐段审查，让"借白名单洗白"的把戏失效；
• 软件沙箱用工作目录围栏、超时熔断、输出限额和机密脱敏，把一条命令能造成的爆炸半径压到最小。

对于想自建 24/7 AI 助手（Telegram Bot、个人数字员工）的开发者来说，这份"SSRF 防护 + 命令黑名单 + 沙箱"的三层组合，本身就是一份可直接借鉴的安全清单。

【免费下载链接】mercury-agentSoul-driven AI agent with permission-hardened tools, token budgets, and multi-channel access. Runs 24/7 from CLI, Telegram or More.项目地址: https://gitcode.com/gh_mirrors/me/mercury-agent