企业官网建设流程全解析

AgentShield 是一款面向 AI Agent 的安全扫描器，能检测 Agent 配置、MCP 服务器和工具权限中的漏洞。当 Agent 从"单兵作战"走向团队协作，仅靠静态扫描还不够——权限必须做到细粒度。本文展望一条可行路线：用 AgentShield 扫描产出的"授权素材"，加上 OpenFGA 这套基于 ReBAC 的关系型访问控制引擎，为 AI Agent 构建"谁能运行哪个 Agent、哪个 Agent 能调用哪个工具"的完整授权设计。

为什么 RBAC 挡不住 AI Agent 的权限问题

传统 RBAC（基于角色的访问控制）回答的是"这个角色能做什么"。但 AI Agent 的权限问题远比这复杂：

• 🤖Agent 要调用工具：deploy-bot 能开 GitHub PR，但不能查生产数据库
• 🔗Agent 之间要委托：planner 可以把任务委托给 executor，但委托不等于继承全部权限
• 🎚️风险等级要动态约束：同一个工具，在 dev 环境放开，在 prod 环境要受限

关键一句话来自 AgentShield 的设计笔记（openfga-agent-authorization.md）：

"Agent 不应仅仅因为代表人类行事，就继承人类那套宽泛的权限。"

这正是 RBAC 的盲区，也是本文主角ReBAC（Relationship-Based Access Control，基于关系的访问控制）登场的地方。

核心概念：什么是 ReBAC 与 OpenFGA

ReBAC把权限建模为一张关系图：不再是"角色→权限"的扁平映射，而是"谁，通过什么关系，作用于什么对象"。比如alice —operator→ agent:deploy-bot、agent:deploy-bot —caller→ tool:github.create_pr，三条关系就构成了一张完整的授权图。

OpenFGA是一个 Apache-2.0 许可的开源 ReBAC 引擎，灵感来自 Google Zanzibar 论文。它存储user, relation, object三元组，支持Check（单次判定）、BatchCheck（批量判定）、ListObjects（列出对象）等查询，可部署在 PostgreSQL 14+ 或 MySQL 8 上，官方提供 Go、Node.js、Python、Java、.NET 五套 SDK，已被 Auth0 FGA 用于生产环境。

为什么 ReBAC 天生契合 Agent 授权

OpenFGA 官方文档将 ReBAC 描述为"RBAC 的超集，且当属性以关系形式表达时原生覆盖 ABAC 场景"。落到 Agent 场景，上面提到的三类关系全都是图的边，而不是难以穷举的属性判断：

授权架构：PEP 与 PDP 如何分工

整个运行时架构可以概括为四步：

1. PEP（策略执行点）：API 网关只做两件事——转发 Agent 身份和它请求的工具操作，并执行最终放行/403
2. PDP（策略决策点）：把请求映射成(user, relation, object, context)四元组，携带环境、风险等级等上下文
3. OpenFGA：执行Check或BatchCheck，返回 allowed: true/false
4. 审计：PDP 记录决策与审计日志，OpenFGA 全程看不到任何 prompt 或 payload 内容

这个分层很重要：授权引擎只处理"关系 + 属性"，Agent 的业务数据永远不进入授权链路。

设计核心：一个可运行的授权模型

设计笔记中给出了一套覆盖完整 Agent 场景的模型，核心类型包括user、team、agent、mcp_server和tool，几个关键设计点值得展开：

1️⃣ 委托是关系，不是继承

allowed_agent ... or delegate from allowed_agent让授权沿委托链自然流动：如果 planner 被允许接入某 MCP 服务器，它的委托者 executor 也能接入。但 PDP 仍要求委托方以显式元组存在——图里没有任何"隐式继承"。

2️⃣ 环境与风险等级用条件表达式表达

caller: [agent with env_and_tier_ok, agent]这一行的妙处在于：授权可以附带条件，比如"元组里存了 dev 环境与风险等级 ≤ 2"，请求时校验tuple_env == request_env && request_tier <= max_tier。风险分级（ABAC 味道最浓的部分）由此内联进同一张图，不需要第二套策略语言。

3️⃣ 一次 Check 长什么样

PDP 发出的判定请求携带请求上下文和"临时上下文元组"（如当前会话的团队 membership，单请求上限 100 条）：

