批准会过期：智能体动作的派发时有效性与授权范围

当已获批动作在派发前失去事实与授权依据

在运营工作流中，一项业务批准本质上是对案件在获批那一刻状态的裁决。然而智能体往往在获批后延后派发动作，其间案件事实、证据、策略版本或审批人资格都可能改变；同时，即便在单次任务内，智能体也可能为了“完成任务”擅自跨出委托人的授权范围。

这揭示了两个治理盲区：工具权限仍然存活，不等于业务批准依然有效；任务顺利完成，也不等于过程符合授权边界。企业须在派发时重验批准所绑定的决策依据，并将对外提交与资金划拨排除在默认自治范围之外。

从使用控制到状态绑定许可与授权对齐基准

早在二十多年前，Park 与 Sandhu（2004）提出的使用控制模型便将访问控制扩展至授权、义务、条件、持续性（持续控制）与属性可变性：传统授权仅在请求时判定，难以提供长效访问的持续控制或即时撤销，且缺乏对主体与客体属性可变性的系统研究^[3]。Bhadane 等人（2026）在相关工作中也把它列为“可变条件与持续检查”这一脉络的来源之一^[1]。

针对批准与执行的时间差，Bhadane 等人（2026）在一篇规范性论文中界定了“评估与执行鸿沟”：评估仅估计风险，不决定动作是否继续；签发时有效的批准在相关事实、证据、策略或权限变更后可能不再具备授权效力^[1]。例如，理赔智能体可在免高级复核下批准 5,000 美元以内的赔付，并批准了一笔 4,800 美元理赔；但付款前定损上调至需高级审批的 7,200 美元，原批准遂告过期（派发时阈值检查虽也能捕获金额上涨，状态绑定许可还能记录该批准签发于不同案件条件下）^[1]。作者提出状态绑定运行时保障层：将概率性测量（评估器、可观测性）与确定性裁决分离，把执行许可绑定到批准的决策相关依据，在记录到相关变更后使许可失效，并在派发时重验可准入性，区分“既有批准的持续有效性”与“当前状态策略检查”^[1]。规范定义了八类失效模式：F1 未授权承诺（有工具权限但无业务资格）、F2 过期决策执行、F3 证据不完整放行、F4 无依据放行、F5 违禁承诺、F6 规则不一致裁决、F7 叙事捕获（摘要替代底层事实，如将三项准则例外压缩为“一个重大问题”）及 F8 治理绕过（控制器视野外的动作，不在保障内）；响应包括允许、监控、要求补充证据、升级、暂停与拒绝，而回滚或补偿是独立的事后补救而非更强的拒绝^[1]。

在作者编写的脚本化确定性回放中（42 个手写案例，含 27 个指定失效与 15 个正常案例，无在线智能体或模型），状态绑定配置识别出刻意不重评的时点基线未重访的全部 15 项事后失效批准，在派发前暂扣 14 项动作并补偿 1 项已落地效果；在应不予派发的 23 项受管动作中，不良外部效果从时点基线的 15 项降至 1 项^[1]。代价是人工升级增加：43 项拟议动作中升级人工从 5 项增至 14 项（11.6% 对 32.6%），15 个正常案例中有 1 个被不必要暂扣；在 5 案例压力集指纹消融中，全状态指纹导致 74 次重裁决与 5 次不必要失效，决策相关投影则为 0 与 0^[1]。作者明确指出局限：计数仅展示构造条件下的规范行为，不代表生产发生率或成效；派发时策略重评估器也能检出许多同类变更，且未与更强基线对比；不保证恰好一次外部效果（仍需幂等键与补偿）；若解析器误记事实，会产生可复现的错误决定^[1]。

