面对open claw的安全问题：我开源一个 MCP 安全检测项目

面向 MCP Server 的风险扫描、策略评估、运行时隔离与审计追踪

最近一直在看 MCP 生态，也在认真想一个问题：

如果 MCP Server 越来越多，大家开始频繁安装、调用、组合第三方工具，那么它的安全边界到底在哪里？

现在很多讨论都停留在“这个生态很有前景”，但真正落到工程层面，会马上遇到几个现实问题：

1. MCP Server 本质上就是可执行能力的入口。
2. 它可能访问本地文件、环境变量、网络、外部 API。
3. 一旦缺少验证、权限控制和审计能力，风险不会停留在理论层面。

所以我最近开始做一个开源项目：MCP Aegis。

这个项目的目标很直接，不是做一个只有 PPT 的“安全平台”，而是把 MCP 安全链路尽量做成真正能跑、能验证、能继续演进的工程化系统。

https://github.com/xiao-zi-chen/mcp-aegis.git

目前这个项目已经开源在 GitHub，仓库名是 mcp-aegis。

我想解决的核心问题

我现在关注的不是“如何做一个 MCP 商店”，而是更底层的问题：

1. 一个 MCP Server 到底有没有明显风险？
2. 这些风险应该如何被量化和归类？
3. 当发现风险后，系统应该给出什么策略决策？
4. 决策之后，运行时到底怎么限制它？
5. 出现问题后，审计链路能不能追得回来？

真正让我决定做这件事的，不只是“AI Agent 很火”，而是我看到了一些已经公开暴露出来的问题。

以 OpenClaw 为例，公开安全资料已经非常明确地说明了一件事：这类 Agent 平台默认就处在一个高风险边界里。OpenClaw 官方安全文档直接把核心风险讲得很直白，它本质上会接触 Shell 执行、文件读写、网络访问、浏览器控制以及外部不可信内容处理，这些能力一旦组合起来，攻击面就会迅速放大。官方文档也明确强调，它并不是一个面向“敌对多租户”场景设计的安全隔离边界，而更像是一个默认信任单一操作者的个人助理模型。
参考：https://docs.openclaw.ai/gateway/security

更关键的是，这类风险并不是停留在理论层面。公开资料里，2026 年 1 月 30 日 出现了与 OpenClaw 相关的 CVE-2026-25253，而 2026 年 2 月 4 日 又有社区资料记录了 341 个恶意 ClawHub skills 的问题。即便不讨论每个细节是否都完全一致，至少有一点已经足够明确：Agent 生态一旦开始承载“工具调用 + 本地权限 + 外部扩展市场”，安全问题就会从配置疏忽迅速演变成供应链问题、执行边界问题和审计追踪问题。
参考：https://clawdocs.org/security/overview/

也正因为如此，我做 MCP Aegis 的出发点并不是再做一个“工具列表网站”，而是想补上 MCP 生态最容易被忽略、但后面一定会变成基础设施的那一层：

风险检测 -> 策略决策 -> 沙箱执行 -> 审计追踪

MCP Aegis 当前已经做了什么

目前项目已经做出的能力，主要有这几块。

1. MCP Server 风险扫描
现在已经实现了一批静态分析能力，主要检测这些风险点：

1. Shell 或子进程执行
2. 出站网络访问
3. 文件写入
4. 环境变量和潜在密钥读取
5. 监听端口暴露
6. 不安全安装说明
7. manifest 生命周期脚本
8. Python build hook
9. prompt/tool 元数据投毒

1. 可疑凭证请求

这意味着项目已经不只是“扫一眼 package.json”，而是能对 MCP Server 代码和包元数据做初步风险识别。

2. 风险评分和策略决策
扫描出来的 finding 不只是罗列出来，而是会进一步进入评分和策略判断流程。

当前已经支持：

1. 风险分数计算
2. 风险类别聚合
3. 策略规则匹配
4. 运行时 profile 生成
5. 推荐动作输出

也就是说，系统不会只告诉你“这里有问题”，还会进一步告诉你：

1. 应该 allow、review、restricted 还是 deny
2. 是否要求人工审批
3. 是否禁止远程访问
4. 是否应该走受限沙箱执行

3. 沙箱执行计划
这一块是我比较重视的，因为很多安全项目只做到“检测”，不真正进入“控制”。

当前 MCP Aegis 已经能基于策略生成运行时计划，包括：

1. 只读根文件系统
2. 网络禁用
3. 可写路径限制
4. 环境变量白名单
5. 资源限制
6. Docker 启动命令草案
7. 审计事件输出

这意味着发现高风险 MCP Server 后，系统不是只给一段建议，而是可以继续往“怎么安全运行”推进。

4. 运行时能力识别
这一点虽然看起来小，但很重要。

比如在我当前这台机器上，并没有安装 Docker。现在项目已经可以在运行前真实识别这一点，并在结果里明确返回：

1. 当前运行引擎是什么
2. 对应二进制是否存在
3. daemon 是否可达
4. 是否支持实际执行
5. 失败原因是什么

这类信息会直接进入 runtimeCapabilities，而不是让用户靠猜。

5. 审计查询接口
我不想把这个项目做成“一次扫描就结束”的工具，所以加了 control-api 这一层。

当前已经支持查询：

1. 服务器列表
2. 策略列表
3. assessment 结果
4. assessment summary
5. runtime plan
6. audit events

这一步很关键，因为后面如果要继续做前端控制台、团队治理、审批流或者市场聚合器，这层 API 会是基础。

为什么我觉得这个方向值得做

我现在的判断是，MCP 生态真正缺的不是“再来一个工具列表网站”，而是更接近基础设施的东西。

尤其是下面几个点，我觉得问题会越来越明显：

1. MCP Server 的能力边界天然比普通插件更敏感
2. 个人开发者和小团队很难自己补全安全治理
3. 缺少统一验证、策略执行和审计能力
4. 一旦生态扩张，安全问题一定会从个例变成系统性问题

所以我更愿意把 MCP Aegis 做成一个偏底层、偏严肃、可嵌入的安全能力层，而不是只做“演示型项目”。

目前项目状态

实话实说，现在它还不是完整版产品，但已经不是一个空架子了。

当前阶段更准确的定义应该是：

一个已经跑通核心链路的 MCP 安全防护 MVP

它现在能做的是：

1. 扫描 MCP Server 风险
2. 输出评分和策略决策
3. 生成受限运行计划
4. 识别本机运行时能力
5. 输出审计事件
6. 通过 API 查询 assessment 和 audit 数据

接下来我会继续往这几个方向补：

1. 签名验证与版本冻结
2. 供应链风险校验
3. 更真实的容器执行适配层
4. 更完整的前端控制台
5. MCP 服务市场聚合与安全排序

为什么选择开源
这个项目我从一开始就想按开源方式推进，因为这类安全基础设施如果不透明，很难建立信任。

我希望它后面能做到几件事：

1. 规则和策略可以被审查
2. 扫描逻辑可以被复现
3. 风险判断可以被讨论和迭代
4. 社区可以一起补齐 MCP 生态安全标准

结尾
如果你也在关注 MCP、AI Agent Tooling、插件安全或者供应链治理，欢迎一起交流。

这个项目我会继续往“真正可用”推进，而不是停在架构图和概念阶段。

如果你对下面这些方向感兴趣，也欢迎直接提建议（希望star也可以互相交流）