[LLM Agents F25] Agentic AI Safety & Security
| 字段 | 内容 |
|---|---|
| 作者/整理 | 基于 Dawn Song 课程内容整理 |
| 来源 | Berkeley RDI |
| 日期 | 2026-04-02 |
![[LLM Agents F25] Agentic AI Safety & Security](cover.jpg)
课程定位与问题定义
本讲是 Berkeley Agentic AI MOOC F25 的安全专题开篇。Dawn Song 先强调一个背景：2025 年 Agentic AI 增长极快，能力边界持续外扩，系统能够感知环境、调用工具、执行外部动作，已经从 “模型输出内容” 走向 “模型驱动行为”。这使得安全问题从传统 LLM 的对话安全，升级为系统级执行安全。
为什么 Agent 安全比纯 LLM 安全更难
LLM 安全主要处理 “输出是否有害”，Agent 安全还要处理 “动作是否越权”、“工具是否被滥用”、“环境交互是否可控”。一旦 Agent 拥有写文件、发邮件、执行命令、访问网页和数据库权限，攻击后果就不再停留在文本层，而会落到真实世界系统。
课程的主问题可归纳为三句：
- 如何定义 Agentic AI 的安全目标与安全边界？
- 如何系统化建模攻击面、威胁模型和风险评估流程？
- 如何建立可工程落地的纵深防御机制，而不是单点护栏？
本讲议程
讲座按 “定义问题 \(\rightarrow\) 拆解攻击 \(\rightarrow\) 风险评估 \(\rightarrow\) 防御设计 \(\rightarrow\) 双用途风险” 展开。它不是单一算法课，而是一门系统安全工程课。
来源：视频画面时间区间：00:03:20–00:03:40。
本章小结
本章的关键结论是：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 返回 | 输入污染、跨模态注入、外部内容投毒 |
| 动作空间 | 回答 / 调工具 / 执行命令 / 发请求 | 越权执行、侧向移动、真实系统破坏 |
| 工具集合 | 无工具 / 固定工具 / 动态发现工具 | 攻击路径不透明、能力边界漂移 |
| 记忆机制 | 无记忆 / 短期记忆 / 持久记忆 | 恶意状态持久化、长期污染 |
| 自主等级 | 人工审批 / 半自动 / 全自动 | 风险收敛速度与损害放大倍数不同 |
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 场景下，动态上下文策略和执行时约束比静态访问控制更关键。
攻击面分层：模型、系统、环境与工具链
课程将攻击面拆解为四层：模型层漏洞、系统层漏洞、环境层可利用点、工具链供应链风险。该分层有两个作用：一是避免把所有问题都归因于 prompt injection；二是指导防御资源优先级分配。
来源：视频画面时间区间：00:14:00–00:14:20。
模型层典型风险
包括 prompt engineering attacks、jailbreak、数据投毒导致的错误遵循、拒绝服务型输入（超长上下文、资源消耗诱导）等。模型层风险是基础，但不是全部。
系统层典型风险
包括会话状态机设计缺陷、审批逻辑缺失、工具参数校验不足、跨组件信任链错误、日志与审计盲区。
环境层与工具链风险
包括恶意网页、恶意邮件、恶意 issue、第三方 API 污染、工具插件供应链被劫持等。攻击者往往不直接攻击模型，而是污染其感知来源与执行目标。
为什么 “只做模型加固” 不够
即使模型本身更强健，只要执行层缺少权限隔离，攻击者仍可通过低成本注入驱动高危工具调用，造成真实损害。
本章小结
Agent 风险不是单层风险，而是跨层攻击链。安全工作必须从 “修一个漏洞” 转向 “切断可行攻击路径”。
威胁模型：攻击者能力、控制面与后果
讲者强调了 Threat Modeling 的必要性：不同攻击者能力下，最优防御完全不同。课程给出可操作框架：先定义攻击者可见面与控制面，再定义攻击目标和攻击后果，最后映射到检测与阻断点。
来源：视频画面时间区间：00:39:00–00:39:30。
| 威胁模型 | 攻击者能力 | 常见后果 |
|---|---|---|
| Black-box | 仅可通过公开接口输入内容 | 注入、越权诱导、间接命令执行 |
| Gray-box | 知道部分系统结构与工具接口 | 构造高命中攻击链、规避浅层护栏 |
| White-box | 可读代码/配置/提示词 | 精准定位注入点、自动化生成攻击样本 |
课程中的核心判断
如果没有清晰 Threat Model，评测指标会失真，防御策略会错位。很多 “防住了” 的结果，只是在弱攻击者假设下成立。
本章小结
威胁建模不是文档工作，而是安全工程入口。先定义攻击者，再定义防御；先定义后果，再定义指标。
代表性攻击路径一：Prompt Injection 到真实执行
本讲对 prompt injection 做了系统升级，不再局限 “模型被诱导说错话”，而是分析 “模型被诱导执行错动作”。尤其是 indirect prompt injection：攻击载荷藏在网页、邮件、文档或 issue 中，Agent 在合法读取后将恶意指令当作环境信息执行。
Indirect Prompt Injection 的危险性
攻击者无需突破系统边界，只需投递 “被 Agent 合法读取” 的恶意内容，就可能触发后续工具调用链。这使得攻击成本低、隐蔽性高、扩散速度快。
课程给出的 web agent 示例中，Agent 被诱导忽略用户原始意图，转而访问恶意站点并下载恶意内容。这里的关键是 “攻击链” 而非单点漏洞：
- 污染输入源（网页内容、issue 文本、邮件正文）；
- 触发计划偏移（从任务目标转向攻击者目标）；
- 借助高权限工具执行危险动作；
- 利用持久状态扩大后续危害。
来源：视频画面时间区间：01:09:30–01:09:50。
工程中最容易忽略的一点
很多团队只过滤 “用户输入”，却忽视 “环境输入”。实际上，环境输入（网页、检索结果、工具返回）才是 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 | 难替换组件与环境 | 创新难复现，结论难验证 |
| 指标不一致 | 同名指标语义不同 | 排行可比性弱 |
| 缺少对抗评测 | 只测正常任务性能 | 安全能力被高估 |
风险评估应覆盖的最小维度
- 正常任务性能（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。
来源：视频画面时间区间：01:28:10–01:28:40。
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 往往更容易先提升攻击效率，因此需要持续监测能力变化而不是一次性判断。
来源：视频画面时间区间：01:45:35–01:45:55。
为什么必须做 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 安全审计如何落地
为了把前面的框架变成团队可执行流程，可以把一次完整审计拆成 “建模-攻击-验证-修复-回归” 五步。下面给出一个接近真实团队协作的执行范式。
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 安全的下一步，不是继续堆单点 patch，而是解决 “可验证性、泛化性、标准化、经济性、人机协同” 五个结构性问题。这些问题决定了 Agent 能否在高风险场景长期可用。
总结与延伸
全讲总结表
| 主题 | 核心观点 | 工程指向 |
|---|---|---|
| 概念框架 | Safety 与 Security 必须合并考虑 | 目标函数从输出安全升级为执行安全 |
| 系统抽象 | Agent 多维能力带来组合攻击面 | 设计期就要做跨维度威胁建模 |
| 攻击路径 | Indirect injection 可劫持执行链 | 环境输入与工具执行都需防护 |
| 评测体系 | 传统 benchmark 集成成本高、标准弱 | 推动统一接口与可复现对抗评测 |
| 防御策略 | 无银弹，必须 Defense-in-Depth | 多层拦截、动态策略、运行时约束 |
| 治理方向 | 双用途风险要求持续监测 | 建立 observatory 与社区协作机制 |
一句话结论
Agentic AI 的安全问题不是 “模型能不能拒答”，而是 “系统在对抗环境下能否持续做对事，并阻止高危错误动作发生”。
延伸阅读
- Dawn Song 团队关于 Agent 安全与自动化红队的近期论文与项目主页。
- LLM/Agent 的 prompt injection、indirect injection 与 tool abuse 研究综述。
- 运行时策略执行与 least privilege 在智能体系统中的实践报告。
- Agent evaluation 标准化方向（MCP 风格接口、统一评测协议、arena 评测）。
- Frontier AI 与网络安全双用途风险治理相关报告与社区框架。