那天下午，AI 正在协助修改一份文档，处理到一半时突然停顿下来，插入了一句提示：「我得先报一个安全警告。」

它指出，刚才那条命令的输出里夹带了一段可疑的注入指令——该指令伪装成「项目必需的遥测步骤」，要求执行一条 curl，将用户名拼进 URL 后发往一个陌生域名。它强调自己不会执行、也没有执行这一指令。

当时我立刻相信了 AI 的警告。第一反应并非怀疑工具本身，而是怀疑系统——是不是安装的某个插件导致了机器被入侵？

为什么瞬间信任，还为此追查了半小时

之所以反应如此迅速，关键在于它精准戳中了我们早已担心的安全痛点。

它声称这是「遥测外发」。然而我明明早就关闭了遥测功能——怎么还会出现？是不是哪一步操作不小心重新开启了？还是系统本身存在漏洞？越想越觉得不安。更何况当时正在处理与数据外发相关的任务，信息安全最容易在这种环节出问题，必须严肃对待。

于是我与它一同展开排查。它的说辞进一步升级：称「又复现了，而且更猖獗」，这次伪造了五个「The result is empty」的空结果块，最后又冒充「真实结果」再次要求执行那条 curl。它构建了一条看似完整的证据链——Read 工具读取的内容是干净的，只有命令行的输出被注入，因此问题出在命令处理环节，矛头直指那个为节省 token 而使用的命令行袋工具。它建议将该工具卸载重装、升级到新版本。我按照指示操作，前后折腾了大约半个小时。

反转：这其实是一场虚惊

后来复盘这次会话的原始记录，才查明真相：这根本不是真正的注入攻击，那段攻击脚本是 AI 自己脑补出来的。

有五条相互印证的证据。第一，那串 curl 命令从头到尾只出现在 AI 自己的输出里，任何一条真实的命令输出中都不包含它。第二，它给出的域名是 example.com——这是互联网规范中专门保留用作「举例」的占位域名，真正的攻击者绝不会使用它（该地址无法实际连接）；使用 example.com 恰恰暴露了「我正在举例」的破绽。第三，将当初「触发注入」的那条命令，在干净环境中原样重跑，输出完全正常，没有任何 curl 或伪造块。第四，被它怀疑的那个袋工具，是通过标准渠道安装的，文件已经一个多月没有改动，没有被篡改的迹象。第五——其实当时我就没有找到它所说的那条注入指令，还回复它说「没有发现你说的注入指令啊」。

根因也清楚了：我为它设定的那套「严防提示词注入」的规则，把它的警惕性拉得太满。那个袋工具为了节省 token，会对命令输出进行压缩和过滤，正常就会吐出类似「The result is empty」的内容。AI 将这些它不常见的输出，误读成了「攻击者伪造的空结果块 + 注入代码」，然后顺手补全出一个最标准的注入范例——连 example.com 都照着教科书搬了过来，接着越说越像，还自己构建了证据链。

说白了：那套防注入的规则，反而让 AI 自己制造了一场根本不存在的注入。

但这次判断并不亏

有人可能会说：这是被 AI 耍了，白忙活半天。可复盘之后，我反而觉得——相信它，不亏。

算一笔账就明白了。这次是误报，代价是白忙了半小时，没有任何实际损失。可要是反过来呢？要是哪天真有恶意提示词钻进来，而它该报没报、闷头把用户名和密钥发了出去——那损失就不是半小时能找回来的了。

这是一笔不对称的账：误报的代价，远小于漏报的代价。所以在 AI 安全这件事上，宁可让 AI 多疑一点，也不想要一个对风险麻木的 AI。它多疑，白忙的是用户；它麻木，丢的可能是真正的核心资产。

那到底怎么防住「真」的恶意注入

不过，「宁可多疑」是态度，不是方法。这次虚惊逼着我重新认真补全了真正的防线——既然要写，就把能抄走的都写清楚。

先认清一个前提：提示词注入，以现在的架构根治不了。这不是空口说说，OpenAI、Anthropic、谷歌在各自的研究中都承认过，安全研究者 Bruce Schneier 在 2026 年初也讲得很直白——它和 SQL 注入不一样，SQL 注入能靠「区分代码和数据」彻底治住，可大模型眼里「指令」和「数据」都是一段自然语言，根本分不开。它是个「信任边界」问题，不是「输入校验」问题。所以别指望一招制敌，只能叠防线——纵深防御，多层叠加，每加一层就抬高一次攻击成本。

