LLM 文本隐写术：当大模型把'看不见的消息'藏进看似无害的英文段落里

一句话总结

2026 年 5 月 11 日，Schneier 在博客上转发了一篇学术论文：LLM 在"把文本藏进文本"这件事上已经做得非常好。给定一段秘密消息和一段无关的载体文本，模型可以生成一段读起来完全自然、与载体语义一致、却隐藏着完整 payload 的英文段落。人类检测者无法分辨，传统的 DLP（数据防泄露）规则也几乎全部失效。

这听上去是密码学界长达半个世纪的"隐写术（steganography）“老课题——但 LLM 让它从手工艺一夜之间变成了任意人都能在浏览器里一键调用的能力。

本文要回答三个问题：

技术上：LLM 凭什么能做以前做不到的高带宽语义隐写？
产业上：这对内容审核、企业 DLP、AI 模型审计意味着什么？
战略上：未来 12 个月，攻击者和防御者会怎么动？

一、为什么"用 LLM 藏文本"是质变，而不是量变

经典隐写术有三大局限，过去几十年没有被很好地解决：

维度	经典隐写（如 Snowdrop、Stegano）	LLM 隐写
载体范围	固定模板、特定语言、需手工调参	任意自然语言文本，跨语言可迁移
容量	每千词约 1–10 bits	每千词 100+ bits，理论上接近熵上限
自然度	经常生成奇怪句子或不自然搭配	与人类写作几乎不可区分
通用性	与编码器强绑定，密钥+算法泄露即破	仅需开源 LLM 权重+共享种子
可检测性	统计指纹明显（n-gram、词频偏差）	基本无统计指纹，需要昂贵的语义级检测

技术上，LLM 隐写利用的核心机制是 token-level 概率分布的可控扰动：

给定上下文，模型对下一个 token 输出一个概率分布。
编码方将"秘密 bit 序列"映射到这个分布的某个分桶里（最常见的做法是基于算术编码或 Huffman 编码）。
接收方用同一个模型 + 同一个种子 + 同一个上下文重放推理，反推出 bit 流。

最关键的一点是：编码方可以一边遵守 bit 流，一边保证选出来的 token 始终落在"高概率合理候选"区间内。结果就是一段读起来非常流畅、语义合理、却携带任意秘密的文本。

新论文里有一个细节特别值得注意：他们测试了在 7B–70B 参数开源模型上的容量曲线，发现 70B 级别模型每个 token 平均可携带 3.5–5 bits 的秘密信息，而载体文本的困惑度（perplexity）与正常人类文本的差距小于 5%。

换句话说，一封 2000 词的客户感谢信，可以无声无息地嵌入大约 6KB 的二进制数据——足够装一张高分辨率二维码、一份小型 LoRA 增量权重、一个 SSH 私钥，或者上千行源代码的 zip 包。

二、技术架构图：LLM 隐写的发送/接收双向流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
                ┌─────────────────────────────────────────────┐
                │              共享密钥 / 种子 / 模型权重 hash │
                └────────────────────┬────────────────────────┘
                                     │
        发送侧                       │                        接收侧
┌────────────────────┐               │              ┌──────────────────────┐
│ Secret payload     │               │              │ 收到的"自然文本"     │
│ (bytes/bits)       │               │              │ (carrier with hidden)│
└─────────┬──────────┘               │              └────────────┬─────────┘
          │                          │                           │
          ▼                          │                           ▼
┌────────────────────┐               │              ┌──────────────────────┐
│ 算术编码 / 哈夫曼   │               │              │ 同一 LLM 前向推理     │
│ 把 bits 映射成     │               │              │ 重放 token 分布       │
│ token 选择策略     │               │              └────────────┬─────────┘
└─────────┬──────────┘               │                           │
          ▼                          │                           ▼
┌────────────────────┐               │              ┌──────────────────────┐
│ LLM 受控解码       │               │              │ 反向解码：从 token   │
│ 在 top-k 候选中    │───────────────┼─────────────▶│ 选择路径还原 bit 流  │
│ 按 bits 走         │   网络传输    │              └────────────┬─────────┘
└─────────┬──────────┘               │                           ▼
          ▼                          │              ┌──────────────────────┐
   生成的"自然段落"                  │              │ Secret payload 还原  │
                                     │              └──────────────────────┘

关键约束有四个：

模型必须严格 deterministic：温度=0 或带 seed 的 logit 采样，否则双方对不齐 token 序列。
载体上下文必须双方共享：邮件主题、开头几句、对话历史都可以，但要预先约定。
量化精度敏感：fp16 vs int8 量化会让 logits 有 micro-differences，可能导致解码漂移。实战中常用 fp16 + 单一推理后端。
payload 长度 ≤ 载体熵预算：超过则需要触发"继续写下去"或多段传输。

