Agent风险等于权限乘以自动化倍率

Agent 风险等于权限乘以自动化倍率

同一项权限交给人和交给 Agent，权限名称没有变化，事故半径却可能完全不同。

这个系列的第一篇提出过一个判断：企业真正担心的不是 CRUD，而是自动化倍率。

现在把这件事展开。

假设一名客服拥有 5000 元以内的退款权限。

他在业务系统中手工退款时，通常会经历：

text 复制代码

打开订单
→ 查看退款原因
→ 输入金额
→ 点击确认
→ 等待系统返回
→ 再处理下一笔

把同一权限交给 Agent 后，执行方式变成：

text 复制代码

读取一批工单
→ 自主判断退款理由
→ 批量生成参数
→ 并发调用退款接口
→ 对失败请求自动重试
→ 再委托子 Agent 处理异常

两边可能使用同一个用户身份、同一个 RBAC 角色、同一个退款 API，甚至通过同一套后端权限检查。

但它们不是同一种风险。

人工操作天然存在速度、注意力和交互摩擦。Agent 可以连续运行、批量执行、并发扩散，并把一次错误稳定地复制到数千个对象上。

所以，评估 Agent 权限时只问"用户有没有这个权限"，远远不够。

还要问：

text 复制代码

这项权限会被以多快的速度、持续多久、影响多少资源、扩散到多少执行者，
以及发生错误后能否及时发现、停止和恢复？

这不是一个精确的数学公式

标题中的"乘以"是一种风险建模方式，不是行业统一公式，也不是用几个数字就能算出事故金额的精确模型。

可以先用下面的启发式模型理解 Agent 的风险包络：

text 复制代码

Agent 风险包络
≈
权限强度
× 资源可达范围
× 执行速度
× 自主运行时长
× 并发与委托扇出
× 决策不确定性
× 恢复难度

它强调的不是小数点，而是相互放大。

一个只读 Tool 即使调用很快，通常也不会直接修改业务状态，但可能高速导出敏感数据。

一个付款 Tool 即使每次金额不高，只要能够长时间循环、并发调用且没有累计预算，仍可能造成大额损失。

一个高权限 Tool 如果只能作用于单个对象、每次需要精确批准、结果可回退，风险又会明显下降。

因此，权限是风险的底座，自动化特征决定了这份权限能在多短时间内扩展成多大的现实影响。

OWASP 所说的 Excessive Agency

OWASP GenAI Security Project 将 Excessive Agency 描述为：LLM 系统因获得调用函数或外部系统的能力，可能在意外、含糊或被操纵的模型输出驱动下执行破坏性动作。

它给出的三个常见根因很直接：

text 复制代码

Excessive Functionality
Excessive Permissions
Excessive Autonomy

翻译到企业架构中：

Agent 看到了完成当前任务并不需要的 Tool；
Tool 使用了过宽的用户权限或服务账号权限；
Agent 可以在没有足够人工门、预算和停止条件的情况下连续执行。

这三件事经常一起出现。

例如，一个文档 Agent 只需要读取知识库，但使用的插件同时提供修改和删除能力；一个客服 Agent 只需要处理当前工单，却拿到了整个区域的客户数据；一个采购 Agent 本来只应生成申请草稿，却能直接提交、审批和通知供应商。

模型是否"聪明"不是唯一变量。

即使模型绝大多数时候判断正确，只要一次错误可以高速复制、长时间不被发现、难以撤销，系统仍然不适合直接进入生产自动执行。

第一层倍率：权限强度

权限强度不只看 read、write、delete 三个动词。

还要看它能触发什么业务后果。

text 复制代码

读取公开产品目录
< 读取客户联系方式
< 导出全体员工档案
< 修改订单状态
< 发起退款
< 批准付款
< 删除生产资源

同样是 update，修改工单标签和修改付款状态不是一个风险等级。

同样是 read，读取一条工单和批量导出薪资数据也不是一个等级。

权限强度至少包含：

