全面MCP安全清单：保护AI驱动基础设施的API安全
随着创新而来的是风险。当各组织竞相构建AI优先的基础设施时，安全防护却难以跟上步伐。基于大语言模型（LLMs）和多组件协议（MCP）构建的多智能体系统虽然潜力巨大，但也带来了传统工具无法应对的新型漏洞。
在Wallarm，我们密切关注这些新攻击面的前沿指导，包括最新发布的OWASP多智能体系统威胁建模指南v1.0。基于这些建议，我们编制了一份实用的MCP安全清单，详细列出了AI原生环境中的实际风险和防御最佳实践。
点击以下链接查看清单内容：
- T11 - 意外远程代码执行和代码攻击
- T26 - 模型不稳定导致MCP请求不一致
- T2 - 通过MCP滥用工具
- T40 - MCP客户端冒充：身份管理
- T30 - MCP实现中的不安全通信
- T4 - 资源过载
- T21 - 服务账户暴露
- T22 - 选择性日志篡改
- T3 - 权限泄露
- T45 - MCP服务器权限隔离不足：身份管理
- T47 - 生态系统中的恶意MCP服务器：代理身份管理
- 最终建议
T11 - 意外远程代码执行和代码攻击
在AI原生系统中，代理不仅响应查询，还会生成和执行代码。这为隐蔽而危险的提示注入打开了大门。如果攻击者将恶意指令（如操作系统命令）注入提示，LLM可能会在不知情的情况下嵌入并执行它们。缓解措施包括：
- 限制AI代码生成权限：仅在绝对必要时允许代码生成
- 沙箱执行环境以防止主机级泄露
- 实施执行控制策略，标记并暂存具有提升权限的AI生成代码以供人工审查
- 限制CPU、内存和执行时间以适应任务范围
- 应用最小权限原则：仅授予所需的最低权限
- 限制对系统资源（如文件系统和网络）的访问
- 使用允许列表而非阻止列表来明确定义允许的操作
- 在代理代码和工具中持续遵循安全编码实践
T26 - 模型不稳定导致MCP请求不一致
当LLM不稳定时，可能导致MCP客户端向MCP服务器发送不一致或异常请求，从而中断操作。例如，模型可能尝试构建SQL查询但遇到错误，它不会停止，而是重复尝试相同的错误指令，对后端产生过量流量。这种不稳定性可能演变为拒绝服务问题。预防措施：
- 工具调用限制：对每个会话或任务施加频率和数量限制
- 速率限制：基于网络条件和代理活动使用自适应速率限制
- 提示工程：使用明确格式和逻辑步骤构建提示
- 使用思维链（CoT）提示引导模型进行逐步推理，减少不一致性
记住：模型并不总是知道它们何时出错，因此您的基础设施需要知道。
T2 - 通过MCP滥用工具
在MCP环境中操作的代理可以访问工具API来执行计算、转换或业务操作。但如果没有适当的验证，它们可能被诱骗使用错误的工具完成任务，改变输出或破坏信任。缓解此风险：
- 强制执行严格的工具访问验证并验证每次调用
- 监控工具使用模式并检测异常
- 不同工具应具有不同的权限集
- 限制每个工具仅访问其需要的内容
- 在受控环境中运行工具以防止交叉影响
- 验证输入、限制函数范围并阻止危险操作
- 防止命名冲突和未经授权的工具间访问
- 限制工具调用的频率和数量
- 在文档中包含必需的类型、测量单位和运行时验证以确保正确使用
T40 - MCP客户端冒充：身份管理
在分布式代理生态系统中，身份就是一切。如果恶意行为者获取有效凭证，或者系统未能正确验证代理身份，他们可以访问特权工具或数据。预防此风险：
- 开发强大的身份验证框架：身份应绑定到多个凭证而非单一凭证
- 使用行为分析检测代理活动偏差
- 实施随时间适应且抵抗操纵的代理信誉系统
- 强制使用PKI：代理必须通过可信CA颁发的数字证书进行身份验证
- 验证私钥所有权以确保代理身份
- 使用具有代理间身份验证的安全通信协议
- 强制执行沙箱化和策略实施以控制受损代理
T30 - MCP实现中的不安全通信
实现不当的通信协议（如JSON-RPC和SSE）可能允许攻击者拦截、修改或注入传输中的数据。例如，MCP客户端和服务器之间的请求和响应通过未加密的HTTP发送。攻击者操纵响应，导致无效的LLM输出。缓解此风险：
- 使用安全通信协议如HTTPS和mTLS
- 验证证书属性和颁发机构以防止中间人攻击
- 对所有MCP相关通信强制加密和身份验证
- 持续监控流量中的异常模式、有效载荷篡改或注入尝试
T4 - 资源过载
攻击者可能用CPU、内存或服务请求过载AI系统，以降低性能或导致拒绝服务。例如，恶意行为者可能触发大型文件读取操作100次，或发送pg_sleep(600)命令冻结数据库操作。缓解此风险：
- 通过分配CPU、内存和I/O预算部署资源管理控制
- 实施具有实时监控的自适应扩展
- 强制每个代理会话的AI速率限制策略
- 设置提示大小、任务持续时间和重试的严格配额
T21 - 服务账户暴露
MCP服务账户可能配置错误，允许通过工具、日志或文件访问暴露凭证。例如，连接到读取环境变量的工具的LLM可能无意中泄露AWS凭证。预防措施：
- 自动化PII和凭证编辑，特别是从日志或代理输出中
- 按角色和上下文使用细粒度访问控制
- 定期轮换凭证以缩短泄露窗口
- 应用防护措施防止凭证共享或意外暴露
- 对所有访问令牌和API应用最小权限原则
T22 - 选择性日志篡改
攻击者可以操纵日志行为以隐藏恶意活动或用噪声淹没系统。例如，他们可以将日志级别更改为DEBUG或TRACE以隐藏攻击，用无用事件过载日志系统，或通过配置操纵禁用日志功能。缓解策略：
- 实施日志的加密验证以确保完整性
- 使用具有严格访问控制的不可变日志存储
- 用元数据丰富日志以获得更深入的可见性
- 部署考虑AI代理非确定性行为的异常检测
T3 - 权限泄露
攻击者可能通过配置错误、提示注入或访问逻辑操纵来提升权限。例如，提示可能说服LLM将管理员权限分配给攻击者，或者恶意用户可能将管理员组权限降级以匹配用户访问级别。缓解措施：
- 在所有层强制执行细粒度访问控制
- 动态验证角色更改并记录所有权限提升
- 除非预先批准，否则阻止跨代理的权限委托
- 对高风险操作应用人工验证
- 使用分层防御防止提示注入和权限滥用
T45 - MCP服务器权限隔离不足：身份管理
如果MCP服务器对主机资源或网络具有过度访问权限，泄露可能跨系统升级。例如，MCP服务器上的易受攻击工具允许路径遍历，暴露其他服务或MCP环境的秘密。预防措施：
- 在服务器级别应用最小权限原则
- 通过沙箱化和资源边界隔离代理和工具
- 强制执行运行时监控和严格访问实施，防止升级或横向移动
T47 - 生态系统中的恶意MCP服务器：代理身份管理
攻击者可能部署冒充合法服务器的恶意MCP服务器。连接到此恶意服务器的代理随后被泄露。这是针对MCP信任模型的生态系统级攻击。缓解此风险：
- 使用去中心化标识符（DID）进行跨服务身份验证
- 应用安全身份验证协议，如相互TLS和DID签名消息
- 使用时间戳验证凭证以防止重放攻击
- 维护可适应动态代理属性的可信代理注册表
最终建议
如果没有强大的安全模型，MCP和多智能体系统的灵活性将变得脆弱。通过遵循OWASP的威胁建模指南和上述建议，组织可以构建既安全又智能的AI基础设施。
需要帮助评估风险暴露或构建更安全的代理生态系统？立即请求演示。