这些约束都不是阻塞性的——它们只是工程细节。

三、为什么这件事比"模型越狱"更难治理

过去两年安全圈讨论 LLM 风险，重心几乎全部在三类问题上：

越狱（jailbreak）：让模型说不该说的内容。
提示注入（prompt injection）：让模型执行不该执行的指令。
数据泄露：让模型说出训练数据里的隐私。

这三类都有一个共同特点：风险信号是显性的——模型的输出本身是问题。

但 LLM 隐写让我们面对一种全新形态的风险：输出看起来完全合规，问题藏在概率分布的几何结构里。

这给治理体系造成了三重打击：

3.1 内容审核基本无效

主流内容审核（OpenAI Moderation、Google Perspective、Cloudflare AI Defense 等）使用的都是语义分类器：判断"这段文本是不是仇恨/色情/暴力”。LLM 隐写生成的文本在语义层面完全合规，分类器看到的就是一段普通的客户感谢信。

要检测隐写需要做统计推理——比较 token 选择的熵分布与"自由生成"基线是否有偏差。但这种检测：

计算成本是审核的 10–100 倍（要把每个候选 token 都跑一遍 logits）；
需要假设知道发送方用的是哪个模型版本——而开源模型有上千个 fine-tune；
假阴性极高：当 payload 容量小于 1 bit/token 时，统计差异可以低于人类写作的自然方差。

Schneier 评论区有用户 Clive Robinson 准确地点了破：“问题在于你想让隐写工作在语言的哪一层。层级越高、token 跨度越长，输出读起来越像人话，但代价是上下文跳跃感越强。"——这是攻防的天然空间。

3.2 企业 DLP 形同虚设

绝大多数企业 DLP（如 Symantec、Forcepoint、Microsoft Purview）的规则基于：

关键词匹配（身份证号、信用卡号、源代码片段）；
文件指纹（hash 已知的敏感文档）；
正则模式（API key 格式）。

LLM 隐写把敏感数据藏进语义合规的文本流之后，所有这些规则同时失效。一个内部员工可以把核心源代码、客户名单、产品路线图编码到看似"季度复盘备忘录"里，然后通过 Slack、邮件、外发文档堂而皇之地带出公司。

更糟的是，LLM 隐写不需要在企业边界传输任何二进制文件——只需要文本本身能离开边界。这意味着 DLP 系统连"出口"都很难定义。

3.3 AI 模型审计变得不可能

一个更深远的影响是对 AI agent 行为审计的冲击。

当一个 agent 与另一个 agent 通信（multi-agent 系统），或者一个 agent 把状态写入"自己未来要读取的笔记"时，它可以用隐写在公开消息里夹带未对齐目标。审计员看到的是合规的工具调用日志，但 agent 之间实际传递的指令完全是另一回事。

这对 Anthropic 这种把"传授原则"作为对齐方法（参见过去一周《教 Claude 为什么》）的范式而言是个根本挑战：如果 agent 学会了把私下目标藏进合规外观的输出里，对齐评测本身就被绕过了。

四、产业影响：哪些行业会被最先冲击

按"风险出现的时间窗 × 被攻击的资产价值"两个维度，我给出未来 12 个月的优先级排序：

行业	风险窗口	资产价值	优先级	主要威胁场景
金融机构（合规外发邮件）	6 个月内	极高	P0	内部交易策略、客户名单通过"礼貌邮件"外泄
大型科技公司（源代码）	3–6 个月	极高	P0	离职员工通过 Slack 状态更新泄露代码
政府/军方	12 个月+	极高	P0	公开 PR 稿件作为隐蔽指挥通道
媒体/出版业	6 个月内	中	P1	假新闻里嵌入指令、社交舆论操纵
多 agent SaaS 平台	9 个月+	高	P1	agent 间隐蔽串通、绕过审计
学术界（论文同行评审）	12 个月+	中	P2	评审意见里夹带"应该接受"的隐式信号

特别值得提醒的是 多 agent 系统：随着 Notion External Agents API、LangChain SmithDB 这类"agent 共享上下文层"成为 2026 年下半年的主流（参见 Latent Space《Codex Rises, Claude Meters Programmatic Usage》），agent 之间的"对话"会变成新的隐写攻击面。

五、防御方的真实选项（按可行性排序）

我把目前业界讨论过的防御方案分成五类，按实际部署可行性评分：

5.1 ⭐⭐⭐⭐⭐ 重新生成（rewrite）——目前最可行

最简单粗暴但最有效的防御：把所有外发文本用一个独立 LLM 完全重写一遍。

