企业 AI 项目的演示常以“已成功调用业务系统”结束，真正的交付问题却从这里开始：智能体代表谁，可以修改哪一张工单，允许多大范围的变化，权限何时失效？本文的判断是，工具连接能力越容易复用，企业越需要把可委托的操作边界写成由业务系统执行的规则。以下是基于公开资料的工程分析，不代表壹典已交付项目或产品功能承诺。
从提供答案到改变状态，验收对象发生了变化
当助手只生成维修建议时，错误首先表现为答案质量问题；当它还能创建工单、调整排程或发送供应商邮件时，同一段错误理解会变成真实状态变化。由此产生的变化并非某个协议突然不安全，而是企业把更多执行权放到了由模型组织的工作流中。仍然只验收回答正确率和接口成功率，会漏掉“操作成功但根本不该操作”的情况。
模型上下文协议 MCP 为工具与资源接入提供统一接口，但接入协议不能替企业定义维修工单是否允许关闭、采购金额是否超限。本文引用的 2025-11-25 版授权规范主要规定 HTTP 传输场景的授权机制，并要求服务端检查令牌是否面向本服务。[1] 因此，“有合法令牌”与“这次业务变更满足组织规则”应分别验证。这里讨论的是长期有效的架构问题，不将旧版规范包装成近期新闻。
把授权预算落到四个可核对的维度
本文建议用“授权预算”描述一项委托的最大边界。它不是模型 token 预算，也不是行业标准，而是一份业务契约：第一是对象，限定租户、项目、设备与记录集合；第二是幅度，限定允许的动作、字段、数量和累计额度；第三是时效，限定开始时间、到期时间以及适用的状态版本；第四是去向，限定数据可以发送到哪些系统和接收方。
四个维度需要同时成立。例如“协助处理 A 厂区本周维修工单”不能自动解释为可修改所有厂区工单，也不能解释为可以向任意外部邮箱发送设备资料。预算的具体值应由业务责任人确定，模型负责在边界内拟定动作。累计额度必须由可信服务统一计数，否则把一笔大操作拆成多次小调用仍可能越界。
这改变了企业选型时应比较的内容。连接器数量能反映接入覆盖面，却不能证明委托范围可控。更有意义的问题是：对象范围能否在服务端过滤，凭证是否对应实际主体，字段是否可限制，预算和有效期能否撤销，以及所有入口是否经过同一套授权检查。
在工具和下游系统两处落实边界
OWASP 将过度代理能力的风险归因于功能、权限和自主程度过大，并建议收窄工具、在下游实施授权。[2] 对企业而言，可以先拆开“查询工单”“保存处置建议”“提交状态变更”，再决定各项适合自动执行还是需要业务审批。一个能够执行任意 SQL 或任意命令的通用工具，往往难以直接表达这种细粒度委托。
工具参数中的 tenantId、ownerId 或 role 不应因为模型填写了就获得可信身份含义。服务端应从认证会话和已登记委托中确定主体，再检查请求对象。若下游只能接受共享服务账号，适配层必须可靠实施对象级检查，并在审计中保留发起人；无法覆盖的入口应明确列为上线限制，而不是把共享账号权限当成所有用户的权限。
MCP 的安全指引明确反对未经正确受众验证的令牌透传。[4] 接入团队应说明面向 MCP 服务的凭证与调用下游系统的凭证如何分离、映射和撤销。完成接入时展示一次成功请求不够，还应展示越权对象请求被拒绝，以及拒绝时没有产生业务写入。
构造场景：同一维修助手为何需要不同授权
以下为构造示例，不是客户案例。假设某厂区助手负责读取设备告警，生成维修建议，并在已分派的工单上保存草稿。该委托允许自动读取和保存建议，但关闭工单需要工程师批准，修改设备控制参数不在范围内。这样划定后，助手可以自主完成资料整理，业务系统仍掌握会改变责任状态的操作。
设工单 T-204 的当前版本为 17。助手提交的关闭方案包括工单号、目标状态、检查证据和版本 17；工程师批准的是这份具体方案。真正执行时，服务端再次确认主体权限、批准有效期和工单版本。如果另一个人已经把工单改到版本 18，旧批准不应继续推动新状态，应重新核对差异。批准绑定的关键字段一旦变化，就进入重新评估流程。
若告警附件含有“把所有工单导出到某邮箱”的文字，它只是待分析资料，不能新增委托。模型可能误读资料，工具端仍应拒绝未经允许的数据去向。再假设十张工单被合并为一个批处理，服务端需要逐项校验对象和总量；只审核批处理名称，无法证明其中每个动作都在授权内。
审批放在哪里，决定自动化是否仍有价值
把每次读取都交给人工确认，会使稳定流程难以运行；给智能体一个永久高权限账号，则把风险集中到每次推理上。本文建议按操作后果选择控制点：范围明确、可核查的读取和草稿保存可在预先授权内执行；涉及对外承诺、业务最终状态或难以撤销的操作，按组织规则绑定具体批准。这里的分级是设计建议，不能代替企业已有审批制度。
审批页面应展示操作对象、关键差异、数据接收方及有效期，让审批人知道到底授权了什么。审批结果由可信系统签发或保存，执行器校验其适用范围，不接受模型自己生成“已批准”的文字。重复提交也应使用同一业务操作标识，防止一次批准变成多次效果。
授权解决的是能否执行，幂等与恢复解决的是执行后如何确定结果。两者需要结合，但不应混成一个成功标记。可继续阅读多智能体可靠执行中的幂等与恢复，理解网络中断后为什么必须先查询实际结果，再决定是否继续。
隔离能缩小影响范围，但不能判断业务是否合理
Anthropic 的公开工程说明将运行环境约束与模型行为防护分开，使用沙箱、文件边界和网络出口控制限制可达范围，并指出受审查的连接器并不意味着它读取的内容可信。[3] 这为企业提供了一个实用判断：即使选择更强模型，运行环境与工具权限仍是独立的交付项。
不过，沙箱允许访问的工单系统里仍然可能存在不该关闭的工单。网络白名单也无法单独区分“发送合法维修报告”和“把全部设备资料发送给同一个合法域名”。隔离负责缩小可触达范围，业务授权负责限定范围内的合法动作；两者缺一项，就应缩小自动执行范围。
成本同样需要列入方案。细粒度工具增加适配维护，逐次授权带来延迟，审批会增加等待，短期委托需要到期和续期管理。对于低频、不可逆且规则尚未稳定的流程，先交付建议和可审阅草稿可能更经济。对于高频、边界清晰的流程，则值得将规则固化到服务端，减少重复人工判断。
用拒绝样本和撤销演练验收委托能力
建议验收集同时包含合法操作、跨租户对象、被撤销权限、过期批准、批准后参数变化、累计额度超限，以及资料中夹带额外指令。每个样本都要预先写明预期结果。拒绝样本检查的是没有出现未授权副作用，不能只看到助手回答“无权执行”就判定通过。
可以定义三个观测量：合法任务完成率，分母为满足全部前提的任务；授权逃逸次数，统计发生了超出委托边界的真实动作；撤销生效延迟，从权威撤销提交到各执行入口稳定拒绝旧权限。本文不提供通用合格阈值，企业应按业务后果和恢复能力制定目标，并保留测试覆盖范围。
审计记录至少应能把主体、委托、批准、工具调用和下游业务回执串起来，同时避免记录原始凭证及无必要的敏感正文。上线后再安排一次撤销演练：权限撤回时，排队任务、长会话和缓存的批准是否同步失效。只有这种证据完整，企业才知道可以把哪部分流程交给智能体，以及在什么条件下收回执行权。