MCP服务器为何需要红队测试：七大边界攻击面解析

MCP（Model Context Protocol）正在成为AI Agent调用外部工具的事实标准。但一个被忽略的事实是：MCP服务器暴露的攻击面远比传统API更隐蔽——因为它的核心交互媒介是自然语言本身。

工具描述：一条从未被防火墙覆盖的信任链

MCP协议中，工具描述（tool description）被当作可信元数据对待。LLM客户端在建立连接时接收这些描述，不做任何净化处理，直接将其折叠进system context。

这意味着一段藏在描述字段里的隐藏指令——一个HTML注释、一串零宽字符、一句直接写给模型的话——会在Agent自身的推理循环中执行。传统安全架构中的防火墙、WAF、输入过滤，在这个位置全部失效。

这不是理论推演。安全团队Stonepath IT在一篇技术分析中将其列为Agent边界测试七大类发现之一，并指出背后的攻击面远不止于此。

Model Context Protocol（MCP） 是 Anthropic 于 2024 年底开源的一套通信协议，旨在让 LLM 应用以统一方式连接外部数据源与工具。它采用客户端-服务器架构：MCP Host（如 Claude Desktop、IDE 插件）通过 MCP Client 与 MCP Server 建立连接，Server 向外暴露三类能力——Tools（可调用函数）、Resources（可读取数据）与 Prompts（预置模板）。

与 OpenAPI 等传统接口描述规范不同，MCP 的 Server 在握手阶段会主动向 Client 推送工具列表及描述文本，这些内容随后被序列化进模型的 system prompt。换句话说，MCP 把"对外宣传自己有什么能力"这一步也交给了模型去读，而不是交给人类开发者去读。这一设计极大降低了集成门槛，但也让描述字段成为攻击者可写入、模型会执行的"半可信代码"。

System context（系统上下文） 指在对话开始前就被注入到模型上下文窗口中的那段高优先级内容，通常包括系统提示词、工具定义、角色设定等。它对用户不可见，却会被模型当作"最高指令"对待。当 MCP 工具描述被折叠进 system context 时，攻击者实际上获得了一个越权写入系统提示的通道——这正是 prompt injection 在 Agent 场景下最具破坏力的变体：攻击载荷不需要欺骗用户，只需要欺骗一次工具注册流程。

七大边界失败类别

Stonepath IT定义的"Agent边界评估"测试AI Agent与其所触及系统之间的界面。七类发现对应七种失败方式：

工具投毒（Tool Poisoning）——描述、schema和默认值中夹带隐藏指令。这是最容易被低估的一类，因为它利用了协议本身的设计信任假设。

工具滥用（Tool Misuse）——函数未经校验即可访问内网、云元数据端点（如169.254.169.254）或凭证存储。CLAUDE.md中一个看似无害的fetch_url工具，可能成为SSRF的入口。

身份与权限（Identity and Privilege）——认证缺失、token泄露、通过调试接口暴露的硬编码凭证。

记忆与上下文投毒（Memory and Context Poisoning）——笔记存储、RAG检索和对话历史接受并回放注入的payload。

过度代理权（Excessive Agency）——无白名单的shell执行、无路径校验的文件访问、Agent可以采取但未经人类批准的操作。

数据泄露（Data Leakage）——响应中携带内部状态、环境变量或用户数据跨越信任边界。

治理缺口（Governance Gaps）——缺少审计追踪、没有human-in-the-loop关卡、事后无法还原Agent做了什么。

每一类发现都同时标注MITRE ATLAS技术编号、OWASP LLM Top 10风险分类和NIST AI RMF治理控制项——这三个框架的交叉映射，恰好是采购和安全评审环节最常追问的内容。

单元测试找不到的东西

一个单元测试断言函数在正确输入下返回正确值。它不会断言工具描述中不含prompt injection，不会断言fetch_url("http://169.254.169.254/latest/meta-data/")被拦截，也不会断言run_command("env | grep TOKEN")拒绝执行。

这些是边界失败，不是逻辑失败。它们存在于组件之间的缝隙里——每个组件的作者都假设对方会执行约束。对抗性测试之所以能发现它们，是因为它问了作者没想到要问的问题。

这个区分对工程团队很重要：边界测试不是"更多单元测试"，而是需要不同的思维模型。写测试的人需要像攻击者一样思考，而非像验证者一样思考。

修复的资产化：从报告到CI流水线

Stonepath IT的做法值得关注：每一项发现都附带一个机器可读的YAML回归场景，工程师可以直接在CI中运行。

这个设计的价值在于：当prompt改变、模型升级或工具描述被编辑时，修复措施不会悄悄失效。报告只是快照，测试框架才是资产。

对于正在交付MCP服务器、LLM驱动的Agent，或任何AI模型代表用户调用工具的系统，这个思路提供了一个可操作的起点——不是做一次渗透测试然后归档报告，而是把安全性转化为可持续验证的工程实践。

谁需要关注这件事

如果你在构建以下任何一类系统，边界评估都应纳入发布流程：

• MCP服务器或类似工具调用协议的服务端
• 使用function calling的LLM应用
• 任何Agent可以自主执行操作的系统

核心判断标准很简单：当AI模型代表用户调用工具时，组件之间的信任假设是否经过了对抗性验证？如果没有，那么工具描述中的一行隐藏指令、一个未校验的URL参数、一次过度授权的shell调用，都可能成为突破口。

安全边界不会因为没人测试就自动存在。

背景补充

SSRF（Server-Side Request Forgery，服务端请求伪造） 是一种让服务器代替攻击者发起网络请求的漏洞。在传统 Web 场景中，攻击者通过操纵 URL 参数让后端去访问内网服务；在 Agent 场景中，触发点变成了工具的调用参数。云环境的元数据端点 169.254.169.254 是 SSRF 的经典目标——它无需认证即可返回实例的 IAM 临时凭证、用户数据脚本等敏感信息。一旦 Agent 的 fetch_url 类工具缺少地址白名单或私有网段拦截，模型就可能被诱导去"读取这个 URL"，从而把云账号凭证原样吐回对话中。

这三个框架分工不同：MITRE ATLAS 是面向 AI 系统的攻击技战术知识库，对标传统安全中的 ATT&CK，回答"攻击者怎么做"；OWASP LLM Top 10 是应用层风险清单，回答"最可能出什么问题"，如 LLM01 Prompt Injection、LLM06 Excessive Agency；NIST AI RMF 是治理与流程框架，回答"组织应如何管理风险"，其 Govern/Map/Measure/Manage 四职能对应治理动作。把一次测试发现同时挂到三者上，意味着同一份证据既能被工程师用来复现漏洞、又能被安全团队用来评级、还能被合规与采购部门用来对标控制项——这是漏洞报告能真正推动组织行动的关键。