机器人礼貌犯错背后的身份危机

部署WorkBuddy类Agent时，常见一个诡异现象：机器人能准确执行指令却总把结果发给错误的人。某制造业客户反馈，其物料审批流程中，Agent将采购总监的钢材订单确认函发给了同名的车间班长——只因两者在IM系统里displayName相同。这类「礼貌而精确的错误」暴露出Agent网关在身份主键（Primary Identity Key）设计上的致命盲区。

身份主键的四种战场

1. 用户ID映射表不是银弹

多数团队第一反应是建立用户ID映射表，但现实往往更复杂： - 跨系统生命周期不同步：HR系统已注销的账号在Slack仍存活48小时 - 同名用户碰撞：ActiveDirectory的zhangsan与钉钉的张叁实为同一人 - 临时身份逃逸：访客通过临时Token调用工具后未被及时回收权限

2. 主身份源的选型陷阱

选择主身份源时需权衡：

# ClawHub典型配置对比
identity_source:
  - type: "LDAP"   # 权威但延迟高
    sync_interval: 15m
  - type: "IM"      # 实时但不可信
    fallback: true
  - type: "HRIS"    # 真实但接口脆弱
    timeout: 8s

3. 离职链路的自动化缺口

审计发现，83%的权限泄露事件源于： - 离职流程中IAM系统吊销了AD账号 - 但WorkBuddy的本地缓存未收到Webhook通知 - 遗留的API Key继续活跃了72小时

工程化解决方案

四层防御架构

1. 统一事件总线
2. 将HR事件（入职/转岗/离职）通过ClawBridge广播到所有子系统

3. 强制要求IM/邮件等系统返回ACK确认

4. 动态身份解析器

5. 实时查询时组合多种身份源

6. 采用类似DNS的TTL缓存机制

7. 沙箱内的强制代答

8. 当身份不明时，要求Agent必须返回： "请通过企业微信重新认证您的工号"

9. 禁止继续执行工具调用

10. 审计归因增强

11. 在日志中同时记录： { "raw_identity": "zhangsan", "resolved_employee_id": "E20489" }
12. 与VPN日志做关联分析

实施检查清单

• [ ] 验证HR系统与IM的账号停用时间差
• [ ] 测试同名用户在审批流程中的区分度
• [ ] 部署身份解析器的熔断策略
• [ ] 建立身份事件的死信队列监控

血的教训

某金融客户因未处理身份映射，导致Agent将年薪调整指令执行给了同名实习生。事后分析发现： - 企业微信返回的user_id与OA系统不一致 - 但工具调用时只校验了是否存在该ID - 沙箱未对薪酬类操作设置二次确认

技术落地细节

身份解析器的实现要点

1. 权重策略
2. 主身份源（如HR系统）权重设为100
3. 次级源（如IM）权重设为60

4. 当差异超过阈值时触发人工审核

5. 缓存失效设计

   # ClawSDK示例：带优先级的缓存刷新
   def refresh_identity(user_id):
       primary = get_hr_record(user_id)  # 同步阻塞调用
       publish_event("identity/update", {
           'user': user_id,
           'primary_source': primary
       })  # 异步通知其他系统
       return primary if primary else get_im_fallback(user_id)

6. 测试用例覆盖

7. 模拟HR系统延迟响应（>5秒）时的降级行为
8. 构造同名不同部门用户的冲突场景
9. 测试离职员工Token在缓存过期前后的API调用

权限边界设计

最小权限沙箱规则

1. 工具调用分级

1. 横向移动防护
2. 禁止Agent用已认证身份代理其他用户操作

3. 所有跨部门数据请求必须经过ClawHub审计通道

4. 紧急熔断机制

5. 当检测到异常身份切换频率时（如5分钟内切换10次）
6. 自动锁定账号并触发安全工单

这提醒我们：Agent的身份安全不是功能开关，而是需要从网关路由到工具协议的全链路设计。下次当你的机器人又「彬彬有礼」地犯错时，不妨先检查它的身份证到底是谁颁发的。建议定期进行红蓝对抗演练，特别要模拟主身份源不可用时的故障转移场景。