客服 Agent 代客户查订单
晚上十点四十，李雷在 App 里问客服："我上周买的咖啡机到哪了？"人工客服早就下班了，接待他的是客服 Agent。要回答这个问题，Agent 得进订单系统，查李雷的订单——注意，是李雷的，而且只能是李雷的。
客服负责人苏青对这件事的担心比谁都具体。传统客服系统揣着一个万能服务账号，能查全库所有客户的订单——人工客服时代，这个口子靠坐席培训和抽查兜着。Agent 接进来之后，性质变了：Agent 的输入来自任何一个陌生客户，一句精心构造的话（提示注入）就可能诱导它去查别人的订单、别人的地址、别人的手机号。苏青要的不是"相信 Agent 不会出错"，而是一个硬边界：Agent 替李雷干活时，能看到的天花板就是李雷自己的数据。
流程
答案是把授权主体从"系统"换成"这位客户本人"。李雷发起会话时完成一次授权确认，Agent 拿到的是以李雷为主体的委托令牌（Delegate Token）——资源侧校验的不再是"这个服务账号行不行"，而是"这条数据归不归李雷"。图中 ①–⑦ 是全流程跳号，与一次委托的完整旅程一致，本页截取 ②–⑥：
C 端场景怎么读这张图
在 C 端场景里，User 泳道就是你的终端客户；Human IAM 泳道对应你的客户身份体系。"人的真实权限"在这里有个朴素的含义：李雷本来就只能看李雷自己的订单——委托给 Agent 的权限，天花板不会高过这一条。
三个关键时刻
- 授权确认（Consent）：李雷的对话窗口里弹出一张授权卡片："允许客服 Agent 以你的身份查询你的订单，仅限查询，有效期 30 分钟。"李雷点"允许"，查询才开始。他不需要懂 OAuth——授权的主语是他自己，这就够了。整个环节发生在会话里，不打断体验。
- 审计记录：这次查询带着一条 audit_id 落进审计链：谁授权——李雷（终端用户）；以谁身份——李雷，由客服 Agent 代表行动（on-behalf-of）；做了什么——查询订单接口，命中 1 条，只读。更重要的是反面：如果 Agent 被诱导去查询不属于李雷的数据，资源侧按
sub=李雷校验直接拒绝，拒绝本身同样留痕——安全团队看到的不是一次悄无声息的越权，而是一条报警线索。 - 吊销：会话结束、客户投诉、或者风控发现异常，都可随时吊销授权，之后新的令牌申请不再被受理；已签发令牌的失效时效见吊销与应急处置。常态下无需任何人动手：30 分钟一到，令牌过期，授权自动归零。
本场景用到的能力
| 能力 | 在本场景中的作用 | 深入阅读 |
|---|---|---|
| 委托模式（on-behalf-of） | 令牌主体是客户本人，不是万能服务账号 | 三种访问模式 |
| 用户级授权确认（Consent） | 客户在会话内一句话看懂、一次点击授权 | Consent 与审批 |
| 缩权（attenuation）与令牌兑换 | 只读、只查订单、只在 30 分钟内 | Delegate Token 与缩权 |
| 资源侧校验 | 订单接口按 sub/act/scope 交集把数据边界焊死 | 让 Agent 代表用户调用你的 API |
| 审计链 | 每次查询——包括被拒绝的——都可追溯 | 审计与追责链 |
下一步
- 场景：员工数据助手——同一套机制在企业内部的样子
- 上手：让 Agent 代表用户调用你的 API——把你的订单接口接进这条链路
- 概念：Consent 与审批——三种"人说了算"的时刻