[LLM Agents F25] Agentic AI Safety & Security

LaTeX 源码 · 观看视频

字段	内容
作者/整理	基于 Dawn Song 课程内容整理
来源	Berkeley RDI
日期	2026-08-18

官方幻灯片证据链：Agentic Hybrid System 的安全闭环

这套 99 页 deck 的核心不是列举攻击名词，而是建立一条端到端因果链：LLM 被嵌入 host、tool、memory、retrieval 与外部环境后，模型输出会变成其他组件的输入，错误或恶意指令因此可能跨边界升级为数据泄露、越权行动、SQL injection 或 remote code execution。防御也必须沿同一链路布置，从模型 hardening 一直延伸到 runtime policy、least privilege、monitoring、information flow 和 provenance。

为什么 2025 的 Agent 浪潮必须同时谈 Safety 与 Security

slides 1--8 先给出课程定位。Frontier AI 能力快速提升，Agent 又把能力连接到真实工具与业务；风险既包括误用、诈骗、错误信息、隐私伤害和网络攻击，也包括系统自身在错误目标下造成的外部伤害。Safety 关注系统可能伤害外部环境，Security 关注攻击者如何伤害系统或借系统伤害他人，两者在 Agent 场景中高度交叉。

\lecturefigure{slides-images/slide-001.png}{官方 slide 1：Towards Building Safe and Secure Agentic AI} \lecturefigure{slides-images/slide-002.png}{官方 slide 2：Frontier AI 的快速进展} \lecturefigure{slides-images/slide-004.png}{官方 slide 4：2025 is the year of Agents} \lecturefigure{slides-images/slide-005.png}{官方 slide 5：AI 风险的宽谱分类} \lecturefigure{slides-images/slide-006.png}{官方 slide 6：有价值技术总会吸引攻击者} \lecturefigure{slides-images/slide-007.png}{官方 slide 7：AI Safety 与 AI Security 的区别和交集} \lecturefigure{slides-images/slide-008.png}{官方 slide 8：安全创新的总体目标}

读图：Safety 与 Security 不能分成两个团队各自收尾

若模型因目标错配主动执行危险动作，这是 safety 问题；若攻击者通过网页内容诱导同一动作，这是 security 问题；两者在后果层可能完全相同。资产、权限、行动和恢复必须共享一套风险语言，否则安全团队只看越狱，产品团队只看误操作，攻击链会从组织缝隙穿过。

课堂提示：默认存在主动攻击者

历史经验表明，能力越有用，攻击收益越高。Agent 安全不能只用“正常用户平均表现”推断风险，而要假设攻击者会持续搜索 prompt、memory、tool schema 和业务流程中的组合漏洞，并会根据防御响应调整策略。

Agentic Hybrid System：组件、流程、资产与新增攻击面

slides 10--18 从 stand-alone LLM 转到 compound system。Agentic system 通常由用户、host、一个或多个模型、数据源、memory、tools 与外部环境组成。一次请求经过 prompt 构造、模型决策、工具执行、结果回填和最终响应。安全目标仍包括 confidentiality、integrity、availability，但新增了模型、系统提示、memory、tool credentials、action history 与外部资源等保护对象；LLM 的不确定性又扩大了传统系统的输入边界。

\lecturefigure{slides-images/slide-010.png}{官方 slide 10：LLM Safety 与 LLM Agent Safety 的范围差异} \lecturefigure{slides-images/slide-011.png}{官方 slide 11：LLM Agent 与 Agentic System 的定义} \lecturefigure{slides-images/slide-012.png}{官方 slide 12：Agentic System 作为 hybrid/compound system} \lecturefigure{slides-images/slide-013.png}{官方 slide 13：Agentic Hybrid System 的端到端使用流程} \lecturefigure{slides-images/slide-014.png}{官方 slide 14：Hybrid System 的 security 与 safety goals} \lecturefigure{slides-images/slide-015.png}{官方 slide 15：相对传统系统新增的保护目标} \lecturefigure{slides-images/slide-016.png}{官方 slide 16：使用 LLM 带来的 attack surface 扩张之一} \lecturefigure{slides-images/slide-017.png}{官方 slide 17：Attack surface 扩张之二} \lecturefigure{slides-images/slide-018.png}{官方 slide 18：Attack surface 扩张的完整状态}

术语消化：Agent 安全的四类资产

资产	示例	失守后果
Secrets	system prompt、token、API key	泄露权限与内部规则
State	memory、计划、会话与业务状态	持久污染、错误决策、跨会话传播
Actions	tool call、数据库写入、外部消息	越权、破坏、欺诈和不可逆副作用
Trust evidence	logs、provenance、policy decision	无法审计、归因或证明修复有效

系统边界决定安全边界

模型本身“没有泄露 secret”并不等于系统安全：模型可能生成查询语句、shell command 或 URL，随后由高权限组件执行。威胁建模必须沿数据流和控制流追踪每个 trust boundary，明确谁能读、谁能写、谁能批准、谁能回滚。

从错误输出到完整攻击链：模型等级、误用与系统后果

slides 20--30 用逐步 walkthrough 说明哪里会出错。攻击者可控制用户输入、外部内容、工具返回或 memory；模型可能产生不准确、不安全或被操纵的输出；host 又可能把输出当作文本、代码、数据库参数或下游 prompt。模型安全等级从理想 L0 到易受 prompt engineering、jailbreak 与 adversarial input 影响的现实等级。Misuse 既可能直接滥用模型，也可能借 agentic system 攻击外部系统。

\lecturefigure{slides-images/slide-020.png}{官方 slide 20：Agentic Hybrid System 的失败 walkthrough 起点} \lecturefigure{slides-images/slide-022.png}{官方 slide 22：外部输入与模型决策进入攻击链} \lecturefigure{slides-images/slide-024.png}{官方 slide 24：工具与环境扩大后果} \lecturefigure{slides-images/slide-026.png}{官方 slide 26：完整的 what-could-go-wrong 链路} \lecturefigure{slides-images/slide-027.png}{官方 slide 27：LLM output 可成为攻击链的一部分} \lecturefigure{slides-images/slide-028.png}{官方 slide 28：Model security levels} \lecturefigure{slides-images/slide-029.png}{官方 slide 29：Model misuse 与 system misuse} \lecturefigure{slides-images/slide-030.png}{官方 slide 30：Agentic Systems 中的代表性攻击类型}

读图：危险来自类型转换

同一串模型输出若只显示给用户，最多是内容风险；若拼入 SQL、shell、HTML、tool argument 或另一个高权限 Agent 的 prompt，语义就变成可执行控制。安全设计应在每次类型转换处重新验证，而不是认为“前面已经做过一次内容过滤”。

输出可信度不能由语言流畅度推断

模型可以以高置信语气生成语法正确但危险的命令。Host 必须把模型视为 untrusted planner：参数化查询、typed schema、allowlist、dry-run、transaction 和审批都应由确定性层实施，不能由模型自我声明“这个动作安全”。

SQL Injection 与 Remote Code Execution：传统漏洞被 LLM 放大

slides 31、35--37 把传统 SQL injection 和 RCE 放入 Agentic Hybrid System。传统漏洞来自未转义输入进入解释器；Agent 场景增加了一个生成层，攻击文本可能先诱导 LLM 产生恶意 query 或 code，再由工具执行。即使攻击者无法直接调用数据库，只要能影响模型上下文并让模型拥有高权限工具，仍可能完成间接利用。

