本文信息来源:felicis

AI 智能体的采用与现有的身份和访问管理(IAM)系统产生了根本性的不匹配。

传统的 IAM 系统假设确定性的执行者执行可重复、可预测的工作流程。但 AI 智能体在设计上就是非确定性的。将静态安全模型应用到动态系统上会产生不可接受的风险级别。

安全部署智能体需要超越静态角色和权限范围,转向基于动态、上下文感知和临时权限的新授权模型。这是一个必要的架构转变。问题的核心在于执行者的本质与身份系统设计之间日益扩大的差距:

静态身份
(基于角色的访问控制)
动态身份
(上下文感知)
可预测的参与者
(例如,服务、脚本)
充足 更具韧性
非确定性参与者
(例如,AI 代理)
不可接受的风险 必要

错配:确定性安全 vs 非确定性参与者

传统的 IAM,包括基于角色的访问控制(RBAC)和 OAuth 作用域,运行在一个简单的原则之上:你定义一个具有固定权限集的角色或作用域,然后将其分配给用户或服务。这种方式有效是因为执行者——无论是遵循业务流程的人员还是执行硬编码逻辑的脚本——都是可预测的。它们的潜在行为是有限且提前已知的。

LLM 驱动的智能体打破了这个假设。它们的行为是涌现的,由目标、上下文和运行时数据引导。没有预定义的脚本或有限状态机;执行路径是实时生成的。

为本质上不可预测的实体分配广泛的静态权限构成了重大的安全隐患。当执行任务所需的”权限”在执行时刻之前都是未知的时候,最小权限原则几乎不可能维持。

一个具体示例:智能体工作流程中的职责分离

考虑一个既可以提交费用报告,又可以批准其直接下属报告的经理。代表这名经理行事的 AI 智能体将继承这两个操作的权限:submit_expense 和 approve_expense

现在,考虑这样的工作流程:

  1. 经理向智能体询问:”为我最近的出差提交费用报告并获得批准。”
  2. 智能体使用其 submit_expense 权限创建并提交报告。
  3. 为了满足提示的第二部分(”获得批准”),代理立即对刚刚提交的报告使用其 approve_expense 权限。

这违反了职责分离(SoD)原则,这是一项基础的安全控制。在传统系统中,你可能会通过复杂的应用级业务逻辑来防止这种情况,检查提交者和批准者是否是同一人。这种方法很脆弱,因为它将全部安全负担都放在每个应用开发人员身上,要求他们正确实施。

一个稳健的安全模型不应该在身份层面允许这种情况。代理永远不应该拥有同时提交和批准同一实体的权力。第一个操作(提交)的上下文应该动态改变第二个操作可用的权限。这只是当今几个基于感觉编程的平台面临的授权漏洞类型之一。

前进之路:代理原生授权的原则

为了保护智能体的安全,我们需要将授权从静态网关演变为动态的智能层。这种模型建立在三个核心原则之上。

1. 即时(JIT)和范围受限权限

固定权限是最主要的风险。我们不应该向智能体授予角色,而应该为特定目的在最后可能的时刻临时提供权限。

  • 工作原理: 智能体开始时拥有零权限或最小权限。当它需要执行任务时(例如,读取文件),它会请求该特定权限。运行时授权系统评估请求,如果获得批准,则授予短期凭证。像 ConductorOne 这样的公司已经在人员访问方面通过即时(JIT)权限开拓了这一领域,这种范式的自然延伸是为承担人类身份的智能体提供便利。

2. 基于上下文的访问控制

权限不应基于静态角色,而应基于请求的实时上下文 。这是基于属性的访问控制(ABAC)的演进,专为代理工作流的速度和可变性而设计。

  • 工作原理 :权限应寻找上下文信号,包括 
  • 意图: 代理的既定目标是什么?(例如,”总结文档”与”删除存储库”)。
  • 历史: 代理在此会话中以及过去执行了哪些操作?
  • 数据敏感性: 所请求的资源是否被标记为个人身份信息(PII)、财务数据或战略知识产权?
  • 环境: 当前的时间、地理位置和设备状态是什么?

这种”策略即代码”的方法,由像 Oso 这样的公司倡导,为定义和执行此类丰富的、上下文感知的规则提供了以开发者为中心的构建模块。

3. 持续和基于行为的验证

身份验证和授权不应该是会话开始时的一次性事件。系统必须持续验证代理的行为是否与其授权意图一致。

  • **工作原理:** 授权层监控代理的行为流(其”行为”)。如果行为显著偏离初始意图或既定模式——例如,一个负责代码摘要的代理突然尝试访问生产环境密钥——其权限可以立即降级或撤销,等待人工审核。这创造了一个在当今模型中缺失的关键安全反馈循环。

Keycard 和 Anysource 等公司是提供这种持续验证的早期平台,使团队更容易信任他们的智能体。

最终,这三个原则将引导我们构建一个既能(1)统一凭证及其获取方式,又能(2)确保最小权限访问的层级。这将控制权重新交还给企业,从而增加对他们构建和使用的智能体的信任。

A flowchart diagram titled “The Enterprise Agentic Identity Layer” illustrates the interaction between users, agents, and cloud services through a central identity platform.  Users connect to an Agent, which is shown exchanging information bidirectionally with the Agent Identity Platform.  The Agent Identity Platform consists of three core services:  Dynamic Tokens  Vault Secrets  Token Broker  The platform connects to an MCP Server, which acts as a coordinator.  The MCP Server interfaces with various SaaS services such as AWS, Salesforce, Figma, GitHub, and more.  The flow indicates that the Agent gets identity and access credentials from the Agent Identity Platform, mediated by the MCP Server, to access SaaS services on behalf of the user.  The diagram is branded with the Felicis logo in the bottom-right corner.

为不确定性而构建

AI 智能体是一种具有独特属性的新型身份类别,需要一种全新的安全模型。继续应用静态角色和权限既不可持续也不安全。下一代 IAM 必须为非确定性而构建。通过采用动态、即时和上下文感知的授权机制,我们可以构建必要的防护措施,安全自信地部署智能体系统。