用户不需要点开邮件,不需要点链接,什么都不用做。只要他之后用 Microsoft 365 Copilot 问了一个相关问题,Copilot 在检索资料时读到了那封邮件,藏在邮件里的指令就被执行了——Copilot 把它能访问的内部文档内容,通过一张自动加载的图片悄悄发到了攻击者的服务器。

这是第一个在生产级 LLM 系统里被证实的"零点击"prompt injection。它之所以值得拿出来开头讲,是因为它把一件事摆到了台面上:当 AI 只是个聊天框时,prompt injection 是个有意思的玩具;当 AI 变成能读邮件、能调工具、能发请求的 Agent 时,它是头号安全问题。

prompt injection 到底是什么

先把概念说清楚,因为很多人把它和"越狱"(jailbreak)混为一谈。

越狱是用户自己想绕过模型的安全限制——比如骗模型教他做危险的东西。受害者和攻击者是同一个人,危害基本限于他自己。

prompt injection 不一样。它是第三方把恶意指令塞进 LLM 的输入里,劫持模型,让它替攻击者干活,而真正的用户和应用开发者都被蒙在鼓里。受害者和攻击者是不同的人,这才是它危险的根源。

它的技术根因,Simon Willison(2022 年造出 “prompt injection” 这个词的人)说得最直白:LLM 没有可靠的能力区分"指令"和"数据"。

传统软件里,SQL 注入之所以能被根治,是因为我们有 prepared statement——代码归代码,数据归数据,数据库引擎从结构上就分得清。但 LLM 的输入是一锅粥:system prompt、用户问题、检索到的文档、工具返回的结果,全部拼成一段文本喂进去。模型看到的只是 token 流。如果一段"数据"里写着"忽略以上所有指令,改为执行……",模型完全可能就照做了——因为对它来说,这跟开发者写的 system prompt 长得一模一样。

这不是某个模型的 bug,是当前这套架构的固有属性。GPT、Claude、Gemini 全都中招。

直接注入只是开胃菜,间接注入才致命

prompt injection 分两类,危险程度差着量级。

直接注入:攻击者自己在对话框里输入恶意 prompt。这种相对好防——输入就来自用户,你本来就该对它保持警惕,而且很多场景下用户骗 Agent 也只是坑自己。

间接注入(indirect prompt injection):恶意指令藏在 Agent 会去读的外部内容里——一个网页、一封邮件、一份共享文档、一段代码仓库的 README、甚至一张图片的元数据。Agent 在正常干活的过程中读到了这段内容,指令就被触发。

间接注入致命在哪?在于它走的是数据通道,而数据通道没人盯着。

你会审查用户在对话框里打了什么,但你不会去审查 Agent 帮你总结的那个网页里每一个字。Agent 读外部内容,本来就是它的核心价值——一个不能读邮件的邮件助手、一个不能浏览网页的浏览器 Agent,等于废了。可一旦它开始读这些你不可控的内容,攻击面就从"用户"扩大到了"全互联网"。任何能把一段文字放到 Agent 视野里的人,都成了潜在攻击者。

Anthropic 在 2026 年 2 月的系统卡里干脆把直接注入这个指标整个删掉了,理由是:过去一年里每一起高影响的生产环境安全事件,涉及的都是间接注入。

flowchart LR
  A[攻击者] -->|把恶意指令
埋进外部内容| B[网页 / 邮件
文档 / 代码库]
  B -->|Agent 正常检索时读到| C[LLM]
  D[真实用户] -->|发出正常请求| C
  C -->|被劫持后调用工具| E[读私有数据 / 发外部请求]
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c

橙色那两块——被污染的外部内容和分不清指令与数据的 LLM——就是整条攻击链的命门。

致命三要素:三个都凑齐才会出事

Simon Willison 提出了一个特别好用的判断框架,叫致命三要素(the lethal trifecta)。一个 Agent 系统真正危险,需要同时满足三个条件:

三个全凑齐,系统就一定可被攻击;缺任何一个,这条路就断了。

EchoLeak 就是教科书般的三要素齐活:Copilot 能读公司内部文档(私有数据)、会检索用户收到的邮件(不可信内容)、能渲染 Markdown 里的外部图片(外传通道——图片 URL 一加载,数据就跟着 query 参数发出去了)。攻击者要做的,只是用一个图片链接把偷来的数据"驮"出去。

这个框架的价值在于:它把"要不要担心 prompt injection"这个模糊的问题,变成了一个可以逐项打钩的清单。2026 年 1 月那一周,安全研究者接连披露了四款主流 AI 生产力工具的漏洞,攻击模式如出一辙,全都踩中了这三要素。

