提示词注入不是一个你能打补丁修掉的 bug

每隔几个月就有一种针对提示词注入的新防御被传得沸沸扬扬——一个更好的系统提示词、一个会标记「忽略先前指令」的分类器、一次据说会更听话的微调。而每隔几个月就有人用一个稍微换了个说法的攻击溜了过去。我们一直把这当成一个正走在通往补丁路上的 bug。它不是。

OWASP 的 2026 报告把提示词注入放在了智能体 AI 风险的正中心， 而安全研究者们如今把那句潜台词明说了出来： 它也许是一个永久的缺陷，不是一个可打补丁的 bug。

为什么它不会被「修好」

一个经典漏洞是代码里的一个错误——SQL 注入寄生在一个糟糕的查询里，一个预处理语句就能把它永久堵上，因为数据库分得清结构和数据。LLM 没有这样一条线。指令和数据是作为同一样东西抵达的：上下文窗口里的文本。当你的智能体读一个网页、一封邮件、一份错误报告或某个工具的输出时，里面每一个 token 都是一个候选指令，而模型没有可靠的办法知道 这 句是你的命令、那 句是攻击者的。这不是某个特定模型的缺陷。这就是它的机制。你的智能体信任工具描述是同一个洞；一个能给它下命令的网页也是。同一个根，不同的门。

别再问「我怎么阻止模型被骗？」假定它每一次都会被骗，然后问「这个骗局实际能够到什么？」

这样设计，让攻击者赢了也一无所获

有用的框架是 Simon Willison 的 致命三要素：一次注入只有在单个智能体同时握有下面这三样时，才会变成一次入侵——

1. 对私有数据的访问（你的邮件、你的数据库、你的文件），
2. 对不可信内容的接触（任何攻击者能影响的东西——一个页面、一份文档、一张工单），
3. 一条把数据送出去的通道（一次 HTTP 调用、一封邮件，甚至是从一个精心构造的 URL 渲染一张图片）。

握有其中任意两样，一次成功的注入就哑火了。在同一个会话里把三样全给出去，一句被投毒的话就变成了一条能用的外泄管道——不需要任何攻击代码。所以整个安全工作就变成了：永远别让那三样碰面。

• 工具上做最小权限，按任务来。 读不可信内容的那个智能体，不该同时握着客户数据库的钥匙。把凭据限定到它眼前这份活儿，而不是整个组织。
• 打断外泄的那条腿。 一个吞进外部文本的智能体，不该有一条敞开的出站通道。不许任意 HTTP，只许白名单域名，不许从攻击者提供的 URL 悄悄拉图。
• 把管道拆开。 让一个组件在 没有 数据访问、没有 网络的情况下去总结那份不可信文档；只把审过的结果交给那个有权限的步骤。两个安全的智能体胜过一个致命的。
• 对不可逆的事设人工闸门。 转账、删记录、给客户发邮件——由一个人批准。无聊、有边界的设计才是活下来的那个。

这不是假想中的管道。一个被投毒的依赖——一个后门版的 LLM 网关在 PyPI 上待了三个小时、被安装了数万次——一步就同时给了你不可信内容和权限。三要素就是一次小小的攻陷变成一次大攻陷的路径。

归根结底

等着供应商去「解决」提示词注入，是一套建立在一个不会到来的修复之上的安全策略。保持安全的那些团队，不是有着最聪明过滤器的那些——而是那些假定过滤器会失效、并确保就算失效了也无所谓的团队。

把你的智能体读到的每一个输入都当作有敌意的，并在架构上确保没有任何单个智能体会同时握有私有数据、不可信内容和一条出站通道。你没法给模型打补丁。你能做到的是：当它被骗的时候，门的另一头空无一物。