AI智能体的治理：身份、委托与权限实践

AI智能体在现代系统中执行任务时，其身份和权限管理成为关键挑战。许多团队为了快速部署，往往让智能体共享API密钥或直接使用开发者的凭证，这导致了严重的治理漏洞。本文提出了一种基于委托的治理模型，确保每个智能体都有明确的身份、有限的权限，并且每项操作都能追溯到授权源头。

**错误的做法**

第一种错误做法是“模拟用户”。智能体继承人类用户的所有权限，导致权限过度膨胀。例如，一个客服代表触发智能体查询订单，智能体却可能接触到财务报表、HR记录等完全无关的数据。一旦遭遇提示注入攻击，攻击者就能获取用户的所有API权限。审计日志也无法区分是人类操作还是智能体行为。

第二种错误做法是使用服务账户。虽然智能体有了独立身份，但问责困难：服务账户无法被解雇、无法在事件复盘中被质询。当设置它的工程师离职后，权限可能长期未被审查，形成安全隐患。NIST SP 800-207将其称为“仅基于所有权的隐式信任”，违背了零信任原则。

**委托模型：正确的路径**

正确的模型是：智能体拥有自己的身份，但代表人类行动。两个身份都被保留，权限是智能体角色与委托者权限的交集。用公式表示：有效权限 = 智能体角色 ∩ 委托者权限。实习生触发管理级智能体？只有实习生级别的结果。管理员触发受限智能体？智能体只能执行其角色范围的操作。双方不会互相升级权限。

Red Hat将此称为“验证并永不信任”，NIST SP 800-207则强调在建立会话之前分别进行身份验证和授权。这一原则同样适用于AI智能体。

**身份是锚点**

智能体需要一个永久的、稳定的标识符，与人类使用相同的身份系统、目录、生命周期和吊销路径。没有独立身份，智能体就是系统中的“幽灵”，无法被命名、吊销或调查。

**天花板与地板**

每次操作强制执行两重边界：天花板（智能体的角色上限，由管理员设定）和地板（委托者的权限下限）。有效权限总是取两者中较窄的。例如，一个仅具有发票读取和创建权限的智能体永远无法接触薪资数据，因为平台层阻止了该调用，而非依赖LLM的诚实。

当智能体被提示注入攻击时，其操作范围仍被交集限制，爆炸半径由数学保证，而非靠希望。

**智能体不感知权限**

关键设计：智能体不携带任何令牌，不检查权限，也不知道委托用户的信息。所有授权都在平台层完成，位于智能体进程、提示词和攻击者可达范围之外。这样，相同的智能体代码可以因委托者不同而拥有不同的有效范围，无需代码变更，仅需配置。

**自主触发器与失效授权**

对于定时任务、webhooks等自主触发场景，没有人类在场参与委托。规则不变：无委托上下文即拒绝。每个自主触发器由人类创建，系统在创建时记录委托者，并在每次分派时重新验证：委托是否存在？是否有效？委托者是否仍有权限？任何检查失败，智能体不执行。

如果离职工程师设置的同步任务未受此约束，它可能长期运行已失效的授权；而此机制能让离线委托者自动失效，无需手动清理。

**每个动作两个名字**

每次操作记录两个身份：执行者（如invoice-agent）和授权者（如[email protected]），以及触发方式。审计在数据库触发器层面捕获，与数据修改在同一事务中，智能体无法绕过或篡改。

**令牌契约**

内部委托令牌遵循RFC 8693（令牌交换）：仅包含身份，权限每次从数据库按需解析；短生命周期（120秒）；限定接收服务。令牌只说明“此智能体代表此人类”，平台在每次请求时决定组合的权限。

**RootCX中的实践**

每次在RootCX Core上部署的智能体自动获得治理身份，无需配置。确定性身份、与人类相同的RBAC、每次工具调用的交集计算、自主触发的常设委托验证、智能体外的平台级授权、双重身份审计、短生命周期令牌。构建者无需考虑治理，平台像Okta处理人类认证一样透明地处理。

**8点检查清单**

1. 每个智能体是否有独立身份？
2. 是否有按智能体设置的能力上限？
3. 有效权限是否是交集？
4. 无委托者是否等于拒绝？
5. 智能体是否不感知权限？
6. 自主触发是否有常设委托？
7. 令牌是否短生命周期且限定受众？
8. 审计追踪是否包含两个身份？

8/8意味着受治理的智能体，否则只是披着风衣的脚本与API密钥。