这篇文章记录了我为什么开始做 MCP Aegis，以及我对 MCP Server 风险扫描、策略决策、沙箱执行和审计追踪这条安全链路的理解。

原文链接：https://blog.csdn.net/xyc_yyds/article/details/159215539

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

MCP Aegis 封面

一、为什么开始做这个项目

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

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

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

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

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

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

二、我真正想解决的问题

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

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

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

以 OpenClaw 为例，公开安全资料已经说明了一件事：这类 Agent 平台默认就处在高风险边界里。
官方文档明确提到，它会接触 Shell 执行、文件读写、网络访问、浏览器控制以及外部不可信内容处理，这些能力一旦组合起来，攻击面会迅速放大。

参考资料：

OpenClaw 安全资料

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

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

三、MCP Aegis 当前已经做了什么

1. MCP Server 风险扫描

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

  • Shell 或子进程执行
  • 出站网络访问
  • 文件写入
  • 环境变量和潜在密钥读取
  • 监听端口暴露
  • 不安全安装说明
  • manifest 生命周期脚本
  • Python build hook
  • prompt/tool 元数据投毒
  • 可疑凭证请求

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

2. 风险评分和策略决策

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

当前已经支持：

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

系统不仅会告诉你“这里有问题”，还会继续告诉你：

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

3. 沙箱执行计划

这一块我比较重视，因为很多安全项目只做到“检测”，并没有真正进入“控制”。

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

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

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

4. 运行时能力识别

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

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

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

5. 审计查询接口

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

当前已经支持查询：

  • 服务器列表
  • 策略列表
  • assessment 结果
  • assessment summary
  • runtime plan
  • audit events

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

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

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

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

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

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

五、目前项目状态

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

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

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

它现在已经能做这些事情：

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

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

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

六、为什么选择开源

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

我希望它后面能做到这些事情：

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

结尾

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

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