本文信息来源:felicis
AI 智能体的采用与现有的身份和访问管理(IAM)系统产生了根本性的不匹配。
传统的 IAM 系统假设确定性的执行者执行可重复、可预测的工作流程。但 AI 智能体在设计上就是非确定性的。将静态安全模型应用到动态系统上会产生不可接受的风险级别。
安全部署智能体需要超越静态角色和权限范围,转向基于动态、上下文感知和临时权限的新授权模型。这是一个必要的架构转变。问题的核心在于执行者的本质与身份系统设计之间日益扩大的差距:
| 静态身份 (基于角色的访问控制) |
动态身份 (上下文感知) |
|
|---|---|---|
| 可预测的参与者 (例如,服务、脚本) |
充足 | 更具韧性 |
| 非确定性参与者 (例如,AI 代理) |
不可接受的风险 | 必要 |
错配:确定性安全 vs 非确定性参与者
传统的 IAM,包括基于角色的访问控制(RBAC)和 OAuth 作用域,运行在一个简单的原则之上:你定义一个具有固定权限集的角色或作用域,然后将其分配给用户或服务。这种方式有效是因为执行者——无论是遵循业务流程的人员还是执行硬编码逻辑的脚本——都是可预测的。它们的潜在行为是有限且提前已知的。
LLM 驱动的智能体打破了这个假设。它们的行为是涌现的,由目标、上下文和运行时数据引导。没有预定义的脚本或有限状态机;执行路径是实时生成的。
为本质上不可预测的实体分配广泛的静态权限构成了重大的安全隐患。当执行任务所需的”权限”在执行时刻之前都是未知的时候,最小权限原则几乎不可能维持。
一个具体示例:智能体工作流程中的职责分离
考虑一个既可以提交费用报告,又可以批准其直接下属报告的经理。代表这名经理行事的 AI 智能体将继承这两个操作的权限:submit_expense 和 approve_expense。
现在,考虑这样的工作流程:
- 经理向智能体询问:”为我最近的出差提交费用报告并获得批准。”
- 智能体使用其
submit_expense权限创建并提交报告。 - 为了满足提示的第二部分(”获得批准”),代理立即对刚刚提交的报告使用其
approve_expense权限。
这违反了职责分离(SoD)原则,这是一项基础的安全控制。在传统系统中,你可能会通过复杂的应用级业务逻辑来防止这种情况,检查提交者和批准者是否是同一人。这种方法很脆弱,因为它将全部安全负担都放在每个应用开发人员身上,要求他们正确实施。
一个稳健的安全模型不应该在身份层面允许这种情况。代理永远不应该拥有同时提交和批准同一实体的权力。第一个操作(提交)的上下文应该动态改变第二个操作可用的权限。这只是当今几个基于感觉编程的平台面临的授权漏洞类型之一。
为不确定性而构建
AI 智能体是一种具有独特属性的新型身份类别,需要一种全新的安全模型。继续应用静态角色和权限既不可持续也不安全。下一代 IAM 必须为非确定性而构建。通过采用动态、即时和上下文感知的授权机制,我们可以构建必要的防护措施,安全自信地部署智能体系统。
