【免费下载链接】agentshieldAI agent security scanner. Detect vulnerabilities in agent configurations, MCP servers, and tool permissions. Available as CLI, GitHub Action, ECC plugin, and GitHub App integration. ️项目地址https://gitcode.com/gh_mirrors/ag/agentshield点击查看免费下载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.mdAgent 不应仅仅因为代表人类行事就继承人类那套宽泛的权限。这正是 RBAC 的盲区也是本文主角ReBACRelationship-Based Access Control基于关系的访问控制登场的地方。核心概念什么是 ReBAC 与 OpenFGAReBAC把权限建模为一张关系图不再是角色→权限的扁平映射而是谁通过什么关系作用于什么对象。比如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 场景上面提到的三类关系全都是图的边而不是难以穷举的属性判断关系示例ReBAC 建模用户 → Agentalice 可以运行 deploy-botoperator关系团队 membership 可传递Agent → 工具/MCPdeploy-bot 可调用 create_prcaller关系MCP 服务器授权可流向其下属工具Agent → Agentplanner 委托 executordelegate关系委托是一条边不是一次策略重写授权架构PEP 与 PDP 如何分工整个运行时架构可以概括为四步PEP策略执行点API 网关只做两件事——转发 Agent 身份和它请求的工具操作并执行最终放行/403PDP策略决策点把请求映射成(user, relation, object, context)四元组携带环境、风险等级等上下文OpenFGA执行Check或BatchCheck返回 allowed: true/false审计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再查一次这是最容易踩坑的地方BatchCheckPDP 预过滤即将提供给 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引擎模型条件/属性适配 Agent 图备注OpenFGAZanzibar ReBACCEL 条件 上下文元组⭐ 强Postgres/MySQL5 个官方 SDKApache-2.0SpiceDBZanzibar ReBACCaveats (CEL)⭐ 强另一套 schema 语法商业厂商 AuthzedOry KetoZanzibar ReBAC有限中生态较小条件能力弱Cedar策略语言原生中策略而非元组动态委托图较弱OPA / Rego通用策略语言原生中需手动推数据无内建关系图与反向查询选择 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 设计规划你的授权图从第一条元组写起。赞分享【免费下载链接】agentshieldAI agent security scanner. Detect vulnerabilities in agent configurations, MCP servers, and tool permissions. Available as CLI, GitHub Action, ECC plugin, and GitHub App integration. ️项目地址https://gitcode.com/gh_mirrors/ag/agentshield点击查看免费下载相关推荐Gitpod SpiceDB 组件深度解析基于 ReBAC 的细粒度授权模型与实现Gitpod SpiceDB 组件深度解析基于 ReBAC 的细粒度授权模型与实现 导读本文以 Gitpod 仓库中 components/spicedb开发工具后端云原生OpenFGA完全指南如何构建企业级细粒度授权系统OpenFGA完全指南如何构建企业级细粒度授权系统 OpenFGA是一个开源的高性能细粒度授权引擎专为现代微服务架构设计。它能够帮助开发者在应用程序中轻松建认证鉴权后端API 设计中的基于属性访问控制ABAC细粒度授权模型的原理、策略与落地实践API 设计中的基于属性访问控制ABAC细粒度授权模型的原理、策略与落地实践 导读本文以 developer roadmap 仓库中 ABAC 主题文档文档教程知识库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
