企业部署AI智能体前，如何重建身份认证与权限治理体系？

当企业把AI智能体接入邮箱、客户关系管理、财务、工单或内部知识库时，风险就不再只是“模型回答得准不准”。智能体可能代表员工读取信息、调用工具、修改记录，甚至触发跨系统流程。部署前真正需要回答的是三个问题：一个智能体能代表谁，能够调用什么，以及事后能留下哪些可信证据。

这三个问题分别对应身份认证、权限治理和安全审计。若企业仍把智能体当作普通应用，用一个共享账号连接多个系统，或者只记录“某用户发起了一次请求”，就很难判断实际执行者、授权范围和责任边界。更稳妥的做法，是把智能体视为一种需要独立管理的非人身份，并为它建立从创建、授权、运行到注销的完整控制体系。

先定义智能体到底“代表谁”

人的身份、智能体身份和任务身份要分开

一次看似简单的智能体操作，通常至少涉及三类主体：

• 发起人：提出请求或批准任务的员工、客户或业务角色；
• 智能体：负责理解意图、规划步骤和调用工具的软件实体；
• 被调用系统或连接器：邮箱、数据库、CRM、支付、办公协同等实际提供数据或执行动作的系统。

这三类身份不能被压缩成一个账号。员工登录系统，并不意味着智能体可以永久继承该员工的全部权限；智能体拥有服务身份，也不意味着它可以脱离具体任务自由操作。

企业应在身份目录中为每个生产智能体建立唯一记录，至少包含以下信息：

这里的“业务负责人”不能被技术账号替代。身份治理不仅是给智能体分配一个客户端凭证，更是要明确谁能够批准它代表企业执行哪些事情。

认证重点从“能不能登录”转向“当前凭什么执行”

传统应用认证往往只关心请求是否来自合法客户端。智能体场景还需要确认：

1. 请求由哪个人发起；
2. 由哪个智能体处理；
3. 智能体使用哪个版本和运行环境；
4. 当前任务是否经过必要授权；
5. 请求是否仍在有效时间和有效范围内。

因此，调用链中应尽量保留可关联的身份上下文，而不是只把最终请求转发给下游系统。下游服务至少需要能够区分“员工直接调用”“智能体代表员工调用”和“智能体后台自动调用”这几种情况。

对于高风险操作，还应要求人工确认或二次授权。例如，智能体可以自动整理付款申请，但正式付款、批量修改客户等级、删除业务记录等动作，应由符合条件的人员明确批准。人工确认不是为了弥补所有技术缺陷，而是为不可逆或高影响操作增加责任节点。

权限治理不能只看智能体能访问什么

从静态角色改为“任务、资源和动作”组合授权

权限治理的基本单位不应只是“某智能体属于哪个角色”，还要具体到：

• 任务：这次请求要完成什么目标；
• 资源：涉及哪些客户、项目、部门或数据范围；
• 动作：允许读取、创建、修改、发送、审批还是删除；
• 条件：在什么时间、网络环境、审批状态下有效；
• 结果：智能体是否可以继续把结果传给其他工具。

例如，一个销售辅助智能体可以读取指定客户的公开资料和已授权的内部记录，但不应因此获得全部客户数据的导出权限。它可以生成报价草案，却不一定可以直接发送正式报价；可以创建工单，却不一定可以关闭涉及退款的工单。

这意味着权限策略应尽量表达为“谁在什么条件下，对什么资源执行什么动作”，而不是笼统地配置“允许访问CRM”。

工具调用链要逐段校验权限

智能体常见的执行链路是：

用户请求 → 智能体规划 → 工具或连接器 → 下游业务系统 → 返回结果 → 下一步工具调用

风险往往出现在链路中间。例如，第一步读取到的客户信息被自动带入第二个工具，第二个工具却没有重新判断数据范围；又或者智能体获得了一个可以调用多个接口的长效令牌，后续每一步都默认拥有相同权限。

较稳妥的设计包括：