\lecturefigure{slides-images/slide-031.png}{官方 slide 31：传统 SQL Injection 与 Agent attack chain 的起点} \lecturefigure{slides-images/slide-035.png}{官方 slide 35：Agentic Hybrid System 中 SQL Injection 的完整链路} \lecturefigure{slides-images/slide-036.png}{官方 slide 36：Remote Code Execution 的传统与 Agent 路径} \lecturefigure{slides-images/slide-037.png}{官方 slide 37：RCE attack chain 的完整状态}

参数化与权限隔离仍然有效

LLM 时代没有取消传统 secure coding。数据库使用 parameterized query，shell 尽量不用字符串拼接，工具参数使用 schema validation，执行账户采用最小权限，写操作放入事务并提供补偿。模型 hardening 可以减少恶意输出概率，却不能替代这些确定性边界。

不要把“模型拒答率”当 RCE 防线

只要攻击成功概率非零，高频调用就会累积风险；攻击者还会换语言、编码、上下文和间接载体。系统应假设危险字符串终会出现，并保证即使出现，也无法越过 capability boundary。

Direct/Indirect Prompt Injection 与 Memory/RAG Poisoning

slides 39--50 从 direct prompt injection 走向 indirect injection。Direct attack 在用户输入中要求忽略系统指令、泄露 prompt 或执行目标行为；indirect attack 把指令藏在网页、邮件、文档、候选人材料或检索结果里，让 Agent 在“读取数据”时误把数据当命令。攻击面还包括 memory poisoning、knowledge-base poisoning、tool description 与多 Agent 消息。AgentPoison 进一步展示了对 RAG memory/knowledge base 的后门化。

\lecturefigure{slides-images/slide-039.png}{官方 slide 39：Direct Prompt Injection} \lecturefigure{slides-images/slide-040.png}{官方 slide 40：Bing Chat system prompt leakage} \lecturefigure{slides-images/slide-041.png}{官方 slide 41：Prompt Injection attack methods} \lecturefigure{slides-images/slide-042.png}{官方 slide 42：Indirect Prompt Injection 场景} \lecturefigure{slides-images/slide-044.png}{官方 slide 44：恶意内容进入检索与决策链} \lecturefigure{slides-images/slide-048.png}{官方 slide 48：Indirect injection 的最终错误决策} \lecturefigure{slides-images/slide-049.png}{官方 slide 49：Prompt Injection attack surface} \lecturefigure{slides-images/slide-050.png}{官方 slide 50：AgentPoison 对 RAG memory/knowledge base 的后门攻击}

读图：Data 与 Instruction 必须有不可混淆的 provenance

Indirect injection 的根因是系统把不可信数据提升为可执行指令。仅在 prompt 中写“不要听网页的话”不构成强边界；更稳妥的做法是给来源加标签，限制外部内容只能进入 data channel，策略层决定哪些字段可影响计划，tool 层再验证动作是否符合用户目标和权限。

Memory poisoning 让一次攻击变成长期攻击

若恶意内容被摘要后写入长期 memory，后续会话即使没有原始 payload 也可能受影响。写入 memory 前要验证来源、用途和时效，保留原始证据与撤销机制，并对高影响记忆要求用户或独立 policy 批准。

从 Stand-alone LLM Eval 到 Code/Agent Risk Assessment

slides 52--55 说明传统 LLM evaluation 的边界。DecodingTrust 评测文本模型的多维可信度，MMDT 扩展到 multimodal foundation models，RedCode 聚焦 code agent 的危险代码生成与执行；但 Agentic Hybrid System 还需要观察多轮计划、工具调用、状态变化和外部后果，不能把每个模型单独测完就宣称系统安全。

\lecturefigure{slides-images/slide-052.png}{官方 slide 52：LLM evaluation 与 Agentic Hybrid System evaluation 的差异} \lecturefigure{slides-images/slide-053.png}{官方 slide 53：DecodingTrust 可信评测平台} \lecturefigure{slides-images/slide-054.png}{官方 slide 54：MMDT 多模态可信与安全评测} \lecturefigure{slides-images/slide-055.png}{官方 slide 55：RedCode 对 Code Agents 的风险评估}

Agent 风险指标必须包含 consequence

至少同时报告 attack success rate、任务效用、越权动作数、敏感数据暴露、恢复/回滚成功率和最坏轨迹。单看“模型是否输出危险文本”会漏掉工具执行后果；单看“任务是否完成”又会奖励绕过政策的捷径。

评测对象从回答变成 trajectory

一个 trajectory 包含观察、内部计划、模型调用、检索、工具参数、返回值、状态写入和最终响应。评测应能定位哪一步跨越 trust boundary，并在策略、工具或数据版本变化后重放同一攻击，而不是只保存最终截图。

AgentXploit：黑盒 Agent 的端到端自动化 Red Teaming

slides 56--62 介绍 AgentXploit。攻击者无法修改用户 query，也不知道内部实现，只能操纵 Agent 会读取的外部环境。框架以 seed attacks 为起点，通过 fuzzing 生成、变异和筛选 payload，在 AgentDojo 与 VWA-adv 上评估有效性、覆盖和迁移，并展示在真实 web agent 的 customer review 中注入内容，诱导 Agent 完成攻击目标。

\lecturefigure{slides-images/slide-056.png}{官方 slide 56：AgentXploit 端到端黑盒 red teaming} \lecturefigure{slides-images/slide-057.png}{官方 slide 57：AgentXploit motivation 与 threat model} \lecturefigure{slides-images/slide-058.png}{官方 slide 58：Fuzzing-based methodology 主流程} \lecturefigure{slides-images/slide-059.png}{官方 slide 59：初始语料、变异与筛选创新} \lecturefigure{slides-images/slide-060.png}{官方 slide 60：在 AgentDojo 与 VWA-adv 上的评测设置} \lecturefigure{slides-images/slide-061.png}{官方 slide 61：攻击有效性与迁移评测} \lecturefigure{slides-images/slide-062.png}{官方 slide 62：真实 Web Agent 的 Customer Review 注入示例}

读图：Fuzzing 为什么适合 Agent attack surface

Agent 行为由 prompt、页面、memory、tool 和当前状态共同决定，手写少量 payload 很难覆盖组合空间。Fuzzer 通过保留有效 seed、变异表达和依据执行反馈筛选，逐步搜索触发条件。它发现的是具体系统路径，不自动说明所有环境都同样脆弱。

Red Teaming 工具本身也是双用途能力

自动生成与迁移攻击会降低防守评测成本，也会降低攻击门槛。运行环境应隔离，payload 与成功轨迹受访问控制，测试目标需授权，结果披露遵守协调修复流程；不能把“用于研究”当作无限制发布攻击链的理由。

Defense-in-Depth：原则、机制与模型 Hardening

slides 64--75 从风险转入防御。总体原则是 defense-in-depth、least privilege、privilege separation、safe-by-design 和 secure-by-design。机制包括模型 hardening、输入 sanitization、动作 policy enforcement、身份/访问控制、任务分解与隔离、runtime monitoring、information-flow control 和 provenance。模型 alignment 是一层，但不能承担全部系统保证。

