授权模型只回答一件事：谁，能对什么，做什么。RBAC（Role-Based Access Control，基于角色的访问控制）和 ABAC（Attribute-Based Access Control，基于属性的访问控制）是两种主流解法。
RBAC：先分角色，再发权限
像公司门禁：你是财务部员工，行政发你一张“财务部”的卡，这张卡能进财务区。你不直接拥有权限，你的角色拥有权限。
结构是三层：用户 → 角色 → 权限。给人配角色，给角色配权限。来一百个新财务，挂上“财务”角色就行；要收权，改角色，一百人同时生效。代价是角色会膨胀：财务专员、华东财务专员、只读财务专员……最后没人说得清谁能干什么。
ABAC：不看身份，看条件
ABAC 当场算属性：主体（部门、职级）、资源（密级）、动作（读/写）、环境（时间、IP、设备）。条件是“部门=财务 且 在工作日 且 走内网”，全部成立才放行。
放到智能体上：客服 Agent 能查工单、发邮件、发起退款。用 RBAC 给它一个“客服助手”角色，允许查询和发邮件、不允许退款，粗粒度够了。但业务常要求“可以退款，只要金额低于阈值、订单属于它负责的地区、且状态已审核”。这种带条件的规则写成角色会爆炸，写成 ABAC 策略一条就够。实践中多是两者混用：RBAC 定框架，ABAC 卡细节。
| 维度 | RBAC | ABAC |
|---|---|---|
| 判断依据 | 用户所属角色 | 主体/资源/环境属性 |
| 维护成本 | 低，改角色即生效 | 高，属性与策略要治理 |
| 灵活性 | 一般，角色易膨胀 | 高，能表达复杂条件 |
| 典型场景 | 部门、岗位级授权 | 金额、时间、地域等约束 |
顺带划边界：认证（Authentication）回答“你是谁”，授权（Authorization）回答“你能干什么”，RBAC 与 ABAC 都属于授权；更早的 ACL（Access Control List，访问控制列表）是逐条资源记名单，资源一多就难维护。
对做 AI 的人意味着什么
第一，把最小权限原则（Least Privilege）落到 Agent 上：默认不给，按需给；能只读就不给写，能读一张表就不给整库，能限额就不给无限额。
第二，权限是最后一道闸。Agent 会被提示注入（AI 词典：Prompt Injection">Prompt Injection）带偏，模型层面难有百分百的可靠，真正兜底的是“它就算被骗了也没这个权限”。
第三，留审计。每次工具调用记清：哪个 Agent、以什么角色或属性、调了什么、结果如何。没日志，越权了也查不出来。
选型不必比谁先进：岗位稳定、规则简单，RBAC 够用；规则跟金额、时间、地域强相关，就上 ABAC。具体平台对角色和策略的支持各有差异，落地以官方页面为准。
自检一句：先想“这个 Agent 最坏能造成多大破坏”，再倒推它需要哪些权限。