• 每个工具拥有清晰、独立的权限边界；
• 工具调用前重新校验调用者、发起人、资源和动作；
• 不把上游系统返回的用户信息直接当作授权凭证；
• 对不同工具使用不同的受限凭证；
• 优先采用短时、按任务生效的访问令牌；
• 任务结束后主动撤销或使临时权限失效；
• 禁止用共享账号掩盖多个智能体或多个业务流程。

“最小权限”在智能体环境中还应加上“最短时间”和“最小数据范围”。一个智能体即使长期存在，也不应长期持有完成单次任务所不需要的高权限。

为高风险动作建立分级策略

可以按照动作影响划分权限等级：

分级不应只根据工具名称判断。同一个“写入数据库”接口，更新测试数据和修改生产财务记录的风险并不相同。策略需要结合资源敏感度、动作可逆性、影响范围和业务时间窗口。

通信配置是身份治理的一部分

企业在部署智能体时，常把通信配置当作平台工程问题，身份治理则交给安全团队。实际上，通信链路直接决定身份信息能否被可信地传递和验证。

明确每一跳通信的信任边界

需要逐项梳理以下链路：

• 用户端到智能体入口；
• 智能体到模型服务；
• 智能体到工具网关；
• 工具网关到业务系统；
• 智能体之间的委派调用；
• 运行环境到密钥或凭证管理系统。

每一跳都应明确通信双方、认证方式、凭证来源、可传递的身份字段和失败后的处理方式。不能因为请求已经在内网，就默认它可信；也不能因为上游已经认证过用户，就让所有下游服务无条件接受上游转发的身份声明。

对于服务间通信，应使用经过企业认可的加密和服务认证机制，并将密钥放入专门的凭证管理系统。密钥不应写入代码、提示词、配置文件或日志。测试环境和生产环境也应使用不同的身份、密钥和数据范围，避免测试配置被直接带入生产。

防止身份上下文被“越权继承”

智能体可能调用另一个智能体、插件或外部服务。此时要避免一种危险的默认逻辑：上游智能体具有什么权限，下游组件就自动继承什么权限。

更好的做法是让每次委派都明确记录：

• 委派方是谁；
• 被委派方是谁；
• 委派的具体任务是什么；
• 允许访问哪些资源；
• 权限何时失效；
• 下游是否可以继续委派。

如果下游组件只需要完成一个查询，就不应获得上游完整会话令牌。身份传递应当是受限、可验证、可追溯的，而不是简单复制请求头或转发长效凭证。

用行为基线识别“正常但不合理”的动作

身份认证解决的是“是谁”，权限治理解决的是“允许做什么”，但两者都不能完全替代运行时监测。一个合法身份也可能因为配置错误、模型异常、工作流变化或账号被滥用而表现出异常行为。

行为基线不等于给模型贴固定标签

行为基线是对智能体正常运行模式的描述，通常包括：

• 常用工具和调用顺序；
• 典型调用频率和时间段；
• 正常访问的数据类型与数量；
• 单次任务的最长持续时间；
• 常见失败率和重试次数；
• 可接受的外部通信范围；
• 人工审批出现的频率；
• 版本、提示词和工具配置的变化。

基线应来源于经过验证的业务流程，而不是简单根据一段历史数据自动生成。上线初期可以先以观察模式运行，收集正常任务样本，再设置告警阈值。对于刚上线或刚发生重大变更的智能体，应采用更严格的监控策略。

发现异常时要能降级，而不只是报警

有效的运行控制应包含分级响应：

• 轻微偏离：记录并提高观察等级；
• 频率异常：限制调用速度或暂停当前任务；
• 访问范围异常：阻断相关工具调用；
• 连续失败或循环调用：终止任务并冻结临时凭证；
• 高风险动作异常：转人工审批或进入隔离环境。

例如，智能体突然在短时间内访问大量客户记录，或者连续调用与当前任务无关的管理接口，即使认证完全通过，也应触发限制。行为基线的价值在于补充静态权限，及时发现“身份合法但行为不合理”的情况。