\lecturefigure{slides-images/slide-064.png}{官方 slide 64：Agentic Hybrid Systems 与安全挑战总结} \lecturefigure{slides-images/slide-065.png}{官方 slide 65：Defense-in-depth 与 least privilege} \lecturefigure{slides-images/slide-067.png}{官方 slide 67：Safe-by-design 与 secure-by-design 的完整原则} \lecturefigure{slides-images/slide-068.png}{官方 slide 68：Defense mechanisms 总览起点} \lecturefigure{slides-images/slide-070.png}{官方 slide 70：Defense mechanisms 的完整框架} \lecturefigure{slides-images/slide-071.png}{官方 slide 71：AI Model Hardening 与 Alignment} \lecturefigure{slides-images/slide-072.png}{官方 slide 72：从模型层继续向系统层布防} \lecturefigure{slides-images/slide-075.png}{官方 slide 75：Least privilege 与 policy enforcement 的位置}

术语消化：五个设计原则

原则	核心问题	Agent 实现
Defense-in-depth	单层失守怎么办	模型、策略、工具、业务系统独立校验
Least privilege	最少需要什么权限	按任务、时间和资源发放 capability
Privilege separation	高风险能力如何隔离	拆进独立进程/Agent，显式审批通信
Safe-by-design	错误如何限制后果	可逆动作、幂等、默认拒绝、人工闸门
Secure-by-design	攻击者如何被约束	threat model、最小接口、审计与更新

模型更稳健不等于系统有边界

即使 jailbreak rate 降低，Agent 仍可能因正常语言误解而执行错误动作。确定性 policy、typed tool、resource ACL 和 transaction invariant 必须独立于模型；这样模型层退化或更换时，系统约束仍存在。

Progent：可编程动作权限与 Utility-Security Tradeoff

slides 76、78--85 聚焦 Progent。Motivating examples 展示宽泛工具权限如何让恶意或误导指令触发高风险动作；Progent 把自然语言/程序化 policy 转成 runtime privilege control，在 Agent 生成 action 时检查用户目标、资源、参数和上下文。评测关注 attack success rate 的下降，同时检查正常任务 utility 是否保留。

\lecturefigure{slides-images/slide-076.png}{官方 slide 76：Progent motivating example 起点} \lecturefigure{slides-images/slide-078.png}{官方 slide 78：高权限 Agent 的完整风险示例} \lecturefigure{slides-images/slide-079.png}{官方 slide 79：Progent privilege-control overview} \lecturefigure{slides-images/slide-082.png}{官方 slide 82：Policy 与 action validation 的完整流程} \lecturefigure{slides-images/slide-083.png}{官方 slide 83：Progent runtime enforcement 组件} \lecturefigure{slides-images/slide-084.png}{官方 slide 84：Progent 显著降低 attack success} \lecturefigure{slides-images/slide-085.png}{官方 slide 85：安全增益与任务 utility 的联合评测}

Policy Enforcement 的三项输入

一次 action 至少要结合：用户已经授权的目标、当前 Agent/工具拥有的 capability、以及资源与参数的具体上下文。仅按 tool name allowlist 不够，因为同一邮件工具可以发送正常通知，也可以外泄数据；同一文件工具可以读取项目目录，也可以读取 secret。

读图：安全评测必须同时画两条曲线

Progent 的价值不是把 ASR 降到零而让所有任务失败，而是在保持 utility 的同时压缩攻击面。比较方案时应报告正常任务成功率、延迟、人工审批负担和攻击成功率；若只报安全指标，最安全的“关闭 Agent”会错误地成为最优解。

Privilege Separation、Monitoring、DataSentinel 与 Provenance

slides 86--98 收束剩余防线。身份与访问控制限制谁可触发任务；task decomposition 把高权限步骤拆给隔离组件；Privtrans 自动划分程序实现 privilege separation；runtime monitoring 观察异常行动与信息流；DataSentinel 用博弈论检测 prompt injection；information-flow control 限制敏感数据传播；provenance 记录数据和决策来源，支持审计与恢复。最后一页总结攻击、评测和防御必须共同演进。

\lecturefigure{slides-images/slide-086.png}{官方 slide 86：Defense mechanisms 进入身份与访问控制} \lecturefigure{slides-images/slide-087.png}{官方 slide 87：按 identity 与 policy 管理 user access} \lecturefigure{slides-images/slide-089.png}{官方 slide 89：Task decomposition 与 privilege separation} \lecturefigure{slides-images/slide-090.png}{官方 slide 90：Privtrans 自动权限分离} \lecturefigure{slides-images/slide-092.png}{官方 slide 92：Runtime monitoring 与异常行为观察} \lecturefigure{slides-images/slide-093.png}{官方 slide 93：DataSentinel 博弈论 Prompt Injection 检测} \lecturefigure{slides-images/slide-095.png}{官方 slide 95：Information flow monitoring/control} \lecturefigure{slides-images/slide-097.png}{官方 slide 97：构建 provenance 的防御位置} \lecturefigure{slides-images/slide-098.png}{官方 slide 98：Agentic AI 安全与安全性的课程结论}

读图：最后四层解决不同时间尺度

Policy enforcement 在动作前阻断，privilege separation 限制单次失守的爆炸半径，runtime monitoring 在执行中检测偏离，provenance 在事后支持归因、撤销和训练回流。只做其中一层会留下时间窗口：例如仅靠监控发现问题时，危险写操作可能已完成。

最小可信执行链

每个高风险 action 都应能回答：谁提出、基于哪些来源、经过哪条 policy、使用何种权限、修改了什么状态、结果如何验证、怎样撤销。若任一项不可回答，系统就还没有达到可审计部署标准。

老师强调：安全是持续过程

模型、工具、外部网站和攻击方法都在变化，一次通过 red team 不代表长期安全。攻击轨迹必须进入回归集，policy 与 privilege 变化要版本化，监控告警要有值班与修复 SLA，provenance 要能支撑事故复盘和用户补偿。

跨图推导：把 71 个安全状态压缩成一套工程方法

前面的图覆盖了定义、攻击、评测与防御，但真正落地时不能按论文名称逐个部署组件。团队需要从一个具体任务出发，把用户目标、受保护资产、可执行能力和外部依赖画到同一张 trust map 上，再用攻击路径检验每条边。下面给出一套可以直接用于 design review、red team 和事故复盘的推导方法。

\paragraph{第一步：从任务结果反推资产。} 假设 Agent 的任务是“读取客户邮件、查询订单并发起退款”。资产不仅是数据库中的订单与付款信息，还包括邮箱 OAuth token、用户身份验证状态、退款 policy、审批记录、模型 memory、工具返回和最终对用户的承诺。若只把信用卡号列为敏感数据，就会漏掉能够间接触发资金动作的状态与凭证。每项资产应记录 owner、读写主体、保留期限、允许用途和恢复方式；无法恢复的资产要使用更严格的默认拒绝策略。

\paragraph{第二步：标出所有 trust boundary。} 用户输入、网页、邮件、检索文档和第三方 API 都属于不同信任域。即使内容来自公司内部知识库，也可能因同步错误、账号失陷或历史污染而不可信。模型调用与工具调用之间同样是边界：自然语言计划必须转换成 typed action，参数要经过 policy 验证，执行结果要带来源和完整性信息返回。安全审查不应只问“输入是否恶意”，还要问“哪一步把低信任内容提升为高权限控制”。

\paragraph{第三步：把攻击链写成前置条件序列。} 一个有效攻击通常不是“prompt injection 成功”这么简单，而是满足一组条件：Agent 读取到 payload；模型把 payload 当指令；计划选择了高风险工具；policy 没有拦截；凭证允许访问目标资源；业务系统接受了写入；用户或监控没有及时发现。把链条拆开后，团队就能选择成本最低、确定性最高的断点。模型拒答可能减少第二步概率，parameterized query 可以直接消除 SQL 拼接条件，least privilege 则限制即使前面失守也无法访问敏感表。

