给 AI 分配权限时，为什么岗位角色还不够

同样是销售经理，有人负责华东客户，有人刚加入一个联合项目，有人只在本周代班。若 AI 权限只按“销售经理”这一岗位发放，三个人可能拿到相同资料范围。岗位角色适合表达稳定职责，但项目关系、资料密级和临时协作状态往往决定一次具体访问能否成立。

角色可以做起点，不能代替全部条件

OWASP 授权指南介绍了基于角色、属性和关系的访问控制。把它们用于文档 AI，角色可以说明员工通常能执行什么操作；属性可以约束资料类别、组织和时间；关系可以说明员工是否属于某个项目或被邀请参与协作。团队不必一开始就建设复杂策略平台，但需要承认，一个岗位名称无法表达所有业务边界。

选一条高风险规则做小规模验证

例如，企业希望销售人员只用 AI 处理自己负责客户的受限报价。可先写成业务句子：“销售角色、属于该客户项目、授权仍有效，并且选用已批准的处理环境，才允许访问。”这句话应由业务和数据负责人共同确认，再交给技术实现。规则中每个条件都要有可信数据来源，不能让员工在提示词中自行声明“我属于项目组”。

随后设计四个人工样本：角色正确但项目不符、项目正确但授权过期、全部条件满足、资料没有分类。最后一类尤其重要。属性缺失时应采用明确的保守处理或复核流程，不能因为无法判断就默认放行。测试使用虚构文件和测试账号，既能覆盖拒绝路径，也避免在验证过程中暴露真实业务资料。

复杂度主要来自维护

增加属性并不会自动提高安全性。项目成员表长期不更新，错误标签在部门间复制，或者代班授权没有到期机制，都可能使看似精细的规则失去意义。因此，每种条件必须有维护人、更新时间和异常处理方式。团队应关注哪项基础数据经常过期，再决定是否值得把它接入自动授权。

权限复核也应按业务变化触发。员工调岗、项目结束、资料级别提高和模型处理范围变化，都可能让旧规则失效。OWASP 提醒要定期审查权限膨胀，企业可据此安排与自身风险相匹配的检查节奏，而不是照搬一个所有岗位通用的周期。

当规则难以向业务解释时，先减少例外，把一组稳定场景做清楚。验收时要求展示“为什么允许”和“为什么拒绝”，并能指出决定结果的角色、属性或关系。岗位权限与业务上下文结合之后，AI 才能在员工实际职责内工作；具体规则能力仍需在所用系统中验证。

参考资料

• Agent identity concepts in Microsoft Foundry
• OWASP Authorization Cheat Sheet