模型需要查订单，为什么不该直接拿到管理员密码？

模型需要查订单，为什么不该直接拿到管理员密码？

知道你是谁，不等于允许你做所有事

用户让助手查询订单A123是否发货。服务端需要知道请求来自哪个运行、哪个用户或工作负载，这叫身份；还要判断它是否能读这个订单的发货状态，这叫授权；访问令牌或密钥是证明身份或携带权限的凭据。三者相关，但不能混成“有密码就什么都能做”。

如果把管理员密钥直接放进模型上下文，助手可能有能力删除订单、导出全库或修改支付信息。即使密钥隐藏在工具后端、模型看不到明文，若这个工具允许任意管理员操作，能力仍然过宽。隐藏秘密解决的是泄露面的一部分，不自动解决请求权限。

对于这个任务，合理能力可以是：运行R17代表用户U，读取属于U的订单A123的发货字段，在任务有效期内使用。它不包含读取其他用户订单、不包含修改地址、不包含删除记录。资源范围、操作范围、字段范围和持续时间都可以成为授权条件，具体实现由服务端能力决定。

短期凭据能减少任务结束后继续使用的时间，但到期不是唯一条件。运行被取消、用户撤销、目标资源归属变化时，也可能需要立即拒绝。令牌签名正确只表示它由可信签发者发出，并不意味着它对任何资源、任何时刻都有效。

一种结构是模型只生成结构化请求：查询A123的发货状态。执行器连同运行ID把请求交给凭据代理。代理查到该运行的权限范围，核对身份、动作、资源和有效期，通过后才使用服务器保存的凭据访问订单服务，并记录独立审计事件。模型拿到的是结果或拒绝原因，不是管理员秘密。

这里有一个细节：不能让模型随意填写另一个运行ID就继承权限。运行身份应由可信运行器绑定，用户可控参数不能直接覆盖它。资源标识也要规范化，防止检查的是一个路径、执行时却解析到另一个对象。授权检查和最终服务调用要围绕同一个确定的目标。

观察过程 · 改变条件

先预测结果，再逐步查看；切换条件时留意是哪一个中间量改变。案例是教学构造的规则回放，不是模型训练实测。

教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。

这一轮的输入

R17只可读取用户U订单A123的发货状态

绑定身份

运行器提供R17，模型不能任意替换。

1 / 3

先预测，再核对结果与原因

查询完成，凭据不进入模型上下文。

最小权限仍足以完成用户任务。

第一，动作从读取改成删除，但订单仍是A123。资源相同并不意味着权限相同，代理应拒绝删除，并返回“该运行仅具备发货状态读取权限”。助手可以解释没有执行，继续提供已获取的合法信息。不能把这次拒绝当临时错误无限重试，或者换一个工具名尝试相同效果。

第二，动作仍是读取，资源改成其他用户的订单B456。操作相同也不意味着允许跨资源访问。服务端应根据实际归属检查，而不是因为请求字符串格式正确就通过。只验证API schema能防参数类型错误，不能替代业务授权。

对于确实需要写入的任务，确认应显示目标资源、变更内容及可能副作用，让用户批准明确操作。用户确认“更改A123地址”不等于批准下一条删除订单请求；确认结果应绑定动作参数或稳定标识。如果等待确认时目标状态变化，执行前还需检查是否仍适用。

这不是要求每次只读查询都打断用户。已有授权范围内的操作可以继续；需要确认的是实际越过范围的动作。合理系统让边界明确，避免既给宽泛管理员权限，又用大量无关确认弹窗补救。

准备同一身份下的允许读取、禁止删除、禁止跨用户读取、到期后读取四个测试请求，检查服务是否产生对应副作用，不能只看模型回复。审计日志应记录运行、资源、动作、允许或拒绝及原因，同时避免把秘密写进日志。下一课讨论监控如何利用这些事件，区分真正危险动作与仅仅听起来可疑的文字。

问题 1

模型看不到API密钥就没有过宽权限了吗？

展开解释

不是。隐藏密钥的工具仍可能允许任意管理员请求，必须在执行边界检查可做的动作和资源。

问题 2

能读A123是否意味着能删A123？

展开解释

不意味着。资源相同但动作不同，读取与删除需要各自授权。

问题 3

API参数格式正确为何仍可能拒绝？

展开解释

schema只说明结构有效，不说明用户拥有该资源或该操作权限。业务授权要单独验证。