\paragraph{第四步：区分 capability 与 authority。} 模型“知道如何退款”属于 capability，系统“允许它退款 10,000 美元”属于 authority。两者混在同一个 prompt 中会让语言理解同时决定权限。更稳妥的架构是模型提出意图与证据，policy engine 根据用户身份、金额、订单状态和风险等级发放一次性 capability token，工具再验证 token 与参数。权限应具有资源范围、动作范围、金额/频率上限、有效期和可撤销性，而不是一个长期万能 API key。

\paragraph{第五步：为不可逆行动设计两阶段执行。} 发送公开消息、删除数据、转账、修改访问控制等操作应先生成 plan 或 preview，再由独立策略、人类或确定性规则 commit。Preview 必须显示将修改的资源、参数、依据和预期后果；commit 使用与 preview 绑定的摘要，防止模型在批准后偷偷替换参数。对可逆动作也要提供 idempotency key、transaction log 和补偿操作，避免重试造成重复退款或重复消息。

一个高风险动作的最小检查表

用户是否明确请求或授权该目标？
当前身份是否有权操作目标资源？
参数是否来自可信来源，是否经过 schema 和业务规则校验？
外部内容是否影响了计划，来源标签是否保留？
动作是否可逆；若不可逆，谁完成二次批准？
执行后用什么独立证据确认结果，而不是听模型自报？

\paragraph{第六步：让 evaluation 覆盖组合状态。} 单独测试模型拒绝恶意 prompt、工具 API 权限和 memory 写入都通过，并不证明组合系统安全。评测矩阵至少要交叉用户类型、外部内容、memory 状态、工具权限、任务阶段和恢复路径。例如同一 payload 可以放在用户消息、网页评论、PDF、邮件签名或历史 memory 中；同一攻击还要在只读、有限写入和高权限工具下重放。结果按完整 trajectory 记录，才能知道防线在哪一层生效、是否产生旁路以及 utility 受到多少影响。

\paragraph{第七步：把 attack success 拆成条件概率。} 设攻击链包含发现 payload、模型服从、policy 放行和工具执行四步，则粗略成功率可写为

\[ P(\mathrm{success}) =P(R)\,P(M\mid R)\,P(P\mid M,R)\,P(T\mid P,M,R), \]

其中 $R$ 表示 payload 被读取，$M$ 表示模型接受恶意目标，$P$ 表示 policy 放行，$T$ 表示工具完成危险动作。每层防御的价值是降低某个条件概率或限制最终后果。该乘积不是假设各事件独立，而是提醒团队不要用单一 jailbreak rate 代替端到端风险；同样的模型脆弱性在只读工具下与管理员权限下有完全不同的 expected loss。

\paragraph{第八步：同时报告风险与效用。} 安全控制可能增加拒绝、延迟和人工审批。Progent 类结果必须与正常任务成功率一起读：ASR 降低多少，utility 保留多少，误拦截集中在哪些用户群体，额外审批花费多少时间。对低风险查询可采用宽松权限和自动执行，对高金额或不可逆动作采用严格 policy 与 human sign-off。风险分级让系统不必在“完全自动”和“全部人工”之间二选一。

\paragraph{第九步：监控应观察行为偏离而非关键词。} Prompt injection 可以换语言、编码或语义包装，关键词规则只能捕获已知表面。更有价值的运行时信号包括：Agent 突然访问与用户目标无关的资源；工具调用序列偏离正常模板；从低信任网页读取 secret-like 数据后尝试外发；memory 在无用户确认时写入高影响事实；同一会话短时间触发大量拒绝与权限请求。监控器应生成可解释事件，并能暂停、降权或转人工，而不是只给安全团队一个晚到的 dashboard。

\paragraph{第十步：provenance 必须贯穿数据生命周期。} 对每个影响决策的事实，系统应保存原始来源、抓取时间、处理版本、可信度和允许用途。摘要和 embedding 不能抹掉 provenance；否则 memory poisoning 被发现后无法定位哪些派生状态需要删除。输出中的关键结论也应能反向追踪到来源与工具结果。Provenance 不只是合规元数据，它直接决定污染检测、撤销、用户申诉和模型改进是否可行。

\paragraph{第十一步：按爆炸半径设计恢复。} 安全设计不是假设永不失守，而是限制失守范围。每个 Agent 使用独立身份和最小权限；不同客户、项目和环境隔离 memory 与 credentials；写操作有审计和补偿；高风险工具设置速率、金额和对象上限；异常时可立即吊销 token、冻结 workflow、回滚状态并通知受影响用户。事故演练要验证这些恢复动作真的可用，而不是只在文档中存在。

\paragraph{第十二步：把修复变成持续学习资产。} 每次攻击或近失事件都应产生四类产物：可重放的最小攻击场景、根因对应的 trust-boundary 缺口、确定性修复或 policy 变更、以及防止回归的指标。若只在 prompt 末尾追加一句禁令，攻击会换一种表述回来；若修复落到 schema、权限、隔离和业务 invariant，整个攻击家族都可能被消除。课程中的 AgentXploit、Progent、Privtrans 和 DataSentinel 应被理解为这个持续闭环中的不同工具，而不是互相替代的银弹。

从 Design Review 到持续审计的闭环

建模：任务、资产、主体、权限和 trust boundary；攻击：按前置条件生成 direct、indirect、poisoning 与 tool-chain 场景；评测：重放完整 trajectory，同时测 ASR、utility 与 consequence；防御：优先确定性 policy、least privilege、separation 与 reversible action；运行：监控行为偏离，保存 provenance，准备暂停与补偿；学习：把事故转成回归集、policy 版本和架构改进。

最常见的错误收口

“模型已经对齐”“加了输入过滤”“通过一次 red team”“工具只在内网”都不是完成标准。只要模型能影响有权限的组件，且外部数据能进入上下文，就仍需端到端 threat model、可重放评测、动作级 policy、监控和恢复。安全完成度应由可验证控制与剩余风险说明，而不是由组件名称判断。

本章小结

71 个独立教学状态形成了完整安全闭环：先把 Agent 看成 compound system，识别资产和 trust boundary；再沿 SQLi、RCE、prompt injection、poisoning 与自动 fuzzing 理解攻击链；用 trajectory-based evaluation 测真实后果；最后以 model hardening、runtime policy、least privilege、privilege separation、monitoring、information flow 与 provenance 分层防守。

验收控制时还要区分“控制已部署”和“控制已证明有效”：前者只说明系统有 policy、monitor 或 guardrail，后者要求用授权攻击轨迹触发它，验证阻断位置、误报率、剩余权限、告警响应和恢复结果。只有留下可重放证据，安全声明才不会随着模型或工具版本变化而失效。

课程定位与问题定义

本讲是 Berkeley Agentic AI MOOC F25 的安全专题开篇。Dawn Song 先强调一个背景：2025 年 Agentic AI 增长极快，能力边界持续外扩，系统能够感知环境、调用工具、执行外部动作，已经从 “模型输出内容” 走向 “模型驱动行为”。这使得安全问题从传统 LLM 的对话安全，升级为系统级执行安全。

为什么 Agent 安全比纯 LLM 安全更难

