大型语言模型的系统提示词是决定其行为模式、响应风格和安全边界的关键配置。随着 ChatGPT、Claude、Gemini 等主流平台被广泛用于企业级应用，系统提示词中往往包含了品牌规范、过滤规则、系统边界定义甚至敏感的业务逻辑。一旦这些提示词被泄露，攻击者不仅可以复制模型的「人格」特征，还可能绕过安全机制进行恶意利用。本文将从技术实现角度解析跨平台系统提示词提取的 MITM 代理方法，对比三大平台的泄露模式差异，并结合最新研究成果给出可落地的防御参数与监控策略。
MITM 代理提取技术的原理与实现
中间人攻击（Man-in-the-Middle，MITM）并非新概念，但将其应用于 LLM 系统提示词提取则代表了一种新的攻击范式。system_prompts_leaks 项目收集了来自 OpenAI、Anthropic、Google 等平台的真实提取案例，其核心方法是在客户端与 LLM 服务器之间的通信链路上部署代理层。当用户向模型发送请求时，请求首先经过代理服务器，代理可以完整记录包含系统提示词的请求负载；同样，模型的响应在返回途中也会被捕获和分析。
这种攻击的技术门槛主要集中在三个方面。首先是证书管理：为了截获 HTTPS 流量，攻击者需要在客户端设备上安装受信任的根证书，这意味着攻击场景通常局限于可控的内部环境或社会工程学诱导的受害者设备。其次是协议解析：不同平台的 API 响应格式各异，系统提示词可能以明文形式直接传输，也可能经过编码、加密或分片处理。最后是时序问题：系统提示词通常在会话初始化时一次性下发，后续对话不再重复传输，代理必须准确捕获首次握手的完整上下文。
从工程实现角度看，一个完整的 MITM 代理工具需要包含流量拦截层、协议解析层和持久化存储层。流量拦截可以基于系统级代理设置或网络层流量镜像；协议解析需要针对不同平台的 API 规范进行适配，例如 OpenAI 的 Chat Completion API 与 Anthropic 的 Messages API 在提示词封装方式上存在显著差异；持久化存储则用于保存提取结果供后续分析使用。
三大平台的泄露模式对比
通过对 system_prompts_leaks 项目中收集的案例进行分析，可以识别出 ChatGPT、Claude 和 Gemini 在系统提示词泄露方面呈现出明显的模式差异。
OpenAI 的 ChatGPT 在早期版本中对系统提示词的保护相对薄弱。在某些配置下，系统提示词会直接嵌入到 API 响应的消息历史中，通过精心构造的对话诱导即可使其在后续响应中「复述」自身指令。随着安全机制的迭代，OpenAI 引入了响应长度限制、内容审核前置检查以及提示词分片传输等技术，显著提高了直接提取的难度。然而，MITM 代理仍然能够捕获会话初始化阶段的完整系统提示词，因为这一阶段的信息交换是模型正常运行的必要条件。
Anthropic 的 Claude 在泄露防护方面表现较为突出。根据项目贡献者的分析，通过 MITM 代理提取的 Claude 系统提示词与 Anthropic 后续官方公布的版本具有高度一致性，这表明提取结果具有较高的可信度。Claude 的系统提示词通常包含详细的响应风格规范、工具使用限制以及安全边界定义，其结构化程度为后续的防护策略设计提供了有价值的参考。值得注意的是，Claude 4.5 系列（2025 年 12 月提交）的完整系统提示词已在项目中收录，显示即使是较新的版本也未能完全阻止提取尝试。
Google 的 Gemini 呈现出独特的挑战性。Google AI Studio 的默认系统指令曾被提取并提交到项目 PR #51，而 Gemini 2.5 Flash 的提示词提取则展示了 Google 在多模态场景下的防护复杂性。Gemini 的系统提示词不仅包含文本形式的指令，还可能涉及图像理解、代码执行等特殊能力的配置参数。这种多模态特性使得提示词的结构更加复杂，也为防御方提供了更多的设计空间。
从提取难度排序来看，当前格局大致为：ChatGPT 较易提取、Claude 中等难度、Gemini 相对困难但多模态场景增加了攻击面。这一差异源于各平台在安全投入、资源配置和技术路线上的不同选择。
防御策略与工程化参数
针对 MITM 代理攻击，学术界和工业界已提出多种防御策略，其有效性差异显著。基于 SPE-LLM 框架的系统性评估表明，单纯依靠响应长度限制或内容过滤的防御措施容易被自适应攻击绕过。ProxyPrompt 作为当前最有效的防御方案，通过将原始系统提示词替换为功能等价但语义模糊的「代理提示词」，在保持模型任务效用的同时阻碍攻击者获取真实提示词结构。实验数据显示，ProxyPrompt 能够保护 94.70% 的提示词免受提取攻击，显著优于次优方案的 42.80% 保护率。
在工程实践中，防御部署需要关注以下参数配置。首先是提示词混淆强度：代理提示词与原始提示词在语义空间中的距离需要平衡可防御性与功能保真度，过度混淆可能导致模型行为偏离预期。其次是动态轮换机制：定期更换系统提示词可以增加攻击者的信息收集成本，但需要配合版本管理和兼容性测试。再次是流量加密增强：对系统提示词传输层实施端到端加密，即使代理能够拦截流量也无法直接读取明文内容。最后是异常检测集成：在流量监控系统中加入提示词访问模式检测，当检测到异常的会话初始化请求频率或来源时触发告警。
监控维度的设计同样关键。建议跟踪的指标包括：会话初始化请求的成功率变化、系统提示词相关 API 调用的响应时间分布、来自非预期 IP 段或设备类型的会话创建请求比例，以及对话历史中首次响应与后续响应的语义一致性偏离度。这些指标的异常波动可能预示着潜在的提取攻击正在进行中。
系统提示词的安全防护是一个持续演进的技术对抗过程。MITM 代理攻击利用了通信链路层面的固有信任假设，单靠应用层防御难以彻底根除。企业在部署 LLM 应用时，应将系统提示词视为敏感配置资产，参考 Zero Trust 原则实施最小权限访问控制，同时建立覆盖网络层、应用层和行为层的纵深防御体系。随着模型能力的持续提升和攻击手段的不断演化，防御策略也需要保持动态更新，确保安全边界始终领先于潜在威胁。
资料来源
- system_prompts_leaks 项目：https://github.com/asgeirtj/system_prompts_leaks
- System Prompt Extraction Attacks and Defenses in LLMs：https://arxiv.org/html/2505.23817v1