当 AI 只能回答问题时，企业主要担心它说错话；当 AI 开始调用数据库、更新工单、创建订单或修改配置时，企业必须先回答另一个问题：系统里执行这次操作的，究竟是谁？
2026 年 10 月下旬，NIST 发布了面向智能体身份管理系统的十项初始设计原则，包括独立身份、授权委派、零常驻权限、短时可撤销授权、人工升级、策略与推理分离、持续监控和不可篡改证据。几乎同时，IBM 宣布 Agent Identity 与 HashiCorp Vault 相关能力，提出为 AI 智能体建立身份记录，并签发范围受限、有效期较短的凭证。
前者是基于公开反馈提出的设计原则，不是已经定稿的合规标准；后者是厂商产品发布，也不能替代企业自身的架构验证。但两项信息指向同一个变化：智能体身份正在从一个安全细节，变成企业 AI 能否进入生产的基础设施。
“以某员工身份运行”，看似方便，实际同时破坏三件事
很多 AI 试点从个人效率工具开始。员工登录系统后，智能体沿用他的会话或令牌完成工作，这种方式配置简单，也符合“AI 是人的助手”的直觉。
一旦智能体开始跨系统持续执行任务，这种做法就会暴露问题。
第一，审计失真。日志只能看到员工账号访问了客户资料或修改了工单，却无法区分是员工亲自操作、AI 根据员工指令操作，还是 AI 在后续步骤中自行选择了动作。
第二，权限放大。员工为了完成一整类工作，通常拥有较宽权限；智能体执行当前任务可能只需要读取一个项目、更新一个字段。如果直接继承员工权限，智能体获得的能力远大于任务所需。
第三，责任断链。员工转岗、离职或权限变化后，依赖其账号的智能体可能突然失效；更危险的情况是，长期令牌仍然有效，系统继续以一个已经不合适的身份运行。
共享服务账号也没有解决本质问题。十个智能体共用一个账号，日志只会显示“自动化账号做了什么”，仍然无法证明是哪个智能体、哪次任务、受谁委托，以及当时获得了什么授权。
独立身份不等于再建一个长期账号
为每个智能体创建独立身份，只解决了“叫什么”的问题。真正可靠的方案还需要把身份、任务和权限绑在一起。
可以把一次智能体执行理解成一条授权链：
发起人或业务规则 → 任务委托 → 智能体身份 → 临时权限 → 工具调用 → 业务结果
这条链上的每一段都要可验证：
NIST 提出的“授权递减”尤其值得注意：当主智能体把工作交给子智能体或下游服务时，后者获得的权限不能比上游更大。否则，一项原本只允许读取数据的任务，可能在多次转交后意外获得写入或审批能力。
- 谁发起：具体员工、获批流程或上游智能体；
- 委托什么：预期结果、有效时间、允许使用的系统和禁止动作；
- 谁执行：可唯一识别的智能体、版本、运行环境和责任人；
- 获得什么权限：只针对本任务、目标资源和必要动作；
- 实际做了什么：每次工具调用、输入依据、返回结果和异常；
- 谁承担结果：哪个业务角色负责验收，出现问题由谁接管。
权限应随任务出生，也随任务结束
传统应用常使用长期密钥，因为软件行为相对固定、调用关系相对稳定。智能体不同：它会根据上下文选择工具和步骤，也可能因为提示注入、错误信息或推理偏差偏离最初目标。
因此，企业不应只问“这个智能体平时需要什么权限”，而应问“它完成这一次任务需要什么权限”。
更合适的授权方式具有四个特征：
例如，一个“核对本周逾期发票”的智能体，需要读取指定账期的应收数据，也许可以为客户经理生成跟进草稿，但不应因此获得修改收款记录、调整信用额度或向客户直接发送消息的权限。如果需要升级动作，应重新获取授权，而不是沿用原有凭证继续扩大范围。
这也是为什么短时凭证比定期轮换长期密钥更适合智能体。轮换解决的是密钥使用太久，任务级授权解决的是权限从一开始就不应长期存在。
- 默认无权：智能体空闲时不持有生产系统的常驻权限；
- 按需签发：任务启动后，根据发起人、智能体、资源与风险签发临时凭证；
- 范围收窄：权限限定到特定客户、项目、数据集、API 动作或金额区间；
- 随时可撤销：任务完成、环境变化、行为异常或人工叫停时，权限立即失效。
不要让大模型自己决定自己能做什么
企业常在提示词里写“不得访问敏感数据”“金额超过十万元必须审批”。这些要求可以帮助模型规划，却不应成为真正的权限边界。
大模型会同时处理指令和外部数据。网页、邮件、文档或工具返回内容都可能包含误导性指令。如果“想做什么”和“被允许做什么”都由同一个推理过程决定，提示注入就可能从影响答案升级为扩大权限。
NIST 因此提出将策略与推理在架构上分离，并保留确定性的访问决策。简单说：
“模型认为合理”不是授权依据，“提示词要求克制”也不是安全控制。真正的控制必须位于模型无法自行修改的边界之外。
- 模型可以建议下一步调用哪个工具；
- 独立策略层根据身份、任务、资源、时间和风险决定是否放行；
- 高风险动作触发人工复核；
- 异常行为可以在任务进行中撤销权限，而不是等任务结束后查日志。
企业可以先做一次“借号排查”
在采购新的智能体管理平台之前，企业可以先对现有试点做一轮快速检查：
如果一个智能体能够修改生产数据，却无法明确回答“它是谁、代表谁、这次获准做什么、权限何时失效”，就不应该因为模型测试准确率不错而进入生产。
- 检查项：需要识别的风险
- 身份：是否借用员工账号、浏览器会话或多人共享账号
- 凭证：是否保存长期 API Key、静态令牌或明文密钥
- 权限：是否直接继承发起人的全部权限，是否明显超过任务所需
- 委托：日志能否关联发起人、任务目的、智能体版本和批准范围
- 转交：子智能体或工具是否可能获得比上游更大的权限
- 撤销：能否单独停止一个智能体或一次任务，而不是关闭整套系统
- 证据：关键日志是否由独立系统保存，智能体自身无法修改
- 生命周期：责任人离职、智能体升级或试点结束后，身份是否自动失效
身份治理的目标不是限制智能体，而是让企业敢于授权
过于宽泛的身份与权限，表面上减少了集成工作，实际会迫使企业把智能体长期限制在低价值的只读场景。因为一旦让它采取行动，风险就难以隔离，责任也难以追踪。
独立身份、任务级授权和短时凭证带来的真正价值，是把风险限制在可理解的边界内：一个智能体出错，不必停掉所有自动化；一次凭证泄露，不会变成永久入口；一次业务委托，可以完整追溯到发起人和批准范围。
企业 AI 从“能回答”走向“能办事”，中间缺的并不只是更多连接器。它还需要一套能够证明授权、限制权限并随时收回信任的机制。
只有当企业可以准确地撤销一个智能体的权力，才真正具备把权力交给它的条件。
