先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
批准对象与执行时授权
在工具执行边界落实权限检查，把审批绑定到不可变参数及资源版本，拒绝提示词注入扩大授权。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 批准对象与执行时授权
先理解核心原理
先备概念：业务授权、不可变版本、参数规范化
批准必须指向确定的动作语义与内容，执行还必须满足当前权限。身份认证、模型建议和历史批准都不能自动证明此刻可以对该资源执行该动作。
为什么需要确定的批准对象
后端授权常写成主体、资源、动作三元组。Agent 额外生成参数，若只存“同意执行”，随后把金额或收件人改掉，批准就失去对象。先完成格式与业务校验，形成包含工具版本、有效参数、目标与资源版本的不可变提案，再展示和批准同一份提案。
哈希不是授权本身
摘要可检查内容是否变了，但不能证明审批人有权批准，也不能证明权限未撤销。执行网关检查身份、批准范围、有效期和资源状态；批准后内容改变需要重审。跨服务检查与提交存在竞态时，应在最终业务服务使用版本条件或能力约束，而不是宣称单次检查永久安全。
确定序列化先有业务含义
金额宜用最小货币单位整数或明确十进制字符串，默认值在签摘要前显式落实，规范化算法要跨端一致。JCS 是可选技术依据，并不自动决定金额舍入和默认策略。下面的提案结构是工程建议，未验证完整审批系统。
用一个问题检查理解
Agent 可以调用写入工具，怎样防止越权与审批后参数被修改？
模型只提出动作，服务端执行器决定能否执行。我会用可信会话确定用户和租户，校验资源权限与工具参数；高风险写入先产生不可变提案，审批绑定参数摘要、资源版本、有效期和审批人。执行前重新检查权限与版本，变化就重新审批。工具返回的文本作为数据处理；OAuth、提示词和模型判断都不能代替业务授权。
实现与取舍
在执行器检查权限
工具 schema 只约束参数结构。真正执行写入时，从可信登录会话取得 actor_id 与 tenant_id，不接受模型自行指定租户。执行器按动作、资源及字段校验权限，再用限定租户的查询读取目标；搜索和检索也必须应用同样范围。低风险读取可以直接执行，发布、删除与资金动作按业务策略进入审批。授权失败应明确返回可处理错误，不能自动换工具绕过。工具列表可以按身份缩减，但执行器仍需再次检查。
审批绑定具体提案
先持久化 action_id、规范化参数、参数摘要、资源版本、提案人和有效期，审批页面展示实际将发生的变化。审批记录绑定这一提案，执行器读取已批准的原始参数，不使用模型后来重新生成的值。执行前重新检查当前权限、提案状态与资源版本，采用事务或条件更新保护版本判断；若参数或目标变化，产生新提案。人工审批并不提供外部写入幂等性，还需稳定业务幂等键和可查询结果。
协议授权不等于业务授权
MCP 的 Authorization要求服务端验证令牌是否发给自身。其 Security Best Practices解释 token passthrough 风险；不能把发给其他资源的 token 原样接收再转交下游。即使 OAuth 通过，服务端仍需判断用户是否能编辑这篇文章或这个账户。第三方网页、文档和工具响应可以包含恶意指令，它们只属于待处理数据，不获得新增权限。
用恢复和攻击场景验收
采用 LangGraph 时，interrupt可暂停并保存状态，恢复时节点会重新执行，因此将审批前逻辑设计为无副作用，不能先写入再等待审批。验收覆盖跨租户资源编号、伪造管理员参数、过期审批、批准后修改参数和重复点击执行。额外放入一段要求上传密钥的检索文本，检查执行器能拒绝。审计保存判定依据、提案摘要和执行结果，避免把密钥本体写入审计。安全取舍是让普通读取保持流畅，同时对具有实际后果的动作给出可核对的提案。
工程推演
- 场景
- 假设工程场景：内容 Agent 生成文章并请求发布，审核人在等待期间修改了目标文章。
- 设计决策
- 发布审批绑定文章内容摘要与当前版本，执行前采用版本条件检查。
- 验证目标
- 预期行为是旧审批不能覆盖新文章，转为重新审核；这是设计验收条件，未声称已上线实验。
- 适用边界
- 审批只能证明具体动作得到授权，不能保证文章事实准确，仍需内容质量验证。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层审批通过后资源权限被撤销，执行器应如何处理？
批准与执行之间存在时间，因此当前权限可能变化。
参考解答
停止执行并记录撤销原因。批准不替代当前授权；重新验证主体、目标和动作，必要时重新申请权限与批准。若权限检查与目标写入分离，还应使用目标方条件更新或短期受限凭证约束竞态，明确可接受传播窗口。
第 1 层参数规范化时浮点数、键顺序和默认值如何处理？
摘要比较依赖参数的唯一表示，必须说明业务规范化。
参考解答
先解析和拒绝歧义输入，再固定业务表示：金额避免浮点舍入，默认值在提案生成时展开，未知字段按规则拒绝。对象键采用一致规范化，数组顺序按业务保持，保存算法及工具版本；审批展示与执行使用同一规范提案。
沿着这个回答继续深入
第 2 层默认收件人由工具升级改变，原参数没有这个字段，旧批准能继续用吗？
父问固定规范表示，子问让未显式字段在版本升级后改变。
参考解答
不能直接继续。默认值属于实际动作语义，应在旧提案中明确展开并绑定工具版本；若无法恢复旧语义，重新提案并批准。只比较用户显式输入会漏掉默认行为变化。
沿着这个回答继续深入
第 3 层规范化摘要相同，但执行目标被 DNS 或重定向换掉，批准仍有效吗？
父问考察默认语义，继续检查参数之外的实际执行目标。
参考解答
摘要只绑定它包含的对象。网关还需验证实际目标身份、允许地址与重定向策略，敏感动作使用受控连接和目标服务授权。不能把 URL 字符串相同当服务器相同；无法确认目标时拒绝发送并记录原因。
第 1 层对外服务不支持幂等键时，超时后怎样决定是否重试？
安全写入还涉及批准之后的未知执行结果。
参考解答
先保存业务标识并查询目标回执，得到已执行就补本地状态，可信未执行才讨论重试。无法去重且无法核对时保持未知并转人工，不能因为超时就换新请求。是否允许重复效果必须由业务决定，不能由模型猜。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
从发草稿改为正式发信
改变的条件：动作从本地可改产物变成外部传播。
延伸问题：原“批准报告”能覆盖发信吗？
推导与参考解答
不能自动覆盖。新提案需列明收件人、内容版本、附件和发送目的，批准范围明确包含发信，再执行当前权限和目标验证。草稿批准只说明内容阶段被认可；外发是独立动作。
保持不变的原理：批准范围与真实动作语义必须一致。
审批等待数天
改变的条件：权限、订单状态与工具版本可能已经变化。
延伸问题：只检查批准未过期够吗？
推导与参考解答
不够。核对资源版本与业务条件，检查审批人和执行者当前权限，必要时重生成并批准。任务恢复不能绕过最终网关；等待时间越长，旧状态失效概率越高，需要明确有效期和再确认规则。
保持不变的原理：批准对象固定，执行条件以当前事实为准。
易错点
- 只写一句“不要越权”作为权限控制。
- 审批记录只保存“同意”，没有绑定实际参数和资源。
- OAuth 验证通过后跳过租户及资源级授权。
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 执行前独立校验权限，危险动作需要批准。
- 中高级信号
- 批准绑定身份、动作摘要、版本和有效期。
- 资深信号
- 覆盖参数变化、撤销、回放、竞态与实际副作用验证。
动手验证 按需完成 · 建议 15 分钟
在批准后更改收件人，推演执行网关应如何处理。
展开验收要求与检查点
- 旧批准不能覆盖新接收人
- 服务端核验可信批准
- 重复回调不重复执行
重点检查
- 能将用户身份、租户范围与资源权限放在服务端，而非依赖模型参数。
- 能处理审批到执行之间的参数变化和资源变化。
- 理解 MCP 授权、业务授权及人工审批的不同边界。