短答案
为什么 MCP 安全会在 2025 到 2026 年迅速升温
MCP 安全最佳实践，指的是一整套用来防止 AI 智能体信任错误服务器、复用错误权限或听信错误文本的控制。最清晰的思路，是把 MCP 拆成四层：发现与供应链、身份与会话、运行时权限，以及面向模型的不受信内容。
官方文档、OWASP、Microsoft、Docker、Palo Alto 与多篇新论文得出的结论高度一致：会“说 MCP”并不意味着服务器可信；用了 OAuth 也不意味着整个工作流就安全。
四层 MCP 安全模型
| 层 | 通常会坏在哪里 | 最佳实践 |
|---|---|---|
| 发现与供应链 | 错拼域名、恶意服务器、静默元数据漂移、第三方审核不足 | 可信注册表、来源验证、版本固定、校验和、分阶段发布、审批日志 |
| 身份与会话 | token 透传、共享授权状态、调用者混淆、scope 过宽、重定向处理松散 | OAuth 2.1、PKCE、精确重定向验证、短时 scope、按会话绑定、禁止全局复用 |
| 运行时与权限 | 文件系统 / 网络权限过大、秘密暴露、危险的本地 HTTP 暴露、失控动作 | 容器或等价沙箱、只读挂载、出网限制、配额、最小权限 |
| 面向模型的内容 | 工具投毒、提示词注入、清单 / 提示 / 资源 / 工具输出中的隐藏指令 | 把元数据当不受信内容、做 schema 校验、任务隔离、审批门与输入检查 |
现实中最值得优先落地的六条做法
第一，发现阶段必须走可信注册表或 allowlist，记录是谁批准了哪个服务器，并固定版本。第二，授权不能停留在“某处有 OAuth”，而要绑定到“这个调用者、这个会话、这次调用”。
第三，对第三方或高风险 MCP 服务器做容器化或等价沙箱隔离。第四，把工具名称、描述、清单、提示模板与外部资源统统当成不受信文本。第五，对高影响动作保留审批。第六，持续监控、复验，并准备好一键 kill switch。
- 优先使用可信注册表，并在批准后固定版本与哈希
- 对 token、会话状态与调用者身份做按连接绑定，而不是全局缓存
- 对第三方服务器启用容器 / 沙箱、只读挂载与最小出网
- 对工具输入做预览，对敏感动作保留确认
- 持续记录工具使用、批准记录与异常读写，并在漂移时快速下线
Veridicus Scan 在这条链路里最适合做什么
像这样的指南不应该假装“一个产品就能解决 MCP 安全”。Veridicus Scan 也不是为此设计的。它最合适的位置，是本地输入层与复核层：当工作流会把 URL、提取文本、文件或工具可见内容喂给模型时，先检查这些材料，再交给智能体。
如果工作流还需要运行时复核，那么 Scope Tools、Guard Plan 与 Gate Action 这类方法更适合放在监督层，而不是代替授权、最小权限或运行时隔离。
常见问题
什么是 MCP 安全最佳实践？
就是一组用于防止 AI 智能体信任错误服务器、复用错误权限或听信错误文本的控制层。核心包括可信发现、调用者绑定授权、运行时隔离、审批门和把工具元数据视为不受信内容。
只有 OAuth 就够了吗？
不够。OAuth 很重要，但它不会自动把每次工具调用绑定到真实调用者，也无法自动解决运行时权限过大。
MCP 服务器应该跑在容器里吗？
对第三方或高风险服务器来说，容器通常是最实用的默认选项，因为它能显著降低爆炸半径。