数据敏感度；
动作是否产生副作用；
副作用是否涉及资金、合规或人身安全；
是否不可逆；
是否可以创建新的权限、凭证或执行主体；
是否可以影响其他系统。

这里最危险的反模式是共享高权限服务账号。

用户原本只能查看自己的客户，Agent 却通过一个区域管理员账号访问全部客户。此时 Agent 的权限上限不再是用户权限，而是服务账号权限。

只要 Prompt Injection、参数误判或 Tool 选择错误发生一次，攻击面就会覆盖服务账号可以触达的全部资源。

第二层倍率：资源可达范围

传统权限审查经常停在：

text 复制代码

客服可以退款

但真正决定爆炸半径的是：

text 复制代码

可以给哪些订单退款？

可能的范围差异很大：

text 复制代码

当前订单
当前客户
当前工单队列
当前区域
当前法人
全部订单

Agent 的有效权限不应只包含动作，还要包含资源集合。

text 复制代码

Allow refund

不够。

更完整的表达是：

text 复制代码

Allow refund
for order:20260824001
up to 300 CNY
once
before 16:00
for reason logistics_delay

这就是 Task Grant 的意义：把长期角色权限收窄为本次任务可以触达的具体对象和预算。

资源范围还要防止隐式扩大。

例如 Tool 接受任意搜索条件：

text 复制代码

search_customers(filter)

即使底层对每条记录都执行 ACL，Agent 仍可能通过分页、组合查询和长时间循环，把用户可见范围内的大量数据持续抽取出来。

单条读取合法，不代表批量汇总和外传同样合理。

第三层倍率：执行速度

人类用户的操作速度通常有限。

Agent 可以：

毫秒级发起下一次请求；
并行调用多个 Tool；
自动翻页处理数据；
失败后快速重试；
在无人观察时持续运行。

这意味着传统系统为人工使用设计的限流，可能不适合 Agent。

如果一个人工用户每分钟处理两笔退款，异常往往能在几十笔以内暴露。

如果 Agent 每秒处理二十笔，同样的发现时间可能已经对应数千次副作用。

因此，调用速度本身就是权限控制参数。

Action Contract 应支持：

text 复制代码

每秒调用上限
每分钟业务动作上限
单任务最大调用次数
单任务累计金额
并发执行上限
每批最大对象数
异常率熔断阈值

普通 API Rate Limit 主要保护系统容量。

Agent Action Limit 还要保护业务风险预算。

一个系统能承受每秒一千次退款请求，不代表业务应该允许 Agent 每秒退款一千次。

第四层倍率：自主运行时长

一次交互式调用与一个运行八小时的后台 Agent，不应使用同一份授权。

自主运行越久，越容易遇到：

用户意图已经变化；
组织或角色已经变化；
资源状态已经变化；
Agent 版本已经更新；
上游数据被污染；
凭证或任务本应撤销；
错误累计到更大规模。

因此，Agent 授权必须有时间边界。

text 复制代码

用户长期角色
≠
Agent 长期持有同等能力

高风险任务更适合短期 Grant：

yaml 复制代码

task_grant:
  issued_at: 2026-08-24T14:00:00+08:00
  expires_at: 2026-08-24T14:30:00+08:00
  max_calls: 20
  max_amount: 10000
  renewable: false

任务没有在 30 分钟内完成，不应静默延长权限。它应该重新读取用户、Agent、资源和风险状态，再决定是否续期。

长期后台 Agent 则需要自己的 Agent Identity、Sponsor、职责范围和生命周期，不能永久借用某个员工的会话权限。

第五层倍率：并发和委托扇出

单 Agent 串行执行已经会放大速度，多 Agent 扇出会进一步扩大影响。

text 复制代码

主 Agent
├── 客户数据 Agent
├── 退款 Agent
├── 通知 Agent
└── 对账 Agent

如果每个子 Agent 都自动继承父 Agent 的全部权限，系统会出现两个问题。

第一，权限扩散。

原本只需要读取订单的通知 Agent，可能同时拿到退款权限。

第二，预算穿透。

