引言
模型上下文协议(Model Context Protocol, MCP)[1]是一个开放标准，为 AI 模型和智能代理应用连接各种数据源和工具提供了统一方式。它使 AI 应用能够获取上下文信息 (文档、数据库记录、API 数据、网络搜索结果等)。这种能力虽然强大，但也带来了网络安全问题。
当 AI 助手通过 MCP 访问敏感文件、数据库或服务时，组织必须确保这些交互是安全的、经过认证的和可审计的。
MCP 架构 (主机、客户端、服务器) 本身就创建了可以应用安全控制的清晰边界点。下面我们将探讨 MCP 如何用于安全目的 (从保护模型交互和记录操作，到防御恶意输入和确保数据保护合规性)。
MCP 及其安全架构概述
MCP 采用客户端-服务器模型，角色划分明确。
MCP 主机 (AI 应用或代理) 通过 MCP 客户端库连接到一个或多个 MCP 服务器。
每个服务器通过标准化协议提供特定功能 (如读取文件、查询数据库或调用 API)。这就是为什么人们将 MCP 称为"AI 应用的 USB-C 接口"。
这种架构设计引入了安全边界：主机和服务器只通过 MCP 协议通信，这意味着可以在协议层强制执行安全策略。例如，MCP 服务器可以限制它返回的文件或数据库条目，无论 AI 模型请求什么内容。同样，主机可以决定信任并连接哪些服务器。这种组件的明确划分让应用零信任原则 (将每个组件和请求视为不可信，直到验证) 变得更加容易。
使用 MCP 时的安全考虑
下表概述了实施 MCP 时需要注意的几个安全问题。
|
|
|
|
|
没有适当的监控机制，AI 助手可能悄悄访问或修改敏感数据。被攻击的提示或恶意指令可能利用合法的 MCP 连接窃取机密信息。
|
|
|
标准 MCP 实现没有内置的审批流程，这使得为关键操作 (如数据库修改或金融交易) 实施人工介入变得困难。
|
|
|
尽管 MCP 支持强大的集成功能，但它本身并不提供全面的提示监控。这可能会因记录的交互信息不完整而阻碍安全调查和合规报告。
|
|
|
管理多个安全需求不同的 MCP 服务器访问权限非常复杂。如果没有适当的控制措施，确保每个组件以最小权限运行会变得困难，增加敏感操作暴露的风险。
|
安全和认证的模型交互
MCP 的主要优势之一是能够实现 AI 模型、MCP 服务器、工具和数据源之间的交互。传统的"插件"式集成或自定义脚本可能会在没有强大认证的情况下暴露数据。
下表包含实施 MCP 传输机制时的关键安全考虑因素，以及最佳实践和实施建议：
|
|
|
|
|
|
采用标准化协议- 使用成熟的协议，如 OAuth 2.0/OAuth 2.1 或 OpenID Connect- 示例：使用带有 OAuth 2.0 策略的 Passport.js 的 Node.js 服务存储和验证客户端凭证- 使用加密数据库 (如 CyberArk Conjur, HashiCorp Vault) 安全存储凭证使用安全令牌处理- 使用具有过期和轮换机制的 JWT- 安全令牌存储 (HttpOnly cookies，安全移动存储)- 实施令牌撤销机制实施授权检查- 使用基于角色的访问控制 (RBAC) 和访问控制列表 (ACL)- 集成中间件以强制执行策略
|
- 标准协议为管理令牌提供了安全框架- 凭证的安全存储和处理减少了泄露风险- 通过 RBAC 和 ACL 强制授权确保只有授权用户才能访问敏感操作或数据
|
|
|
使用 TLS 进行网络传输- 配置具有有效 TLS 证书的 HTTPS (如 Let's Encrypt 或组织 CA)- 强制使用强密码套件并禁用过时协议净化输入数据- 使用输入验证库清理用户输入- 示例：Python 的 bleach 库，JavaScript 的 DOMPurify
|
- TLS 加密保护传输中的数据免受窃听或中间人攻击- 净化输入可防止注入攻击并确保数据完整性
|
|
|
实施速率限制- 使用中间件或 API 网关 (如 Node.js 的 express-rate-limit，Nginx 设置) 限制每个 IP/客户端的请求- 考虑突发控制以允许短时峰值使用适当的超时设置- 在服务器和客户端上设置连接、读取和写入超时- 调整 Web 服务器配置处理 DoS 场景- 实施断路器和节流逻辑监控异常模式- 将日志记录与 SIEM 工具 (Splunk, Graylog, ELK) 集成实施适当的防火墙规则- 配置网络防火墙和应用防火墙 (WAF)- 应用网络分段
|
- 速率限制和超时有助于减轻资源耗尽和 DoS 攻击- 与 SIEM 集成的持续监控有助于检测异常- 防火墙配置和网络分段限制了攻击面并控制潜在的漏洞影响范围
|
暴露工具时的安全考量
在暴露工具时，必须实施严格的安全措施来防止恶意输入、未授权访问和其他与 AI 应用 MCP 相关的潜在漏洞。
下表展示了最佳实践、考量因素和实施建议。
|
|
|
|
|
|
- 根据架构验证所有参数- 净化文件路径和系统命令- 验证 URL 和外部标识符- 检查参数大小和范围- 防止命令注入
|
- 使用 JSON Schema 验证器强制执行输入结构- 净化并使用白名单限制文件路径和命令，避免意外执行- 确保 URL 符合预期格式- 设置参数大小限制防止资源耗尽- 转义或拒绝可疑的命令输入
|
|
|
- 在需要时实施认证- 使用适当的授权检查- 审计工具使用- 限制请求速率- 监控滥用
|
- 使用可靠的方法 (OAuth, JWT) 进行用户认证- 为工具操作强制执行基于角色的访问控制 (RBAC)- 记录所有工具调用及其详细上下文- 实施速率限制减轻 DoS 攻击- 持续监控日志和使用模式查找异常
|
|
|
- 不向客户端暴露内部错误- 记录与安全相关的错误- 适当处理超时- 错误后清理资源- 验证返回值
|
- 返回通用错误消息防止内部系统信息泄露- 安全记录详细错误数据供调查使用- 设置适当的超时值避免进程挂起- 确保所有资源 (文件、连接) 在错误后正确释放- 验证工具输出符合预期格式
|
其他安全考量和最佳实践
下表列出了实施 MCP 的额外安全问题和关键要求。
|
|
|
|
|
|
- 用户必须明确同意并理解所有数据访问和操作- 用户必须保留对共享数据和执行操作的控制权- 提供清晰的界面用于审查和授权活动
|
- 提供直观界面，清晰显示正在访问哪些数据及原因- 确保细粒度的同意选项，允许用户针对不同操作调整权限
|
|
|
- 主机必须在向服务器暴露用户数据前获得明确同意- 未经用户同意，主机不得传输资源数据- 使用适当的访问控制保护用户数据
|
- 强制执行加密和严格的访问控制策略保护敏感数据- 建立同意工作流程，防止未授权的数据传输，并记录数据流向以符合合规要求
|
|
|
- 工具代表任意代码执行，需要谨慎对待- 主机必须在调用任何工具前获得用户明确同意- 用户应在授权使用前清楚了解每个工具的功能
|
- 清晰记录每个工具的功能和潜在影响，帮助用户做出明智决定- 实施安全措施，将工具操作限制在预先批准的场景中，降低意外代码执行的风险
|
|
|
- 用户必须明确批准任何 LLM 采样请求- 用户应控制是否进行采样、发送什么提示以及服务器可以看到什么结果- 协议有意限制服务器对提示的可见性
|
- 通过在执行前向用户展示关键信息，确保采样过程透明- 提供配置选项，让用户设置数据暴露的限制，在 LLM 交互中保持对输入和输出的控制
|
监控智能代理（Agentic）实现
MCP 支持服务器向客户端传输结构化日志消息的统一方法。客户端可以通过设置最小严重性级别来调整日志详细程度，而服务器发送包含日志严重性、可选记录器标识符和其他 JSON 可序列化信息的通知。
小结
👉 关注「玄月调查小组」，解剖硬核技术！
参考资料
[1]
Model Context Protocol : https://modelcontextprotocol.io/introduction
原文始发于微信公众号（玄月调查小组）：别再为AI安全焦虑！一文掌握MCP的安全风险与防护
评论