Agent 替员工去调系统时，用的是谁的身份和权限

Agent 替员工查数据、调工具时，每次调用都应当带上两个身份：发起请求的员工，以及实际执行动作的 Agent。这就是 Agent 身份要解决的事。它能做的事，取两者的交集：既要在该 Agent 被允许执行的范围之内，也要在发起员工本人的职权范围之内。如果只用一个权限很高的共享服务账号替所有人跑任务，Agent 就可能替权限不够的人拿到越界数据，引发混淆代理问题，而且在后台审计日志里看不出异常。

很多团队接入 Agent 时为了图省事，在后台配一个全局权限的服务账号。业务在前端发提问，Agent 就拿这枚凭证调底层。底层根本不知道是在为谁工作，提问的人间接继承了全局权限。

一个例子说清混淆代理：外包员工问出高管薪酬

混淆代理（Confused Deputy）是自动化流程里常见的一类越权隐患：一个本身拥有合法高权限的服务被恶意或无意利用，代替低权限用户执行了他本人无权执行的操作。

Okta 10 月 8 日介绍了已正式上线的 Agent Gateway。它要求每次工具调用的凭证同时写明发起请求的用户和执行的 Agent，用 RFC 8693 的委托方式换凭证，Agent 能做的事是网关允许范围和用户本人权限的交集。文中举的例子是 HR 助手用一个能读全部员工记录的服务账号，外包人员问 CEO 薪酬也能拿到。

在这个例子中，外包员工在 HR 系统里只能查阅公共考勤制度，无权看高管薪酬。但 HR 助手后台配置的服务账号拥有全库只读权限。当外包员工提问“请汇总高管薪酬”时，数据库验证凭证合法直接放行。Agent 成了替无权人员取数的工具，而审计日志只记着“HR 助手查询了薪酬表”，真正的提问者完全隐形。

只靠提示词约束为什么挡不住越权

有些团队试图在提示词里打补丁，比如在系统指令里写上一句：“不要把薪资信息告诉人事部门以外的人”。

靠自然语言提示词管不住权限。模型遵循指令有概率波动，诱导或注入容易绕过约束；更根本的是，底层凭证把门全打开了。

数据库和接口只校验出示的令牌。只要令牌有全库权限，存储层就会放行。权限控制要落在网关上直接拦截，不能寄托在提示词上。

读写权限与动作分离控制，可参考 Agent 读邮件可以，改日历发信要先批什么。

共享凭证的另一个问题：一撤全断，往往没人撤

在很多企业内部，供 AI 工具调用的服务账号一旦创建，往往会被多个团队的 Agent 共同复用。有的用来跑报表，有的抓工单，有的清洗线索。

Okta 在文中提到，共享凭证一撤会让所有 Agent 断开，所以往往没人撤。一旦凭证出问题想注销，用着它的业务都会报错停下，最后只能一直拖着不处理。

工具调用前要能回答的四个问题

Okta 在文中列了四个问题，用来评估一个 Agent 网关靠不靠谱。企业选网关或自查现有网关时，可以逐条问：

第一，MCP 服务器收到的是什么凭证、谁签发的？落到自查上：凭证要由企业身份提供商（IdP）签发，带数字签名和有效期，不要用写死在配置里的静态密钥。

第二，网关能不能证明这次调用是为哪位用户？落到自查上：网关要能证明调用背后是哪位真实在职员工，不能只挂一个模糊的 Agent 名字。

第三，这个 Agent 访问那台 MCP 服务器，是谁的同意授权的？落到自查上：要能查到这份同意的记录，看清哪位员工对哪台 MCP 服务器同意过；查不到记录的，就当没有授权。

第四，Agent 手里有没有不经过网关也能用的凭证？落到自查上：检查 Agent 本地环境有没有私存直连数据库或接口的密钥，防止绕开网关。

日志要记清：哪个 Agent 替哪个人做了什么

单身份日志只记「服务账号 A 在某时导出了用户表」，看不出是谁让它导的。安全人员分不清这是正常分析还是越权探测。

合规的日志要同时记下两边：终端员工张三，通过销售助手 Agent，调用客户查询接口读取了名单。员工和 Agent 两个标识绑在一起。

处理多智能体协同或办公机器人接入时，审计链路可参考 企业开通 Grok Bot，权限和审计要先定什么。出问题时，靠两个身份就能直接查清发起人和执行路径。

企业落地排查：先查哪几类 Agent 还在用共享账号

第一类是连接敏感数据的查询类 Agent。连着薪酬、财务、客户和核心代码库的助手，优先换掉共享账号，接入网关按提问者权限过滤结果。

第二类是跨部门或面向外包人员开放的公共 Agent。这类工具使用人权限差异大，用统一账号容易越权，要改成身份委托。

第三类是带写入、改状态或调资金权限的执行类 Agent。改数据、发通知或走审批的操作，都要核对发起员工的权限，并记全两个身份的日志。

Agent 身份：常见问题

终端员工已经在前端通过了身份登录，为什么后端接口还会丢失用户身份？

前端会话通常只停留在用户和网关之间。Agent 去调微服务或数据库时，很多系统没传员工身份，而是拿全局服务账号发请求。员工身份在后台断掉了，后端只收到一个通用的机器令牌。

采用双身份取交集的鉴权模式，会不会导致系统响应延迟明显增加？

合理的身份委托不会明显变慢。网关一般用 OAuth 换令牌，初次置换后会在有效期内做短期缓存。换令牌的时间通常远短于大模型生成内容的时间，上线前测一下就能确认。

企业如何规范员工对个人 AI 工具的代理授权？

代理授权先由管理员登记：哪些 Agent 可以替员工调用哪些系统。员工只能对登记过的 Agent 做代理授权，不要把自己的企业账号授权给没审查过的外部 AI 工具。Agent 停用或员工离开时，把对应的代理授权一并收回。