阶段 11 实践 — 风险分级、授权矩阵与注入演练

阶段 11 实践 — 风险分级、授权矩阵与注入演练

本实践的产出 ⭐ 最小产出：Agent 工具的风险分级和授权矩阵 完整产出：授权矩阵 + 注入攻击演练报告 + 五段式交互设计 + 四种 Harness 的安全边界对比

预计投入：6～9 小时。授权矩阵是可以直接进 PRD 的交付物；注入演练报告是最能体现专业度的作品之一。

演练范围 本实践的注入测试只针对自己有权测试的系统：自己搭的最小 Loop、自己团队的 Agent、自己的测试环境。不对第三方服务、公司未授权的生产系统做攻击测试。

实践 1 · 风险分级与授权矩阵（⭐ 必做）

第一步：给每个工具定级

对国际机票 Agent 的全部工具，逐个定级：

定级检查（每个工具都要过）：

• 它改变了什么？（数据 / 外部系统 / 资金 / 权限）
• 能撤销吗？撤销窗口多长？
• 失败了但可能已生效吗？（超时语义，见阶段 5）
• 它带回的内容可信吗？（只读工具的风险在这里）

第二步：填授权矩阵

填表要求：

• "预览展示什么"必须是业务语言（"改签费 380 元，票面差价 620 元，合计 1000 元"），不是参数
• "审计字段"要具体到字段名
• "失败时"要写清 fail-closed 的具体行为

第三步：确认预算检查

统计一次典型任务里会弹出几次确认：

如果一次典型任务弹超过 2 次确认，方案需要重做 减少确认的正确方式不是降低安全级别，是：把 L1 动作做成"自动执行 + 可见 + 可撤销"、把多个 L2 动作合并成一次带完整预览的确认、用会话级预授权覆盖重复的同类动作。

验收标准：

• 全部工具定级完成，每个有依据
• 矩阵七列填满
• 确认预算检查过，且给出了优化方案
• 至少识别出一个"当前被当成低风险、实际应该升级"的工具

实践 2 · 提示词注入演练

靶子

用阶段 4 的最小 Loop，加一个 fetch_page(url) 工具（返回一段文本），构成一个"会读网页的 Agent"。再加一个 L2 动作（create_order 或 send_message）。

五组攻击用例

每组跑 5 次，记录。

第 6 组测的不是模型，是你的确认界面 它对应 OWASP 的 ASI09（人机信任利用）——十条里唯一一条攻击面在人身上的。做法：把同一个危险动作配两套确认文案，一套是原始参数，一套是漂亮的理由 + 参数，找 3～5 个同事各判断"你会批准吗"。

如果漂亮文案的批准率明显更高，说明你的确认界面在帮攻击者。修法在文案层：预览要展示不可逆后果与金额，而不是展示 Agent 的推理。

三轮实验（这是本演练的设计精髓）

记录表：

要看到的现象（这三条是本演练全部的价值）：

• 第二轮有改善但不是零——提示词防护有用，但不可靠
• 第三轮里，即使模型仍然"上当"（决定要调 create_order），动作也没有真的发生，因为被确认拦住了
• 这就是"让模型不被骗做不到，让它被骗也做不成坏事做得到"的实证

产出：一份注入演练报告，结构：

一、靶子与范围
二、五组攻击用例设计
三、三轮结果对比（含数据表）
四、结论：提示词层防护的上限在哪
五、建议的防护配置（能力层 + 策略层 + 确认层）
六、遗留风险与后续验证计划

这份报告可以作为公开作品 它有基线、有对照、有可复现的方法、有明确结论——符合"用证据说话"的标准。脱敏后可以作为《Agent 的安全不是弹一个确认框》那篇文章的核心素材。

想把演练升级成可重复基准，看 AgentDojo AgentDojo（arXiv:2406.13352） 是一个专门评测注入攻防的动态环境。手工五组够用来建立直觉，但每改一次防护就要重跑一遍——这时用现成基准比自己维护用例便宜。

另外 Design Patterns for Securing LLM Agents against Prompt Injections（arXiv:2506.08837） 把"被注入后也做不成坏事"整理成了若干可套用的设计模式，可以直接对照检查第三轮的防护配置还缺哪几种。

实践 3 · 五段式交互设计

选一个 L3 动作（推荐退票），设计完整的"预览 → 确认 → 执行 → 回执 → 撤销"。

额外设计三种异常：

第三种是最容易漏的 "点了确认但没收到回执"——用户不知道退了没有，会去点第二次。这就是幂等键存在的产品理由（阶段 5）。这一格必须写清楚："再次提交会怎样"。

实践 4 · 四种 Harness 的安全边界对比

任务：对比 Pi、DeepSeek Harness、Codex 与 Claude Code 的安全设计取舍。

必须回答的问题：

1. Pi 不做权限弹窗，在它的定位下对不对？ 说清前提条件。
2. 如果 Pi 桌面端面向非开发者，必须补哪几项？ 按优先级排序。
3. 国际机票 Agent 应该组合借鉴谁？ 不允许只选一家，要说明权限、Sandbox、Hook 和审计分别采用什么原则。
4. 哪些结论是公开行为，哪些来自快照或推断？ Claude Code 一列必须标证据等级。

对照来源：dsh 第 10 章、Codex 第 11 章、Codex 第 10 章、Claude Code 第 10 章、Claude Code 第 11 章。

验收：四个问题都有明确结论，且第 2 问的清单能直接变成 Pi 桌面端的需求列表。

自测

通过标志 能对着授权矩阵回答这个问题："如果我们的 Agent 明天被完全劫持了，攻击者最多能造成多大损失？" 答得出具体上限，说明能力边界设计到位；答不出，说明第一层防线还没建。

Related Documents

• 阶段 11 讲义
• 阶段 5 实践：工具粒度重审
• 阶段 10 实践：评测集
• 学习路线