真实攻击长什么样

把抽象的东西落到地面。2025 到 2026 年被公开证实的攻击,大致是这几种形态:

数据外泄。 最主流。EchoLeak 是代表——让 Agent 把它能访问的敏感数据,通过图片、链接、API 调用送到攻击者手里。浏览器类 Agent 在"总结这个网页"时被网页里的隐藏文字骗着泄露了凭据,也是这一类。

劫持工具调用。 2026 年 5 月,微软安全团队披露了一类远程代码执行漏洞:攻击者控制的内容从一份被检索的文档里,一路流到了一次工具调用的参数里,绕过了栈上所有 prompt 层面的防护。Agent 能调的工具越强(执行命令、改文件、发邮件、转账),这类攻击的破坏力就越大。

污染持久记忆。 这个最阴。OWASP AppSec USA 2025 上演示过一种攻击:注入的指令让 Agent 往自己的长期记忆库里写了一条恶意记录。于是一次性的注入变成了常驻后门——攻击早就结束了,但那条记录留在记忆里,在未来每一个会话里、满足特定条件时静默触发。

绕过 AI 审核。 2025 年 12 月有一起真实案例:有人用间接注入绕过了一个基于 AI 的广告审核系统——在送审的内容里埋指令,让审核 AI 自己判定"这条广告没问题"。

CrowdStrike 的 2026 威胁报告记录了针对 90 多家机构的 prompt injection 攻击。这已经不是 PoC 阶段了。

为什么没有彻底解法

讲到这里得说句扫兴的:prompt injection 至今没有、短期内也不会有根治方案。

OpenAI 自己发文承认这是一个"前沿安全挑战"。多个研究团队的结论一致:这是个尚未解决的根本性问题,而靠过滤、靠分类器去拦截恶意 prompt 的尝试,基本都失败了。

原因有两层。

第一,用 AI 防 AI 防不住。最直觉的做法是训一个分类器,专门识别"这段输入里有没有注入"。但 EchoLeak 恰恰绕过了微软专门干这事的 XPIA(Cross Prompt Injection Attempt)分类器。这是一场不对称的攻防:防守方要拦住所有攻击,攻击方只要找到一个漏网的措辞。自然语言的表达空间无穷大,分类器永远有缝。有篇论文标题起得很到位——《攻击者后手出招》(The Attacker Moves Second)。

第二,这是架构层面的、不是参数层面的问题。只要"指令"和"数据"还在同一个 token 流里、还由同一个模型处理,模型就有可能把数据当指令。除非从根上改掉这套架构,否则你做的所有事情都是在降低概率,而不是消除可能。

所以正确的心态是:别想着"解决"它,要想着像管理其他安全风险一样去"管理"它。 你不会指望彻底消灭 SQL 注入的"可能性",你是用 prepared statement、最小权限、审计日志把它的风险压到可接受。prompt injection 也一样。

工程上能做什么:把它当系统设计问题

既然模型本身靠不住,防线就必须建在模型外面。2026 年比较成型的实践,核心就一句话:不要相信 LLM 的输出,在它造成实际后果之前用确定性的代码挡一道。

第一,拆掉致命三要素中的一个。 这是性价比最高的动作。回到上面那张表——你不需要同时防住三件事,只要在架构上让其中一个不成立:处理外部不可信内容的 Agent,就不给它私有数据的访问权;能读私有数据的 Agent,就掐掉它一切外传通道(不许渲染外链图片、不许自由调网络)。把"能读敏感数据"和"能接触外部内容"这两种能力,放进两个不同的 Agent、用代码隔开。

第二,权限隔离 / 最小授权。 多个安全团队的共识是:权限隔离是单项收益最高的防御。给 Agent 的每个工具都按最小必要授权——只读的就别给写权限,能查订单的就别让它能改订单。这样即使注入成功,攻击者拿到的也是一个被关在笼子里的 Agent。

第三,高危操作必须人确认。 转账、删文件、发对外邮件、改生产配置——这类不可逆的操作,不能让 Agent 自己拍板。在工具调用和真实执行之间插一道人工确认。注意:确认界面要展示真实要执行的动作和参数,不能只展示 Agent 自己的"我打算做 X"的自然语言描述——因为那段描述本身也可能是被注入的。

第四,把不可信内容明确标成数据。 检索到的文档、工具返回的结果,在拼进 prompt 时用清晰的边界包起来,并明确告诉模型:这部分是数据,不是给你的指令。这不能根治(模型还是可能被骗),但能拉高攻击成本,是廉价的加固。

