AI 智能体身份：控制不拖慢规模化

AI 智能体只有具备身份、边界和每项行动的证据，才能实现规模化。当智能体读取数据、查询系统、修改记录或发起流程时，它就不再只是一个语言接口，而是作为企业内部的非人类身份运行。

这一变化要求重新审视一个常见假设：应用权限不足以治理自主性。智能体可能收到合法请求，却在执行期间从电子邮件、文档、网页或工单中遇到恶意指令。它也可能组合来自不同来源的数据，并产生任何单个系统都未明确授权的行动。

这一议题近期获得了更高的技术关注。2026 年 2 月，NIST 发布了一项专门提案，涵盖软件和 AI 智能体的识别、认证、授权、委托和不可否认性。5 月，Google Cloud 将智能体身份作为一种独立的主体类型提出，与用户和服务账号区分开来。OWASP 也将身份和权限滥用列为智能体应用最关键的风险之一。NIST, 2026 (nccoe.nist.gov) Google Cloud, 2026 (cloud.google.com) OWASP, 2026 (genai.owasp.org)

什么是 AI 智能体身份，为什么必须将其独立区分？

**AI 智能体身份是可验证的记录，用于将智能体与人员、通用应用和其他智能体区分开来。**它应包含技术和运营属性：所有者、环境、用途、所用模型、允许使用的工具、代码来源、风险等级和生命周期。

一个反复出现的错误，是让智能体使用权限过大的服务账号运行，或者更糟糕的是，使用用户的永久 token。这会降低初始摩擦，却消除了 accountability。事件发生后，团队知道某个凭证执行了一项操作，却无法回答基本问题：哪个智能体使用了它、出于什么目标、在什么上下文中，以及代表谁提出请求。

独立身份解决了职责分离问题。用户仍然是任务的请求者，智能体成为任务的执行者，工具或 API 则是受保护资源。这一区分允许针对每种关系应用不同策略。

以下术语有助于使设计更明确：

• **非人类身份：**访问资源但不属于个人的软件、服务、机器人或智能体身份。
• **委托：**授权智能体临时代表用户或流程行事。
• **证明：**通过密码学证据证明工作负载确实是其所声称的身份，并在预期环境中运行。
• **不可否认性：**能够在事后证明哪个身份采取了行动，以及该行动基于何种授权。

这种分离还可避免将智能体视为拥有无限访问权限的企业聊天工具。总结文档的助手，与修改价格、批准退款或向供应商创建工单的智能体，具有不同的风险画像。身份应从注册阶段就体现这种差异。

每项行动需要做出哪些访问决策？

**授权应评估具体行动，而不仅是安装时授予的权限。**在传统系统中，应用获得 scopes，并以相对可预测的方式使用它们。对于智能体，执行路径会随任务、检索到的上下文和可用工具而变化。

因此，访问决策至少需要考虑七类信号：智能体身份、委托用户或流程、请求资源、意图行动、所涉数据、环境和交易风险。客户服务智能体可以查询某位客户的历史记录，并不意味着它可以导出全部联系人数据库或修改商业条款。

这一模型称为上下文授权。它将 RBAC（基于角色的访问控制）与 ABAC（基于属性的访问控制）结合。RBAC 定义简单基础，例如“支持智能体”。ABAC 则增加条件：客户所在地区、数据分类、时间、财务金额、来源渠道和会话信任等级。

Microsoft 的最新文档建议，在智能体访问工单、文件、电子邮件或客户记录时保留用户的授权上下文。当存在已认证用户时，委托访问模式更为合适；纯应用访问应限制在边界清晰、可审计的后端任务中。Microsoft Learn, 2026 (learn.microsoft.com)

在实践中，策略问题不应是“智能体可以使用 CRM 吗？”。而应是：“这个智能体，为这个用户，在这项任务中，现在是否可以读取这条记录并执行这项行动？”这看似是语义差异，实则是架构差异。

当智能体决定下一步时，如何应用最小权限？

**智能体的最小权限意味着仅授予完成下一项可验证步骤所需的访问权限。**这并不意味着因为流程在某个阶段可能需要某些权限，就预先交付一组宽泛权限。

应用这一原则最安全的方式，是用短期、专用且可撤销的 token 替代永久凭证。每个 token 都应按工具、资源、行动和有效期限制 scope。需要创建提案草稿的智能体，可以获得对已批准客户数据的读取权限，以及仅向草稿库写入的权限。它不需要发送文档、应用折扣或更新主数据的权限。

还应按关键性对工具进行分层。可将其分为四类：

1. **低影响查询：**检索文章、订单状态和公开文档。
2. **敏感查询：**访问合同、财务数据、HR 信息或个人数据。
3. **可逆操作：**创建草稿、创建工单、建议修改和更新非关键字段。
4. **实质性操作：**发起付款、删除数据、修改价格、变更权限或作出外部承诺。