安全审计要记录一条完整证据链

只记录“某员工使用了某智能体”是不够的。发生争议、误操作或安全事件时，企业需要还原从请求到结果的全过程。

一次关键操作至少应关联这些证据

• 发起人身份及其当时的认证状态；
• 智能体唯一身份、版本和运行环境；
• 请求进入和任务完成的时间；
• 原始任务目标及必要的上下文摘要；
• 采用的模型、工具和连接器；
• 每次工具调用的动作、资源和结果状态；
• 授权决策、审批人和审批时间；
• 输入输出的数据分类或敏感等级；
• 失败、重试、降级和阻断原因；
• 配置、提示词、模型和权限策略的版本；
• 关联的请求编号、任务编号和下游事务编号。

日志不等于把所有对话原文永久保存。企业还要考虑个人信息、商业秘密和敏感数据暴露问题。可以根据审计目的，对内容进行脱敏、摘要或分级保存，同时确保在需要调查时仍能关联到原始业务记录。

日志本身也需要保护。应限制查看权限，防止篡改，并设置合理的保存期限和删除机制。对于高风险操作，最好让审计记录与业务系统的事务记录相互引用，避免只依赖智能体平台自己的日志。

部署前应完成一轮可验证的验收

企业不应只用“能否完成演示任务”判断智能体是否可以上线。验收应覆盖身份、权限、行为和证据四个方面。

身份验收

• 每个生产智能体是否有唯一、可停用的非人身份；
• 是否能区分发起人、智能体和下游服务；
• 员工离职、岗位变化或智能体下线后，相关权限能否及时失效；
• 是否存在共享账号、硬编码密钥或长期未轮换凭证；
• 委派调用能否证明上下游身份关系。

权限验收

• 智能体是否只拥有完成任务所需的工具和数据权限；
• 每个工具是否分别校验身份、资源和动作；
• 是否限制批量读取、批量修改和跨租户访问；
• 高风险动作是否需要人工确认；
• 临时授权是否有明确的开始时间、结束时间和撤销机制；
• 测试环境是否与生产环境隔离。

行为验收

• 是否建立了正常调用路径和频率基线；
• 是否能识别异常循环、越界访问和调用爆发；
• 阻断后能否终止任务并使临时凭证失效；
• 模型、工具或提示词变更后是否重新评估基线；
• 是否有明确的告警接收人和处置时限。

审计验收

• 能否从一条业务结果反查发起人、智能体、工具和授权决策；
• 是否记录了失败调用和被拒绝的调用；
• 审批记录能否与实际执行动作关联；
• 日志是否防篡改、可检索并符合数据保存要求；
• 发生异常时，安全团队能否在不依赖模型自述的情况下还原事实。

把身份治理纳入智能体全生命周期

安全设计不应止步于首次上线。智能体的模型、提示词、工具、数据源和业务负责人都可能发生变化，任何一项变化都可能改变原有权限边界和行为基线。

企业可以建立以下生命周期流程：

1. 登记：说明用途、负责人、数据范围和风险等级；
2. 设计评审：确认身份模型、工具清单、通信边界和人工控制点；
3. 测试验收：验证越权阻断、异常降级和审计完整性；
4. 生产上线：使用独立生产身份和受控凭证；
5. 持续监控：观察行为基线、权限使用和配置变更；
6. 定期复核：确认业务需求、数据范围和负责人仍然有效；
7. 暂停或注销：撤销凭证、清理连接、保留必要审计记录。

最终，企业部署AI智能体的安全标准，不应只是“模型表现良好”或“流程已经自动化”，而应是：能够证明谁发起了任务，哪个智能体代表其执行，具体访问了哪些资源，为什么被允许，以及整个过程留下了可核验的证据。

当这三个问题——“代表谁、调用什么、留下什么证据”——都能得到清晰回答时，身份认证、权限治理、行为基线和安全审计才真正形成闭环，智能体也才具备进入关键业务系统的基础条件。