你在供应商支持呼叫中通过屏幕共享泄露的系统提示词

你的 AI 团队将系统提示词（System Prompt）视为专有知识产权（IP）。部署流水线会将其从每一个客户可见的界面中剥离。针对生产环境调试的操作手册（Runbook）要求工程师在任何故障产物（Incident artifact）离开作战室（War room）之前，通过 grep 将其过滤掉。你的上一次安全审查捕获并封堵了三条不同的提示词泄露路径：过于冗余的 API 响应、发布到错误层级的调试请求头（Debug header），以及将提示词嵌入到消息中的堆栈跟踪（Stack-trace）端点。

但在某个早晨，这一切都变得毫无意义：一名工程师加入了一个关于无关账单争议的供应商支持电话，通过屏幕共享展示他们的终端以演示堆栈跟踪信息。而该回溯信息中包含了一行详细的日志，完整打印了完全解析后的提示词——每一个注入的变量都已被替换，包括针对特定客户的业务规则和内部模型路由提示。供应商的支持工程师按照标准支持工作流录制了通话。录音随后进入了供应商的工单管理系统。现在，提示词被清晰地存储在了一个第三方 SaaS 中，而你的安全审查与其没有签订合同，没有签署数据处理协议（DPA），也没有审计权。

这是 OWASP LLM Top 10 中关于系统提示词泄露（System Prompt Leakage）条目往往会被低估的失败模式。已发布的分类法描述了你的应用程序所拥有的渠道——响应、错误消息、对话记忆、智能体间（Agent-to-agent）流量——且该领域已针对每种情况达成了切实的缓解方案。但屏幕像素（Screen pixel）并不在其中。屏幕像素是由你的数据防泄露（DLP）无法挂钩（hook）的操作系统渲染的，被你的供应商采购部门签约的录制栈捕获，并存储在一个你无法在周一早晨回答其数据驻留问题的系统中。

威胁模型：假设应用边界就是泄露表面

在大多数提示词保护计划中，隐含的假设是提示词仅通过团队拥有的代码路径泄露。因此，团队会对代码路径进行加固：过滤响应、清洗日志、对错误消息进行脱敏、通过环境检查拦截调试请求头。红队演练通过面向用户的模型接口探测提示词提取并对结果进行评分。

这种演练是合理的，控制措施也是真实的。但它们也遗漏了普通工程工作实际产生泄露的表面。工程师会共享屏幕。他们会将回溯信息（Tracebacks）粘贴到 Slack 频道中（在现代客户部署的架构中，这些频道通常包含客户）。他们会录制演示 Bug 的 Loom 视频。他们会参加供应商支持电话。他们在与承包商进行配对调试（Pair-debugging）时打开共享终端。他们会将“模型刚刚做的怪事”的截图丢进同步到供应商的 Notion 页面中。

每一个渠道都是一个称职的工程组织运作中完全正常的一部分。每一个渠道都会将终端的内容——包括刚好出现在屏幕上的任何日志行——渲染到安全团队没有签订合同的表面。那个假设应用边界就是泄露表面的威胁模型，在每一次站会演示中都留下了一个破洞。

使这一问题具体化的 2025 年供应商事故并非 AI 特有的。Discord 在 2025 年 10 月的披露中提到，攻击者利用了合法的供应商权限攻击了第三方的 Zendesk 环境。Crunchyroll 2025 年中期的事件追踪到了一个外包支持代理账户泄露了 100GB 数据。Marks & Spencer 在 2025 年 4 月遭受的社会工程学攻击是通过其第三方服务台进行的。AI 工程团队应该从中吸取的教训不是供应商支持系统会被攻破，而是供应商支持系统会无限期地保存你提供给它们的数据，且其安全态势并非由你决定。

“提示词是秘密”究竟意味着什么

如果提示词确实是知识产权（IP），那么团队处理秘密的纪律必须从应用表面延伸到工程师实际工作的操作表面。这种延伸是不舒服的，因为它让安全团队介入了工程人体工程学（Engineering ergonomics），而工程端会产生抵触：在终端中遮掩日志行的脱敏层会降低调试速度；规定哪些产物可以安全共享屏幕的策略会给本就痛苦的供应商通话增加摩擦。

抵触是真实的，而答案并不是“增加更多摩擦”。答案是像一个称职的团队对待任何具有类似泄露特征的秘密那样对待提示词——也就是说，将其视为凭据（Credential），而不是一段业务逻辑。

凭据永远不会以明文形式记录。它以指纹、哈希或稳定的标识符形式记录，工程师可以将其与另一个（受访问控制的）真相来源相关联。以同样方式处理的系统提示词，永远不会以字面文本的形式出现在调试日志行中。它会显示为 prompt_fingerprint=sha256:7a3f… 或 prompt_revision=v0142。在屏幕共享中进行调试的工程师看到的是标识符；需要实际内容的工程师则打开另一个经过审计的工具来检索它；供应商的通话录音捕获的是标识符，而不是内容。