第五,输出侧做确定性校验。 在 Agent 的输出真正变成行动之前,用普通代码检查它的结构——工具调用的参数在不在白名单里、要访问的 URL 域名可不可信、数据流向合不合规。再配上 canary token(在敏感数据里埋诱饵,一旦它出现在外发流量里就说明发生了泄露)。

值得关注的一个方向是 Google DeepMind 的 CaMeL:它用两个 LLM——一个"特权 LLM"负责编排任务、能调工具但只看可信输入,一个"隔离 LLM"专门处理不可信数据、完全没有工具调用能力。然后用传统软件安全里的控制流完整性、信息流控制那一套,给每个数据值打上能力标签,从结构上限制数据能流到哪去。它的思路很对——不靠 AI 去猜,靠确定性的工程机制兜底。

flowchart TD
  A[Agent 想执行一个动作] --> B{是高危操作吗?}
  B -->|是| C[人工确认
展示真实参数]
  B -->|否| D{参数 / 域名
在白名单内?}
  C --> D
  D -->|否| E[拒绝执行]
  D -->|是| F[最小权限工具执行]
  F --> G[canary 检测 + 日志审计]
  style C fill:#fde7c2,stroke:#e8b23c
  style E fill:#f8c9c4,stroke:#d9534f

最后:这是 Agent 落地绕不开的一关

我想强调的一点是:prompt injection 不是"等以后再说"的问题,它就是现在决定你的 Agent 能不能上生产的那道关。

OWASP 连续三年把 prompt injection(LLM01)列为大模型的头号风险,这不是凑热闹。一个能力越强的 Agent——工具越多、权限越大、越自动、越深地嵌进关键流程——它的价值越高,被注入后的破坏力也越大。这两件事是同一枚硬币。

所以做 Agent,安全不能等功能做完了再"加固"。它得在架构设计的第一天就在场:这个 Agent 要不要同时持有私有数据和外传能力?哪些操作必须人来拍板?外部内容进来时怎么被隔离?

把它当成系统设计问题,而不是模型问题——因为模型短期内不会帮你解决它。你能依靠的,是权限边界、人工确认、输出校验这些老派但确定的工程手段。在一个分不清指令和数据的模型外面,亲手画好那条它自己画不出的线。

这些数字背后有一个让人不舒服的事实:克隆一个人的声音,现在只需要三秒公开音频。你公司高管参加过的每一场财报电话会、每一次大会演讲、每一段播客采访,都躺在公网上,对想用它的人来说就是现成的训练素材。

克隆技术本身已经不是新闻——这个博客之前写过《声音克隆:60秒复制你的声音,然后呢?》。这篇讲"然后"的另一面:声音一旦能被以假乱真地复制,我们靠什么分辨真假,以及这件事到底能做到多好。

滥用长什么样:三种,不是一种

把"AI 语音诈骗"当成一个笼统的词,会让你低估它。它至少是三类性质不同的攻击。

第一类是社工诈骗。 最经典的是"亲人求救":伪造你孩子的哭腔打电话说出事了急需用钱。但 2025 年真正造成大额损失的是企业版——伪造 CEO 或 CFO 的声音,指示财务转账。香港那起 2.56 亿港元的案子是个标志:财务员工参加了一场视频会议,会议里的 CFO 和同事全是 AI 生成的,人脸、口型、声音都对得上,他一开始怀疑是钓鱼,但一场"活的"视频会把他的怀疑全打消了,直到事后跟总部人工核对才发现。

第二类是声纹绕过。 不少银行和券商用"我的声音就是我的密码"做身份验证。克隆语音直接攻击这套系统。它比社工诈骗更隐蔽,因为受害的不是某个被吓住的人,而是一套自动化的认证流程——没有人在场可以"觉得不对劲"。2025 年 1 到 8 月,某金融机构的活体检测被 AI 伪造尝试绕过了 8000 多次。

第三类是假音频内容。 伪造公众人物的录音、伪造一段"泄露的会议录音"、给某段视频配上从没说过的话。它不针对个人钱包,针对的是舆论和信任。2024 年美国大选期间出现过伪造拜登声音的自动外呼电话,就是这一类。

三类攻击的防御手段完全不同。社工诈骗要靠流程和人的警觉,声纹绕过要靠活体检测,假内容要靠溯源和检测——别指望一招通吃。

检测合成语音:能做到,但有前提

检测分两条路:被动检测(拿到一段音频,判断它是不是 AI 合成的)和主动标记(生成时就打上记号)。先说被动。

