Agent 安全不能只靠审批按钮：从单次动作走向任务轨迹

8 月 4 日的 Black Hat AI Summit 把 Agent 行为、访问内容和工具调用放在核心位置；同周发布的《Securing Agentic AI》则提出一个更精确的概念：从逐动作检查走向任务轨迹保障。两者共同指出，传统权限控制只能判断某一步能不能做，却未必看得懂许多合法步骤组合起来会发生什么。

想象一个采购 Agent。它可以读取供应商资料，可以生成比较表，也可以给采购经理发邮件。每个动作单独看都合规，但如果它先从私密文档提取底价，再把底价写进发给供应商的邮件，系统就发生了数据泄漏。风险不在任何一个按钮，而在动作之间的因果关系。

这就是逐动作审批的局限。它把安全简化成“允许读取文件吗”“允许发送邮件吗”，却忽略任务目标、数据来源、接收对象和先前状态。Agent 越能规划长链任务，攻击者越可能通过无害的小步骤绕过局部规则，在后面合成一个违规结果。

提示注入让问题更严重。恶意指令可能藏在网页、邮件、文档、记忆或工具返回值中。当 Agent 读到它时，未必立刻执行危险动作，而可能先修改计划、收集更多权限，再等待合适时机。只在工具调用瞬间扫描参数，很难识别计划已经被外部内容悄悄带偏。

轨迹保障的核心，是把安全约束表达成贯穿任务的状态不变量。例如“客户 A 的数据不能影响发给客户 B 的输出”“未经财务确认不能形成不可逆支付”“来自不可信网页的内容不能改变系统权限”。这些规则需要在任务开始、状态变化和最终交付时持续检查。

这要求 Agent 运行时保存结构化来源。每一段重要数据来自哪里、经过哪些转换、进入了什么工具，都应当可追踪。仅保存聊天记录不够，因为聊天文本不会自动表达数据血缘；仅保存最终日志也不够，因为许多关键决定发生在中间计划和工具返回之间。

第二个要求是风险随轨迹累积。读取公开网页风险很低，读取内部合同风险更高；把两者合并后发送给外部地址，风险会突然跃升。权限系统不能把每次调用视为全新事件，而要根据当前任务已经持有的数据、已完成的动作和接下来目的地动态调整。

第三个要求是可恢复。安全系统如果只有“允许”和“拒绝”，Agent 遇到限制时就会不断换写法重试，或者把任务整个丢给用户。更好的设计是给出可执行的恢复路径：删除敏感字段、换用只读工具、请求指定审批，或从最近的安全检查点重新规划。

对产品体验来说，审批也应该从技术权限翻译成业务后果。用户不需要看到“允许调用 send_email”，而需要看到“将把包含客户合同价格的摘要发送给外部域名”。好的确认界面同时展示对象、数据、不可逆性和替代方案，让人能在几秒内作出有意义的判断。

多 Agent 会进一步扩大轨迹。主 Agent 可能把资料交给研究 Agent，再由写作 Agent 生成内容，最后让浏览器 Agent 发布。每个子 Agent 都遵守自身权限，数据仍可能在委托链里越界。因此，任务范围和数据标签必须随委托传播，不能在切换执行者时丢失。

事故响应也要围绕轨迹设计。发现异常后，团队不仅要停掉当前 Agent，还要知道相同数据是否进入其他任务、哪些凭证被使用、哪些外部系统已被修改。可撤销令牌、任务级隔离和影响范围查询，会决定一次小错误是被局部控制，还是扩散成组织级事故。

Builder 可以用一个简单方法检查现有系统：挑选五个高风险结果，从结果向前回放完整路径。它读取了哪些数据，经过哪些 Agent，使用了哪些工具，哪一步改变了权限，哪里可以撤销？如果任何问题只能靠猜，系统就还没有真正的可观测性。

评测也要从恶意单条提示扩展到恶意任务序列。测试者可以设计跨步骤攻击：先建立信任，再污染记忆；先让 Agent 保存文件，再诱导另一工具读取；先获得低风险授权，再改变接收对象。只有覆盖组合行为，团队才会发现局部安全与全局安全之间的缝隙。

这类防线不会由一个“Agent 防火墙”按钮解决。它涉及模型输入净化、数据来源、能力授权、执行沙盒、事件日志、策略引擎和人工接管。安全产品可以提供组件，但应用团队仍要定义自己的业务不变量，因为只有业务知道什么组合构成真正损失。

Black Hat 把 Agent 安全推到中心，说明企业的关注点已经从“AI 会不会说错话”转向“AI 会不会做错事”。前者可以靠过滤和免责声明缓解，后者会改变数据、资金与客户关系。Agent 要进入生产，安全系统就必须理解完整任务，而不是只守住每一次单独点击。