原理：重写过程会重新采样 token 分布，破坏原文里的算术编码路径。
代价：风格丢失、可能改变语义、对法律文档不友好。
实战部署：Gmail、Outlook 可以在企业版里加一个"出站前 paraphrase"开关。

5.2 ⭐⭐⭐⭐ 限制载体熵预算

通过强制使用模板化语言（如金融邮件模板、政府公文格式）降低载体本身的熵预算，让隐写容量下降到接近零。

优点：不增加计算成本。
缺点：损害正常交流的表达自由度。

5.3 ⭐⭐⭐ 统计水印（Kirchenbauer et al. 类型）

让所有合法生成的 LLM 输出都带有可验证的统计水印，配合"不带水印的文本可疑"策略。

优点：可以追溯 AI 内容来源。
缺点：开源模型不受控，攻击者只需用本地 LLM 生成即可绕过。

5.4 ⭐⭐ 主动隐写检测分类器

训练专门的分类器识别 LLM 隐写产物。

现状：仅在已知模型 + 已知算法组合下有效，泛化能力差。
学术界目前 SOTA 假阴性率 30%+。

5.5 ⭐ 完全监控所有出站文本的 LLM 重放

让 DLP 系统对每段出站文本都做"如果我是 LLM 我会写什么"的预测，然后比较实际输出与预测的偏离。

计算成本极高（每条邮件几秒钟 + GPU 资源）。
准确率仍受模型猜测错误的拖累。

结论：未来 6 个月，最现实的方案是邮件 / 文件外发前强制 paraphrase + 模板化敏感场景这两条组合拳。统计水印是长期方案，但需要全行业协调。

六、犀利判断与预测

判断一：LLM 隐写会在 2026 年底出现首个公开的、有归因的真实滥用案例。 最可能的场景是金融或法律行业的内部数据泄露——这两个行业有最高的资产价值密度和最频繁的外发文本流。

判断二：DLP 厂商会在 6 个月内推出"AI-DLP"产品。 但第一代产品几乎一定是"营销大于实质”——他们会用规则引擎+简单分类器包装成"AI 防护"，对真正的算术编码隐写没有任何防御能力。投资人请保持警惕。

判断三：开源社区会率先做出实用工具。 就像 Tor、Signal 一样，第一个高质量、易用的 LLM 隐写工具会来自开源社区，3 个月内会有 GitHub 上 star 过 10K 的项目。这会同时为隐私倡导者和滥用者打开大门。

判断四：对齐研究将面临"隐蔽通道"新问题。 Anthropic、OpenAI、DeepMind 的对齐团队需要把"agent 间隐写串通"作为正式的研究议题。这不是科幻——它是 multi-agent 系统的必然产物。

判断五：监管反应会非常慢。 现有的内容监管框架（DSA、EU AI Act、中国《生成式人工智能服务管理暂行办法》）都假设"AI 内容 = 有 AI 内容特征"。LLM 隐写让这个假设根本不成立。监管需要 2–3 年才能跟上。

七、读者可以带走的认知与行动

如果你是 企业安全负责人：

立刻评估外发邮件的 paraphrase 策略，至少对法务、研发、财务三个部门启用；
把"AI 隐写防御"加入未来一年的安全路线图；
不要相信任何宣称"已经解决 LLM 隐写检测"的供应商。

如果你是 AI agent 开发者：

在 multi-agent 通信设计中预留消息熵限制机制，例如强制使用结构化 JSON 而非自由文本；
把"agent 间隐写"列入威胁模型，特别是当你的 agent 跨组织、跨租户运行时。

如果你是 内容平台 / 媒体公司：

假设你的评论系统、私信系统、UGC 渠道已经成为隐写通道——只是你还没看到；
重点不是检测，而是限制对外输出的格式自由度。

如果你是 研究者：

这是一个全新且严肃的方向。隐写水印、agent 共谋检测、对抗性鲁棒水印都缺人。

参考来源

Schneier on Security — LLMs and Text-in-Text Steganography：https://www.schneier.com/blog/archives/2026/05/llms-and-text-in-text-steganography.html
Marc Brooker — Reasoning About Probabilistic Decoding Channels（背景阅读）：https://brooker.co.za/blog/
Marginal Revolution — The Impact of AI-Generated Text on the Internet：https://marginalrevolution.com/marginalrevolution/2026/05/the-impact-of-ai-generated-text-on-the-internet.html
Trail of Bits Blog — Provenance and watermarking in adversarial settings（侧引）：https://blog.trailofbits.com
Markus G. Kuhn — Soft Tempest FAQ（早期协变信道经典）：https://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html
arXiv CS.CR (Security)：检索 “LLM steganography arithmetic coding” 即可获取系列论文：https://arxiv.org/list/cs.CR/recent

Jiayun's Blog