第三类和第四类需要额外策略。对于实质性操作，应使用 just-in-time（JIT）审批：权限仅针对该项决策、在该时刻、以严格 scope 释放。用户或管理者不是“向智能体授予访问权限”，而是批准一项已声明的行动。

这能降低两类常见风险的影响。第一类是间接 prompt 注入，即外部内容试图误导智能体。第二类是工具滥用，即看似无害的指令诱导智能体采取超出原始意图的行动。OWASP 指出，身份和权限滥用在风险严重性与组织准备度之间存在最大的差距之一。(genai.owasp.org)

策略应放在哪里：prompt、智能体还是基础设施中？

**授权策略应在 prompt 之外执行，并在工具执行前完成验证。**Prompt 用于引导行为，并不是访问控制。模型可能误解指令、接收冲突上下文，或受到外部内容操控。是否允许一笔交易的决策必须位于确定性控制层中。

成熟架构包含五个控制点。第一个是资产清单：每个智能体、工具、MCP 服务器、集成和凭证都必须可见。MCP，即 Model Context Protocol，是用于将模型和智能体连接至工具与上下文来源的协议。它可以加快集成，但也会扩大访问面。

第二个控制点是身份提供商。它为用户、智能体和工作负载签发并验证凭证。第三个是策略引擎，负责评估属性并作出允许、拒绝或请求审批的决策。第四个是工具网关，用于拦截对 API、数据库、SaaS 系统和自动化流程的调用。第五个是可观测性层，负责记录意图、上下文、决策、执行和结果。

推荐流程很简单：

1. 用户或流程发起任务。
2. 智能体获得独立身份和受限委托。
3. 每次调用工具前，网关将属性发送至策略引擎。
4. 策略允许、拒绝或要求额外审批。
5. 事件被记录，并关联用户、智能体、工具和资源。

NIST 强调的正是这些方面：识别、认证、动态授权、委托、行动记录，以及数据和 prompts 来源的可追溯性。(nccoe.nist.gov) 实际含义很明确：安全必须伴随执行过程，而不仅是初始配置。

在生产环境中审计智能体需要哪些证据？

**有效的审计轨迹必须能够还原完整决策链，而不只是列出 API 调用。**传统日志记录某个 endpoint 被调用。对于智能体，这还不够。还必须知道为何采取该行动，以及当时存在哪些限制。

每个相关事件都应包含关联标识符。该标识符将初始请求、委托用户、智能体版本、模型、检索文档、行动计划、所调用工具、策略决策和最终响应连接起来。

还应记录版本。智能体的行为可能因系统 prompt、模型、记忆、工具或策略的变更而改变。没有版本控制，就很难比较事件，也无法将故障归因于某项具体修改。

执行遥测与控制证据之间存在重要区别。遥测展示延迟、调用量、错误率和成本。控制证据则证明某项行动是根据现行策略获得授权的。企业需要两者。

应定义将治理与运营连接起来的指标：已纳入资产清单的智能体比例、闲置权限数量、被拒绝行动量、按风险类别划分的审批数量、超出 scope 的访问尝试、撤销凭证所需时间，以及按工具划分的日志覆盖率。这些指标能够揭示组织是在控制自主性，还是仅仅观察其扩张。

如何在不阻碍运营的情况下实施智能体身份？

**实施应从已经访问关键系统的智能体开始，而不是从理想化平台开始。**初始目标是降低真实暴露面，并建立可复用标准。

先开展 30 天资产清单工作。列出生产中的智能体、可访问真实数据的原型、自动化集成、智能体使用的服务账号、MCP 工具，以及存储在密钥库或环境变量中的凭证。按自主程度、访问数据和行动影响对每项进行分类。

随后，选择一个高价值且风险可控的流程。合适候选包括工单分流、提案准备、指标汇总或辅助更新主数据。不要从付款、数据删除、管理权限或监管决策开始。

为该流程创建专属智能体身份、短期 token、按工具划分的 scopes，以及针对实质性操作的 JIT 审批。随后实施关联记录，并模拟故障：文档中的恶意指令、过期 token、超出 scope 的读取尝试、工具不可用，以及执行期间的上下文变更。

扩展应依靠标准，而不是临时复制。内部智能体目录、已批准工具、策略模板和最低日志要求，能够减少团队间的差异。诸如 Centriu 的编排平台可以集中运营可见性，前提是授权仍由独立且可验证的控制机制执行。

预期结果不是阻止智能体行动，而是让每项行动都具备身份、明确授权、技术边界和可检索证据。这是将自动化转化为可持续运营能力的基础。