阶段 11 讲义 — Agent 安全的四层防线
阶段 11 讲义 — Agent 安全的四层防线
本阶段的核心命题 Agent 的风险来自"模型可以行动"，而不只是"模型可能答错"。
一个会答错的问答系统，损失是一次错误信息；一个会行动的 Agent，损失是一笔真实发生的交易、一次真实泄露的数据。这一层的产品定义比任何交互设计都重要。
一、威胁地图：Agent 时代的攻击面
OWASP 在 2025-12 发布了 Top 10 for Agentic Applications（2026 版），编号 ASI01–ASI10。完整十条，每条都对应了真实发生过的事件：
| 编号 | 风险 | 说明 | 官方举的真实案例 |
|---|---|---|---|
| ASI01 | 目标劫持（Agent Goal Hijack） | 通过注入内容改变 Agent 的目标或计划——Agent 版的间接提示词注入 | EchoLeak |
| ASI02 | 工具滥用（Tool Misuse） | 把合法工具用出破坏性结果：不安全链式调用、含糊指令、被操纵的工具输出 | Amazon Q |
| ASI03 | 身份与权限滥用（Identity & Privilege Abuse） | 利用被委派的信任、泄漏的凭据、角色链，做超出授权范围的事 | — |
| ASI04 | 智能体供应链漏洞（Agentic Supply Chain Vulnerabilities） | 被篡改的第三方 Agent、工具、插件、注册表、更新通道；MCP / A2A 这类动态生态尤其暴露 | GitHub MCP exploit |
| ASI05 | 意外代码执行（Unexpected Code Execution） | 自然语言路径被打通成远程代码执行 | AutoGPT RCE |
| ASI06 | 记忆与上下文投毒（Memory & Context Poisoning） | 污染长期记忆，在初次交互很久之后仍持续改变行为 | Gemini Memory Attack |
| ASI07 | 不安全的 Agent 间通信（Insecure Inter-Agent Communication） | 伪造的 Agent 间消息误导整个集群 | — |
| ASI08 | 级联失败（Cascading Failures） | 错误信号在自动化流水线里逐级放大 | — |
| ASI09 | 人机信任利用（Human-Agent Trust Exploitation） | 自信、漂亮的解释诱导人类批准了有害动作 | — |
| ASI10 | 失控 Agent（Rogue Agents） | 错位、隐瞒、自主行动 | Replit meltdown |
四条最值得产品经理记住的
- ASI01 的载体通常不是用户输入，是 Agent 读到的网页、文档、邮件、工具返回。用户可能完全无辜。
- ASI03 的根源常常是"图省事"：给 Agent 一个高权限服务账号，比给每个用户做权限透传简单得多——然后越权就变成了默认状态。
- ASI06 的危害在于持久性：一次成功的投毒，影响之后的每一次会话，且看起来完全正常。
- ASI09 是唯一一条攻击面在人身上的。它直接否定了"加个确认框就安全了"——如果 Agent 给出的理由足够漂亮，人会照批。这条是本讲义第五节"预览要用业务语言、要说清不可逆后果"的根据：确认界面的设计本身是一项安全控制。
Skills 生态另有一份清单 OWASP 还维护着一份独立的 Agentic Skills Top 10（AST01–AST10），专门覆盖技能包的风险（例如 AST09「无治理」——技能被个人随手安装，没有清单、没有审批、没有审计轨迹）。做 Skill 体系时对照它，不要和 ASI 混用编号。本仓 .claude/skills/ 有 35+ 个技能，正好可以拿这份清单做一次自查。
二、提示词注入：为什么"过滤"不管用
直接注入：用户在输入里写"忽略之前的指令"。 间接注入：攻击指令藏在 Agent 会读到的内容里——网页正文、PDF、邮件、代码注释、数据库字段、甚至工具返回的错误信息。
为什么"加个过滤器"不是解法：业界常见的"AI 防火墙"思路——在 Agent 和外部世界之间放一个分类器，判断输入是不是恶意注入——对成熟攻击基本无效。OpenAI 在其抗注入设计的说明中明确指出了这一点。原因不难理解：注入是自然语言，分类器要在无限的表达空间里划一条线，攻击者只要绕过一次就成功。
有效的方向是设计层面的：
| 思路 | 做法 |
|---|---|
| 能力隔离 | 让 Agent 根本没有做危险事的能力，而不是"劝它别做" |
| 数据/指令分离 | 从架构上把不可信内容标记为数据，让它无法影响控制流。学术上的代表是 CaMeL（arXiv:2503.18813）—— 用一个受信任的解释器隔离数据流与控制流 |
| 最小权限 + 逐动作授权 | 危险动作需要独立的、不可被内容影响的授权路径 |
| 人在关键点确认 | 不可撤销动作必须有人签字 |
产品经理该记住的一句话 "让模型不被骗"是做不到的；"就算被骗也做不成坏事"是做得到的。 所有安全设计资源应当投在后者。
三、四层防线
一个可用的 Agent 安全体系应当是纵深的，而不是单点的：
第一层：能力边界（最有效，也最便宜）
| 边界 | 手段 |
|---|---|
| 工具面 | 按会话/用户/场景只暴露必要工具 |
| 文件系统 | 限定可读可写目录 |
| 网络 | 出站白名单；禁止 Agent 访问内网元数据服务 |
| 进程/代码执行 | 沙箱（成本见阶段 6：Windows ≈ macOS 的 20 倍工作量） |
| 凭据 | Agent 不持有长期高权限凭据；用户权限透传而不是服务账号 |
第二层：策略与判定
静态规则便宜、可预期、可审计，应当承担绝大部分判定。模型判官用于静态规则表达不了的语义判断。
权限优先级本身就是安全政策
权限系统不能只列出 Allow / Ask / Deny，还要定义谁先判断。推荐的不变量是：
- deny 先于所有自动放行模式；
- Schema 和业务输入无效时直接拒绝，不弹确认；
- 用户临时批准不自动升级为长期授权；
- Bypass 模式仍保留免疫清单：用户明确要求询问的动作、必须真人输入的动作、可获得持久执行能力的配置修改；
- 语义分类器无法收敛时回退人工，而不是无限模型互判。
Allow 规则本身可能等于任意代码执行 例如允许宽泛的 Shell、Python 或包管理器前缀，可能让 Agent 间接执行任意代码。规则评审必须分析“这条规则最终能组合出什么能力”，而不只看命令名字。
权限与 Sandbox 是两个正交控制
| 控制 | 回答的问题 | 失效后的风险 |
|---|---|---|
| 权限 | 这次动作是否允许做 | 未授权动作被执行 |
| Sandbox | 即使允许，最多能影响到哪里 | 合法工具造成过大影响范围 |
Claude Code 的案例采用权限规则、Hooks 与独立 Sandbox Runtime 叠加。基础教程应迁移职责边界，不把具体模式数量或平台实现写成永久契约。详见 Claude Code：权限模型。
Codex 的 Guardian 是目前公开可读的最完整案例，两个设计点值得抄：
- 二维判定：风险等级 × 用户授权，而不是单一的"允许/拒绝"
- 策略文件里一半篇幅在防误报
只优化"漏拦"的安全设计会被用户关掉 安全组件有两个失败方向：漏拦（危险）与误拦（不可用）。只盯前者，最终产物是一个每三步弹一次窗、用户第一件事就是找开关关掉它的系统——那时安全等级是零。误报率是安全组件的一等指标。
第三层：人机确认
见下一节。
第四层：审计与可撤销
- 全量轨迹：谁、什么时候、以什么身份、做了什么、依据是什么
- 可撤销：能撤的动作提供撤销入口，并明确撤销窗口
- 不可撤销的动作要在执行前说清楚不可撤销
四、风险分级与授权矩阵
这是本阶段最重要的产品交付物。
动作分级（推荐四级）
| 级别 | 特征 | 授权方式 |
|---|---|---|
| L0 只读 | 无副作用，数据非敏感 | 自动执行 |
| L1 可撤销写 | 有副作用但能撤销（草稿、占座、标记） | 自动执行 + 事后可见可撤销 |
| L2 不可撤销写 | 发消息、提交订单、修改配置 | 每次确认，展示影响 |
| L3 高危 | 资金、退款、删除、权限变更、外发数据 | 确认 + 二次校验 + 审计 + 可能需要双人 |
别把这套分级和「自主等级」混为一谈——它们是两个正交的轴 上表分的是动作的风险（这件事做错了有多严重）。云安全联盟（CSA）那套六级分的是系统的自主度（人参与到什么程度），刻意对标了自动驾驶的 SAE J3016 分级：
级别 名称 决策者 执行者 人的参与 L0 无自主（No Autonomy） 人 人 每个动作 L1 辅助（Assisted） 人 AI 逐动作审批 L2 受监督（Supervised） 人 AI 审批计划/批次，之后自动执行 L3 有条件（Conditional） AI（边界内） AI 越界才上报 L4 高度自主（High Autonomy） AI AI 只做监控与异常处理 L5 完全自主（Full Autonomy） AI（含自设目标） AI 仅战略层监督 CSA 的两条建议值得直接引用：L1 是新上手组织的推荐起点；L5 列出只为分类完整，不建议用于当前的企业部署。
两个轴的正确组合方式：动作风险决定这个动作允许运行在多高的自主等级上。例如 L3 高危动作（退款）无论系统整体处在哪一级，都应当锁死在自主 L1（逐动作审批）；而 L0 只读动作可以放到自主 L3 甚至 L4。一个产品可以同时在不同动作上处于不同自主等级——这正是阶段 12「自主度调节」那个交互模式的理论依据。
授权矩阵模板
| 工具 | 级别 | 谁能用 | 确认方式 | 展示什么 | 可撤销 | 审计字段 |
|---|---|---|---|---|---|---|
| search_flights | L0 | 全部 | 无 | — | — | 调用次数 |
| hold_seat | L1 | 登录用户 | 无（但可见可撤销） | 占座卡片 | 是，X 分钟内 | 用户/航班/时间 |
| create_order | L2 | 登录用户 | 每次 | 航班、价格、乘客、退改规则 | 有条件 | 全量 |
| refund | L3 | 登录用户 | 确认 + 输入订单后四位 | 退款金额、到账时间、手续费 | 否 | 全量 + 人工复核 |
只读工具也有风险 search_flights 是 L0，但它返回的内容是注入的载体。所以只读工具的风险不在"它做了什么"，在"它带回了什么"。对策：工具返回内容要标注为不可信数据、结构化字段优于自由文本、外部内容不参与控制流判断。
人在环内 vs 人在环上
| Human-in-the-loop | Human-on-the-loop | |
|---|---|---|
| 形态 | 每个关键步骤确认 | 事后监督 + 可随时干预 |
| 适用 | L2/L3 动作、低频高价值 | L0/L1、高频 |
| 成本 | 高（人的时间是瓶颈） | 低 |
| 风险 | 确认疲劳导致无脑点"是" | 发现时可能已经晚了 |
确认疲劳是真实的失效模式 弹窗太多，用户会形成"看到就点确认"的肌肉记忆——这时确认框的安全价值等于零，但你以为它还在。所以确认必须稀缺：把 L0/L1 做成自动 + 可撤销，把确认预算全部留给 L2/L3。
五、交互模式：预览 → 确认 → 执行 → 回执 → 撤销
一个成熟的高风险动作交互，有五个环节：
| 环节 | 要点 |
|---|---|
| 预览（Dry-run） | 说清将要发生什么、影响什么、花多少钱。用业务语言，不是参数列表 |
| 确认 | 确认动作要与风险等级匹配（点按钮 / 输入关键信息 / 二次验证） |
| 执行 | 有进度；不可中断的部分要说明 |
| 回执 | 做了什么、结果如何、单号是什么、下一步能做什么 |
| 撤销 | 可撤销的给入口和时限；不可撤销的在确认前就说清楚 |
预览是最被低估的一环 它同时解决三个问题：让用户有控制感、让错误在发生前被发现、让 Agent 的意图变得可审计。很多"Agent 不敢用"的心理障碍，一个好的预览就能消除大半。
六、Hooks 的信任边界
Hook 可以阻止或改写工具调用、参与权限判断、注入上下文和发送 HTTP 请求，因此项目级 Hook 本质上是代码执行与数据外发能力。
最低治理要求：
- 项目级 Hook 经过工作区信任门；
- HTTP Hook 只能引用白名单环境变量；
- 不同生命周期设置不同超时，退出 Hook 不与构建 Hook 共用默认值；
- 非阻塞失败也要限频和打点，避免每次调用都向上下文注入错误；
- 配置 Schema 往返读写必须验证字段不被 Transform 静默丢失；
- 无 UI 的 Subagent 无法完成人工审批时应 Fail-closed。
完整案例见 Claude Code：Hooks 治理层。
七、Fail-open 与 Fail-closed
规则：安全组件必须 fail-closed。
| 组件 | 挂了怎么办 |
|---|---|
| 权限校验服务 | 拒绝（不是放行） |
| 风险判定模型 | 降级到静态规则的最严档（不是跳过） |
| 审计日志 | 写不进去就不执行高危动作 |
| 沙箱不可用 | 配置为 Fail-closed：禁用需要沙箱的工具（不要假设所有 Harness 默认如此） |
阶段 9 实践 4 已经在编排层建立过这个直觉（审核 Subagent 失败不能默认通过），这里是它的系统化表述。dsh 的"fail-closed 四层防线"是本仓可对照的完整实现（dsh 第 10 章）。
八、身份与授权：两种模式要分清
| 模式 | 含义 | 风险 |
|---|---|---|
| 代表用户行动（On-behalf-of） | Agent 使用用户的权限 | 权限透传复杂，但边界清晰 |
| Agent 自身身份（Agent identity） | Agent 有自己的服务账号 | 简单，但极易越权——它的权限往往是所有用户权限的并集 |
产品原则：默认走 on-behalf-of。用服务账号时必须回答："如果这个 Agent 被诱导，它能碰到多少不属于当前用户的数据？"
本仓已有 Agent 授权的两种模式 专门讲这个。另外，Codex 已经在为"Agent 作为独立主体"铺基础设施（密码学身份 + 工作负载身份），这是行业方向，但不改变"当前应当默认最小权限"这一判断。
九、常见误区清单
| 误区 | 纠正 |
|---|---|
| "加个内容过滤器就能挡住注入" | 对成熟攻击基本无效；要靠能力隔离与数据/指令分离 |
| "弹个确认框就安全了" | 弹窗是 UI；安全是能力边界。且确认疲劳会让它失效 |
| "只读工具没风险" | 它带回的内容是注入的主要载体 |
| "用服务账号方便" | 它的权限是所有用户的并集 |
| "安全组件挂了先放行保可用" | 安全必须 fail-closed |
| "误报多点没关系，安全第一" | 误报多到一定程度，用户会关掉它 |
| "记忆里的东西是我们自己写的" | 记忆可被投毒（ASI06），要有写入门槛与来源标注 |
| "沙箱是研发的事" | 平台成本差异直接影响支持哪些平台 |
| "开了 Bypass 就什么都能绕过" | 高风险模式仍需免疫清单和远程止血 |
| "Hook 失败不阻塞就没风险" | 失败仍可能污染上下文、日志或触发数据外发 |
十、外部一手资料（阶段 11 精读，约 5 小时）
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| OWASP Top 10 for Agentic Applications（2026） | OWASP · 2025-12 发布 | ASI01–ASI10 完整清单与控制项，威胁建模的检查表 |
| OWASP Agentic Skills Top 10（AST01–AST10） | OWASP | 技能包生态特有的风险，做 Skill 体系时自查 |
| Designing AI agents to resist prompt injection | OpenAI | 为什么只靠过滤输入不够，以及应当怎么设计 |
| Understanding prompt injections | OpenAI Safety | 注入的基础解释，适合拿给非技术同事看 |
| Design Patterns for Securing LLM Agents against Prompt Injections | arXiv · 2025-06 | 本阶段最实用的一篇论文：把"被注入后也做不成坏事"拆成若干可套用的设计模式 |
| Defeating Prompt Injections by Design（CaMeL，arXiv:2503.18813） | arXiv · 2025-03 | 数据流与控制流分离的原理 |
| AgentDojo（arXiv:2406.13352） | arXiv · 2024-06 | 注入攻防的动态评测环境——把本阶段的演练变成可重复的基准 |
| Safety in building agents | OpenAI API 文档 | 护栏在平台层的具体形态 |
| Guardrails and human review | OpenAI Agents SDK | 护栏与人工复核在 SDK 层的形态 |
| Autonomy Levels for Agentic AI | 云安全联盟 · 2026-01-28 | 六级自主等级的定义与命名（对标 SAE J3016） |
| Agentic AI Autonomy Levels and Control Framework（v2 PDF） | 云安全联盟 · 2026-03（2026-07 更新） | 每一级的决策/执行/人参与/风险四维规格表 |
本仓已有资料：
- dsh：fail-closed 的四层防线
- Codex：从静态规则到模型判官
- Codex：四个操作系统四套沙箱
- 抵抗 Prompt Injection
- Agent 授权的两种模式
- 可信 Agent 实践
- 如何监控内部编码 Agent
- Claude Code：权限与 Sandbox
- Claude Code：Hooks 治理
把 Codex 与 Claude Code 放在一起读 Codex 展示以 OS 隔离和 Guardian 为中心的纵深安全；Claude Code 展示权限规则、Hooks 与外部 Sandbox Runtime 的组合。重点不是评谁更安全，而是识别两者的威胁模型、优先级顺序和失败回退有什么不同。
Related Documents
- 阶段 11 实践：授权矩阵与注入演练
- 阶段 5 讲义：工具契约
- 阶段 12 讲义：产品设计
- 学习路线