IBAC/RBAC/ABAC/ReBAC对比：哪种访问控制适合AI Agent

当AI Agent成为系统调用方时，传统的授权模型开始出现裂缝。过去为人类用户和服务账户设计的访问控制机制，在面对能够自主推理、动态调用工具的智能体时，暴露出诸多不适配之处。本文对比RBAC、ABAC、ReBAC三种主流模型，并探讨新兴的IBAC（基于意图的访问控制）究竟意味着什么。

四种授权模型的本质区别

开发者在构建系统权限体系时，实际会在四种模型间做选择。理解它们的核心差异，是判断谁更适合AI Agent的前提。

RBAC（基于角色的访问控制） 是最广为采用的模型。它将权限绑定到角色，用户通过被分配角色获得权限。RBAC的优势在于简单、可审计、易于管理——管理员只需维护有限数量的角色定义。但它的粒度较粗，当权限需求高度动态时，角色数量会爆炸式增长，形成所谓的"角色泛滥"问题。

ABAC（基于属性的访问控制） 通过评估主体、资源、操作和环境的属性来做决策。它比RBAC灵活得多，可以表达"财务部门的员工在工作时间内可以访问本区域的报销单"这类复杂策略。代价是策略的复杂度和调试难度显著上升，权限的可预测性下降。

ReBAC（基于关系的访问控制） 源自Google Zanzibar的设计思路，以实体之间的关系图为核心。"文档的所有者""团队的成员"这类关系被建模为图结构，权限沿关系传递。ReBAC在处理层级化、共享型资源（如协作文档、组织架构）时表现出色。

ReBAC的起源：Google Zanzibar 是Google于2019年公开的大规模一致性全球授权系统，负责管理Google Drive、YouTube、Google Photos等产品的数十亿用户权限关系。Zanzibar将"谁对什么资源有什么关系"建模为三元组（user, relation, object），并通过图遍历来判断访问是否被允许。这一设计对后来的开源项目产生了深远影响，SpiceDB、OpenFGA等系统均以此为原型。ReBAC在企业协作场景中的优势在于，它能自然表达"A共享给B，B又可以转授给C的团队成员"这类传递性权限，而无需为每种情况单独写策略。其代价是关系图的维护成本，以及在关系链较长时的查询性能挑战。

当调用方是Agent时，模型在哪里失效

AI Agent的引入打破了传统授权的基本假设。多数授权模型默认调用方身份是静态且可预知的——一个用户、一个服务、一组固定权限。但Agent的行为具有动态性和不确定性。

RBAC面临的问题最直接：应该给Agent分配什么角色？如果按最高权限分配，一旦Agent被提示注入或产生错误推理，破坏范围将不可控；如果按最小权限分配，Agent又可能因权限不足无法完成任务，需要频繁的人工介入。角色的静态性无法匹配Agent任务的多变性。

ABAC理论上能通过属性表达更精细的条件，但Agent的"意图"本身很难被编码为可评估的属性。传统属性描述的是"你是谁""资源是什么"，而Agent场景真正需要回答的是"你此刻想做什么、为什么"。

ReBAC在Agent委托链条上会遇到关系断裂的问题。当用户委托Agent、Agent再调用子Agent或外部工具时，原始的关系图无法自然延伸——权限的传递路径变得模糊。

提示注入（Prompt Injection） 是AI Agent场景中权限失效的一个典型攻击向量，值得单独说明。攻击者通过在Agent处理的外部内容（网页、文档、邮件）中嵌入恶意指令，诱使Agent执行超出原始任务范围的操作——例如读取敏感文件、向外部地址发送数据，或以用户身份执行破坏性操作。如果Agent持有过高的静态权限，提示注入的危害将被极度放大，因为恶意指令可以直接驱动Agent完成攻击者意图而无需绕过任何额外屏障。这也是为何"最小权限"原则在Agent场景中比传统服务账户场景更为迫切——Agent的攻击面不仅来自代码逻辑漏洞，还来自其处理的一切非结构化输入。

意图访问控制（IBAC）是什么，不是什么

IBAC（Intent-Based Access Control，基于意图的访问控制）是针对Agent场景提出的思路。它的核心主张是：授权决策应当基于调用方的意图，而不仅仅是身份或属性。

所谓意图，指的是Agent在特定时刻试图达成的具体目标。IBAC试图在权限评估中引入这一维度——不是问"这个Agent有没有权限访问数据库"，而是问"这个Agent当前的意图是否需要、并且合理地包含对该数据库的访问"。

需要澄清的是，IBAC不是让LLM自己决定该给自己什么权限，那会带来严重的安全隐患。它也不是要替代现有的RBAC或ABAC，而更像是在既有授权层之上增加一个意图校验环节。真正的意图必须以某种可验证的方式被捕获和约束，而非依赖模型的自我声明。

实现IBAC"意图可验证"这一要求，目前学术界和工程实践中有几种探索方向。一种是任务令牌（Task Token）机制：在Agent任务启动时，由可信协调层签发一个包含明确任务描述和权限范围的令牌，Agent的每次资源调用都必须携带该令牌，授权系统比对调用行为是否在令牌声明的意图范围内。另一种是计划审查（Plan Review）：对于高权限操作，要求Agent在执行前输出其行动计划，由独立的策略引擎或人工进行意图合规性审核，通过后才释放权限。这些方案仍处于早期阶段，尚无被广泛采用的标准，但它们的共同思路是：意图必须在任务边界处被外部锚定，而非在执行过程中由模型自我声明。

该如何选择

对于Agent系统的实际落地，单一模型往往不够。合理的做法通常是分层组合：用RBAC或ReBAC定义Agent可触达的资源边界，用ABAC补充环境和上下文条件，再考虑用意图层做动态收窄。

关键原则是：给Agent的应当是可撤销、可审计、最小必要的权限，并且权限要能随任务上下文动态调整。任何将高权限静态授予Agent的做法，都会在安全性上留下隐患。随着Agent自主性增强，授权模型从静态身份向动态意图演进，将成为一个持续的工程方向。