浏览器内扫描 MCP 与智能体配置风险
这款免费开源扫描器在浏览器内静态分析 JSON、YAML 和提示词,检查未固定版本的 npx 执行、过宽目录挂载、硬编码密钥等风险。作者称配置无需上传,并支持生成 Markdown 审计报告。
AI 深度解读
把 MCP 接到文件系统、数据库和生产工具后,Agent 能做多少事,往往取决于几行配置。一次未固定版本的 npx 执行、一个过宽的目录挂载,或者跳过确认的写操作,都可能把工具能力变成安全风险。
作者为此开发了 MCP & AI Agent Security Scanner:在浏览器里静态检查配置,提前找出高风险权限组合。它的价值是给部署前审查加一道低成本检查,但扫描通过能证明多少,还要看规则覆盖了什么。
为什么要把配置检查留在浏览器里
MCP 配置里可能同时包含生产数据库 URI、API 密钥和内部系统提示词。把这些内容上传到第三方扫描服务,会增加一份数据暴露面。
作者选择客户端静态分析(SAST),也就是读取配置文本、匹配风险特征,不实际运行 Agent。工具支持即时解析 JSON、YAML 和纯文本提示词,并通过名为 CVSS-AI 的评分生成暴露评级,支持一键导出 Markdown 审计报告。
作者宣称它「100% Air-Gapped」:零遥测、零网络请求,数据只留在本机浏览器内存中。不过,原文没有提供网络检查记录,也没解释网页如何加载及验证离线运行。这些是产品声明,不能当作已经独立验证的结论。
CVSS-AI 的计算公式、权重和校准方法也没有交代。可以拿它安排排查顺序,但原文不足以支持把分数当作通用风险标准。
它检查的是 Agent 获得了哪些危险权限
作者把规则对应到 OWASP LLM Top 10 中的 LLM06: Excessive Agency 和 LLM01: Prompt Injection。前者关注 Agent 权限过大,后者关注恶意输入诱导模型改变行为。
扫描器列出了六类检查:
| 规则 | 要找的配置特征 |
|---|---|
| ARL-MCP-001 | 直接启动 bash、sh,或使用带有 --allow-all 的 npx,且缺少容器或 microVM 隔离。 |
| ARL-MCP-002 | 文件系统 MCP 暴露 /etc/、/、C:\ 等敏感或过宽路径。 |
| ARL-MCP-003 | JSON 环境变量块里直接写入 sk-proj-...、GitHub tokens 或 AWS keys。 |
| ARL-MCP-004 | 提供原始 SQL 执行能力,或存在 readOnly: false 等写权限配置,并缺少参数化约束。 |
| ARL-MCP-005 | 网页抓取或 fetch 工具可以访问任意 URL,形成 SSRF 或数据外传入口。 |
| ARL-MCP-007 | 高影响工具设置 alwaysAllow,让修改状态的操作绕过人工确认(HITL)。 |
这些规则共同关注一件事:模型一旦被误导,工具权限会把后果放大到什么程度。
例如,允许访问任意 URL 不等于已经发生提示词注入,但它可能为间接注入后的数据外传提供通道。同样,扫描到 alwaysAllow 只是审查起点,还要看对应工具究竟能执行什么操作。
开头提到的「未固定版本的 npx 执行」也是风险,但原文没有明确说明是否存在专门检查版本固定的规则,不能自行补上这项能力。
修复要落到权限和运行环境上
作者给了三条整改方向:隔离工具、限制只读范围、在运行时注入密钥。
对文件系统 MCP,具体做法是只开放专用工作目录,并默认只读。密钥则通过环境密钥库在运行时注入,避免直接写进 mcp.json。
工具隔离方面,作者把 Firecracker 和 gVisor 放在临时 microVM 的建议中。这里需要分清:Firecracker 提供 microVM,gVisor 属于容器沙箱方案,两者不是同一种隔离机制。
发现风险靠扫描规则,限制破坏范围靠实际权限。
配置里出现隔离、只读或密钥管理的字样,并不能证明部署后的约束已经生效,仍需结合运行环境检查。
我的判断
这个方向值得采用。对前端和全栈开发者来说,MCP 配置已经成为开发环境权限的一部分,把它加入部署前审查很合理。客户端处理也切中了配置不便上传的实际顾虑。
但原文没有展示检测准确率、误报率、漏报率,也没有与其他扫描方式做对照。作者邀请贡献更多 regex 规则,说明文本模式匹配是其规则扩展方式之一;至于它能否理解多文件引用、继承关系和动态生成配置,原文没说清。
尤其要区分「发现可疑配置」和「证明存在可利用漏洞」。readOnly: false 不能独自说明数据库最终权限,没写沙箱字段也不能证明部署环境没有隔离。反过来,配置看起来安全,也不能排除运行时风险。
与人工审查相比,它适合批量找显眼问题;与容器、数据库权限和人工确认机制相比,它提供的是检查能力。原文支持把它当作辅助 linter,还不足以把它当作安全准入的唯一依据。
能拿来做什么
- 检查本地 AI 编程工具的 mcp.json,优先核对目录范围、明文密钥和 alwaysAllow,并逐项确认对应工具的实际能力。
- 给连接 Node 开发项目的文件系统 MCP 单独划定工作目录,按任务需要开放写权限,避免直接暴露整个用户目录或根目录。
- 为数据库 Agent 同时检查配置与数据库角色权限,核实 readOnly: false、原始 SQL 工具和写操作确认机制,不能只看扫描报告。
- 把 Markdown 报告放进团队配置审查流程,对每条告警记录实际权限和处理结果;评分方法未明确前,先不要直接用 CVSS-AI 分数决定能否上线。