随着大语言模型与自主代理的兴起,Model Context Protocol(MCP)正在成为 AI 编码代理之间共享上下文和工具的事实标准。对安全工程师而言,MCP 并非仅仅是另一套 API 规范,而是引入了新的信任边界、远程执行与数据流通路径,从而扩展了攻击面。本文将以实务为导向,系统性梳理 MCP 的风险类型、常见漏洞、审计与渗透测试思路,以及面向服务器与客户端的防护策略,帮助团队在迁移与集成 MCP 时保持可观测性与最小化风险。 理解 MCP 的核心与攻击面演化 Model Context Protocol 的目标是为语言模型(LLM)提供一套程序化接口,让模型可以在会话上下文之外访问工具、资源和外部提示。与传统 REST/GraphQL 等协议类似,它使用 JSON-RPC 等双向消息通道,但关键差异在于调用者是具备高度自治能力的模型而非固定的应用逻辑。这一特性带来两类本质风险:一是模型作为调用者会放大对外部资源的请求可能性,二是服务器端提供的工具与资源若被滥用或污染,会直接影响模型行为与最终输出。
在审计 MCP 时,应把握三条设计原则。第一,假定任何来自远端 MCP 服务器的资源描述、工具描述与提示都是不可信的,必须以最小信任方式解析与执行。第二,任何允许模型直接触发外部操作的能力都应纳入审批与审计链路,尤其是文件系统、网络请求与命令执行三类高风险操作。第三,身份与授权必须细粒度化,尤其是 HTTP 传输场景下须使用经严格校验的令牌与受限作用域。 典型攻击模式与案例分析 工具投毒(Tool Poisoning)是当前研究与实务关注的重点之一。攻击者通过在 MCP 握手阶段影响服务器返回的工具列表或工具注释,诱导客户端或模型调用恶意工具。
成功的投毒往往依赖客户端对工具注释的过度信任或未对工具版本变更进行监控。防御要点在于客户端应把工具描述视为不可信输入,采用签名校验、版本锁定与变更通知机制来降低风险。 工具遮蔽(Tool Shadowing)对应的是名称冲突或跨服务污染。多个 MCP 服务器可能同时提供同名工具,某个实现可能按字典顺序、轮询或其他策略选择调用来源。攻击者可以利用命名冲突或描述中隐含的不可见字符来优先劫持调用路径。作为缓解,客户端应支持工具的完全限定名解析,并在多来源情形下采用强制来源白名单或基于元数据的优先级规则。
"抽地毯"攻击(Rug-pulling)强调服务器行为随时间发生变化的风险。早期获得批准的远程服务器如果未经持续验证或被中间人劫持,后期可能取代正常工具为恶意实现。为此,组织应对外部 MCP 服务建立持续的健康检查、签名与回滚机制,并在变更时强制重审授权与用户同意流程。 Web 2.0 类型漏洞在 MCP 中并未消失。由于 MCP 常通过 HTTP/JSON 传输,传统的请求走私、响应分割、路径遍历、注入(SQL、shell、LDAP 等)、以及不严格的 JSON 解析都仍可能成为漏洞入口。特别需要关注的是在多租户场景下的流量隔离与回放保护,防止跨会话信息泄露。
采样(Sampling)机制则是一把双刃剑。规范允许服务器请求模型的补全样本或进一步的输入,但如果没有强制的隔离与用户审批,这一功能可能被利用为侧信道或信息回流的通道。审计人员应评估采样请求在审批流程、数据最小化与审计日志方面的实现状况。 实用审计方法与工具链建议 开始 MCP 审计的首要步骤是观察握手与功能广告。类似 GraphQL Playground 的 MCP Inspector 可以帮助审计员确定服务器在握手阶段广告了哪些工具、资源与提示。通过直接检查握手消息,比依赖模型报告更可靠且更快发现异常。
本地 STDIO 传输模式在许多实现中最简单,通常以子进程的形式运行。虽然本地交互对远程攻击面有限,但它带来了本地权限混合的风险:不同工具可能拥有不同权限集,错误的权限设计可能导致本地提权或侧通道。渗透测试时应模拟具有不同权限的工具组合,尝试发现命令注入、路径遍历或不安全的临时文件使用等问题。 对于支持 HTTP 的 MCP 服务器,应进行传统的 API 安全测试,包括但不限于认证授权测试、CORS/Origin 验证、速率限制、请求体与头部的边界条件、以及代理和重定向的滥用情形。重点检查 OAuth 2.1 的实现是否合规,是否有受限作用域和受众(audience)校验,是否在 401 响应中正确返回 WWW-Authenticate 与资源元数据链接。 在渗透测试阶段,尝试构造工具名称冲突、不可见字符注入与工具描述中的指令诱导,以验证客户端的工具解析策略。
若能够在不提示用户的情况下触发工具变更或工具调用,则说明存在严重的信任断层。 服务器端与客户端的安全要求要点 合规与隐私方面,MCP 服务器应在用户授权前明确告知将要访问的数据与可执行的操作范围,并且在每次调用高风险操作(如采样或第三方数据共享)时征得明确同意。对于认证方式,HTTP 传输情形下必须支持 OAuth 2.1,建议配合动态客户端注册以减少静态 client_id 引发的混淆代理(confused deputy)问题。 在实现细节上,服务器端必须对工具输入、提示内容、资源 URI 等进行严格校验与清洗,避免路径穿越与不安全的协议调用。服务应尽量使用密码学安全的随机数生成器产生会话 ID,并避免使用会话机制作为主要的认证方式。任何接收到的第三方令牌都必须进行受众验证并仅接受为该资源专门签发的令牌。
客户端方面需把根(roots)设计为受限的文件系统视图,只暴露经过权限审查的路径,并对路径与 URI 做严格验证。当服务器请求采样或设定新的根时,客户端应触发显式的用户审批流程,提供可预览的采样内容并允许拒绝或修改。工具描述与工具输出都应作为不可信输入进行处理,必要时对输出进行隔离执行并记录可审计日志。 缓解措施与防御深度建设 第一层防御来自最小权限原则。无论是工具进程、HTTP 服务还是客户端根目录,都应按照最小化权限部署,避免将 MCP 服务运行在高权限账户或暴露整个宿主文件系统。第二层防御是强身份与细粒度授权,采用 OAuth 2.1 并实施受众、范围与签名校验,配合动态客户端注册与证书钉扎减少中间人风险。
第三层防御是输入输出的白名单与沙箱执行,对外部命令、网络请求与文件访问采取沙箱限制与系统调用过滤。 此外,变更可追溯性非常重要。任何工具的添加、修改或移除都应产生可审计的事件并通知管理员或用户,关键变更应要求二次审批。对工具的元数据和实现采用签名机制可降低恶意替换的风险。长期运行的集成场景应配置健康探针与行为监控,检测突发的流量模式或异常的工具调用频次。 治理与流程建议 在组织层面,建议将 MCP 服务纳入现有的应用安全生命周期管理。
新的 MCP 集成应在上线前经过安全设计评审、威胁建模与合规检查。运行中要保留丰富的审计日志,包括握手记录、工具解析决策、采样请求与用户审批记录。定期进行红队或对抗测试,从模型诱导、工具注入到链式攻击路径进行端到端验证。 培训也是不可或缺的环节。开发者与产品团队需要理解 MCP 的信任模型,安全团队要提供易于使用的审计工具与最佳实践文档,帮助工程师正确实现根权限、工具签名与用户交互界面。 结语:从可观测到可控 Model Context Protocol 是连接模型与实世界操作的强大桥梁,但与此同时也带来了前所未有的信任挑战。
对安全工程师来说,关键在于将 MCP 的各个环节纳入审计与治理范畴,从握手、工具解析、传输协议到用户审批流程都要确保可观测、可审计并具备回滚能力。通过最小权限设计、严格的认证与授权、工具签名与变更通知,以及用户可见的审批机制,可以将 MCP 的安全风险降到可接受范围,使团队在拥抱 Agent 化开发效率的同时,不牺牲对数据与执行环境的控制权。 安全工程实践永远不是单点的修补,而是一套跨职能的持续工程。把 MCP 的审计清单融入到开发与运维流程中,定期执行握手审查、工具完整性验证与采样审批,就能在快速演化的 AI 生态中构建起稳固的信任防线。愿每位安全工程师都能以谨慎与创新并行的态度,为下一代智能应用保驾护航。 。
