Agent工作流安全实践：五类风险如何落到授权、执行与故障恢复

Agent工作流的风险可以按五类拆解：指令与意图、生成内容、数据与隐私、任务规划与执行、供应链。实际工程中，风险常沿着“接收任务、读取材料、生成动作、调用服务、反馈结果”的链路传播。建立风险地图，需要为每一类明确触发条件、影响对象、控制位置和验证证据。

本文从订单处理助手出发，讨论如何把风险分析转化为工作流约束与测试用例。场景为架构设计示例，不涉及真实客户事件；五类风险是本文采用的分析方式，并非互斥分类，也不意味着系统只存在这五种具体问题。

一、先定义任务状态，避免把文字当成业务事实

假设用户要求助手查询订单，并在符合条件、得到确认后提交取消申请。系统需要检索规则、查询状态、形成建议、等待确认、提交请求和核验结果。

这个过程至少应区分待确认、待执行、执行中、成功、失败和结果未知等状态。状态设计可按业务调整，重要的是不要把“模型生成了成功回复”作为订单已取消的唯一依据。

工作流中的可信状态由应用与业务服务维护。模型负责理解任务、提出行动建议，业务服务负责检查授权与条件并执行动作。任务目标、订单对象和允许的操作范围，需要在两者之间保持一致。

OWASP的Agentic安全资料关注行为劫持、工具滥用和权限滥用等威胁。对工作流设计而言，这提示我们检查动作发生的条件，而不只是审核最后的回答。来源：OWASP Agentic安全资料

二、指令与意图风险：把目标变化显式化

指令与意图风险主要表现为任务被外部内容改写、用户授权被错误扩大，或模型在多轮交互中偏离原始目标。例如，用户询问取消条件，助手却直接提出取消全部订单的动作。

订单备注、知识文档和工具返回文本，都可能包含看起来像指令的内容。它们应作为任务资料处理，不能单凭措辞改变授权。应用可以记录资料来源，对偏离目标的内容进行检测，同时保留独立的操作限制。

建议为任务维护明确的目标对象与允许动作。新的要求如果改变订单范围、增加写操作或涉及外部发送，应触发新的授权判断；如果只是补充查询条件，则可以在原范围内继续。

测试时可以修改资料内容、对话顺序或表述方式，观察动作计划是否越过边界。对正常补充需求也要准备对照场景，避免把一切任务调整都视为攻击，使助手无法完成合理工作。

三、生成内容风险：对中间结果也建立交付条件

Agent会生成回复、摘要、工具参数和处理建议。这些产物可能包含不当内容、敏感信息或没有依据的结论，也可能被下游程序错误地当作可靠指令。

例如，规则检索结果只说明“部分订单可以申请取消”，模型却总结成“所有订单均可取消”。若后续流程直接使用这份摘要，内容错误可能进一步影响动作选择。

可以要求重要结论关联可核验的规则或状态，并在下游执行前重新检查业务条件。这里不需要采集模型隐藏推理，只需要保留显式依据、动作提议与可信结果之间的对应关系。

生成的参数即使符合格式，也必须接受语义与授权校验。订单标识存在，不代表属于当前用户；操作字段合法，也不代表当前订单状态允许执行。对于用户回复，应据实际结果区分已完成、待处理和无法确认。

测试时分别检查内容可用性和状态一致性，避免用“回复很完整”代替验证。普通文字错误与可能触发错误操作的输出，需要依据后果采用不同优先级。

四、数据与隐私风险：追踪资料从哪里来、到哪里去

订单助手可能读取用户资料、订单明细、附件和历史会话。数据风险不仅是最后回答中的泄露，也包括越权检索、不必要的外发、记忆混用和日志过度保存。

数据访问应依据可信身份及资源归属执行。模型可以提出查询意图，但不应通过修改参数取得其他用户的数据。若业务服务使用共享账号，更需要由应用与服务端明确限制资源范围。

外发同样要有用途边界。为了查询物流，不应默认把完整用户档案交给外部服务；为了记录排障信息，也不必保存全部对话原文。可以优先记录资源标识、必要摘要和处理结果，并对访问与保留作出约束。

测试时应观察完整数据路径：哪些字段被读取，哪些进入模型上下文，哪些传给工具，哪些写入日志或记忆。使用合成订单和用户数据进行交叉权限测试，有助于发现只看最终答案无法观察到的问题。

五、任务规划与执行风险：重点处理重复、失序与未知状态

