速评：又有人把提示注入叫新的 SQL 注入。
9 月 27 号发在 DEV 上的那篇，我拖到今天才点开，标题前半句就让我叹了口气——这类比从 2023 年喊到现在，喊的人换了一茬又一茬，老剧本了。读下去得承认，写得不算差，讲数据和指令共用通道那段是扎实的。坏就坏在结论，而那个结论，被评论区替作者自己收走了。
SQL 注入的根因是数据跟指令走同一根通道，提示注入是这毛病往上提了一层，这个类比站得住，比那些"AI 安全形势严峻"的空话具体得多。作者还写了句我该抄下来裱起来的话：智能体的有用和它的脆弱，是同一组功能带来的。它得能读私有数据、得能碰不可信内容、还得能对外说话，三条凑齐就能被利用。
然后他给的结论是：跟 SQL 注入不一样，提示注入没有干净的修复方案，因为自然语言不存在对应的参数化查询。
第一个不同意。
文章把当前阶段比作 SQL 注入的 2004 年——漏洞被命名、被理解，行业还没长出成熟防御。这定位我同意，可它顺手漏掉了另一半：2004 年之后，SQL 注入也不是靠教数据库"识别恶意语句"解决的，是靠参数化把通道拆开，让数据根本进不了代码的位置。拿 2004 年当坐标，答案上一次就写着了。
按这个标准看，评论区里有人给出的东西，几乎就是等价物。
一条是双模型：特权模型永远不碰原始不可信内容，只接收结构化摘要，摘要由接触外部内容的那个非特权模型生成。数据换了个形态进来，指令通道本身被掐断——参数化的本质从来不是把危险字符洗掉，而是让数据不进那条通道，只不过这次的"参数"不是数字，是摘要。
另一条更彻底：有人的浏览器原生 agent 从不向模型提供原始网页内容，只给无障碍大纲和交互元素引用，没有 DOM、没有内联脚本、没有可执行内容。这都不是过滤，是换掉不可信内容的存在形式。
第三条，审批不放在模型嘴里：人工审批得绑定收件人、载荷哈希、有效期，由真正发送的那个服务再校验一遍，而不是让模型自己吐一个 approved: true 出来。作者自己都承认，多数对抗测试只覆盖了"没审批"的情况，压根没测"审批后、执行前动作被换掉"这种错配。
三条拼起来，就是评论区自己归出来的那三层——摄取层允许表示成什么、进程允许做什么、模型允许相信什么。作者也认了，说会写进修订版还署名。一篇讲"我们没准备好"的文章，最硬的那段论证是读者写的，这画面本身就挺说明问题。
真正卡住的从来不是技术难，是造出来之后 demo 不好看了。
把那三条隔离方案往产品上一装：不让读私有数据，它就是个聊天框；不让碰外部内容，它连网页都查不了；不让对外发消息，它只能干憋着。而那三条恰恰就是当下 agent 的卖点。文章前半段自己写得好好的，有用和脆弱来自同一组功能，可它没往下推——往下推就是这条结论。
我也不是说大厂什么都没干。今年 2 月 Anthropic 的系统卡把直接注入的指标整个撤了，理由写的是间接注入对企业更相关。这个动作算不上防御的进步，但至少说明边界在挪：讨论重心从"模型会不会被骗"挪到"这个 agent 被允许做什么"。方向是对的，哪怕换方向的动机大概率不是想明白了，而是直接注入那批指标实在没什么好测的了。
至于那些号称能拦下所有提示攻击的框架——作者回得挺狠，也回得对：任何基于提示的防御，跟攻击在同一条通道里，一个自我检查的模型和攻击者共享同一根管子，那能劫持回答的注入，也能劫持"这条输入该不该标红"这个判断。同一个帖