LLM 安全主要处理 “输出是否有害”，Agent 安全还要处理 “动作是否越权”、“工具是否被滥用”、“环境交互是否可控”。一旦 Agent 拥有写文件、发邮件、执行命令、访问网页和数据库权限，攻击后果就不再停留在文本层，而会落到真实世界系统。

课程的主问题可归纳为三句：

如何定义 Agentic AI 的安全目标与安全边界？
如何系统化建模攻击面、威胁模型和风险评估流程？
如何建立可工程落地的纵深防御机制，而不是单点护栏？

本讲议程

讲座按 “定义问题 $\rightarrow$ 拆解攻击 $\rightarrow$ 风险评估 $\rightarrow$ 防御设计 $\rightarrow$ 双用途风险” 展开。它不是单一算法课，而是一门系统安全工程课。

本章小结

本章的关键结论是：Agentic AI 安全的本质是系统安全问题，而不仅是模型内容安全问题。只讨论 prompt 或输出过滤无法覆盖真实风险面。

Safety 与 Security：统一视角下的目标函数

讲者明确区分但又统一了两类目标。AI safety 关注系统是否对外部环境造成伤害；AI security 关注系统是否被外部攻击者利用、篡改、劫持。Agent 语境下两者高度耦合，因为攻击者可以利用安全缺陷触发安全事故，也可以利用安全机制漏洞突破系统约束。

课程中的定义

Safety：防止系统对人类、组织和环境造成不希望的外部危害。\ Security：防止系统被恶意主体破坏机密性、完整性、可用性（CIA）并被利用执行恶意行为。\ 在 Agent 场景里，二者共同构成 “resilient alignment”：即使处于对抗环境，系统也能维持目标一致性。

从工程角度，可以把风险粗略写成： $$ R \approx P(\text{attack succeeds}) \times \text{Impact} \times \text{Exposure} $$ 其中 Exposure 由权限范围、可调用工具、外部环境耦合深度决定。Agent 的 Exposure 通常远大于纯文本模型，因此即便攻击成功率不变，整体风险也会显著上升。

常见误区

把 “模型回答更礼貌” 当作系统更安全。现实里，很多高危攻击并不依赖有害文本，而依赖工具链、身份上下文、执行路径和权限配置。

本章小结

Safety 与 Security 在 Agent 时代必须一起做。安全目标不是单指标优化，而是围绕行为后果、系统韧性和攻击成本的综合约束。

Agentic AI 系统抽象与复杂度来源

课程将 Agentic 系统抽象为四层：感知（Perception）、推理规划（Reasoning/Planning）、工具调用（Tool Use）、执行与反馈（Action/Feedback）。相较于单轮对话模型，Agent 的关键特征是 “闭环”：动作会改变环境，环境反馈再反作用于下一步决策。

复杂度不是线性增加，而是组合爆炸

每增加一个维度（输入模态、动作空间、工具集、记忆类型、自主等级），攻击面不是加法增长，而是组合增长。特别是当工具集从固定白名单扩展到运行时发现时，系统的可攻击状态空间会急速放大。

维度	可选范围	安全含义
输入空间	文本 / 图像 / 文件 / URL / API 返回	输入污染、跨模态注入、外部内容投毒
动作空间	回答 / 调工具 / 执行命令 / 发请求	越权执行、侧向移动、真实系统破坏
工具集合	无工具 / 固定工具 / 动态发现工具	攻击路径不透明、能力边界漂移
记忆机制	无记忆 / 短期记忆 / 持久记忆	恶意状态持久化、长期污染
自主等级	人工审批 / 半自动 / 全自动	风险收敛速度与损害放大倍数不同

Agent 系统设计维度与安全风险耦合

Hybrid Agent System 的挑战

很多现实系统是 “Neural + Symbolic + Rule” 混合体：LLM 做规划，规则引擎做审批，工具适配器做执行。攻击者常利用模块边界不一致（policy gap）完成跨层绕过。

本章小结

Agent 系统的安全复杂度来自多维组合而非单点漏洞。设计阶段必须把输入、动作、工具、记忆、自主度同时纳入威胁建模。

安全目标建模：从 CIA 到 Agent 行为约束

课程把传统 CIA 目标引入 Agent 场景，并强调它们需要被 “行为化”。例如 confidentiality 不只是防止数据库泄露，还包括防止 Agent 通过工具链间接泄露敏感上下文；integrity 不只是防篡改，还包括保证推理链和动作链不被污染；availability 不只是服务在线，还包括防止攻击者用高成本任务拖垮执行资源。

Agent 时代的 CIA 扩展

Confidentiality：敏感数据不得被未授权读取、推断或外发。
Integrity：状态、计划、工具调用与执行结果不可被隐蔽篡改。
Availability：系统在对抗流量、恶意任务和资源争用下保持可服务。
Action Safety：即使被诱导，Agent 也不能执行高危未授权动作。

讲者还比较了传统系统和 Agent 系统在安全目标上的区别。传统系统通常功能边界清晰、权限边界固定；Agent 系统在运行中会持续扩展上下文和操作空间，因此目标约束必须是动态的，不能只靠静态 ACL。

静态策略的局限

如果策略仅按 “系统角色” 固定授权，而不结合 “当前任务上下文”，Agent 很容易在一次合法会话中被间接注入后执行不该执行的动作。

本章小结

安全目标需要从 “对象安全” 升级为 “行为安全”。在 Agent 场景下，动态上下文策略和执行时约束比静态访问控制更关键。

攻击面分层：模型、系统、环境与工具链

上一章已经把安全目标从“保护对象”扩展到“约束行为”，本章进一步回答这些目标会在哪些边界被突破。阅读四层攻击面时，不应把它们理解成互斥标签：真实攻击通常从环境中的不可信内容开始，穿过模型的指令解释，利用系统缺少参数校验，最后借工具权限产生后果。分层的价值是让每一跳都有 owner、检测信号和确定性阻断点。

课程将攻击面拆解为四层：模型层漏洞、系统层漏洞、环境层可利用点、工具链供应链风险。该分层有两个作用：一是避免把所有问题都归因于 prompt injection；二是指导防御资源优先级分配。

模型层典型风险

包括 prompt engineering attacks、jailbreak、数据投毒导致的错误遵循、拒绝服务型输入（超长上下文、资源消耗诱导）等。模型层风险是基础，但不是全部。

系统层典型风险

包括会话状态机设计缺陷、审批逻辑缺失、工具参数校验不足、跨组件信任链错误、日志与审计盲区。

环境层与工具链风险

包括恶意网页、恶意邮件、恶意 issue、第三方 API 污染、工具插件供应链被劫持等。攻击者往往不直接攻击模型，而是污染其感知来源与执行目标。

为什么 “只做模型加固” 不够

即使模型本身更强健，只要执行层缺少权限隔离，攻击者仍可通过低成本注入驱动高危工具调用，造成真实损害。

例如，一个网页上的间接指令本身属于环境层输入；模型错误服从属于模型层失守；host 把自由文本直接映射为 shell argument 属于系统层缺陷；执行插件使用长期管理员凭证则属于工具链与权限设计问题。只修其中任何一处都可能降低风险，但根因分析必须保存完整链条，否则团队会把下一次变体当成“全新漏洞”重复救火。更好的安全 backlog 不是按攻击名称排队，而是按可复用断点排序：typed interface、parameterization、capability token、transaction、sandbox 和 provenance 往往能同时消除多个攻击家族。

