hello，大家好，这里是“恒脑与AI”——AI知识快充，不定期邀请安全研究团队科普安全知识，及时了解最新的AI技术模式。
本期作品——《MCP暗战三部曲》，来自研究团队X-Lab，跟随他们，领略一下当下最火MCP的一路繁花和荆棘！
第二期正式开始。
MCP安全么？
1
开场白
在使用 Claude、Cursor、Cline 等智能驱动 MCP Hosts 的过程中，Hosts与MCP Servers进行交互，执行任务并获取特定数据，组装相关上下文信息并提交给LLM进行任务决策，虽然显著提升了开发效率，但也引入了一系列网络安全风险。本文讨论一下MCP生态的主要风险点和防护建议。
先回顾一下上期介绍的MCP生态，我们依次分析三个角色，LLM（决策者），MCP Hosts（沟通者）以及MCP Server（行动者），目前MCP Clients一般由MCP Hosts创建子进程完成，简化起见并入MCP Hosts进行分析。
还记得上一期的
类比吗？
MCP主机（MCP Hosts）：就像你使用的外卖APP
MCP 客户端（MCP Clients）：就像外卖小哥
MCP 服务器（MCP Servers）：就像餐厅的后厨
2
长话短说
长文不想看的，直接看这里就行。整个MCP生态中，流动的信息数据是最大的风险来源，任何信息数据的篡改都可能引起LLM（脑子）的不稳定性，进而造成MCP Servers（手脚）对生态环境产生严重威胁。
Cline工具本身的提示词模版，对System提示词、Hosts环境变量、任务上下文数据内容以及LLM决策结果等几类填充内容虽有做分区和隔离，但是这类标签型的分割，一来从实验的结果来看，LLM似乎并未严格遵循；二来即使这类分割在LLM语义上生效，也存在被越界的严重风险。由此，我们给出一些使用场景建议：
1
MCP生态数据全链路认证、加密、完整性校验
2
使用的LLM必须完全被信任
3
使用的MCP Hosts必须完全被信任
4
第三方MCP Servers若不存在完全被信任的条件
– 开源本地部署的MCP Server需要审计MCP Servers源码，确保所有数据传输范围为任务必要数据，不存在信息泄漏；
– 闭源部署的MCP Server，每次都需要严格审计发送给MCPServer的数据和接收返回的数据，确保发送数据范围和接收数据不存在诱导性的提示词注入。此外，仍需警惕利用多次交互上下文关联构建提示词注入的攻击（可能被用于绕过单次的内容安全审计）；
5
MCP Hosts执行环境严格限制，确保风险损失可控
6
充分强调诸如辅助驾驶 不等于自动驾驶的概念，目前任何Auto Approve的行为，都存在严重风险
3
絮絮叨叨
接下来，我们分角色单独分析一下MCP生态面临的安全风险并给出一些安全防护建议。
LLM
1.数据泄露风险
❖
如果LLM是云端部署的，作为生态的决策者，LLM服务提供商可以看见所有运行过程中的数据
❖
若数据未加密或访问控制薄弱，在用户操作失误或存在提示词注入的情况下，存在任务边界范围外的数据被上传的风险
❖
与云端模型交互过程中，如果缺乏端到端加密，会有中间人攻击（MITM）的风险
防护建议
核心业务数据使用，请尽量使用本地部署的LLM服务
与LLM交互时启用端到端加密（如HTTPS/TLS1.2+）
对敏感数据做脱敏处理（内容安全审计、敏感内容遮盖）
控制上传到模型的上下文量，最小化暴露面
2.对抗性攻击风险
❖
恶意输入可以诱导LLM输出不安全或错误的决策，例如绕过权限控制、暴露系统内部指令
防护建议
LLM接收到的所有外部输入，都应该经过严格清洗、转义、检查
对任务指令进行白名单验证（只允许受信模板指令）
3.模型幻觉与不可靠输出风险
❖
LLM可能产生错误、虚假的内容，如果输出未经验证直接执行，可能导致终端执行错误决策
防护建议
为模型生成结果加上可信度打分，以及阈值过滤机制
在关键决策链条中引入人工复核或者AI二次验证
4.过度信任模型输出风险
❖
不同的LLM基座，可能对业务产生不确定性的影响
❖
如果系统将LLM的推理结果直接作为执行命令，缺乏必要的验证、审计或人为干预，将加剧风险
防护建议
模型推理结果只作为辅助参考，实际执行前经过业务逻辑二次确认或风控审批
MCP Hosts
1.伪造服务器攻击风险
❖
生态中MCP Servers被动接受MCP Hosts发起的链接，如果在连接过程中未验证Server身份（如证书校验、签名校验等），攻击者可以伪装成假服务器，发送恶意上下文或指令，控制或破坏MCP Hosts
防护建议
Hosts端实施服务器证书校验（例如TLS双向认证）
建立MCP Servers公钥指纹白名单
拒绝未签名或签名校验失败的上下文任务
2.本地恶意代码注入风险
❖
若Hosts运行环境缺乏沙箱隔离、权限控制或漏洞修补，攻击者可以通过模型生成的指令植入恶意代码，持久化控制Hosts
防护建议
Hosts内置执行环境隔离（如沙箱、容器技术）
指令执行前加沙盒审计，限制执行权限和资源
禁止Hosts侧直接执行未经签名验证的动态代码
3.权限过大问题风险
❖
Hosts如果默认运行在高权限模式（如root），一旦被攻破，攻击面和破坏力会极大扩大
防护建议
Host进程以最小权限运行（如普通用户权限），限制操作目录范围（比如限制在工程工作区内）
使用命令层级管理，来细粒度限制操作权限（如Cline管理中的读写权限分离管控，调用外部MCP Servers工具时，均需要人工复核）
4.通信链路暴露风险
❖
Hosts与Servers、LLM之间的通信如果未加密（如未用TLS等），容易被窃听或篡改上下文数据
防护建议
全链路加密（TLS1.2或以上版本），禁止明文传输任何上下文信息或命令
MCP Servers
1.身份伪造与服务器冒充风险
❖
MCP Server可能会因为名字相近或者构造对抗样本的模式，被“跨域”覆盖，导致MCP Hosts的数据发往不可控的Server
防护建议
MCP Servers命名强化，核心业务的MCP Servers进行功能强绑定，二次复核，避免LLM决策失误
2.后端数据库攻击风险
❖
MCP Server通常需要缓存大量MCP上下文信息，若数据库存在注入漏洞、未授权访问等问题，会导致大规模数据泄露或上下文被篡改
防护建议
数据库启用最小权限账户访问
防SQL/NoSQL注入（使用参数化查询、防止拼接）
上下文数据进行加密存储和访问日志审计
–做好Hosts间的用户访问信息隔离
3.拒绝服务攻击（DoS/DDoS）风险
❖
攻击者可以向MCP Server发起大量请求或构造恶意payload，导致资源耗尽，使MCP Servers不可用，影响所有连接的Hosts
防护建议
MCP Servers接入防DDoS设备或云防护（WAF/DDOS Mitigation）
引入速率限制、连接数上限控制机制
4.缓存污染与上下文污染风险
❖
若上下文缓存未进行内容校验或来源验证，攻击者可以污染缓存，影响后续LLM推理决策，间接诱导错误执行
防护建议
上下文缓存区做内容校验（签名验证、来源验证）
严格区分信任域（外部来源数据必须经过多层审查）
下期预告
本期内容从多个角度讨论了一下MCP生态的网络安全风险，下一期我们来动手实践一下吧！
有啥想问我们的吗？
原文始发于微信公众号（恒脑与AI）：MCP安全-《MCP暗战三部曲》2：MCP安全吗？
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论