MCP服务器仿冒攻击：AI智能体如何被假服务器窃取凭证

当AI智能体信任了一个陌生人

MCP（Model Context Protocol，模型上下文协议）正在成为连接AI智能体与外部工具的关键桥梁。MCP服务器为智能体提供工具，智能体则信任这些服务器、调用它们的工具、与之交换数据。这种信任关系是整个协议运转的基础——但也正是这种信任，成了攻击者眼中的突破口。

设想一个场景：智能体以为自己连接的是一个合法的服务（比如数据库接口、文件存储或支付网关），但实际上背后是一台被攻击者精心伪装的恶意MCP服务器。这就是本文要讨论的 MCP服务器仿冒攻击（MCP Server Impersonation），它是MCP安全系列（第28篇/共40篇）中一个典型且危险的威胁模型。

攻击是如何发生的

仿冒攻击的逻辑并不复杂，但危害极大。攻击者首先搭建一台恶意的MCP服务器，让它在表面上模仿一个合法服务的身份——相同的名称、相似的工具列表、看似正常的接口描述。随后，它向智能体暴露一组“假工具”。

当智能体在缺乏严格身份校验的情况下连接到这台服务器时，信任链就被劫持了。智能体会像对待真正的服务一样，把 凭证（credentials） 交给它、调用它提供的工具、并在交互过程中 泄露数据（leaks data）。换句话说，智能体把一切都托付给了一个陌生人。

这类攻击之所以隐蔽，是因为它不依赖传统意义上的漏洞利用，而是利用了协议设计中“默认信任服务器”的假设。智能体并不会主动怀疑对面是否真的是它所认为的那个服务。一旦连接建立，API密钥、访问令牌、用户数据乃至系统访问权限，都可能在毫无察觉的情况下流向攻击者。

为什么这类威胁值得警惕

在传统的客户端-服务器架构中，身份认证通常是双向且成熟的。但在AI智能体生态中，MCP的采用速度很快，很多实现为了追求便捷性而弱化了服务器端身份校验。智能体天然倾向于“执行任务”，缺乏人类那种对可疑来源的直觉警惕。

仿冒攻击的后果可以是连锁的：窃取到的凭证可能被用于横向渗透其他系统；泄露的数据可能涉及隐私或商业机密；而获取的访问权限则可能让攻击者在用户完全不知情的情况下，以合法身份执行破坏性操作。对企业而言，这意味着一次成功的仿冒可能撬动整条自动化工作流。

MCP仿冒在攻击路径上与 BGP劫持 和 DNS欺骗 有结构性相似之处——三者都不直接攻破目标系统，而是在"寻址/发现"层面插入恶意节点，让受害者主动送上凭证。在AI智能体场景中，这一威胁被进一步放大：智能体通常在无人监督的情况下批量调用工具，一次仿冒可能在数秒内完成数十次凭证泄露，而人工审计日志时才会发现异常。与此同时，多智能体编排（Multi-Agent Orchestration）架构下，一个被仿冒服务器感染的子智能体还可能成为跳板，向上游编排层传递伪造的工具响应，形成供应链式的级联污染。

防御手段：验证身份，别只看招牌

针对MCP服务器仿冒，核心防御思路是 不要默认信任，而要主动验证服务器身份。原始素材给出了几条明确且务实的建议：

验证服务器身份（Verify Server Identity）

智能体在连接前应确认对面服务器确实是它所声称的那一个，而不是仅凭名称或工具列表来判断。身份校验应成为连接流程中的强制环节，而非可选项。

实践中，服务器身份验证可通过多种机制实现。相互TLS（mTLS） 要求客户端与服务器双方均出示证书，从而将单向认证升级为双向认证；OAuth 2.0 / JWT令牌 方案则通过签名令牌携带服务器身份声明，智能体在连接时验证签名的有效性。此外，部分实现采用 注册表/白名单机制：运维方预先维护一份已知合法MCP服务器的指纹或公钥列表，智能体连接时仅允许列表内的服务器通过。无论采用哪种方式，关键原则一致：身份验证逻辑应在握手阶段完成，且失败时应立即中断连接，而非降级为"警告后继续"。

使用TLS加密传输（Use TLS）

通过TLS建立加密通道，不仅保护数据在传输过程中不被窃听或篡改，也为身份认证提供了基础。明文通信在这种威胁模型下几乎等同于把凭证直接暴露。

固定证书（Pin Certificates）

证书固定（Certificate Pinning）是对抗仿冒的有力武器。通过将智能体预期连接的服务器证书“钉死”，即便攻击者伪造了一个看似合法的证书，也无法通过校验，从而阻断中间人式的伪装连接。

证书固定（Certificate Pinning）的工作原理是：在智能体代码或配置中硬编码（或安全存储）目标服务器证书的哈希值（通常是公钥哈希，即HPKP形式），每次建立TLS连接时将服务器实际返回的证书哈希与预存值对比。若不匹配，则拒绝连接。这种方式可有效抵御 中间人攻击（MITM）：即便攻击者持有由受信任CA签发的"合法"证书，只要其公钥哈希与固定值不符，连接仍会被拒绝。实施时需注意 证书轮换问题：服务器更新证书后，智能体侧的固定值也必须同步更新，否则将导致连接中断。建议同时固定主证书和备用证书哈希，并建立完善的轮换通知流程。

写在最后

MCP生态的快速扩张带来了强大的工具调用能力，也引入了全新的攻击面。服务器仿冒攻击提醒我们：在智能体的世界里，“信任”不能是默认设置，而必须建立在可验证的身份之上。对于正在部署AI智能体的开发者和团队来说，把身份验证、TLS和证书固定作为基础设施级别的要求，是防范这类攻击最直接也最有效的起点。