4. 权限模型设计

在 Agent 操作执行权限控制中，权限模型决定了“谁在什么条件下能做什么”。三个主流模型——基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）、基于关系的访问控制（ReBAC）——在粒度、动态性、管理复杂度上截然不同。本章从架构视角拆解三者的模块边界、系统分层、组件职责、数据流/控制流/信任链路，并给出选型权衡、风险点、落地步骤及验收标准。

4.1 模块边界与系统分层

无论采用哪种模型，权限控制逻辑在系统中都落在 策略执行点（PEP）、策略决策点（PDP）、策略信息点（PIP）、策略管理点（PAP） 四个模块之内。其边界如下表所示：

系统分层上，自底向上分为：身份层（用户/Agent 身份）、策略存储层（角色表/属性规则/关系图）、决策层（PDP 引擎）、执行层（PEP 拦截 & 操作执行）。整个链路通过信任锚（Token / 签名）保证请求不可抵赖。

4.2 组件职责与信任链路

三种模型对应的核心组件及信任链路如下：

• RBAC：PDP 从 PAP 加载“角色-权限”二元关系；PIP 只需提供请求者角色（通常来自 JWT 中的 role 声明）。信任链依赖角色分配的管理后台和 JWT 签发。
• ABAC：PDP 解析 XACML / OPA Regolike 策略；PIP 需要从请求、资源上下文、环境（时间、IP 等）抽取属性。信任链需要属性提供方（如 LDAP、外部元数据服务）的签名验证。
• ReBAC：PDP 在关系图上执行逐跳遍历（如 Google Zanzibar 风格）；PIP 维护对象之间的 relation 边。信任链依赖图数据的一致性和变更日志。

下图展示了统一架构中三种模型的组件差异与数据流向：

4.3 数据流 / 控制流 / 信任链路

以 ABAC 为例的完整授权流程（RBAC/ReBAC 仅 PDP 决策逻辑不同）：

1. Agent 发起请求（含 Token 或身份凭证）→ PEP 拦截。
2. PEP 构造授权请求上下文（主体 ID、资源 ID、动作、环境元数据）→ 发往 PDP。
3. PDP 请求 PIP 填充动态属性（如用户部门、资源敏感等级、当前时间）。
4. PDP 从 PAP 加载对应策略（RBAC 查角色表，ABAC 评估规则集，ReBAC 执行图查询）。
5. PDP 计算决策（Permit/Deny）→ 返回 PEP。
6. PEP 执行决策结果，允许或拒绝操作。

信任链路关键点：

• Agent Token 必须由可信的 Identity Provider 签发（OIDC/JWT）。
• PDP 与 PIP 之间的通信需要 mTLS，防止上下文被篡改。
• PAP 的写操作必须经过审计和版本控制。

4.4 选型权衡

4.5 风险点

• 角色爆炸（RBAC）：角色数量随资源维度增长，陷入细粒度陷阱。缓解：引入属性补充或分层角色。
• 策略冲突（ABAC）：多条规则可能同时匹配且结果相反，需定义冲突解决算法（Deny-overrides / Permit-overrides）。
• 关系泄露（ReBAC）：遍历关系图时可能暴露未授权的资源存在性，需设计隐私保护查询（如元组掩盖）。
• PDP 性能退化：ABAC/ReBAC 在高并发下评估耗时长，需引入策略缓存（带 TTL 失效）和异步 PDP。

4.6 落地步骤

1. 业务场景分析：梳理 Agent 操作所需的最小权限集，识别动态条件与关系依赖。
2. 模型选型：根据 权衡表 选择主模型（可混用，如 RBAC 做基础，ABAC 做异常覆盖）。
3. 策略存储设计：
   • RBAC：建表 agent_roles, role_permissions
   • ABAC：定义策略 DSL 并部署 OPA / AuthzForce
   • ReBAC：搭建关系图数据库（如 Neo4j 或 Spanner 模拟）并定义 Relation 模式
4. PDP 引擎集成：将决策点作为独立服务，通过 gRPC 暴露 Decide(requestContext) → Decision 接口。
5. PEP 植入：在 Agent 执行框架的拦截器（如 FastAPI middleware）中调用 PDP。
6. 安全强化：启用 mTLS、策略变更审计日志、Token 绑定。
7. 性能压测：使用工具（如 Locust）模拟高并发，调整缓存大小和决策树优化。

4.7 验收标准