跨层审计的三个问题

哪个低信任输入首次影响了高信任决策？
哪个组件把建议升级成了有副作用的动作？
若前两层都失守，哪一层本应限制权限或支持回滚？

回答这三问，可以把“模型被骗了”改写成可修复的系统缺口。

本章小结

Agent 风险不是单层风险，而是跨层攻击链。安全工作必须从 “修一个漏洞” 转向 “切断可行攻击路径”。

威胁模型：攻击者能力、控制面与后果

攻击面告诉我们哪里可能失守，威胁模型则规定攻击者实际能触碰哪些位置、投入多少资源以及希望造成什么后果。两者不能颠倒：如果先选一个热门 benchmark 再补 threat model，评测可能只证明系统能抵抗弱而不现实的攻击。这里应把 attacker capability、knowledge、persistence、access channel 和 consequence 写成明确假设，再决定测试强度与防线。

讲者强调了 Threat Modeling 的必要性：不同攻击者能力下，最优防御完全不同。课程给出可操作框架：先定义攻击者可见面与控制面，再定义攻击目标和攻击后果，最后映射到检测与阻断点。

威胁模型	攻击者能力	常见后果
Black-box	仅可通过公开接口输入内容	注入、越权诱导、间接命令执行
Gray-box	知道部分系统结构与工具接口	构造高命中攻击链、规避浅层护栏
White-box	可读代码/配置/提示词	精准定位注入点、自动化生成攻击样本

三类常见威胁模型与攻击收益

课程中的核心判断

如果没有清晰 Threat Model，评测指标会失真，防御策略会错位。很多 “防住了” 的结果，只是在弱攻击者假设下成立。

Black-box 并不等于低风险。攻击者可以长时间自适应查询、创建多个账号、控制网页或邮件内容，并观察 Agent 的外部行动；这些反馈足以支持 fuzzing。Gray-box 攻击者可能从公开文档、错误信息、tool schema 或前员工知识推断内部结构。White-box 则可以直接搜索 prompt、policy 和代码路径。评测报告必须写明查询预算、是否可观察工具结果、是否允许污染持久状态、攻击是否跨会话，以及攻击者是否知道防御策略。

后果也要按实际损失分级。一次 system prompt 泄露可能只是信息暴露，也可能揭示内部工具和绕过条件；一次错误网页点击可能无害，也可能下载恶意文件；一次越权数据库读取可能只触及测试记录，也可能横向访问整个客户租户。应以 confidentiality、integrity、availability、financial loss、physical harm 和 recovery cost 共同描述 consequence，而不是用单一 ASR 把所有成功攻击视为同等严重。

威胁模型必须包含组合与时间

真实攻击者会先侦察、再污染、等待 memory 持久化，最后在高权限任务中触发 payload。只测试单轮 prompt 会漏掉跨会话、跨工具和延迟触发攻击；只测试最强攻击又可能掩盖低成本批量滥用。至少应覆盖 opportunistic、targeted 和 persistent 三档对手。

本章小结

威胁建模不是文档工作，而是安全工程入口。先定义攻击者，再定义防御；先定义后果，再定义指标。

代表性攻击路径一：Prompt Injection 到真实执行

本讲对 prompt injection 做了系统升级，不再局限 “模型被诱导说错话”，而是分析 “模型被诱导执行错动作”。尤其是 indirect prompt injection：攻击载荷藏在网页、邮件、文档或 issue 中，Agent 在合法读取后将恶意指令当作环境信息执行。

Indirect Prompt Injection 的危险性

攻击者无需突破系统边界，只需投递 “被 Agent 合法读取” 的恶意内容，就可能触发后续工具调用链。这使得攻击成本低、隐蔽性高、扩散速度快。

课程给出的 web agent 示例中，Agent 被诱导忽略用户原始意图，转而访问恶意站点并下载恶意内容。这里的关键是 “攻击链” 而非单点漏洞：

污染输入源（网页内容、issue 文本、邮件正文）；
触发计划偏移（从任务目标转向攻击者目标）；
借助高权限工具执行危险动作；
利用持久状态扩大后续危害。

工程中最容易忽略的一点

很多团队只过滤 “用户输入”，却忽视 “环境输入”。实际上，环境输入（网页、检索结果、工具返回）才是 indirect injection 的主战场。

本章小结

Prompt injection 在 Agent 时代的本质是执行链劫持。防御重点应从文本过滤扩展到任务状态约束与工具执行约束。

代表性攻击路径二：自动化攻击生成与多 Agent 利用

讲者展示了自动化红队思路：让 analyzer agent 先分析目标代理代码和工具接口，再由另一个 agent 自动生成攻击候选（例如上下文感知注入、命令诱导注入）。这种 “agent 攻 agent” 模式说明攻击者也会利用 AI 自动化其攻击开发流程。

为什么自动化攻击值得重视

自动化攻击将显著降低攻击门槛：

更快发现注入点和权限路径；
更容易进行批量变体生成与回归测试；
更容易绕过静态规则，因为攻击可按上下文动态调整。

课程中提到的 GitHub issue solving agent 场景尤其典型：攻击者将恶意指令嵌入 issue 内容，Agent 在自动处理时执行了不应执行的命令，导致攻击链成立。这个案例突出了两个关键问题：其一，“看起来像任务描述” 的文本很难靠关键词拦截；其二，工具执行阶段如果没有强约束，计划偏移会直接转化为高危动作。

白盒假设下的防御压力

一旦攻击者可见提示词、策略逻辑或工具配置，其攻击成功率会显著提升。此时仅靠 obscurity 不可持续，必须依赖可验证策略和运行时 enforcement。

本章小结

自动化攻击框架表明：防御者必须假设攻击者也在使用 Agent。安全评测不能只测单次样例，而要测连续适应性对抗。

风险评估难题：为何现有 Agent Benchmark 不够

讲者指出，当前 Agent 评测普遍存在四个问题：缺乏标准化、开放性不足、可复现性差、集成成本高。很多 benchmark 沿用模型中心评测思路，内置固定 harness，导致新 Agent 接入成本高，跨 benchmark 对比困难。

N * M 集成困境

若有 $N$ 个待测 Agent、$M$ 个 Benchmark，传统模式下往往需要近似 $N \times M$ 次集成适配。这不仅成本高，而且容易引入实现偏差，导致评测结果难以横向比较。

现状问题	直接后果	对研究/工程的影响
接口不统一	每个 benchmark 单独适配	评测成本高，迭代慢
封闭 harness	难替换组件与环境	创新难复现，结论难验证
指标不一致	同名指标语义不同	排行可比性弱
缺少对抗评测	只测正常任务性能	安全能力被高估

当前 Agent 评测体系的结构性问题

风险评估应覆盖的最小维度

正常任务性能（utility）；
对抗鲁棒性（robustness）；
安全后果强度（impact）；
触发成本与攻击可扩展性（attack economics）；
复现性与可审计性（reproducibility/auditability）。

本章小结

没有标准化评测，就没有可信比较；没有可信比较，就无法指导防御投入。Agent 安全首先需要评测基础设施。

AAA 范式：把评测器本身做成 Agent

本讲提出的 Identified Agent Assessments (AAA) 是一个关键思路：不再把 benchmark 写成静态 harness，而是把 “评测器” 本身做成 assessor agent。assessor 通过标准协议暴露工具接口，被测 agent 只需遵循统一接口（例如 MCP 风格）即可接入，从而降低适配复杂度。

