一句话看懂：开发者Bhavesh Thapar构建了一个名为mcp-audit的沙盒工具，在Docker容器内用strace监控了70个MCP服务器（20个来自npm下载榜，50个来自长尾分布）的启动行为，记录了它们实际打开的网络连接和读取的文件，验证了“官方注册中心只验证谁发布了服务器，而不验证服务器运行后做了什么”这一安全盲区。
事件核心：发生了什么
该项目在隔离的Docker容器中启动每个MCP服务器，通过系统调用级别（openat和connect）记录文件访问和网络连接行为。环境里预先放置了一个伪装凭证作为“金丝雀”——任何试图读取或传输该凭证的操作都会被捕捉。结果是：67台服务器启动时完全干净；3台（okx-trade-mcp、razorpay/blade-mcp、notebooklm-mcp-server）在启动时发出了外部HTTPS连接，但这些连接与其声称的功能一致（如交易所集成、GitHub请求、CDN端点）；1台（bullmq-mcp）读入了/etc/passwd文件，经核实是标准glibc用户查询，数据从未离开进程。没有任何服务器传输了敏感数据。
为什么重要
当前MCP生态的安全信任几乎完全依赖静态分析（扫描源代码和元数据），而MCP官方注册中心只验证发布者身份。静态扫描会遗漏只在运行时才暴露的风险：一台服务器连接到与其描述无关的主机、读取不属于它的凭据或文件，或者通过后续版本更新偷偷改变行为（“拉地毯”攻击）。这个项目首次以运行时行为审计的方式填补了这一缺口——它证明了行为层面的监控可以发现静态分析看不到的问题，例如“外联”行为。从更广阔的视角看，随着MCP（模型上下文协议）在AI Agent和工具编排中逐步采用，运行时安全将成为整个AI应用基础设施的关键一环。
对用户/开发者/创作者的影响
AI应用开发者在集成第三方MCP服务器时，不应仅依赖其功能描述和静态代码审查，而应将其在沙盒中运行并观察实际行为——本项目的工具链可直接复用。对于企业采购或AI平台运维者，上线一个MCP服务器前至少需要验证：它在启动时是否产生了意外的外联？是否读取了环境变量中的敏感凭证？当前mcp-audit只覆盖启动和空闲行为，尚未跟踪工具调用（tool-call）阶段的流量，但已提供了可操作的基线。对AI Agent框架维护者来说，将此类运行时审计纳入包管理或注册验证流程，能显著降低供应链风险。
值得关注的后续
第一，项目路线图明确将推出工具调用追踪——驱动每台服务器执行其所有公开的工具并记录行为，这是比启动检查更具价值的风险点，尤其对那3台已发现外联的服务器。第二，版本差异检测功能可以对比不同版本的MCP服务器行为变化，这是防范“拉地毯”攻击的最关键场景。第三，如果该项目未来能将行为摘要以稳定、可比对的数据格式输出，供客户端或注册中心在安装前消费，将有可能推动社区形成新的MCP安全标准。
来源：github.com