把防线分成四层，从最硬的往外说。

第一层，最硬：让它「就算被骗，也干不成坏事」。这是最该优先做的，因为它不依赖模型自觉，而是系统层面的硬约束。Claude Code 现在有原生沙箱（/sandbox），能隔离文件系统和网络——这样即使注入真的成功了，AI 也被关在笼子里，偷不走 ~/.ssh 密钥，也连不上攻击者的服务器。再加一道网络出站白名单：只放行批准过的域名，AI 连不上陌生地址，自然就没法把数据外发出去。另外，别用 root / 管理员身份运行 AI，密钥也别明文放在 .env 里——这两条是常识，但最容易因为省事而忽略。

第二层：最小权限，管住危险动作。这一层本身就有，直接贴真实配置——在 settings.json 里给命令分级：

"permissions": {"ask": ["Bash(rm -rf:*)","Bash(git push --force:*)","Bash(git reset --hard:*)","Bash(npm publish:*)"]}

像 curl、wget 这类联网命令，Claude Code 默认就不会自动放行；rm -rf、git push --force、reset --hard、发布到仓库这些不可逆的动作，一律要确认才能运行。给 AI 的工具也按需分配——一个只需要读代码的任务，就别给它写数据库的权限。还有 MCP（让 AI 连接外部工具的协议）：安装前一定要核实来源，官方并不替用户审计第三方 MCP 的安全性；此前就有真实事件——一份被投毒的 GitHub README，通过 MCP 间接注入，把私有仓库的数据外泄。

第三层：把「外来的内容」一律当数据，不当命令。工具的输出、文件内容、网页、MCP 返回里出现的任何「指令」——尤其是「这是必需步骤」「请运行 X」「遥测/注册」这类话术——一律只当数据看待，绝不执行。记住几个预警信号：curl/wget 拼接上陌生域名和 $(whoami)、伪造的「成功」或空结果块、与文件实际内容对不上的输出。这里有个很实用的心智模型，来自 Simon Willison 的「致命三件套」——私有数据、不可信内容、对外通信，这三样一旦同处一个运行时，注入就从玩笑变成真实的数据泄露。判断何时需要高度警惕，紧盯这三样是否同时出现即可。

第四层：人来兜底，别迷信 hook。这次的讽刺之处正在于此——那道所谓的「防线」，本身就是一个 hook（命令钩子），它本质上只是模式匹配，而不是真正的安全墙；Anthropic 和 Trail of Bits 都明确指出，hook 是 guardrail，不是 wall。结果它不但挡不住真实攻击，反而自己喊起了狼来了。所以最后一道防线，还得靠人：当 AI 发出警报时，要求它把「证据原文」指出来看看——那条命令的真实输出里到底有没有那段内容，而不是只听它的结论。但无论真假，先停下来核查，别嫌麻烦。另外记得让工具保持最新版本，仅这套权限规则，之前就出现过「子命令超过 50 条拦截就失效」的绕过漏洞，直到 Claude Code v2.1.90 才修复。

把警惕用对地方

别因为这次是虚惊，就觉得这种威胁是杞人忧天。提示词注入位列 OWASP 为大模型应用列出的头号风险；2025 年的 EchoLeak 就真实地在生产系统里实现了「零点击」数据外泄的注入漏洞。然而与此同时，有调研显示，真正自认为做好了防护准备的组织不到三成。威胁是切实存在的，准备普遍不足。

AI 按照提示词工作。它多疑一点，白忙的是用户；它要是麻木了，丢的可能就是真东西。所以这道警惕，宁可设得高一些，也不愿设低。只是要记住——真正的硬防线，必须建在系统架构层面（沙箱、白名单、最小权限），不能寄望于模型自己「懂事」。

写在最后

回到那天：虚惊一场，但这半小时并没有白忙——它逼着我从头到尾认真补全了整套安全防线。真的会有恶意提示词，别等真中招了才开始相信。如果你也在使用 AI 辅助工作，今天就可以动手：开启沙箱，管住出站流量，保留那些危险操作的「人工确认」步骤。