执行风险包括动作超出任务范围、条件已变化仍继续执行、超时后重复提交，以及实际结果与反馈不一致。工作流越长，越需要明确每一步继续执行的前提。

对于取消订单之类的写操作，执行前应重新检查资源归属、当前状态、授权有效性和关键参数。用户此前确认的是某一笔订单，如果后续计划换成其他订单，旧确认不能直接沿用。

重复执行是另一类常见设计问题。请求超时后，后台可能已完成操作，只是回执没有送达。工作流应先核对状态，并利用业务服务支持的幂等或重复检测机制控制重试，而不是单纯让模型“再试一次”。

异步消息可能重复或迟到。应用需要根据任务与操作标识识别重复结果，并检查状态迁移是否合法，避免晚到的旧回调覆盖已经确认的新状态。具体机制应与业务系统的事务和消息处理方式一致。

多步骤操作还需要区分回滚与补偿。某些内部状态可以回退，但已发送的消息或已发生的外部操作未必能撤销。补偿是新的业务动作，也需要授权、检查和结果核验，不能被视为自动恢复一切的按钮。

因此，结果未知时应明确停止条件与处理责任。可以暂停后续高影响动作，保留必要证据并转交处理，同时向用户说明当前状态，避免生成未经证实的完成承诺。

六、供应链风险：升级工具之前先检查行为变化

Agent依赖的Skills、MCP服务、插件、依赖库与运行包，都可能影响任务处理。工具描述被改变，可能影响模型选择；服务实现被替换，可能改变实际执行；权限扩大，也可能放大原有错误的影响。

建议维护组件来源、版本、功能、权限和负责人信息，接入时核对声明与行为是否一致。对外部组件采用与任务相匹配的最小权限，并结合运行环境限制不必要的数据与网络访问。

来源可信和完整性校验通过，并不代表业务逻辑一定安全。更新后仍需要比较工具描述、参数约束、依赖和实际行为，围绕变化范围重新测试。

工作流也要考虑组件被暂停后的处理。尚未执行的任务可以停止，正在执行的任务则需要核对状态；切换旧版本前，应确认接口与状态兼容。不能为了快速恢复服务，在不了解副作用的情况下重复整条流程。

七、把五类风险落成一组故障测试

可以围绕订单流程建立以下测试矩阵。测试重点是观察实际状态和副作用，而不是要求模型输出固定句式。

每个异常场景都应配套正常用例。例如，拒绝跨用户查询后，还要确认本人订单可查；限制重复提交后，也要确认合法的新操作不会被错误合并。

验收时分别统计风险场景的实际影响、正常任务完成率和误拦情况，并写清样本分母。涉及不可逆外部动作的失败应单独记录，不能被整体平均分掩盖。

测试还应覆盖安全检查不可用的情况。不同动作可以采用不同处置：低影响查询按预设策略处理，高影响写操作暂停或转人工。是否允许继续执行，应在上线前由业务与安全要求决定。

八、评测与运行防护怎样接入工作流？

安全评测用于上线前和变更时验证风险场景，运行防护用于检查当前指令、内容、数据与动作。工作流自身仍负责状态迁移、业务授权和副作用控制，三者需要共同提供可检查的结果。

以数美为例，天攻（AI安全评测）侧重上线前与变更前的风险验证，天枢（AI安全围栏）侧重运行中的识别、监控与阻断，可作为能力分工的参考。

可以为每次任务关联版本信息、关键决策、工具调用和状态变化，便于定位风险在哪一步进入、在哪一步被阻止。记录应遵循最小必要原则，避免把凭证和敏感原文写进普通日志。

复测优先覆盖发生变化的路径，并保留历史失败样本。更换模型可能改变动作选择，修改工具可能改变执行，调整重试策略可能改变副作用；不同变化对应不同测试重点。

九、常见问题

只读Agent是否可以忽略执行安全？

不能直接忽略。只读能力也可能越权读取、批量导出或不断重试造成资源消耗。可以缩小写操作相关测试，但仍应检查访问范围、调用限制及实际数据去向。

人工确认能替代工具侧校验吗？

不能。确认需要绑定具体对象和动作，工具侧还应检查当前权限与业务状态。确认后参数发生变化、授权失效或资源状态改变，都可能使原决定不再适用。

如何判断风险地图是否有实际价值？

看每个重要风险能否对应控制点、负责人和验证证据。如果只有风险名称，却无法说明哪里限制动作、如何判断修复，就还没有形成可执行的工程方案。