这是日志行的一个微小变化，却是泄露概况的一个巨大改变。

prompt_fingerprint=sha256:7a3f…
prompt_revision=v0142

## 一个能够识别提示词指纹的针对每个开发者的脱敏层

这种实用的模式是在开发者机器和 CI 运行器的终端边界，而不是在应用边界，建立一个脱敏层。该层持有一个定期更新的指纹列表——包括系统提示词修订版、客户特定的提示词片段、模型路由暗示，以及任何安全团队归类为“不宜截屏分享”的内容。任何与这些指纹匹配的输出流都会被渲染为指纹，而不是字面文本。

这与容器原生机密管理器多年来为凭据实施的模式相同：开发者的本地环境知道机密长什么样，并在其到达屏幕之前将其预渲染为令牌（token）。AI 工程的类比对提示词也做了同样的事情。实现面很小——它是围绕终端输出流的包装器，或者是对任何标注为 `sensitive: prompt` 字段发出指纹的结构化日志适配器——它在应用端控制失效的情况下依然有效，因为它在应用发出日志之后运行。

该层在设计上采用“故障即开放”（fail open）模式：如果脱敏进程崩溃，终端仍然会渲染应用的输出，因为另一种选择——工程师无法调试——比泄露风险更糟糕。随后，故障模式对工程师可见（横幅提示：“提示词脱敏不可用，请勿共享屏幕”），这将决策权交回给知道接下来的 30 秒是否涉及供应商电话的人类手中。

## 识别导致泄露的渠道

另一半工作是策略，它不像技术控制那样令人满意，因为它依赖于训练工程师识别泄露面。尽管如此，这种培训还是值得做的。清单简短且稳定：

- 与提示词所属团队以外的任何人进行屏幕共享。
- 供应商支持电话，特别是那些供应商默认录制内容的电话（大多数企业级 SaaS 供应商都会这样做）。
- 屏幕上有终端的 Loom 和异步视频。
- 截屏到共享频道——特别是包含外部参与者的 Slack 频道和同步到供应商账户的 Notion 页面。
- 与承包商或审计员进行的配对调试会话，这些人名义上在组织内部，但其访问权限面不同。
- 会议演讲和演示。特别是“现场调试”演示，这是一个常见的泄露路径。

对于其中的每一个，策略都可以指定一种脱敏渲染方式——打印指纹而非内容的调试视图、工程师在加入通话前切换到的“屏幕共享安全”终端配置文件、在捕获的帧上运行脱敏层的脱敏 Loom 录制器。其目的不是为了将这些渠道列为禁区，而是为工程师提供一种默认安全的方式来使用它们，让安全路径成为便捷之路。

将这一切整合在一起的领导力论据是从业者最容易低估的一点：“提示词是知识产权”只有在团队处理机密的纪律与提示词实际的泄露特征相匹配时才有意义。提示词的泄露特征是屏幕像素的泄露特征，而不是 API 响应的泄露特征。一个像保护 API 响应那样保护提示词的团队，距离供应商的存档中存有其代码绝不会泄露的内容，仅隔着一次普通的客服电话。

## 将第三方 SaaS 视为存储的内容分类

最后一部分是清单。团队应该能够根据需求回答这个问题：“在我们的应用边界之外，我们系统提示词的碎片在何处被持久化了？”今天大多数团队的诚实回答是“我们不知道”。这个答案应该是一个列表，包含时间戳、供应商名称、保留策略和 DPA 状态——因为每一个条目都是一个提示词可能被传唤、泄露或被对方出售的地方，而这些对方的安全态势并不是由该团队构建的。

建立这份清单不需要新的工具，更多地需要提出问题。支持电话录音保存在哪里，保存多久？哪些 DLP 规则覆盖了工程 Slack 频道？哪些 Loom 录制到了供应商托管的存储，哪些是自托管的？哪些截图工具会自动上传到供应商云端？哪些可观测性供应商的仪表板具有“分享快照”功能，可以将捕获的像素转化为供应商存储的永久 URL？每一个问题，只要问一次，就会产生一个清单条目，并决定团队是接受该风险面还是关闭它。

随后，这种分类就变成了一种契约：任何不在批准列表中的提示词内容存储位置都是控制缺口，而脱敏层的工作就是确保包含提示词的内容从一开始就无法到达这些位置。

## 架构上的领悟

系统提示词不是一个配置值。它是一个机密，具有特定的泄露特征，团队选择将其视为竞争护城河。如果团队做出了这个选择，那么纪律就必须贯穿始终——超越应用边界，超越代码库，超越安全审查能看到的表面，进入工程师实际工作的运营现实中。

做得好的团队并不是通过更加谨慎来取胜。他们取胜是因为意识到应用边界不再是唯一的泄露面，并构建了小型且乏味的基础设施——指纹脱敏层、脱敏的终端配置文件、记录在案的渠道列表、供应商清单——从而使安全路径成为默认路径。

其他所有人距离供应商的存档中存有其代码绝不会泄露的内容，都仅隔着一次普通的客服电话。