{ "tuple_key": { "user": "agent:deploy-bot", "relation": "can_invoke", "object": "tool:github.create_pr" }, "context": { "request_env": "prod", "request_tier": 2 } }

值得注意的细节：

• 一致性旋钮：默认MINIMIZE_LATENCY可能命中缓存；撤销授权后立即用HIGHER_CONSISTENCY再查一次，这是最容易踩坑的地方
• BatchCheck：PDP 预过滤"即将提供给 Agent 的工具列表"时的利器（默认最多 50 个检查，少于约 10 个时并行Check反而更高效）
• ListObjects：直接回答"这个 Agent 能碰哪些工具"，适合每个 Agent 一份工具清单的场景

AgentShield 在其中的角色：授权的"素材供应商"

这里要划清边界：AgentShield 目前是静态扫描器，没有运行时 PEP，所以"现在没有任何东西要强制执行"。但它恰好握有构建授权图所需的两个输入：

• 工具与服务器清单：扫描产出的permissions.allow列表和解析后的mcpServers映射（类型定义见 McpConfigSchema）。每条 allow 项可映射为一个tool对象加一条caller候选元组；每个 MCP 服务器映射为一个mcp_server对象，工具作为其子节点
• 组织策略：OrgPolicy 中的banned_tools和banned_mcp_servers永远不应变成元组——导出时会被输出为显式排除清单，让审核者可以把"意图"和"图实际授予的东西"做 diff

设计笔记提议（尚未实现）的形态是一个agentshield.tuples.v1JSON 文档，与 policy-export 中现有的agentshield.policy-export.v1清单并列，包含候选元组、来源发现项 ID 和扫描 sha256。"候选"意味着最终写入由人来完成，而不是扫描器自动写图。

另一个远期设想：promotePolicyPack 未来可以在策略包晋升前追加一个门禁——除非Check(user:<promoter>, can_promote, policy_pack:<id>)返回 allowed，晋升流程直接失败。这样一来，晋升策略包的权力与 Agent 的权力住在同一张图里，审计证据包（evidence-pack）会记录authorization_model_id和判定结果。

选型对比：为什么是 OpenFGA

选择 OpenFGA 的理由很直接：关系模型与 Agent 图一一映射；委托只是加一条边，不是重写策略；ListObjects白送一个"这个 Agent 能碰什么"的视图；且可自托管、协议开放。

落地路线图：现在、之后、更远

⚠️ 必须强调：截至本文写作，这仍是纯研究阶段，设计文档明确写着"现在扫描器中不发布任何相关代码"。路线图如下：

• 📌现在：只做文档——把扫描产出的 allow 清单和 MCP 清单到候选元组的映射写清楚，让未来导出器有一份稳定契约
• 🔧之后：当 AgentShield 长出运行时执行路径（PEP），引入 OpenFGA 作为 PDP 背后的引擎；模型须先通过fga model validate和store test验证
• 🚀更远：元组导出器（agentshield.tuples.v1）、晋升门禁 Check、仓库内 SDK 依赖——每一项在 PEP 存在前都单独跟踪、单独交付

风险提示：别忽略 ReBAC 的另一面

诚实的设计文档同样列出了代价：

• 多一个有状态服务：OpenFGA + Postgres 都要运维
• 元组卫生成为长期职责：过期授权（stale grants）是全新的故障模式
• 一致性旋钮容易用错：撤销后忘了切换HIGHER_CONSISTENCY，权限"撤销了但其实没有"
• 参考实现只是 demo：社区 agentic-authz 参考仓库明确声明"不是可直接上生产的授权系统"

写在最后

细粒度授权不是 AI Agent 生态的"加分项"，而是它能否进入生产环境的入场券。AgentShield 用 102 条规则在静态层面守住配置安全的第一道门；而 ReBAC + OpenFGA 的设计，为"运行时的每一次工具调用都过一道关系判定"给出了完整的图纸。两者合起来，才是 AI Agent 授权的未来全貌：

扫描器负责发现"你给了多少"，关系图负责裁决"此刻该给多少"。

如果你正在构建多 Agent 系统，不妨从 AgentShield 的一次扫描开始，看看你的 Agent 到底握有多大权限，再对照这套 ReBAC 设计，规划你的授权图从第一条元组写起。