面向 MCP Server 的风险扫描、策略评估、运行时隔离与审计追踪最近一直在看 MCP 生态也在认真想一个问题如果 MCP Server 越来越多大家开始频繁安装、调用、组合第三方工具那么它的安全边界到底在哪里现在很多讨论都停留在“这个生态很有前景”但真正落到工程层面会马上遇到几个现实问题MCP Server 本质上就是可执行能力的入口。它可能访问本地文件、环境变量、网络、外部 API。一旦缺少验证、权限控制和审计能力风险不会停留在理论层面。所以我最近开始做一个开源项目MCP Aegis。这个项目的目标很直接不是做一个只有 PPT 的“安全平台”而是把 MCP 安全链路尽量做成真正能跑、能验证、能继续演进的工程化系统。https://github.com/xiao-zi-chen/mcp-aegis.git目前这个项目已经开源在 GitHub仓库名是 mcp-aegis。我想解决的核心问题我现在关注的不是“如何做一个 MCP 商店”而是更底层的问题一个 MCP Server 到底有没有明显风险这些风险应该如何被量化和归类当发现风险后系统应该给出什么策略决策决策之后运行时到底怎么限制它出现问题后审计链路能不能追得回来真正让我决定做这件事的不只是“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 风险扫描现在已经实现了一批静态分析能力主要检测这些风险点Shell 或子进程执行出站网络访问文件写入环境变量和潜在密钥读取监听端口暴露不安全安装说明manifest 生命周期脚本Python build hookprompt/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 summaryruntime planaudit events这一步很关键因为后面如果要继续做前端控制台、团队治理、审批流或者市场聚合器这层 API 会是基础。为什么我觉得这个方向值得做我现在的判断是MCP 生态真正缺的不是“再来一个工具列表网站”而是更接近基础设施的东西。尤其是下面几个点我觉得问题会越来越明显MCP Server 的能力边界天然比普通插件更敏感个人开发者和小团队很难自己补全安全治理缺少统一验证、策略执行和审计能力一旦生态扩张安全问题一定会从个例变成系统性问题所以我更愿意把 MCP Aegis 做成一个偏底层、偏严肃、可嵌入的安全能力层而不是只做“演示型项目”。目前项目状态实话实说现在它还不是完整版产品但已经不是一个空架子了。当前阶段更准确的定义应该是一个已经跑通核心链路的 MCP 安全防护 MVP它现在能做的是扫描 MCP Server 风险输出评分和策略决策生成受限运行计划识别本机运行时能力输出审计事件通过 API 查询 assessment 和 audit 数据接下来我会继续往这几个方向补签名验证与版本冻结供应链风险校验更真实的容器执行适配层更完整的前端控制台MCP 服务市场聚合与安全排序为什么选择开源这个项目我从一开始就想按开源方式推进因为这类安全基础设施如果不透明很难建立信任。我希望它后面能做到几件事规则和策略可以被审查扫描逻辑可以被复现风险判断可以被讨论和迭代社区可以一起补齐 MCP 生态安全标准结尾如果你也在关注 MCP、AI Agent Tooling、插件安全或者供应链治理欢迎一起交流。这个项目我会继续往“真正可用”推进而不是停在架构图和概念阶段。如果你对下面这些方向感兴趣也欢迎直接提建议希望star也可以互相交流