父任务规定最多退款 10000 元，但四个并发子 Agent 分别读取到"剩余额度 10000 元"，随后各自执行，最终累计超过上限。

所以子任务权限必须满足：

text 复制代码

子任务权限 ⊆ 父任务权限

预算还必须由确定性服务原子占用，不能只写进 Prompt 或关系条件。

委托链至少需要限制：

最大子 Agent 数；
最大委托深度；
子任务允许的 Tool；
子任务资源范围；
父子任务共享还是分割预算；
父任务撤销时是否级联撤销；
是否允许子 Agent 再委托。

模型可以决定把工作分给哪个 Agent，但不能自行扩大权限总量。

第六层倍率：决策不确定性

Agent 的不确定性不仅来自模型幻觉。

还可能来自：

用户请求含糊；
外部文档包含 Prompt Injection；
Tool 描述不准确；
上游 Tool 返回脏数据；
业务状态在推理期间发生变化；
身份或权限缓存已经陈旧；
API 超时但副作用其实已经发生；
模型正确理解目标，却生成了错误参数。

传统后端代码也会出错，但 Agent 会把更多动态信息带进决策链。

因此，企业不能只测最终成功率。

还要识别：

text 复制代码

哪些输入来自用户
哪些输入来自模型
哪些输入来自权威系统
哪些输入来自不可信外部内容
哪些值在执行前必须重新读取
哪些值需要人工确认

一个退款金额可能来自模型对邮件的解析。

订单可退款余额必须来自订单系统。

用户授权范围必须来自 Task Grant。

最终是否允许退款，还要由业务系统在执行时判断。

数据来源不同，可信等级也不同。

第七层倍率：恢复难度

风险不仅取决于错误发生的概率，也取决于错误能否被发现和恢复。

可以粗略分为：

text 复制代码

可直接撤销
可通过补偿动作恢复
需要人工对账
法律或财务上不可完全恢复
物理世界不可逆

修改工单标签通常容易恢复。

发送一封错误邮件可以补发说明，但无法让收件人"没看见"。

重复付款可以尝试追回，却不等于没有损失。

删除生产数据如果没有可靠备份，可能无法恢复。

控制物理设备的错误动作，后果甚至发生在软件系统之外。

因此，高恢复成本 Action 必须拥有更低的自动化倍率：

更窄的资源范围；
更低的调用频率；
更短的授权时长；
更强的审批；
更可靠的读回；
更快的 Kill Switch。

不能因为模型成功率达到某个百分比，就自动开放不可逆动作。

自动重试为什么会把小故障放大

分布式系统中，重试是常见的可靠性手段。

AWS Builders' Library 对幂等 API 的讨论指出，复杂操作往往由多个下游调用组成，重试可以处理许多瞬时故障；但带副作用的操作需要明确客户端意图和幂等语义，不能把"请求看起来相同"简单当成"业务意图相同"。

这对 Agent 尤其重要。

考虑一次退款调用：

text 复制代码

Agent 发送请求
→ 退款服务已经提交
→ 响应在网络中丢失
→ Agent 看到超时

如果 Agent 直接重试，可能产生第二笔退款。

安全流程应是：

text 复制代码

发送带 idempotency_key 的请求
→ 服务端原子记录该业务意图
→ 重复 key 返回同一次结果

如果下游不支持幂等，超时后应进入：

text 复制代码

UNKNOWN
→ 查询现实状态
→ 对账
→ 决定继续、补偿或人工处理

而不是：

text 复制代码

超时
→ 模型认为失败
→ 再执行一次

Agent 的自动恢复能力越强，越需要严格区分"可安全重试"和"必须先对账"。

三个同权限、不同风险的例子

例一：客户数据读取

人工用户：

text 复制代码

搜索一个客户
→ 查看一条记录

Agent：

text 复制代码

遍历全部分页
→ 关联订单、联系人和投诉
→ 汇总后发送到外部模型

两者都可能通过同一条 customer.read 权限。

风险差异来自资源范围、执行速度、数据聚合和外传路径。

