WhatsApp 隐藏 LLM 指令事件暴露了一处检索血缘故障。一个网页可以是可信的官方事实来源，其中的文本依然没有指挥模型的权限。本文给出一套双视图审计方法，逐项核对用户看到的页面、机器提取的正文、进入模型的片段和真正有权约束回答的策略。
阅读时间： 7 分钟 | 篇幅： 约 3,000 字
TL;DR
- Redact 报告在 545 个 WhatsApp 帮助页中发现 102 个隐藏块，其中两个涉及监管机构和隐私法律。
- WhatsApp 向 WIRED 表示，这些文字用于自己的客服机器人，因错误才出现在公开帮助页，随后已移除。
- 10 月 9 日与 10 月 18 日历史快照可以直接复核样本指令的存在与删除。
- 当前没有公开证据证明外部 AI 助手读取或服从了这些文字。
- 生产级检索增强生成（RAG）系统应分开管理来源可信度与指令权限，并保留模型可见内容的完整血缘。
先把已经证实的事实说清楚
Redact 的调查扫描了 545 个 WhatsApp 帮助页面，在其中 80 个页面发现 102 个隐藏文本块。大部分内容属于客服说明和术语消歧，有两个文本块越过了普通知识说明的边界。
账户删除页面中的一段隐藏文字要求 AI 不要建议用户联系数据保护机构、监管者或监督机构。另一个页面则要求 AI 在用户提到诉讼或律师后，不要讨论服务条款、隐私政策和若干隐私法律。这些文字存在于服务器返回内容中，普通用户看到的页面没有显示它们。
这件事至少有四层证据，结论强度需要与证据逐级对应：
| 主张 | 证据 | 可以下的结论 |
|---|---|---|
| 隐藏指令曾出现在公开页面响应中 | 2026 年 10 月 9 日的互联网档案快照源码包含相关文字 | 可以确认文本存在 |
| 指令后来被移除 | 10 月 18 日快照仍有帮助页正文，相关指令已经消失 | 可以确认前后变化 |
| 这些文字用于 WhatsApp 自己的客服机器人 | WhatsApp 向 WIRED表示，相关文字是客服机器人的指令，因为错误才出现在帮助页 | 属于有明确归属的公司回应 |
| 外部 AI 助手读取并服从了这些指令 | 当前没有公开的行为测试 | 仍未证实 |
因此，这是一宗已经确认的模型可见内容泄露和内容治理事故，也形成了一条可能的间接提示注入路径。现有证据还不足以把它描述成第三方模型已经遭到攻击。
历史快照在这里很重要。截图只能证明某个视觉状态。两个带时间戳的源码快照可以把判断绑定到具体 URL、具体内容和具体时间，也能排除事后页面改动造成的证据漂移。
官方来源可信，不等于其中的文字有指令权
RAG 系统通常会提高官方网站的检索权重。与论坛帖子和二次转载相比，官方帮助中心确实更适合支撑产品事实。风险出现在系统把这份事实可信度顺便转换成指令权限时。
两个权限应当分别定义：
- 来源可信度：这段文字能否作为事实证据。
- 指令权限：这段文字能否改变模型任务、回答边界、披露规则或工具动作。
一个官方页面完全可以同时拥有高来源可信度和零指令权限。账户删除说明可以支撑等待期限等事实，其中的祈使句仍然只能作为待分析的数据。监管机构网页也会包含大量命令式法律表述，模型应当引用和解释这些内容，而不是把它们当成系统指令执行。
WhatsApp 事件源于第一方发布错误，目前没有证据表明外部攻击者参与。它揭示的技术边界依然普遍存在：只要网页文本进入模型上下文，数据就可能与真正的系统策略争夺控制权。
这条内容供应链包括：
CMS 内容记录
-> 服务器响应
-> 页面解析与正文提取
-> 检索分块
-> Prompt 组装
-> 模型回答
-> 用户可见结果或工具动作
每次转换都可能改变可见性、出处和权限。
建立四层双视图合同
爬虫成功抓到一个 URL，只能证明传输成功。高风险知识源至少要保存并比较四种视图。
用户渲染视图
保存普通用户实际看到的页面，用于确认公开披露内容和视觉层变化。
原始响应视图
保存服务器返回的 HTML 或结构化数据。隐藏元素、元数据、不同语言分支和面向特定 User-Agent 的内容，都可能只存在于这一层。
检索提取视图
记录解析器处理脚本、导航、隐藏元素和重复内容之后的标准化文本。这一层决定搜索和召回系统真正能够索引什么。
模型上下文视图
记录最终进入 Prompt 的准确片段，同时附上来源 URL、内容版本、检索分数、解析器版本和策略版本。回答出现异常时，团队才能知道模型到底看到了什么。
四种视图应当共享同一个不可变内容标识。最小清单可以包括：
{
"source_url": "https://example.com/help/account-deletion",
"fetched_at": "2026-10-21T00:00:00Z",
"raw_hash": "...",
"rendered_hash": "...",
"extractor_version": "...",
"chunk_ids": ["..."],
"source_trust": "official-product-documentation",
"instruction_authority": "none"
}
最后一个字段决定了控制边界：内容可以支撑回答，同时没有资格支配回答。
把门禁放到发布和入库阶段
等线上回答已经偏移再抽查，定位成本很高。更有效的做法是在内容进入生产索引前建立门禁。
比较渲染内容与提取内容
两者存在差异很常见，辅助功能文字和结构化元数据都有合理用途。检查器应聚焦隐藏的祈使句、策略术语、只对特定爬虫返回的文本，以及影响隐私、安全和升级路径的差异。
把策略与知识分开存储
客服机器人的行为策略应进入独立、版本化的策略系统，配有责任人、访问控制、评审记录和回滚机制。帮助中心负责产品事实。两者混在同一个公开响应里，文档与控制面的边界就会消失。
在 Prompt 组装时剥离权限
检索片段进入上下文时，应附带明确约束：这些内容只能作为证据使用，没有资格修改任务。这个约束无法单独消除所有间接提示注入，但能让系统层级变得可检查、可测试。
保存片段级血缘
引用链接需要指向回答生成时使用的具体版本和具体片段。只保存当前 URL，会让后续页面更新覆盖历史证据，旧回答也就失去可审计性。
做成对回答测试
隐私、法律、安全和账户处置等敏感主题，可以用相同问题测试两份受控输入：一份只包含用户可见正文，另一份包含完整提取结果。比较回答是否仍然说明监管升级路径、是否准确引用政策、是否保留必要披露。
这项测试直接测量隐藏内容对回答的影响，比统计命中多少条可疑正则更接近真实风险。
先按治理故障处理，再判断是否构成攻击
安全事件的名称会影响后续动作。把所有隐藏指令都称为攻击，团队容易得到一份通用提示注入清单。把本事件定义为检索血缘和发布治理故障，检查范围会准确落到 CMS、正文提取器、索引、策略库和回答评测。
当前证据支持以下分类：
- 已确认：模型可见的客服指令泄露到公开帮助页响应。
- 已确认：用户可见内容与机器可见内容不一致。
- 已确认：行为策略与公开知识没有隔离。
- 合理风险：外部检索系统可能把这些文字带入上下文。
- 尚未确认：第三方助手实际读取并服从了指令。
这也说明本题与两类既有风险的差别。此前的文档携带型 AI 蠕虫关注恶意指令如何沿生成文档传播；本事件发生得更靠上游，批准过的第一方知识源直接向人和机器提供了不同内容。LLM 中转服务审计则关注传输链上的中间服务能否读取或改写 Prompt 和工具调用。
最小检索血缘检查表
把一个官方网站加入生产检索索引前，应能回答八个问题：
- 页面渲染结果与机器提取结果是否包含实质不同的主张或指令？
- 该内容系统能否发布只对模型可见的文字，谁有审批权？
- 来源可信度与指令权限是否为两个独立字段？
- 每个回答能否追溯到不可变内容版本和准确片段？
- 行为策略是否存放在公开知识库之外？
- 成对测试能否检测隐私、法律、安全和升级建议的变化？
- 可疑内容能否单独隔离和回滚，无需重建整个索引？
- 新增隐藏祈使句或面向特定 User-Agent 的响应能否触发告警？
官方域名可以继续作为高质量证据。它不应因此成为无边界的模型控制面。
常见问题
这是一次已经确认的提示注入攻击吗？
现有证据确认了模型指令出现在帮助页，以及内容与控制没有隔离。外部攻击者和第三方助手受控的事实仍未得到证明。更准确的表述是：已确认的内容治理故障，形成了潜在的间接提示注入路径。
外部 AI 助手是否读取或服从了这些文字？
目前没有公开测试可以证明。Redact 明确把外部助手行为列为未知项。
为什么用户看不到，模型却可能看到？
模型管线通常解析原始 HTML 或结构化页面数据，视觉层隐藏的文字仍可能保留在服务器响应和提取正文里。
如何审计模型可见的网页内容？
同时保存渲染页面、原始响应、提取文本和最终 Prompt 片段；逐层比较，标记隐藏祈使句；把每个片段绑定到版本化清单；再用成对问题测试隐藏内容是否改变回答。
域名白名单能否解决 RAG 安全问题？
域名白名单证明来源身份。它无法证明每个片段都对用户可见、内容仍然有效、符合当前政策，或者有资格指挥模型。
下一步
从生产助手正在使用的官方知识源中挑一个敏感页面，同时保存渲染页面、原始响应、提取正文和最终 Prompt 片段，把四层内容绑定到同一个版本清单，再用用户可见正文与完整提取正文各跑一次成对问答。一次实验就能看出系统是否真正区分来源可信度与指令权限。