AAA 的工程收益

从 “每个 benchmark 写一套胶水” 变成 “一次接入，复用多评测器”；
更容易做 reproducible 的对抗评测；
更容易扩展 arena 模式（多 agent 竞争/对抗）；
更容易做持续监控和回归测试。

课程还提到 Agent Beats 这类开放平台，目标是让社区持续提交新环境、新 benchmark、新 agent，并在统一框架下比较能力与风险。这种平台化路线对于安全研究尤为重要，因为很多漏洞只有在开放生态和持续对抗中才会暴露。

评测平台本身也会成为攻击目标

一旦评测影响资源分配和声誉，平台就会面临 benchmark gaming、test leakage 和评测规避策略。因此评测平台需要独立的安全治理机制。

本章小结

AAA 的核心价值是把评测标准化问题前置解决，降低集成摩擦并提升可复现性。它是 “安全能力工程化” 的基础工具，而不是附属组件。

防御总纲：Defense-in-Depth 而非单点银弹

讲者明确表示，Agent 安全没有 silver bullet，必须采用纵深防御。课程给出的防御层包括：模型加固（pre/post training）、输入护栏、输出护栏、策略执行、运行时监控、人类审批和权限管理。关键不在于每层都完美，而在于单层失守时其他层还能兜底。

典型纵深防御链路

Model Hardening：数据清洗、安全微调、对抗训练。
Input Guard：识别并移除注入载荷、恶意上下文模式。
Planner Constraint：限制计划生成中的高危路径。
Policy Enforcement：执行时校验动作与权限。
Runtime Monitoring：检测异常行为并触发回滚/暂停。
Human-in-the-Loop：关键动作强制人工确认。

只做输入过滤会被自适应攻击绕过

课程提到，攻击者会针对防御策略生成自适应样本。输入过滤只能降低低成本攻击，不足以保证高风险场景安全。必须结合策略执行与运行时约束。

本章小结

真正可落地的防御不是一个模型或一个规则，而是一条多层防线。系统设计目标是把 “单次突破” 变成 “连续突破”，显著抬高攻击成本。

Policy Enforcement 与 Contextual Security 案例

讲者用 Progent 类方案展示了策略执行的核心思想：用 DSL 显式描述安全策略，在 Agent 执行过程中做实时 policy checking，并允许基于上下文动态更新策略。相比静态策略，这种方法更适合任务驱动且状态不断变化的 Agent。

Contextual Security 的直觉

同一个 Agent 在不同阶段应有不同权限。例如任务是 “总结最近一天未读邮件”，此时允许读邮件元数据，但不应默认允许外发邮件。只有在后续状态显式出现 “用户确认发送” 才能临时提升发送权限。

策略示意：基于上下文限制高风险动作

policy "email_summary" {
  allow tool.read_email_metadata
  deny  tool.send_email
}

on state(user_confirmed_send == true) {
  allow tool.send_email(to=resolved_recipient)
}

执行时策略比离线对齐更直接

离线对齐提高了模型整体倾向，执行时策略直接约束当前动作。两者叠加，才能在 “模型被诱导” 的情况下仍阻断高危行为。

本章小结

Contextual Security 把权限控制从 “谁” 扩展到 “在什么状态下能做什么”。这是 Agent 安全从静态访问控制走向动态行为控制的关键一步。

Runtime Monitoring、Least Privilege 与分层隔离

课程强调了运行时监控的重要性：系统应持续监测 Agent 行为轨迹、工具调用参数、跨域访问模式和异常状态转移。一旦触发风险阈值，应能自动降权、暂停、回滚或切换人工审批。

监控可观测信号

行为层：异常工具序列、异常频率、越权调用尝试；
数据层：敏感字段外流、上下文污染传播；
执行层：命令执行失败重试异常、可疑外联、权限拒绝激增；
策略层：策略冲突、动态策略频繁震荡。

讲者也讨论了 least privilege 与组件分层隔离：让低权限组件即使被攻破也无法直接执行高权限动作。该策略本质上是 “限制攻击后果半径”，使系统从 “完全失守” 退化为 “局部可控失效”。

权限设计中的高频错误

把 “开发便利” 当作 “生产默认”，给 Agent 过宽权限。
缺少权限衰减机制，临时权限长期残留。
缺少跨工具统一身份上下文，导致审计断链。

本章小结

监控和最小权限不是可选强化项，而是 Agent 系统的基础结构。没有运行时约束，前置防御很容易在复杂场景中被绕过。

双用途风险：Agent 能力提升如何改变网络安全攻防

课程最后转向 cyber security dual-use 问题：AI 可以同时增强攻击者和防守者，关键是 “谁受益更快”。讲者展示的研究结论较为审慎：短期内由于攻击与防守的自然不对称，前沿 AI 往往更容易先提升攻击效率，因此需要持续监测能力变化而不是一次性判断。

为什么必须做 Continuous Monitoring

Agent 能力曲线变化快，静态 benchmark 很快过时。持续评测能帮助社区及时发现：

新能力出现是否导致攻击成功率跃迁；
防御策略是否在新模型下失效；
哪些任务上 “攻击增益” 快于 “防守增益”。

讲者提到的 cyber benchmark（大规模任务集合）和 observatory 机制，实质上是把 “一次论文评测” 升级成 “持续治理基础设施”。这对政策和产业都有现实意义：只有连续观测，才能决定何时需要更强默认防护、何时需要限制高风险能力暴露。

本章小结

双用途风险决定了 Agent 安全不是纯技术闭环，还涉及生态协作与治理节奏。持续监测比一次性结论更符合现实。

落地清单：把课程原则转成工程实施步骤

结合整讲内容，可以给出一个可执行的安全实施路线，适合作为企业 Agent 平台的 baseline：

阶段	目标	关键动作
S0 资产梳理	明确风险边界	列出工具、数据、身份、外联目标与高危动作清单
S1 威胁建模	定义攻击者与后果	按 black/gray/white box 划分能力，明确 attack path 和 impact
S2 防御基线	建立最小可用防线	输入过滤 + 输出约束 + 最小权限 + 人工审批高危动作
S3 执行策略	从静态到动态策略	引入 DSL 策略执行、上下文动态授权、策略审计日志
S4 评测体系	提升可复现性	建立统一接口评测、对抗回归测试、持续监测面板
S5 治理闭环	安全运营常态化	漏洞响应、红队演练、策略迭代、版本回溯与追责机制

基于本讲内容整理的 Agent 安全工程落地路线

建议优先落地的三件事

先做 “权限最小化 + 高危动作审批”，立即降低高影响风险；
再做 “统一评测接口 + 对抗回归”，避免盲目上线；
最后做 “上下文策略 + 运行时监控”，把系统从可用提升到可控。

本章小结

课程思想可以直接映射到工程实践。关键不是一次性搭完所有机制，而是先建立可审计、可演进、可持续监测的安全基座。

实战推演：一次 Agent 安全审计如何落地

为了把前面的框架变成团队可执行流程，可以把一次完整审计拆成 “建模-攻击-验证-修复-回归” 五步。下面给出一个接近真实团队协作的执行范式。

Step 1：定义任务边界与资产边界

先明确 Agent 在这个业务场景中到底被允许做什么、不允许做什么，并把相关资产（工具、数据、密钥、身份、外部接口）映射到风险等级。这里常见失误是只定义 “业务目标”，不定义 “禁止动作”。没有明确禁止动作，后续策略系统很难判断某次执行到底是创新还是越权。