控制重点不是取消读取权限，而是：

限制查询对象和字段；
限制每任务结果数量；
控制敏感数据进入模型；
记录导出和聚合行为；
对跨域数据取权限交集。

例二：退款

人工用户：

text 复制代码

一次退款 300 元

Agent：

text 复制代码

读取 2000 条投诉
→ 自动判断责任
→ 并发发起退款
→ 对超时请求自动重试

两者都在单笔 5000 元角色上限内。

风险差异来自批量规模、累计金额、并发和重试。

控制重点是：

单任务累计金额；
最大对象数；
幂等键；
Expected Version；
异常率熔断；
结果读回和对账。

例三：云资源管理

人工管理员：

text 复制代码

删除一台确认废弃的测试实例

Agent：

text 复制代码

根据标签识别"闲置资源"
→ 批量删除
→ 子 Agent 清理磁盘、快照和网络

两者可能使用同一个云管理员权限。

风险差异来自分类错误、委托扇出和不可逆删除。

控制重点是：

只生成删除 Proposal；
显示精确资源清单；
检查环境和所有者；
保护生产标签；
分离实例、磁盘和快照权限；
延迟删除并保留恢复窗口。

把"自动化倍率"变成可执行预算

只说"这个 Agent 风险很高"无法落地。

可以为每个任务签发 Capability Budget：

yaml 复制代码

task_id: task:refund-20260824-001
subject: user:service-agent-a
actor: agent:refund-assistant@12.4.1

allowed_actions:
  - refund_order

resource_scope:
  queue: logistics-delay
  max_orders: 20

financial_budget:
  max_per_order: 500
  max_total: 5000

execution_budget:
  max_calls: 20
  max_concurrency: 2
  max_duration_seconds: 900
  max_delegation_depth: 0

safety:
  require_idempotency_key: true
  require_expected_version: true
  require_post_action_readback: true
  stop_on_unknown_result: true
  circuit_breaker_error_rate: 0.1

approval:
  required_above_total: 2000

这不是要求所有企业使用同一种 YAML。

关键是把模糊的"允许 Agent 退款"变成可计数、可占用、可撤销的运行时边界。

预算不能只由 Agent 自己维护。

高风险动作需要由 Action Service、策略执行点或事务型预算服务原子扣减。否则多个并发 Agent 都可能认为预算尚未使用。

人工确认应该降低哪一层倍率

"加个人工确认"是最常见的安全建议。

它有价值，但要看确认发生在哪里。

低质量确认：

text 复制代码

Agent 想调用 refund_order，是否允许？

高质量确认：

text 复制代码

将为 18 个订单退款
累计金额 4280 元
原因：物流超时
目标队列：华东售后
执行 Agent：refund-assistant@12.4.1
有效期：15 分钟
失败策略：停止并人工对账

后者降低的是资源范围、金额预算和自主时长的不确定性。

确认还必须绑定精确 Proposal。

如果确认后对象列表、金额或目标系统发生变化，旧批准应失效。否则用户批准的是 A，Agent 最终执行的可能是 B。

每次调用都弹窗也不是答案。频繁弹窗会制造确认疲劳。

更合适的方式是：

text 复制代码

先批准一份有明确边界的 Task Grant
→ Agent 在边界内自动执行
→ 超出边界时重新确认

运行时必须有刹车

上线前的权限配置无法覆盖运行时所有异常。

Agent 执行层还需要动态刹车：

text 复制代码

调用次数达到上限
累计金额达到上限
异常率突然升高
连续出现业务拒绝
读回结果与预期不一致
PDP 或源系统返回 Indeterminate
权限或 Agent 已被撤销
出现 UNKNOWN 副作用结果

命中条件后，应采取确定性动作：

text 复制代码

停止新调用
冻结任务 Grant
取消未开始的子任务
保留已获得的结果和幂等键
进入对账或人工队列

不要把熔断后的处置继续交给同一个出错 Agent 自主决定。

Kill Switch 也要区分层级：

