研报速递
一名券商员工，在企业微信工作台里打开了员工智能体，问了一句：
「查一下我名下有多少营销关系的客户。」
智能体随即去查 CRM。在看似自然的一问一答背后，有一个问题必须先回答：这个 Agent，是以谁的身份去访问的？
这个问题不解决，智能体就很可能越权读到本不属于提问人的数据。对券商来说，这一条足以让项目停在评审阶段。
该券商与派拉软件的合作，正是围绕这个问题展开：为智能体建立独立的机器身份，把员工身份安全地传递到业务系统，并在全程留下可追溯到人的记录。
PART 01
上线前的三道身份关：权限、追溯与凭据
金融机构把智能体接入内部业务系统时，身份层面普遍会撞上三堵墙：
权限放大：一个账号看到所有人
给智能体配一个共用的服务账号最省事，但这个账号往往在业务系统里权限很大。员工通过智能体，就能看到本不属于自己的数据——企业辛苦建立的权限边界，在智能体这一层失效了。
责任不可追溯：出了问题不知道是谁发起的
业务系统日志里只有一个服务账号，无法区分这次查询是哪位员工发起的。谁在什么时间、以什么身份访问了什么，审计时缺少可核对的技术依据。
交账号密码：突破安全底线
让员工把自己的账号密码交给智能体代为登录，等于把凭证交给了中间层。这既不符合券商的安全要求，也让凭证本身成了新的暴露面。
这三关不是选一关过，而是必须同时过：只解决了权限、没解决追溯，审计依然无从核对；只解决了追溯、没解决权限，智能体仍然能看到不该看的数据。
共用账号和交密码，这两条路都走不通。该券商走了第三条：让智能体以提问员工本人的身份访问 CRM——CRM 返回的，就是这位员工按自己权限能看到的数据。
PART 02
监管其实已经把话说明白了
这三关不是行业自己的焦虑。翻监管文件会发现，「身份越权」不是本文的修辞，而是原文。
「身份越权」，是金监局文件里的原词。
2025 年 4 月，证监会科技司在证券行业人工智能发展研讨会上，把「身份伪造」与模型篡改、算法漏洞、数据泄露并列，列为行业必须防范的风险。
也就是说，监管已经认定智能体身份是个真问题，但专门针对智能体凭证与密钥的成文细则，目前还没有。
细则留白，不等于可以等。评审现场没人会拿「细则还没出」当免责理由，只会问一句：你的智能体，是以谁的身份访问 CRM 的？
把监管要求摊开，这套方案要答的其实是四道题。
这也解释了一件事：为什么这个项目只接了 CRM 一个系统，却值得单独写一篇。它验证的不是「接得通」，而是「接得住」。
PART 03
架构设计：智能体、员工与业务系统之间的「身份接力」
本项目的核心解法，一句话：智能体本身不持有任何长期凭据，员工身份在调用链路上逐段传递、逐段收窄，最终由业务系统按员工本人的权限返回数据。
整个方案分三层：
入口层（企业微信 + 员工智能体，该券商自研）：员工进入智能体，智能体负责理解问题、调用工具，并已完成员工登录认证——它知道此刻提问的是谁（企业微信用户标识）。
平台层（核心枢纽）：三个组件配合。NHI（Non-Human Identity，非人身份）为智能体所在的运行环境签发机器身份证书，相当于一张不可伪造、到期自动更换的电子工牌；请求发出时证书自动附加，智能体代码里不存任何密钥。STS（安全令牌服务）核验调用方身份后，签发「代表某位员工」的短期令牌。Ditto（工具网关）把业务接口封装成智能体可调用的工具，并把员工令牌换成业务系统认可的登录会话。
落地层（该券商已有系统）：IAM（该券商已有的统一身份平台）用员工令牌换出该员工的访问令牌；CRM 不做任何改造，沿用原有登录与权限体系。
一次提问，身份走过的六个环节
1、员工提问：员工在企业微信里已完成登录，智能体知道当前是谁在发问。
2、申请令牌：请求离开智能体时，被同一运行环境里的 Envoy 自动接管，在请求上附一张机器身份证书——证书由平台签发、经本机 Agent 领取，有效期 1 小时，到期前自动续期。智能体既不用改代码，也不需要知道证书放在哪。
3、核验签发：STS 先核验证书有效、且这台智能体已登记在白名单中，再在员工目录里找到这位员工，签发一张 60 秒有效、只能交给指定接收方的令牌，同时绑定员工与智能体两个身份。
4、调用工具：智能体带上这枚 60 秒的员工令牌，调用「查询客户关系」这类工具。
5、换取令牌：工具网关核验令牌后，向该券商的 IAM 换取该员工的访问令牌。
6、以员工身份调用：工具网关运行业务系统配置的认证脚本，用访问令牌登录 CRM。在 CRM 看来，这就是员工本人登录后发起的查询，返回的数据也按员工本人的权限过滤。
PART 04
能不能过安全评审，看这四个细节
链路跑通只是及格线。真正决定这套方案能不能过券商安全评审的，是下面四件事——它们也恰好对上监管文件里的那几句话。
1、智能体「不碰密钥」，是起点而非附加项
机器身份证书由平台自动签发、轮换，凭证在请求发出时由 Envoy 注入，智能体代码里不存任何密钥。这意味着：即使智能体本身被攻破，攻击者也拿不到可以带离环境、长期复用的凭据——它手上只有一张有效期 1 小时、绑定在当前运行环境上的证书；即便借这张证书去换员工令牌，换到的也只有 60 秒、且只能交给指定接收方。传统架构里「配置文件就是命门」这件事，在这里不再成立。
2、令牌「按人签发、60 秒失效、限定接收方」
三个约束同时生效，各管一段：短时令牌解决的是「拿到之后能用多久」，按人签发解决的是「能用到谁的数据」，限定接收方解决的是「被截获之后还能不能用出去」。三者不能相互替代。监管说的「系统和数据权限」要真正落地，靠的不是一句授权声明，而是令牌里写死的这两个身份和这一小时的窗口。
3、会话要复用，否则每问一句登录一次
员工令牌只有 60 秒，但业务系统的登录会话不该跟着 60 秒一换。工具网关对员工的业务会话按人缓存，有效期以访问令牌为准，会话失效时自动重新认证一次再重试。这一步不做，智能体就会变成一台高频登录业务系统的机器——在业务系统的安全日志里，那比攻击还可疑，也容易触发异常登录风控，把员工账号直接锁死。
4、业务系统「零改造」，是能落地的前提
CRM 这类传统系统只认登录会话，不支持 OpenID Connect 之类的现代认证协议。方案的做法是：接入一个新系统，只需在工具网关里配置它的接口和认证脚本，业务系统本身不用改。这条不成立，每接一个系统都要排期改造、走一次变更评审，智能体能覆盖的范围就会被流程卡死。
PART 05
上线之后：从「能用」到「敢用」
项目已在该券商上线运行，本期接入的业务系统是 CRM。员工在企业微信工作台里用自然语言提问，比如查询本人在 CRM 中的档案信息，或查询某位员工名下营销关系的客户数量与明细——后者需要在千万级的客户关系数据中完成查询。
这一步的意义，不在于接入了哪一个系统，而在于验证了一件事：员工身份可以无缝地「穿」过智能体这一层，直达业务后台。这条链路一旦成立，后续接入更多系统只是配置工作。更细的授权范围划分、跨系统的一致身份视图、面向更多智能体场景的身份策略，是接下来的演进方向。
写在最后：身份底座先行，智能体稳步规模化
正在规划引入 AI 智能体的金融机构，大多会遇到同一个难题：模型能力不缺，场景不缺，缺的是一套让业务系统「认得出、敢放行」的身份机制。
让智能体访问内部系统，从来不是简单的接口对接，而是一场关于「身份信任」的重构。只有确立了智能体的合法机器身份，并让员工权限在链路中安全穿透，企业才敢真正把核心业务交给 AI 去打理。
这正是派拉软件【AI 身份治理诊断】在做的事情。欢迎联系我们，与您的技术团队一起把核心链路梳理清晰，让智能体安全、合规地走向业务一线。
