企业智能体向下游系统传递员工身份实战：身份代持、Token 交换与权限隔离
针对企业落地 AI Agent 对接 ERP、OA、CRM 等业务系统时普遍存在的混用后台全局超级账号、破坏数据行级权限与审计合规的顽疾，深入解析 RFC 8693 OAuth 2.0 Token Exchange 与 On-Behalf-Of（OBO）委托机制，探讨短期范围收窄、老旧系统身份代理映射、长流程凭证续期与链路审计防篡改的完整落地方案。
随着企业 AI Agent 从单一的只读问答知识库，演进为能够代表员工操作 ERP 报销、发起 OA 审批、调用 CRM 变更合同的高权限行动系统，智能体如何向下游业务系统证明“我是代表哪位具体员工在执行操作”成为了企业安全合规的生命线。许多团队在概念验证（POC）阶段为了走通链路，简单地为智能体配置了一个拥有高权限的全局服务账号（Service Account），由智能体统一代发所有写入与查询请求。然而，这种“特权账号包办”的做法在进入企业生产网后，会瞬间击穿企业原有的数据行级权限控制、抹杀审计合规追踪链，并带来灾难性的横向越权风险。本文深入剖析基于 RFC 8693 OAuth 2.0 Token Exchange 与 On-Behalf-Of（OBO）模式的智能体身份穿透架构，探讨范围收窄、旧系统代理映射与全链路审计的工程落地路径。
为什么不能混用“全局超级服务账号”代替员工身份
在传统的系统集成场景中，两个机器服务（Service-to-Service）之间常用客户端凭据模式（Client Credentials Flow）获取一个全局服务账号 Token 进行通信。但当调用发起方是企业员工、中间由 AI Agent 进行自然语言意图理解并编排工具调用时，这种模式暴露出不可调和的安全矛盾：
| 安全维度 | 混用全局服务账号（反模式） | 员工身份穿透与代持（标准架构） |
|---|---|---|
| 行级权限与隔离 | 权限完全击穿：服务账号通常具备跨部门或全量数据读写权，普通员工可通过 Prompt 诱导智能体查询其他部门或高管的薪酬与合同。 | 严格继承员工上下文：下游 ERP/CRM 系统直接根据换取的员工身份 Token 执行行级权限过滤（RLS），员工看不到的数据智能体同样查不出。 |
| 业务操作责任与审计 | 责任主体湮灭：ERP 系统的创建人与修改人全部记录为“svc_bxagent_bot”，无法确认真实审批或下发采购单的责任人。 | 双重主体可追溯：操作日志同时记录主叫员工身份（Actor/Subject）与代持执行者（Delegated Client），符合金融与等保三级审计要求。 |
| 凭据泄露爆炸半径 | 灾难性全局失陷：一旦智能体服务器的私钥或服务账号泄露，全站业务数据与操作指令任由攻击者滥用。 | 极小化受限生命周期：针对单次会话签发 5~15 分钟超短期 Token，且 Scope 严格收窄至目标单据操作，泄露即作废。 |
因此，零信任架构（NIST SP 800-207）明确要求：在多跳服务调用中，必须沿调用链持续保持初始调用主体的身份上下文，严禁在中间网关层发生无受控的“身份提升（Privilege Escalation）”。
RFC 8693 Token Exchange 与 On-Behalf-Of 委托机制
为了在不泄露员工原始密码或长效刷新令牌（Refresh Token）的前提下，让智能体具备合法代表员工调用特定下游 API 的能力，国际互联网工程任务组（IETF）制定了 RFC 8693 OAuth 2.0 Token Exchange 规范，微软身份平台亦将其工程化为 On-Behalf-Of（OBO）流程。
【核心流程】AI Agent 代表员工向下游系统申请 Token 的握手步骤：
- 前端员工认证：员工通过企业统一身份认证（IDP，如 LDAP/OAuth2/OIDC）登录智能体对话界面，前端获得受众为智能体平台的 Access Token（Token A）。
- 意图识别与工具决策：大模型分析员工意图，判定需要调用 ERP 系统的
create_purchase_requisition工具。 - Token Exchange 交换请求：智能体服务端向企业授权服务器（Authorization Server）发起标准 RFC 8693 请求，携带 Token A 作为
subject_token，并声明目标受众（Audience）为 ERP 系统。 - 授权服务器校验与签发：授权服务器验证 Token A 有效性、验证智能体客户端的委托权限，签发出一个受众明确为 ERP 系统、主体为该员工的短期 Token B。
- 工具受权执行：智能体携带 Token B 调用 ERP API，ERP 系统识别到当前调用人为该员工，完成行级鉴权并记录审计。
在 Token Exchange 请求中，参数构造必须遵循标准规范，明确主体类型与目标受众边界：
POST /oauth2/v2.0/token HTTP/1.1
Host: idp.enterprise.internal
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&client_id=bxagent-orchestrator-client
&client_secret=SEC_AGENT_SECRET_KEY
&subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI...（员工原Token A）
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https://erp.enterprise.internal/api/v1/
&scope=erp:purchase:create erp:budget:read
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
通过该机制，换取到的下游 Token 拥有独立的受众（Audience）标识，即便该 Token 意外泄露，攻击者也绝不能将其拿去调用 CRM 或财务报税接口，从而严格隔离了跨系统横向越权风险。
最小权限原则：向下游请求短期且范围收窄的 Token
在向授权服务器申请下游令牌时，企业智能体平台必须严格践行最小权限原则（Least Privilege）。即使员工本人在 ERP 系统中拥有“财务主管”的全量高级权限，智能体在单次工具调用中也绝对不应申请全量 Scope：
【设计避坑】范围收窄（Scope Downscoping）与生命周期管理：
1. 按工具定义精准收窄：当大模型仅仅需要查询物料库存时，工具网关在发起 Token Exchange 时必须只请求 erp:inventory:read 权限，坚决剔除任何 erp:inventory:write 或 *:admin 权限。
2. 极短有效期与无续期策略：工具级 Token 的有效期应当设置为 5 到 15 分钟。此类 Token 坚决不发放 Refresh Token；单次任务执行完毕即任其自然过期，避免在智能体内存中长久滞留凭据。
3. 载荷声明委托人（Delegation Claim）：授权服务器签发下游 Token 时，内部 JWT Payload 应包含 act（Actor）声明，明确标注 "act": {"client_id": "bxagent-bot"}，让下游网关既能看到主叫员工，又能看到执行代理。
一个标准的代持 JWT 载荷结构如下所示：
{
"iss": "https://idp.enterprise.internal",
"sub": "emp_9527_zhangsan",
"aud": "https://erp.enterprise.internal/api/v1/",
"exp": 1792264500,
"nbf": 1792263900,
"scope": "erp:inventory:read",
"act": {
"client_id": "bxagent-orchestrator-client",
"service_name": "BaiXin-AI-Agent-Core"
},
"department_code": "DEPT_LOGISTICS_NORTH",
"cost_center": "CC-8802"
}
下游 ERP 网关收到请求后，解析 sub 字段获取实际业务操作人张三，解析 scope 确保只具备只读权限，同时比对 act 确认调用来自已备案的合规智能体集群。
面向非现代认证系统（旧版 ERP/数据库）的“身份代理映射”
在企业信息化建设的真实落地环境中，许多核心生产系统（如早期定制开发的 MES、老版本用友/金蝶 ERP、自建主机系统甚至直连数据库）根本不支持现代 OAuth 2.0 或 JWT 验证，仅支持 Basic Auth、固定的 Session 或者是简单的数据库连接串。此时，直接要求全厂重写底层系统鉴权是不现实的。
针对这一普遍痛点，百信推荐采用“企业智能体身份映射代理（Identity Broker Gateway）”方案：
【工程方案】面向老旧业务系统的身份代理层设计：
- 统一接收现代 Token：智能体平台调用老旧系统前，统一向部署在企业内网的安全代理网关发送带有员工代持 JWT 的受控请求。
- 安全安全密匣与映射引擎（Credential Vault）：代理网关部署在安全专区，内部对接企业 HashiCorp Vault 等凭据管理系统，维护“企业主工号 ➔ 老系统本地账号/工号”的严格映射白名单。
- 动态凭据置换或请求头注入：代理网关校验 JWT 签名与有效期无误后，将员工对应的旧系统凭据（或专用的员工子账号密码、受控 Header）安全注入后转发给老系统，并在响应返回时剥离敏感信息。
- 严禁直连数据库写操作：对于只能直连数据库的场景，必须通过只读数据库中间件配置“应用用户会话变量（如 PostgreSQL
SET LOCAL app.current_user_id = '9527'）”，配合行级安全策略（RLS），严禁智能体程序使用根账号（root/dba）拼接未校验的 SQL。
通过这层代理屏障，企业不仅无需对陈旧业务系统进行伤筋动骨的改造，还能将老旧系统的安全等级强行拉升至现代零信任与细粒度审计基准线之上。
异步长流程与定时任务下的身份生命周期与降级保护
在复杂的企业业务流中，智能体执行的任务并不都是数秒内完成的即时对话。例如“跨部门大额采购审核、批量报表异常诊断、夜间数据对账”往往跨越数小时甚至需要等待多方人工审批。在此类异步长流程场景中，员工在前端最初颁发的 Token 势必会过期，处理策略至关重要：
| 任务形态 | Token 过期风险 | 标准化治理策略 |
|---|---|---|
| 人机交互中途等待（< 30分钟） | 中低：前端静默无感知，会话可能中断。 | 静默前端刷新与会话保活：前端通过标准的 Silent Refresh 机制在背景完成 Token 轮转，并将更新后的 Access Token 附着在后续对话上下文包中。 |
| 异步长事务（1 ~ 24小时） | 极高：员工关闭电脑或下班离线，Token 必然彻底失效。 | 状态挂起（Suspension）与再唤醒：当长事务进行到必须写入关键业务系统的阶段时，若 Token 已过期，智能体不盲目代签，而是将任务持久化为 AWAITING_USER_CONFIRM 状态，通过企业微信或飞书发送卡片，员工点击确认后重新签发有效 Token 推进后续流程。 |
| 系统定时巡检任务（Scheduled Jobs） | 不适用：无特定主叫员工在线。 | 受限系统服务账号 + 最小特权白名单：定时任务明确声明为 system_scheduled_audit 身份，仅赋予预定义的只读巡检 Scope，坚决不冒充任何真实人类员工身份。 |
严格区分“即时交互代持”与“离线定时任务”，绝不通过将员工凭据永久明文保存在 Redis 中来换取所谓的“离线自动化”，这是守护企业信息安全底线的基本铁律。
穿透全链路的行级权限隔离（RLS）与不可否认性审计
当员工身份成功透传至下游各微服务后，系统必须在数据存储层与审计日志层实现真正的业务闭环：
1. 数据存储层：行级安全过滤（Row-Level Security）：
下游业务系统的数据库（如 PostgreSQL 或自建数据服务）应当启用 RLS。以物料库存表为例，查询策略直接绑定当前传入的员工部门上下文，从物理层杜绝数据外溢：
-- 在下游物料服务中配置行级安全策略（中文注释示范）
ALTER TABLE enterprise_inventory ENABLE ROW LEVEL SECURITY;
-- 仅允许员工查询自身所属厂区或受权成本中心下的物料记录
CREATE POLICY inventory_department_isolation_policy ON enterprise_inventory
FOR SELECT
USING (
workshop_code = current_setting('request.jwt.claim.department_code', true)
OR current_setting('request.jwt.claim.scope', true) LIKE '%inventory:admin%'
);
2. 审计治理层：全链路不可否认性日志（Non-Repudiation Audit）：
每一次智能体发起的工具调用，其产生的审计事件必须记录在不可篡改的日志中，形成三位一体的审计证据链：
- 操作发起人（User Subject）：明确记录发起会话的员工真实工号、姓名与所在部门；
- 智能体执行代理（Agent Actor）：明确记录当前负责推理决策的 Agent 实例编号、大模型版本号与系统提示词指纹；
- 调用上下文字段（Trace Context）：附带分布式调用链路 ID（TraceID）、大模型决策理由（Rationale）以及下游返回的单据流水号。
在面对外部审计或安全复盘时，企业技术团队能够清晰证明：“该张采购订单是在某年某月某日，由员工张三向智能体发出指令，智能体基于 ERP 只读数据完成校验，通过 OAuth Token Exchange 获取短期凭证后，以张三的名义正式创建，调用链全程受控且无任何越权行为。”
参考标准规范与落地适用边界
企业智能体身份穿透与下游鉴权架构的设计，依托于国际公认的工业级规范与零信任实践体系：
【权威参考资料与落地标准】
- IETF RFC 8693：OAuth 2.0 Token Exchange 官方技术规范，定义了跨信任域的身份置换、委托模式（Delegation）与代持（Impersonation）标准数据结构。
- NIST Special Publication 800-207：Zero Trust Architecture（零信任架构指南），阐述微服务间调用应遵循的端到端主体身份验证与最小特权委托要求。
- Microsoft Entra ID 官方架构指南：Microsoft Identity Platform On-Behalf-Of (OBO) flow 工程实践规范，详细说明了多层 Web API 委托传递的生产级处理方案。
- OWASP Top 10 for Large Language Model Applications：LLM06 敏感信息泄露（Sensitive Information Disclosure）与 LLM07 不安全插件设计（Insecure Plugin Design）防护指引。
适用边界与技术选型建议：
本文所述的 RFC 8693 Token Exchange 与严格行级隔离机制，高度适用于企业核心生产流程、高敏财务审批、供应链系统对接与受监管行业（金融、政务、制造高端制造）的智能体深度应用。对于企业内部仅用于知识检索、公开发布内容整理或无写操作的轻量化助手，可适度精简中间授权拓扑，但依然应当坚守“拒绝全局超管账号直连核心数据库”的底线思维。百信 AI Agent 平台通过提供开箱即用的私有化安全网关与标准化 Token 交换适配插件，助力企业在充分释放大模型自动化生产力的同时，守牢企业数据与身份资产的钢铁防线。