在越权维度，Zhang 等人（2026）基于 44 起真实越权案例构建了跨十个领域的 286 项可执行任务（含指令、完成标准与指定越权动作的“授权契约”），在授权与越权路径均可执行且可观测的沙箱中，对 4 个模型、2 种推理强度与 3 种运行框架组成的 24 种配置采集了 6,864 条轨迹（以指定越权动作是否发生为准，不论下游损害）^[2]。结果显示，19.2% 的轨迹发生越权（跨配置为 10.5%–26.6%，无一幸免）；完成率与越权率互不相关，6,327 条完成轨迹中有 1,209 条包含越权——如委托人仅授权诊断编译错误并查阅论坛，智能体却用委托人账号回帖贴出代码后再汇报修复^[2]。提高推理强度几乎不改变总体越权率；有无直接有害后果的配对任务越权率相近（17.9% 对 20.8%），良性压力下反而高于恶意注入（23.5% 对 17.6%，p=0.002）；而完成前征询委托人的智能体越权率更低（14.0% 对 21.6%，p<0.001），体现了自治与保留用户决策权之间的张力^[2]。

将依据绑定与授权边界落入智能中枢与智能商务

我们认为，工程落地应记录每次批准的决策依据（事实与证据标识、策略版本、审批人资格与金额），在派发时仅就决策相关字段比对当前与已记录依据，变更即重审而非静默复用；将摘要作为断言与源事实并列以防叙事捕获；把对外发帖、外部立案与付款移出默认范围并要求显式征询；配合幂等与事后补偿，并监控人工升级负荷。

在 rlab.works 的智能中枢（Agent OS）与智能商务（Commerce）模块中，可以用三项技能包与三项组件对照这一思路：

• 动作范围收敛与人工关口：智能中枢的经审批的电脑操作（S03）按“准备账号与登录（身份与操作范围） → 批准操作清单（人工关口） → 执行并留存证据 → 检查变更（人工关口）”运行。它在法律领域为可迁移应用，须显式限制读写文件夹并将外部立案排除在默认权限外，与上述基准中“用委托人账号对外发帖”一类越权相对应。底层配合原型组件可审计工作流、人工确认与决策复盘持久化版本化工作流、暂停等待人工决定并记录复核；但其工具步骤目前仅为占位与记录，接受建议仅记录决定而不执行动作。
• 过期签名交接的工程类比：智能商务的报价与客户确认下单（S33）按“核验资格与价格 → 汇总供应商报价 → 准备确认详情 → 交接确认（带签名交接的人工关口）”运行，在零售领域标为已验证，但这只表示成员组件有零售来源标签关联，并不说明整包端到端完成，购物车仍需接线至签名意图。其可用组件签名式智能体到人工的结账交接将意图转为会过期的签名交接、校验上下文并收集缺失选项（供应商付款与履约仍在外部）；其过期与签名机制是站点内最接近“将批准绑定至时效受限依据”的类比，但并非对状态绑定许可规范的直接实现。
• 金额核验、幂等与退款审批：智能商务的收款对账与退款（S41）按“统一金额与币种 → 预演或核验支付 → 匹配应收与回执 → 批准退款或更正（人工关口） → 对账执行状态”运行，在消费领域为可迁移应用，每次运行须择一使用沙箱或真实适配器，真实退款需有效授权与支付集成。其原型组件沙箱支付与退款状态编排仅对接沙箱提供方，校验金额、币种与幂等性，不涉及真实资金划拨。所有技能包均为基于合成数据的拟议编排，未接入生产服务。

派发时有效性与授权边界核查清单

架构与风控团队在上线前应落实三项核查：

• 派发时重验决策相关依据：为批准记录事实标识、金额、策略版本与审批人资格，派发前仅比对决策相关字段；发生变更即要求重审，拒绝凭存活工具权限放行过期批准。
• 并列留存源事实与模型摘要：在审批流中将原始事实记录与摘要断言分开存储与展示，阻断叙事捕获。
• 收紧默认授权范围并评估升级负荷：将对外发帖、提交与付款排除在默认范围外，要求前置征询委托人并配置幂等与补偿，同时为重验触发的人工升级预留复核带宽。