停止一个任务；
停止一个 Agent 版本；
停止一个 Action；
停止一个业务域；
撤销一类凭证；
阻止所有生产写操作。

事故时只提供"关闭整个平台"通常太粗，只提供"等待 Agent 自己停下"又太弱。

风险分级不能只看 Tool 名称

同一个 Tool 在不同合同下可以属于不同风险级别。

以 export_report 为例：

text 复制代码

导出本人负责的 20 条公开产品数据

和：

text 复制代码

导出全公司客户、订单和联系方式

不是同一风险。

所以风险等级应该由调用上下文计算：

text 复制代码

Risk Tier
=
Action 固有风险
+ 数据敏感度
+ 资源范围
+ 金额与数量
+ 自主时长
+ 委托深度
+ 环境风险
+ 可恢复性

低风险任务可以采用更轻的流程。

高风险任务则需要更窄权限、短期 Grant、审批、预算、读回和对账。

不要为了方便，把开发环境中允许的宽 Tool 自动提升到生产环境。

比"任务成功率"更重要的指标

任务成功率不能反映最坏情况下的影响范围。

企业至少还应监控以下指标。

最大授权爆炸半径

text 复制代码

一个任务最多可影响多少对象、金额、数据量和系统？

看的是合同上限，不是平均使用量。

无人工观察窗口

text 复制代码

Agent 最长可以连续运行多久、执行多少次副作用？

撤权时延

text 复制代码

用户离职、角色撤销、任务取消或 Agent 禁用后，多久停止生效？

需要同时测策略、缓存、凭证、队列和已经分发的子任务。

结果读回覆盖率

text 复制代码

多少写操作能从权威系统确认最终状态？

API 返回 200 不等于业务目标已经完成。

UNKNOWN 比例与对账时长

text 复制代码

多少写操作进入不确定状态？
多久能够确认现实结果？

幂等覆盖率

text 复制代码

多少非只读 Action 拥有服务端幂等语义？

自动化预算利用率

text 复制代码

任务实际使用量占最大授权量多少？
是否存在长期发放、几乎不使用的宽预算？

人工否决率

text 复制代码

用户在确认界面拒绝了多少 Proposal？
拒绝原因是什么？

它可以暴露模型误解、范围过宽和确认界面问题。

补偿成功率

text 复制代码

发生部分失败后，哪些副作用可补偿，补偿是否真的完成？

这些指标比"接入了多少 Tool"更接近生产风险。

上线前应该做的倍率测试

Agent 测试不能只给一组正常任务，然后统计完成率。

还要主动测试放大路径。

权限放大

用户没有权限时，Agent 是否仍能通过服务账号完成？
Tool 是否暴露了任务不需要的删除、导出或管理功能？
源系统 Deny 能否阻止中间层 Allow？

范围放大

单对象任务能否通过搜索、分页或批量参数扩展到更多对象？
多次小额调用能否穿透累计预算？
数据聚合后是否产生新的敏感组合？

速度放大

并发和速率是否受业务预算限制？
连续错误达到阈值后是否自动停止？
任务达到最大调用次数后是否仍能继续？

时间放大

Grant 过期后旧会话能否继续调用？
用户撤权后缓存多久失效？
队列中的旧任务是否会在授权失效后重新执行？

委托放大

子 Agent 能否获得父任务没有的 Tool？
多个子 Agent 能否分别消费完整预算？
父任务取消后子任务是否级联停止？

重试放大

同一 idempotency key 是否只产生一次副作用？
超时后是否进入 UNKNOWN 而不是盲目重试？
晚到响应是否会被误认为另一次新任务？

恢复放大

Kill Switch 能否在目标时限内停止新动作？
已执行动作能否读回、补偿或进入人工队列？
审计能否还原 Subject、Actor、Task 和影响对象？

这些测试的目标不是证明 Agent 永远不会犯错。

目标是证明一次错误不会无限扩散。

常见反对意见

"用户本来就有权限，Agent 只是替他操作"

用户权限应继续作为上限，但"有权"不等于"授权自动、批量、长期执行"。

