OpenAI 锁定模式上线：为什么切断数据外传是根治提示注入的务实之道？

起因：从一条开发者推文到 LLM 安全软肋的公开解剖 Simon Willison 在他 6 月的博客里宣布 OpenAI 的 Lockdown Mode 正式上线。这并非一个简单的功能更新，而是对 LLM 应用安全核心难题的一次正面回应——提示注入（prompt injection）导致的数据泄露。他早前提出的“致命三合一”（Lethal Trifecta）理论点出了这类攻击的命门：当一个系统同时拥有对私密数据的访问、接触不可信内容（如用户上传的文件或网页内容）、存在数据外传渠道时，攻击者的成功只是时间问题。你无法完全阻止不可信内容夹带恶意指令，也很难为了安全而放弃私密数据的接入，所以最务实的做法就是切断那条外传通路。这恰恰是 Lockdown Mode 的设计逻辑。

拆解：用最“笨”的规则做最聪明的防守 Lockdown Mode 的原理听起来并不炫酷：它直接限制 ChatGPT 的出站网络请求。比如，禁止向未知域名发送数据，或者只允许有限的白名单请求。其精妙之处在于它使用了完全确定性的、非 AI 的规则。为什么这一点很重要？因为它避开了安全领域中一个常见的陷阱：让 AI 来判断某个操作是否危险。如果由 AI 做安全门卫，攻击者就可以通过更巧妙的提示注入（比如藏在网页内容里的指令）来蒙蔽这个门卫，形成所谓的“次级注入”。相反，一个简单的网络白名单不会被花言巧语绕过去。这就好比银行金库的大门不靠一个会和人聊天的智能保安，而是靠一把只有物理钥匙才能打开的锁。

从功能层面看，Lockdown Mode 切断了“致命三合一”中最容易控制、对用户体验影响最小的一条腿。它没有试图让模型本身“变得绝对安全”（这几乎不可能），也没有禁止用户让 ChatGPT 读取邮件或文件（这会大幅降低实用性），而是从系统架构的出口处上了把锁。这种“从不信任自身模型”的防御思路，是安全工程在 AI 时代的一次重要回调。

趋势洞察：AI 安全正在回归系统工程而非魔法 Lockdown Mode 的诞生揭示了一个更广泛的变化：前沿 AI 的安全保障正从“让模型更聪明地识别危险”转向“用传统安全手段给模型套上笼头”。过去两年，业界花了太多精力在对齐训练和 RLHF 上，希望模型能自主拒绝恶意请求。但事实证明，只要有足够强的对抗压力，语言模型总会暴露出可以通过诱导来绕过的脆弱性。因此，纵深防御（defence in depth）又重新成为共识——模型层仍然需要安全训练，但必须在它之外加上多层确定性的、不可绕过的主机或网络控制。你可以预见，未来云厂商和模型 API 服务商将提供更多类似防火墙、沙箱、出口审计的功能，而不是仅仅依赖一个“更对齐的模型”。

实用价值：给自己的 LLM 应用也加一把锁 如果你正在构建会访问私密数据（如企业知识库、用户邮件）或处理不可信内容（如网页爬取、用户上传文件）的 LLM 应用，请立即审视你的数据外传路径。不一定非要使用 OpenAI 的 Lockdown Mode，但可以借鉴其思想：用非 AI 的、可审计的规则来实施出口控制。例如，对你的后端代码执行环境施加严格的网络白名单；对 LLM 生成的任何外部请求先做二次过滤；使用沙箱运行所有不可信输入的解析。另外，请留意你的 AI 服务提供商默认的安全配置——这次 Lockdown Mode 的出现本身就是一个信号：很多我们原以为“安全”的系统，其实存在巨大的外传敞口。

反常识/意外：默认状态远比你想象的脆弱 大多数人可能默认 ChatGPT 或同类产品在安全上已做到足够好，但 Lockdown Mode 的推出反而证实了：在没有开启该功能时，系统对精心构造的数据窃取攻击防护并不充分。这相当于 OpenAI 主动承认了此前版本的脆弱性。更令人意外的是，他们选择用“笨方法”而非更复杂的 AI 检测去解决问题——这种工程上的诚实与务实，在当下追逐大模型万能论的风气中，反倒是一股清流。

原文地址: OpenAI Help: Lockdown Mode