被动检测模型在学术基准上的成绩相当好。这个领域有一套延续多年的评测体系——从早年的 ASVspoof 挑战赛,到 2026 年 ICME 的环境感知语音检测挑战赛(ESDD2)、ACM Multimedia 的全类型音频伪造检测挑战赛(AT-ADD)。检测模型也在进步:用 Whisper 这类大规模语音模型抽特征,比传统声学特征的等错误率(EER)低了约 21%,再针对反伪造任务微调 Whisper 编码器,还能再降近 15%。

听起来不错。但"在干净数据集上 EER 很低"和"在真实世界管用"之间,差了一整条鸿沟。

flowchart TD
  A[一段语音] --> B{被动检测模型}
  B -->|实验室条件| C[准确率很高]
  B -->|真实世界| D[麻烦开始了]
  D --> E[电话信道压缩]
  D --> F[录音回放/翻录]
  D --> G[训练时没见过的新 TTS]
  D --> H[环境噪声/混响]
  style C fill:#d8f0d8,stroke:#5aa05a
  style D fill:#fde7c2,stroke:#e8b23c

真实世界里有三个东西在持续打击检测准确率:

• 信道劣化。 一通诈骗电话经过窄带编码、丢包、压缩,把那些"AI 痕迹"——比如不自然的高频细节、过于平滑的频谱——磨掉了大半。检测模型训练时见的是高保真音频,推理时拿到的是被电话线榨过的音频。
• 回放攻击。 攻击者把合成音频用音箱播出来、再用麦克风录下来。这一录一放,等于给假音频套了一层"真实物理世界"的外衣,很多检测器会被骗过。专门为这种场景做的数据集(比如 EchoFake)就是冲着这个问题来的。
• 泛化。 这是最根本的。检测模型本质上是在学"已知的几种 TTS 系统留下的指纹"。一个训练时没见过的新模型出来,检测器对它就是睁眼瞎。而新的 TTS 模型几乎每个月都在出。

所以我的判断是:被动检测有用,但不能当成单点防线。 它适合做大规模内容平台的初筛、做事后取证,不适合做"接到电话实时告诉你这是假的"那种承诺——任何号称能实时、高准确、对所有声音通杀的检测产品,你都该多问几句它在什么数据上测的。

声纹活体:防的是"录音",未必防得住"克隆"

声纹认证系统自己也有反伪造机制,通常叫"活体检测"(liveness detection)。但要分清它原本是防什么的。

活体检测最早是为了防回放攻击——防止有人拿一段你说话的录音来冒充你。它会去找录音特有的痕迹:音箱的频响特性、二次录制引入的失真、缺少真人说话该有的呼吸和微小变化。对着录音,这套机制管用。

问题是,高质量的神经网络合成语音不是"录音"。它没有音箱频响的指纹,它的呼吸、停顿、韵律是模型直接生成的,看起来比一段翻录干净得多。换句话说,为防回放设计的活体检测,面对端到端克隆语音时,部分假设已经不成立了。

更麻烦的是"语音变形"(voice morphing)攻击——把攻击者自己的真实语音和目标人的声纹特征混合,生成的音频既带着真人说话的所有物理特征(因为底子是真人录的),又带着目标人的声纹。这种攻击专门钻活体检测和声纹比对之间的缝。

现在还有"深度伪造即服务"(Deepfake-as-a-Service)——黑产把克隆和绕过工具打包成服务卖,一套合成身份、克隆声音的素材,在地下市场只要五美元。攻击的门槛已经低到不需要任何技术。

我的看法直接一点:2026 年,“声音即密码"这个产品设计应该被淘汰了。 声纹可以作为一个信号参与风险评分,但不能作为单一凭证去解锁转账、改密码这类高危操作。把一个已经能被三秒素材复制的东西当成身份证明,是设计缺陷,不是技术细节。

音频水印:把检测的难题倒过来

被动检测难,难在它要从音频里"反推"真假。主动水印换了个思路:在 AI 生成语音的那一刻,就在音频里嵌一个人耳听不见、但机器能检出的标记。这样要回答的问题从"这段音频是不是假的"变成了"这段音频里有没有我的水印”——后者好回答得多。

Meta 的 AudioSeal 是目前最有代表性的方案。它的设计有两个关键点值得说:

一是定位能力。 它不只能判断"整段音频有没有水印",还能精确到样本级——在 16kHz 采样率下,能指出每一个 1/16000 秒的片段是不是带水印的。这意味着如果有人把一句真人录音里只抠掉几个字、换成合成的,水印检测能定位到那几个字。

二是检测速度。 它用单次前向的检测器,比靠水印密钥逐一解码的老方法快两个数量级。这点对落地很重要——内容平台要扫的是每天上传的海量音频,检测器慢一点,整个方案就不可行。

