ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Go 执行权限环(Execution Rings)实战:用四级特权环为 AI Agent 构建默认拒绝的运行时访问控制

Go 执行权限环(Execution Rings)实战:用四级特权环为 AI Agent 构建默认拒绝的运行时访问控制 Go 执行权限环Execution Rings实战用四级特权环为 AI Agent 构建默认拒绝的运行时访问控制【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit本文基于 agent-governance-toolkit 仓库中 Go 模块 AgentMesh 的execution-rings示例系统讲解四执行环Ring 0Ring 3特权模型的配置、分配与访问判定机制。读完本文你将掌握如何用NewRingEnforcer、Assign、GetRing、CheckAccess、SetRingPermissions五个核心 API 为多 Agent 场景构建可预测的最小权限管控并理解未分配即默认拒绝的安全语义及其与 kill switch、策略引擎的组合用法。为什么运行时需要执行环而不是纯 RBAC在 AI Agent 运行时权限控制发生在代码正在执行的过程中而不只是判断这个角色属于谁。仓库中的 ADR 0002Use four execution rings instead of RBAC for runtime privilege 明确记录了这一设计决策的背景The runtime needs to decide what an agent may do while code is executing, not just what role it belongs to. ... static roles alone do not model runtime risk, reversibility, or trust decay.也就是说静态角色无法表达运行时风险、操作可逆性与信任衰减。执行环提供了一个更小、可预测的特权格privilege lattice直接映射到爆炸半径blast radiusRBAC 仍然存在于仓库中用于面向人的管理、合规映射与 IATP 作用域但运行时沙箱化实时执行的主机制是四级执行环环比完整角色建模更粗糙因此细粒度授权仍需由能力策略、作用域与审批流叠加实现。四级特权环模型从 Ring 0 到 Ring 3四环模型定义在 agent-governance-golang/packages/agentmesh/rings.go 中是一个基于整数的常量枚举数值越小权限越高// Ring represents an execution privilege level (0 most privileged). type Ring int const ( RingAdmin Ring 0 RingStandard Ring 1 RingRestricted Ring 2 RingSandboxed Ring 3 )常量数值语义示例权限RingAdmin0通配权限wildcard*任意 actionRingStandard1读 写data.read、data.writeRingRestricted2只读data.readRingSandboxed3无任何 action空权限集环的粒度比角色粗但足够表达分级访问、未知 Agent 的安全默认值和清晰的升级规则无需为每个 Agent 发明大量专属角色这让策略解释与违规检测更简单。核心 API 与底层实现执行环的全部逻辑集中在单个文件 rings.go 中核心数据结构是一个带读写锁的RingEnforcertype RingEnforcer struct { mu sync.RWMutex assignments map[string]Ring // agentID - ring permissions map[Ring]map[string]bool // ring - allowed actions }1.NewRingEnforcer()— 创建空执行器返回一个空分配、零默认权限的执行器任何 Agent 都不会隐式获得权限func NewRingEnforcer() *RingEnforcer { return RingEnforcer{ assignments: make(map[string]Ring), permissions: make(map[Ring]map[string]bool), } }2.SetRingPermissions(ring, allowedActions)— 配置环权限用给定的 action 列表整体替换某个环的允许集func (r *RingEnforcer) SetRingPermissions(ring Ring, allowedActions []string) { r.mu.Lock() defer r.mu.Unlock() perms : make(map[string]bool, len(allowedActions)) for _, a : range allowedActions { perms[a] true } r.permissions[ring] perms }注意语义是替换而非追加重复调用会覆盖该环之前的配置。3.Assign(agentID, ring)— 将 Agent 放入环一个 Agent 在同一时刻只属于一个环再次调用Assign会直接覆盖其旧环这在TestReassignRing中有所验证func (r *RingEnforcer) Assign(agentID string, ring Ring) { r.mu.Lock() defer r.mu.Unlock() r.assignments[agentID] ring }4.GetRing(agentID)— 查询 Agent 所在环返回两个值环编号与是否已分配。第二个返回值是区分未分配 Agent的关键func (r *RingEnforcer) GetRing(agentID string) (Ring, bool) { r.mu.RLock() defer r.mu.RUnlock() ring, ok : r.assignments[agentID] return ring, ok }5.CheckAccess(agentID, action)— 访问判定判定逻辑遵循先查分配、再查权限、最后处理通配的顺序任何一步失败即返回falsefunc (r *RingEnforcer) CheckAccess(agentID string, action string) bool { r.mu.RLock() defer r.mu.RUnlock() ring, ok : r.assignments[agentID] if !ok { return false } perms, ok : r.permissions[ring] if !ok { return false } // Wildcard permission grants everything. if perms[*] { return true } return perms[action] }关键细节未分配的 Agent 直接返回false——没有隐式环没有隐式权限已分配但环未配置权限的 Agent 也返回falseTestDefaultDenyNoPermissions验证了这一点*通配条目放行一切 action这是RingAdmin的实现方式。完整示例配置四个环并分配五个 Agent示例源码位于 agent-governance-golang/examples/execution-rings/main.go完整展示了上述 API 的配合使用。核心逻辑如下enforcer : agentmesh.NewRingEnforcer() enforcer.SetRingPermissions(agentmesh.RingAdmin, []string{*}) enforcer.SetRingPermissions(agentmesh.RingStandard, []string{data.read, data.write}) enforcer.SetRingPermissions(agentmesh.RingRestricted, []string{data.read}) enforcer.SetRingPermissions(agentmesh.RingSandboxed, []string{}) enforcer.Assign(admin-agent, agentmesh.RingAdmin) enforcer.Assign(worker-agent, agentmesh.RingStandard) enforcer.Assign(readonly-agent, agentmesh.RingRestricted) enforcer.Assign(sandboxed-agent, agentmesh.RingSandboxed) agents : []string{admin-agent, worker-agent, readonly-agent, sandboxed-agent, unassigned-agent} actions : []string{data.read, data.write, system.shutdown} for _, agent : range agents { ring, assigned : enforcer.GetRing(agent) ringLabel : fmt.Sprintf(%d, ring) if !assigned { ringLabel - } fmt.Printf(%-20s %-8s, agent, ringLabel) for _, a : range actions { fmt.Printf( %-16v, enforcer.CheckAccess(agent, a)) } fmt.Println() }运行方式在agent-governance-golang/examples/execution-rings/目录下go run .预期输出agent ring data.read data.write system.shutdown admin-agent 0 true true true worker-agent 1 true true false readonly-agent 2 true false false sandboxed-agent 3 false false false unassigned-agent - false false false对这张判定网格的逐行解读admin-agentRing 0*通配权限使其对三个 action 全部放行包括高危的system.shutdownworker-agentRing 1拥有data.read与data.write但无法触发system.shutdownreadonly-agentRing 2只能data.read写操作被拒sandboxed-agentRing 3空权限集任何 action 都被拒绝unassigned-agent从未调用Assign因此环标签显示-未分配三个 action 全部被拒绝——这是默认拒绝语义的直接体现。Note: unassigned agents are denied by default — no implicit ring, no implicit permissions.源码测试默认拒绝与通配语义的可验证保障与 rings.go 同目录的 rings_test.go 用 8 个测试用例锁定了执行环的全部关键行为TestAssignAndGetRing分配后GetRing返回对应环TestGetRingUnassigned未分配 Agent 的ok返回falseTestCheckAccessAllowed/TestCheckAccessDenied权限命中与未命中TestDefaultDenyUnassigned即使给RingAdmin配了*未分配的nobody对任何 action 依然是拒绝TestDefaultDenyNoPermissions已分配但环没有权限配置时拒绝TestWildcardPermission*放行任意 actionany.action.at.allTestReassignRing将 Agent 从RingAdmin重新分配到RingSandboxed后权限立即从全放行变为全拒绝。这些测试从反面印证了设计目标环权限是可预测、可枚举的未知 Agent 与未知 action 的默认结果都是拒绝。与周边模块组合纵深防御管线执行环不是孤立存在的它与 kill switch、策略引擎共同构成多级防护。示例之间的Where to go next明确给出了组合方式先过 kill switch再查环权限kill-switch-scopes 示例 演示了全局 / Agent / 能力三级 kill switch。其 README 明确指出ring assignment is evaluatedafterkill switches in the pipeline; combine them for defence-in-depth.也就是说在治理管线中 kill switch 先生效——无论 Agent 属于哪个环一旦命中激活的 kill switch 作用域就会被直接阻断环分配在 kill switch 之后才参与判定。这构成了第一层紧急熔断 第二层常规最小权限的组合。用策略文件驱动哪个 action 落入哪个环policy-yaml 示例 展示了如何用 YAML 策略替代硬编码权限。其语义是drivewhichring an action falls into from a policy file rather than hard-coded permissions.环决定Agent 能做什么策略决定某个 action 属于什么等级两者分工互补。七子系统组合的完整管线如果只想看一个例子理解 SDK 如何拼装full-stack 示例 将身份、环、信任、策略、kill switch、审计、SLO 七个子系统组合进标准中间件栈data.read放行、data.write审查、system.shutdown拒绝依次执行随后激活能力级 kill switch 阻断下一次data.read最后输出 SLO 报告、审计链校验结果与信任分——展示的正是各模块在真实管线中的交互顺序。在 SDK 中的 API 定位与使用建议执行环 API 在 AgentMesh Go 模块 README 中与身份、信任、策略、审计、客户端等模块并列安装方式为go get github.com/microsoft/agent-governance-toolkit/agent-governance-golang其 API 速览函数 / 方法说明NewRingEnforcer()创建环执行器(*RingEnforcer).Assign(agentID, ring)将 Agent 放入指定环(*RingEnforcer).GetRing(agentID)获取 Agent 的环(*RingEnforcer).CheckAccess(agentID, action)检查 action 是否被允许(*RingEnforcer).SetRingPermissions(ring, actions)配置环权限实践建议均以仓库代码与测试为据永远先配置权限再分配 Agent避免 Agent 处于已分配但环权限缺失的意外状态虽然后者同样默认拒绝但配置顺序清晰更利于审计对未知 Agent 保持零信任不调用Assign即默认拒绝这正是默认安全的体现Ring 0 的*是最高危配置只应授予完全可信的系统级 Agent把环与 kill switch、策略引擎叠加使用形成熔断 → 环权限 → 细粒度策略的纵深防御管线环粒度较粗细粒度授权仍需叠加能力策略、作用域与审批流见 ADR 0002 的 Consequences 说明。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表