我们如何构建自动化的 MCP 安全扫描器（以及我们的发现）
Source: Dev.to
我们要解决的问题
当你安装一个 MCP 服务器时，你就在给 AI 代理赋予新的能力。该服务器可能会读取你的文件系统、执行 shell 命令，或调用外部 API。但在代码运行在你的机器上之前，谁审计过它？
没有人。直到现在。
在 AgentAudit，我们构建了一个自动化的多代理流水线，审计 MCP 服务器、npm 包、pip 包以及 AgentSkills——并在你的代理接触它们之前标记安全风险。
架构
我们的审计流水线并行运行三个专门的子代理，每个都有不同的安全视角：
Agent 1: 静态分析
扫描源代码中已知的漏洞模式：
- 未经消毒的 shell 命令注入（
child_process.exec与用户输入） - 硬编码的凭证和 API 密钥
- 过于宽泛的文件系统访问权限
- 不安全的反序列化
Agent 2: 能力图分析
我们解析 MCP 服务器的 tool schema declarations——即每个工具能做什么的 JSON 描述——并将其与代码实际行为进行交叉对照。
一个声明只读取天气数据却在内部能够访问你的文件系统的天气 MCP 服务器？这就是红旗。我们会捕捉到这种差距。
Agent 3: 依赖链审计
递归扫描依赖树，查找：
- 传递依赖中的已知 CVE
- 权限异常宽泛的包
- 供应链异常（例如，一个包在两周前更换了维护者）
多代理共识
每个代理生成结构化的审计报告。共识层随后：
- 去重 重复的发现
- 分配严重性 基于在代理上下文中的可利用性
- 生成可信分数（0–100）用于该包
为什么要多代理共识？因为单一模型会产生幻觉。三个拥有不同系统提示的模型相互交叉检查，就不会了。
结果（截至目前）
在对 194 个包进行 211 份独立审计报告后：
| 严重性 | 数量 | 总计百分比 |
|---|---|---|
| 🔴 致命 | 5 | 4.2% |
| 🟠 高危 | 9 | 7.6% |
| 🟡 中等 | 63 | 53.4% |
| 🟢 低危 | 41 | 34.7% |
平均可信分数：98/100。 MCP 生态系统大体安全——但这 14 条关键/高危发现代表了真实且可被利用的漏洞。
最常见的模式
- 通过提示输入进行 Shell 命令注入——精心构造的提示会导致 MCP 服务器执行任意 shell 命令
- 环境变量泄漏——API 密钥意外出现在 LLM 上下文窗口中
- 过于宽泛的文件系统访问——服务器请求完整的
~/访问权限，而实际只需要一个目录
什么使 MCP 安全性与众不同
传统扫描器（Snyk、Socket）在已知 CVE 和供应链风险方面表现出色。但 MCP 服务器引入了不同的威胁模型：
- 攻击向量是提示（prompt），而非网络
- “用户”是 AI 代理——它不会注意到可疑行为
- 执行上下文 是你的本地机器或生产服务器
一个包可以通过所有传统安全检查，却仍然可以通过对抗性提示被利用。这正是我们要填补的空白。
试一试
在 agentaudit.dev 审计任何 MCP 服务器、npm 包或 pip 包。
完整报告： State of MCP Security 2026
每条发现都会在交付给你之前由三个独立的 AI 代理交叉验证。