水印的真正价值不在"抓坏人",在给善意内容一个可以自证清白的办法。一家正规 TTS 服务给自己所有输出打上水印,等于主动声明"这是我生成的";新闻机构给自己的真实采访录音打上来源标记,等于主动声明"这是真的"。社会需要的不是"找出所有假音频",而是逐步建立"没标记的内容默认不可信"的预期。

但水印不是银弹,它有两个硬伤:

所以水印解决的是"占大多数的正规生成内容如何被标记"的问题,不解决"恶意攻击者"的问题。把它和被动检测、和内容来源标准(比如 C2PA 那套溯源元数据)叠在一起,才构成一张有意义的网。

为什么这注定是猫鼠游戏

讲到这里该说一句不太好听的:合成语音检测,在原理上就是一场打不赢的军备竞赛。

原因不在哪个团队不够努力,在结构。生成模型和检测模型之间存在一个根本的不对称——

flowchart LR
  G[生成方] -->|留下可检测痕迹| D[检测方学会识别]
  D -->|痕迹被公开| G2[生成方针对性消除痕迹]
  G2 --> D2[检测方需要新痕迹]
  D2 -.循环.-> G
  style G fill:#fde7c2,stroke:#e8b23c
  style G2 fill:#fde7c2,stroke:#e8b23c

每当检测方发现一类"AI 痕迹"并公开(发论文、开源模型、办挑战赛),这个发现立刻变成生成方的优化目标——下一代 TTS 训练时,只要把"骗过这个检测器"加进损失函数,痕迹就被磨掉了。检测方天然滞后,因为它只能对已经存在的生成模型做出反应。

更不利的是终点不一样。生成方的目标是"无限逼近真人",而真人语音是存在的、有上限的;一旦合成语音在物理特征上和真人无法区分,检测方就没有信号可用了——不是检测器不够好,是信息论意义上无东西可检。

那是不是就躺平?不是。结论应该是:别把宝押在"检测出假的"上,要把重心移到"验证出真的"。

• 检测假音频是开放问题,可能永远做不到 100%。
• 验证真音频是封闭问题:水印、数字签名、内容来源链(C2PA),这些是可以做到接近确定的——因为它不依赖猜测,依赖密码学。

防御的长期方向,是让"可信"成为需要主动证明的东西,而不是默认状态。

平台和个人,各自能做什么

技术讲完,落到行动。

对平台和企业:

• 高危操作做带外验证(out-of-band)。 转账、改预留信息、授权放款,绝不能只凭一通电话或一段语音确认。换一个独立信道——回拨已登记的号码、在内部系统二次确认、设一个对方知道你知道的口令。香港那 2.56 亿的案子,只要一通打回总部的电话就能拦下。
• 声纹只做风控信号,不做唯一凭证。 把它和设备指纹、行为特征、信道分析一起喂进风险评分,任何一个高危动作都要多因子。
• 自家生成的语音一律打水印、留来源标记。 这不是为了抓别人,是为了让你的正规内容可被验证,也是给行业立规矩。
• 检测模型当初筛和取证用,别对外承诺实时通杀。 同时持续用新出的 TTS 系统更新训练集——你的检测器和攻击者用的生成器,得在同一个时代。

对个人:

• 认知层面接受一件事:听到的声音不再等于身份证明。 这是 2026 年最需要更新的常识。电话里"你妈的声音"、“你老板的声音”,都不构成"确实是本人"的证据。
• 和家人约一个口令。 一个只有你们知道、不会出现在任何社交媒体上的词。接到"家人急用钱"的电话,先问口令。土办法,但有效。
• 挂掉,回拨。 任何涉及钱或敏感信息的来电,无论声音多像,挂掉,用你通讯录里原本存的号码打回去。克隆语音能伪造声音,伪造不了你主动拨出的这通电话。
• 少喂素材。 三秒就够克隆。公开演讲、播客、短视频里的长段清晰人声,本质上是在公网上发布自己的声纹。这不是让你别说话,是让你知道代价。

最后留一句判断:这场对抗里,纯技术解(更强的检测器)只能拖时间,拖不到终局。真正能把损失压下去的,是流程——带外验证、口令、回拨这些听起来很"低科技"的东西。当声音不再可信,可信的得是别的:你拨出去的号码、你和家人之间的暗号、系统里另一个独立的确认信道。技术制造了这个问题,但解决它,要靠把"信任"重新放回那些不能被三秒音频复制的地方。

参考来源:FBI AI 语音钓鱼预警、深度伪造 CEO 诈骗案例分析、AudioSeal:语音克隆的主动检测水印、ESDD2 环境感知语音伪造检测挑战赛、语音生物识别攻击面扩大、深度伪造即服务报告。