人工操作中的速度、页面流程和逐次确认，本来就限制了影响范围。Agent 去掉这些摩擦后，需要用 Task Grant、预算、限流和审批补回明确边界。

"模型准确率已经很高"

高准确率可以降低错误概率，不能自动降低单次错误的影响。

一个 99.9% 正确的系统，如果每天自动执行一百万次不可逆动作，剩余错误仍可能无法接受。

这里的数字只是说明概率与影响必须分开评估，不代表某个准确率可以直接换算成上线门槛。

"每次 Tool 调用都需要用户确认"

精确确认能降低风险，但批量任务中的高频确认会导致疲劳。

更可行的是批准结构化、有限期、有预算的任务范围，并在超限、参数变化或风险升高时重新确认。

"加限流就够了"

限流只控制速度，不控制权限强度、资源范围、累计金额、委托深度和恢复难度。

每秒一次付款，持续八小时，仍然可能造成严重后果。

"出了问题可以看日志"

日志只能帮助解释，不能自动停止正在扩散的副作用。

还需要实时预算、熔断、撤权、Kill Switch、读回、对账和补偿。

分阶段降低自动化倍率

第一步：量出当前最大半径

不要先看平均调用量。

先回答：

text 复制代码

一个 Agent 在没有人工介入时，最多能做什么？

包括最大对象数、金额、数据量、运行时长、并发数和子 Agent 数。

第二步：删除不需要的功能

如果任务只需要读取，不要同时暴露修改和删除 Tool。

如果只需要提交申请，不要授予审批权限。

减少功能比增加 Prompt 规则更可靠。

第三步：把长期权限收窄为任务预算

为 Action 指定对象、金额、次数、TTL 和 Agent 版本。

高风险预算由确定性服务原子占用。

第四步：限制速度和扇出

分别设置系统限流与业务限额，限制并发、批量大小和委托深度。

第五步：补齐结果闭环

每个写操作都要知道：

text 复制代码

如何证明成功
如何识别 UNKNOWN
如何对账
如何补偿
何时转人工

第六步：真实演练撤权和熔断

在任务执行中途：

撤销用户角色；
取消 Task Grant；
禁用 Agent 版本；
打开 Action Kill Switch；
模拟下游超时；
模拟读回不一致。

记录系统真正停止的时间，而不是只检查配置页面显示"已禁用"。

结论

同一项业务权限交给 Agent 后，风险变化并不是因为 RBAC 突然失效，也不是因为 MCP 天生不安全。

变化来自执行方式。

Agent 可以自主选择 Tool、连续调用、批量处理、并发扇出、自动重试，并在无人观察时持续运行。权限没有变，速度、范围、时长和传播方式变了。

因此，企业需要同时控制两件事：

text 复制代码

Agent 可以做什么
×
Agent 可以把这件事自动做到多大规模

前者由用户权限、Agent Identity、Tool allowlist、Task Grant、Action Contract 和源系统最终校验共同收窄。

后者由资源预算、调用次数、累计金额、TTL、并发上限、委托深度、熔断、读回、对账和恢复能力共同限制。

成熟的 Agent 权限架构，不是承诺模型永远不犯错。

它应该证明：

text 复制代码

即使模型犯错
→ 权限不会无限扩大
→ 自动化不会无限持续
→ 副作用不会无限复制
→ 撤权和熔断能够及时生效
→ 现实结果可以被读回和恢复

真正的安全目标不是把 Agent 变成人工点击器。

而是在保留自动化价值的同时，为自动化倍率设置清晰、可计数、可撤销的上限。

参考资料

发布摘要

同一项权限交给人和交给 Agent，为什么会变成完全不同的风险？因为 Agent 会把权限与资源范围、执行速度、自主时长、并发扇出、决策不确定性和恢复难度相乘。本文提出"自动化倍率"风险模型，给出任务级 Capability Budget、运行时熔断、撤权指标和负面测试方法，帮助企业在保留自动化价值的同时限制最大事故半径。