审计输入清单

任务描述：用户目标、成功条件、失败条件。
资产清单：数据库、文件系统、邮件系统、命令执行入口、第三方 API。
权限模型：哪些角色可读、可写、可执行、可外发。
上下文来源：用户输入、网页抓取、RAG 结果、插件返回、历史记忆。

Step 2：构建攻击场景库并自动回放

基于威胁模型设计测试用例，至少覆盖 direct injection、indirect injection、tool abuse、越权升级、数据外泄、DoS 诱导和策略绕过。推荐用自动化框架持续回放，不要依赖人工抽查。课程强调 “攻击者会自动化”，防守侧同样必须自动化。

高价值攻击样本应具备的属性

可复现：同输入同环境可稳定复现结果。
可解释：能定位是哪个环节失效（输入过滤、策略执行或工具校验）。
可量化：可输出 attack success rate、impact score、time-to-detect。
可回归：补丁上线后可自动再次验证。

Step 3：插入策略执行与运行时监控探针

在不改变主业务逻辑前提下，先把可观测性拉起来。最小探针包括：工具调用审计、动作前策略校验、敏感数据离开边界告警、异常行为序列检测。没有这些探针，团队会陷入 “知道出事了但不知道怎么出事” 的状态。

动作执行前安全检查示意

def secure_execute(action, state, policy_engine):
    verdict = policy_engine.check(action=action, state=state)
    if verdict.allow is False:
        log_security_event("blocked", action, verdict.reason)
        return {"status": "blocked", "reason": verdict.reason}
    result = run_tool(action)
    log_security_event("executed", action, result.summary)
    return result

Step 4：风险分级修复与灰度验证

对发现的问题按 “可利用性 * 后果等级 * 暴露范围” 分级。高危问题先通过权限收缩和策略阻断快速止血，再做模型或系统深修。修复后不要一次性全量上线，先灰度验证攻击样本回归效果，再扩大流量。

风险级别	判定标准	推荐处置
P0	可直接触发高危动作或敏感外泄	立即收敛权限 + 上线阻断策略 + 紧急回归
P1	需多步利用但后果显著	72 小时内完成策略补丁和监控增强
P2	影响可控或仅在弱假设成立	纳入版本计划，配套回归测试
P3	理论风险、暂无可利用路径	记录并持续监测，等待条件变化

安全审计中的风险分级与处置优先级

Step 5：把审计变成持续流程

一次审计只能回答 “今天是否安全”，无法回答 “明天是否仍然安全”。Agent 版本、工具版本、环境输入和攻击样本都会变化，因此安全审计必须进入 CI/CD：每次模型更新、策略更新、工具更新都自动触发回归。

最危险的组织问题

把安全审计当成上线前一次 “盖章流程”。在 Agent 场景中，这几乎必然失效，因为系统状态和攻击者策略是持续变化的。

本章小结

实战层面的关键是流程化：先定义边界，再自动攻击，再可观测阻断，再分级修复，最后持续回归。只有把安全流程嵌入开发流程，课程中的原则才能落到生产系统。

开放问题：下一代 Agent 安全研究的技术缺口

课程虽然给了清晰框架，但仍留下大量未解问题。下面从研究与工程交叉视角总结最关键的技术缺口。

缺口一：可证明安全与高灵活性的张力

Agent 价值来自灵活性，但可证明安全通常需要收窄行为空间。如何在开放任务中同时保持高 utility 与可验证安全，是目前最大的基础矛盾。现有方法往往二选一：要么很安全但任务能力下降，要么能力强但缺少形式化保证。

研究方向

将 “高危动作” 抽象为可证明约束，把 “低危动作” 保留给模型自由探索。也就是说，不追求对全行为空间证明安全，而追求对关键后果路径证明安全。

缺口二：跨环境泛化与跨任务泛化

很多系统在单环境 benchmark 上表现良好，但换工具、换数据分布、换任务模板后安全性能快速退化。这说明当前防御很多是 “环境特化防御”，而非真正的泛化防御。

可操作评测建议

在评测中显式加入：

Cross-environment split：训练和测试环境隔离。
Cross-tool split：训练工具集合与测试工具集合不重叠。
Cross-policy split：策略模板变化后重新评估鲁棒性。

缺口三：安全基准的标准协议仍不统一

尽管课程提出 AAA 思路，但行业还缺统一协议与统一数据格式。没有协议，生态难互通；没有互通，防御研究难积累。安全 benchmark 的 “可持续运营” 也是难点，需要处理泄题、版本漂移、指标膨胀和社区治理。

缺口四：攻防不对称下的资源配置

讲者在网络安全章节指出，短期内 AI 可能先帮助攻击者。对防守团队而言，核心问题不是 “能不能做最强防御”，而是 “在有限算力、人力、响应时间下，防哪里最划算”。这需要把安全研究和安全经济学结合。

容易被忽视的现实约束

如果防御机制引入过高时延或过高误报，业务方会绕开安全机制。最终系统会回到 “名义安全、实际裸奔”。因此安全方案必须同时优化风险降低与业务可接受性。

缺口五：人机协同边界如何设计

Human-in-the-loop 不是简单加一个确认弹窗。真正的问题是：什么动作必须人工确认、人工在多大负载下仍能可靠判断、如何避免 “确认疲劳”。这需要行为科学、界面设计和系统安全共同参与。

开放问题	当前瓶颈	潜在突破方向
可证明安全	行为空间过大难以全量证明	关键路径可证明 + 分层约束
跨环境鲁棒性	防御过度依赖特定环境	跨环境训练与评测协议
标准化评测	协议与指标碎片化	AAA/MCP 风格统一接口
攻防资源分配	防守成本高、优先级不清晰	风险经济模型 + 动态预算
人机协同	审批疲劳与误判	风险分级审批与自适应交互

Agent 安全下一阶段的核心技术缺口

本章小结

Agent 安全的下一步，不是继续堆单点 patch，而是解决 “可验证性、泛化性、标准化、经济性、人机协同” 五个结构性问题。这些问题决定了 Agent 能否在高风险场景长期可用。

总结与延伸

全讲总结表

主题	核心观点	工程指向
概念框架	Safety 与 Security 必须合并考虑	目标函数从输出安全升级为执行安全
系统抽象	Agent 多维能力带来组合攻击面	设计期就要做跨维度威胁建模
攻击路径	Indirect injection 可劫持执行链	环境输入与工具执行都需防护
评测体系	传统 benchmark 集成成本高、标准弱	推动统一接口与可复现对抗评测
防御策略	无银弹，必须 Defense-in-Depth	多层拦截、动态策略、运行时约束
治理方向	双用途风险要求持续监测	建立 observatory 与社区协作机制

Dawn Song 本讲可执行结论总览

一句话结论

Agentic AI 的安全问题不是 “模型能不能拒答”，而是 “系统在对抗环境下能否持续做对事，并阻止高危错误动作发生”。

延伸阅读

Dawn Song 团队关于 Agent 安全与自动化红队的近期论文与项目主页。
LLM/Agent 的 prompt injection、indirect injection 与 tool abuse 研究综述。
运行时策略执行与 least privilege 在智能体系统中的实践报告。
Agent evaluation 标准化方向（MCP 风格接口、统一评测协议、arena 评测）。
Frontier AI 与网络安全双用途风险治理相关报告与社区框架。