Agent Governance Toolkit 动手实验指南原生 ACS 策略与多智能体信任实战【免费下载链接】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 官方 Workshop 的 lab-guide.md带你完整体验其两个核心实验Lab 1 原生 ACS 策略用 Agent Control Specification 清单 Rego 策略对工具调用做实时放行/拒绝裁决与Lab 2 多智能体信任用 AgentMesh 构建身份、握手、信誉与吊销闭环。读完本文你将掌握 ACS 干预点绑定与 Rego deny 条件的编写方法、AgentMesh 信任握手与风险评分的完整调用链并能独立运行两个实验脚本、完成扩展练习。Workshop 全套材料位于 docs/workshop/ 目录包含幻灯片 slides.md、参与者实验指南 lab-guide.md、讲师手册 facilitator-notes.md 与前置准备清单 prerequisites.md。建议在动手前先完成环境准备。一、实验环境准备两个实验均在 Python 3.10 环境中运行。按 prerequisites.md 的要求创建虚拟环境并安装完整工具包python -m venv agt-workshop source agt-workshop/bin/activate # macOS / Linux # agt-workshop\Scripts\activate # Windows PowerShell pip install agent-governance-toolkit[full]验证三个关键 API 是否就绪对应三个独立的控制平面组件python -c from agent_control_specification import validate_manifest; print(native policy API OK) python -c from agentmesh import AgentIdentity; print(agentmesh-platform OK) python -c import agent_governance; print(agent-governance-toolkit OK)其中agent_control_specification原生 ACS Python SDK与agentmeshAgentMesh 平台是 Lab 1、Lab 2 分别依赖的核心库。实验脚本位于 docs/workshop/labs/。注Lab 1 的 Rego 策略由 OPA 执行需确保opaCLI 在PATH中原生 ACS 包未安装、manifest 中 bundle 路径被改动而未同步移动 Rego 文件是讲师手册 facilitator-notes.md 中列出的两个最常见问题。二、Lab 1原生 ACS 策略Native ACS Policy2.1 实验文件与目标Lab 1 涉及三个文件文件作用docs/workshop/labs/lab1-manifest.yamlACS 清单声明策略引擎、Rego bundle、干预点绑定docs/workshop/labs/lab1-policy.regoRego 策略定义三个 deny 条件与默认 allowdocs/workshop/labs/lab1_first_policy.pyPython 宿主加载 manifest驱动多组工具型输入做裁决目标运行原生 manifest观察对工具形态输入tool-shaped input的 allow / deny 裁决。ACS 的思想是策略决策由清单声明、由宿主强制宿主在每个干预点把完整快照交给 ACS 运行时再执行返回的裁决见 docs/tutorials/55-agent-control-specification.md 的 How ACS fits in AGT 一节。2.2 阅读 manifest识别input干预点绑定打开 lab1-manifest.yaml核心结构如下agent_control_specification_version: 0.4.0-alpha.1 metadata: name: workshop-lab1 version: 1.0 extends: [] policies: workshop: type: rego bundle: . query: data.agt.workshop.lab1.result intervention_points: input: policy_target: $.input.body policy: id: workshop逐项解读policies.workshop声明一个名为workshop的 Rego 策略bundle: .表示从 manifest 同目录加载 bundlequery指向 Rego 包内data.agt.workshop.lab1.result这个查询结果。intervention_points.input定义名为input的干预点。宿主在输入进入会话这一时点把快照交给策略引擎。policy_target: $.input.bodyJSONPath 表达式指明策略引擎实际看到的快照切片——即宿主输入快照的input.body字段对应宿主传入的body{tool_name: ..., token_count: ...}。policy.id: workshop把input干预点绑定到上面的 Rego 策略。这个设计回答了实验讨论题为什么由 manifest 拥有策略绑定干预点与策略的绑定关系是声明式配置宿主代码只负责在什么时机调evaluate策略如何裁决、绑定到哪个策略全部收敛在 manifest 中换策略不需要改宿主代码。2.3 阅读 Rego 策略识别三个 deny 条件打开 lab1-policy.regopackage agt.workshop.lab1 import rego.v1 result : { decision: deny, reason: code_execution_blocked, } if { input.policy_target.value.tool_name execute_code } else : { decision: deny, reason: write_operation_blocked, } if { startswith(input.policy_target.value.tool_name, write_) } else : { decision: deny, reason: token_budget_exceeded, } if { input.policy_target.value.token_count 2000 } else : { decision: allow, reason: safe, }三个 deny 条件按优先级从上到下短路求值代码执行拦截tool_name execute_code→deny / code_execution_blocked。直接命中高风险代码执行工具。写操作拦截startswith(tool_name, write_)→deny / write_operation_blocked。任何以write_开头的工具名都被视为写操作并拒绝这是前缀匹配的批量拦截模式。预算超限拦截token_count 2000→deny / token_budget_exceeded。按输入快照中携带的 token 计数做预算管控。都不命中时落到默认allow / safe。注意策略读取的字段input.policy_target.value.tool_name与.token_count——这正是 manifest 中policy_target: $.input.body决定的切片结构value即 body 本身这是实验第 5 步要求你解释的策略读了哪个输入字段的答案。2.4 运行实验并核对裁决执行脚本python docs/workshop/labs/lab1_first_policy.py脚本核心逻辑lab1_first_policy.py定义了 5 组场景(tool_name, token_count)SCENARIOS ( (read_customer_data, 100), (execute_code, 50), (write_database, 200), (read_reports, 3000), (read_inventory, 150), )随后通过 ACS 宿主 API 加载 manifest 并逐条裁决manifest Path(__file__).with_name(lab1-manifest.yaml) runtime AgentControl.from_path(str(manifest)) session HostSession( runtime, agent_idworkshop-agent, session_idlab1, ) for tool_name, token_count in SCENARIOS: evaluation session.input( body{tool_name: tool_name, token_count: token_count} ) print( f{evaluation.verdict:5} f{tool_name:20} ftokens{token_count:4} f{evaluation.verdict.reason} )对照三个 deny 条件可预期输出read_customer_data/ tokens100 →allow非写操作、未超预算execute_code/ tokens50 →denyreasoncode_execution_blocked尽管 token 少条件 1 优先命中write_database/ tokens200 →denyreasonwrite_operation_blockedread_reports/ tokens3000 →denyreasontoken_budget_exceededread_前缀放行但预算超限read_inventory/ tokens150 →allow这段代码也印证了 docs/quickstart.md 中的标准宿主模式AgentControl.from_path()构建运行时HostSession(runtime, agent_id..., session_id...)打开会话session.input(...)等价于干预点evaluate返回带verdict与reason的评估结果。2.5 扩展练习新增 deny 条件实验第 5 步要求向 lab1-policy.rego 增加一个 deny 条件并重跑。例如拦截所有读取财务类数据的操作可新增} else : { decision: deny, reason: sensitive_read_blocked, } if { startswith(input.policy_target.value.tool_name, read_) contains(input.policy_target.value.tool_name, finance) }重跑脚本后read_finance_ledger这类输入将命中sensitive_read_blocked。这个练习验证了 Rego 的增量 else 链语法新条件只要插在默认 allow 之前即可按优先级参与裁决。2.6 源码佐证会话计数器与运行时职责分离实验讨论题还问了为什么由HostSession拥有计数器和如果策略调度器或 OPA 进程失败会怎样。从源码看HostSession是会话级状态的载体而AgentControl运行时本身不持有会话计数。框架适配层 agent-governance-python/agent-os/src/agent_os/integrations/_native_adapter_runtime.py 中的NativeAdapterRuntime._session_for()展示了这一点会话按session_id or agent_id缓存通过session.builder提升tool_call_count/token_count计数器max()保证不回退并在evaluate_pre_tool_call后调用session.builder.record_tool_call()计费——连被拒绝的尝试也会先计费quickstart 明确Attempted tool calls are charged before evaluation, including denied attempts。这保证了预算审计不会因策略拦截而漏记。至于失败语义Agent Governance Toolkit 遵循fail closed失败即拒绝原则策略评估出错、运行时/审批出错、动作与身份不匹配时一律 deny且对外错误信息经过脱敏参见 docs/quickstart.md 的PolicyViolationError处理与 slides 的 Fail closed 一页。因此OPA 进程挂掉的后果不是放行而是拒绝——这正是治理系统的安全默认值。三、Lab 2多智能体信任Multi-Agent Trust3.1 实验文件与目标Lab 2 只有 docs/workshop/labs/lab2_multi_agent_trust.py 一个文件它是一个带TODO标记的模板要求参与者补全四个函数。前置依赖为pip install agentmesh-platform。目标创建两个 AgentMesh 身份执行信任握手通过正向行为积累信誉最后吊销凭证并验证下一次握手失败。这与 Lab 1 形成对照ACS 决定当前动作是否允许AgentMesh 决定对端是谁、双方是什么关系——身份与策略是两个正交的控制平面facilitator-notes 中特别强调的要点。3.2 Step 1创建两个身份create_agents()AgentIdentity.create(name, sponsor, capabilities)是创建受治理智能体的主要工厂方法。在 agent-governance-python/agent-mesh/src/agentmesh/identity/agent_id.py 的源码中create()会校验name非空、sponsor为合法邮箱格式然后生成Ed25519 密钥对ed25519.Ed25519PrivateKey.generate()公钥做 Base64 编码通过AgentDID.generate(name, organization)生成DIDdid:mesh:...形式由公钥哈希生成key-sha256 前 16 位的密钥 ID私钥保存在内存不参与序列化供后续sign()使用。按注释要求补全 TODOdef create_agents() - tuple: orchestrator AgentIdentity.create( nameorchestrator, sponsoraliceexample.com, capabilities[orchestrate:agents, read:data], ) worker AgentIdentity.create( nameworker, sponsorbobexample.com, capabilities[read:data, write:reports], ) return orchestrator, worker每个身份都带一组能力声明capabilities这是后续握手时必需能力校验的依据。3.3 Step 2信任握手attempt_handshake()信任握手是Ed25519 质询/响应协议见 agent-governance-python/agent-mesh/src/agentmesh/trust/handshake.py 的模块文档。其流程在源码中可清晰还原发起方创建TrustHandshake(initiator..., responder_did..., required_capabilities..., min_trust_score...)握手生成HandshakeChallenge包含challenge_id、32 字节随机nonce、时间戳与 30 秒过期时间若require_freshnessTrue还会带上 RFC 9334 的 freshness nonce用于证据活性证明对应 ADR-0005/0009 的 liveness 机制响应方返回HandshakeResponse回显 challenge、声明agent_did、capabilities、trust_score并用自身 Ed25519 私钥对载荷签名校验通过后产出HandshakeResultverified、peer_did、trust_score、trust_level枚举verified_partner / trusted / standard / untrusted、capabilities、rejection_reason以及握手延迟latency_ms。补全 TODO模板中已给出注释掉的参考实现def attempt_handshake(initiator, responder, min_trust_score: int) - bool: result TrustHandshake( initiatorinitiator, responder_didstr(responder.did), required_capabilities[read:data], min_trust_scoremin_trust_score, ).execute() if result.trusted: print(f[OK] Handshake succeeded — session_token: {result.session_token}) return True print(f[FAIL] Handshake failed — {result.rejection_reason}) return False主流程第一次调用使用min_trust_score700。而 AgentMesh 的常量定义agent-governance-python/agent-mesh/src/agentmesh/constants.py显示TRUST_SCORE_DEFAULT 500、TIER_TRUSTED_THRESHOLD 700、TIER_VERIFIED_PARTNER_THRESHOLD 900。新建身份的默认信任分是 500低于 700 的信任层级阈值因此第一次握手必然失败——这正是实验设计的预期expected: fail目的是让参与者先观察低信任度如何阻止协作再通过 Step 3 把分数养上去。3.4 Step 3用正向行为建立信誉build_trust()RiskScoreragent-governance-python/agent-mesh/src/agentmesh/identity/risk.py提供持续风险评分分数区间 0–1000越高越安全由身份、行为、网络、合规四个分量构成并按严重度critical/high/medium/low/info加权聚合风险信号。补全 TODO循环记录 10 条正向事件def build_trust(agent, num_events: int 10) - int: scorer RiskScorer() for i in range(num_events): scorer.record_event( agent_didstr(agent.did), event_typepolicy_compliant_action, detailsfCompleted task {i 1}, ) score scorer.get_score(str(agent.did)) print(f[INFO] Trust score after {num_events} events: {score.total_score}) return score.total_score主流程随后用min_trust_score540重试握手。由于 orchestrator 的分数已从默认 500 因合规行为上升通常能通过 540 的阈值若仍失败脚本会提示增加事件数或降低阈值。3.5 Step 4吊销并验证拒绝revoke_and_verify()补全最后的 TODO吊销发起方凭证后再次握手确认返回credentials revoked原因def revoke_and_verify(initiator, responder) - None: print([INFO] Revoking initiator credentials...) initiator.revoke() attempt_handshake(initiator, responder, min_trust_score400)源码层面AgentIdentity.revoke(reason)与IdentityRegistry.revoke(did, reason)见 agent_id.py负责吊销标记被吊销的身份即使信任分足够也会在握手阶段被拒绝——吊销是比信任分更高优先级的硬性拦截这是实验第 4 步要验证的握手失败行为。facilitator-notes 提醒的常见问题是忘记记录信誉事件、阈值始终高于最新分数、以及在握手成功后未测试吊销——补全时留意这三点。3.6 讨论题要点哪些控制属于 AgentMesh 而非 ACS密码学身份DID/密钥对、信任与信誉评分、能力授予、跨智能体传输属于 AgentMesh策略定义与干预点属于 ACS见下文 Wrap-up 表格。为什么策略评估与身份验证必须分离两者回答不同问题ACS 回答这个动作在绑定策略下是否被允许AgentMesh 回答对端是谁、信任关系如何。合并会引入单点失效和职责耦合——策略层挂了不能影响身份层判定反之亦然。重建跨智能体决策需要哪些审计字段至少需要双方 DID、握手时间与延迟、能力集合、信任分与阈值、吊销状态、事件类型与详情这些字段共同构成可回放replay的决策证据链。仓库中 agent-governance-python/agent-compliance/src/agent_compliance/policy_test.py 的replay()展示了同类思路用 fixture 快照对 manifest 重放并核对预期裁决。四、总结两个实验展示的分离控制平面按 lab-guide.md 的 Wrap-up 表格两个实验完整覆盖了以下独立控制平面及其归属控制项归属方策略定义与干预点Native ACS manifest会话计数器HostSession智能体身份与信任AgentMesh框架生命周期编排Agent OS adapter资源与网络隔离SandboxConfig这套职责划分贯穿整个 Toolkit策略管能不能做身份管你是谁、可不可信会话管花了多少预算adapter 管生命周期在哪一步拦截沙箱管隔离边界。Workshop 的两个实验正是把前两块从理论落到可运行的代码。继续深入学习可前往快速开始 Quickstart —— 标准宿主模式与框架接入Framework Integrations —— 生命周期编排与适配器Agent Control Specification —— ACS 清单与 Rego 策略的完整教程Trust and Identity 与 Audit and Compliance —— 信任与审计纵深Workshop 配套材料slides.md、facilitator-notes.md、prerequisites.md【免费下载链接】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），仅供参考 Agent Governance Toolkit 动手实验指南：原生 ACS 策略与多智能体信任实战
Agent Governance Toolkit 动手实验指南原生 ACS 策略与多智能体信任实战【免费下载链接】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 官方 Workshop 的 lab-guide.md带你完整体验其两个核心实验Lab 1 原生 ACS 策略用 Agent Control Specification 清单 Rego 策略对工具调用做实时放行/拒绝裁决与Lab 2 多智能体信任用 AgentMesh 构建身份、握手、信誉与吊销闭环。读完本文你将掌握 ACS 干预点绑定与 Rego deny 条件的编写方法、AgentMesh 信任握手与风险评分的完整调用链并能独立运行两个实验脚本、完成扩展练习。Workshop 全套材料位于 docs/workshop/ 目录包含幻灯片 slides.md、参与者实验指南 lab-guide.md、讲师手册 facilitator-notes.md 与前置准备清单 prerequisites.md。建议在动手前先完成环境准备。一、实验环境准备两个实验均在 Python 3.10 环境中运行。按 prerequisites.md 的要求创建虚拟环境并安装完整工具包python -m venv agt-workshop source agt-workshop/bin/activate # macOS / Linux # agt-workshop\Scripts\activate # Windows PowerShell pip install agent-governance-toolkit[full]验证三个关键 API 是否就绪对应三个独立的控制平面组件python -c from agent_control_specification import validate_manifest; print(native policy API OK) python -c from agentmesh import AgentIdentity; print(agentmesh-platform OK) python -c import agent_governance; print(agent-governance-toolkit OK)其中agent_control_specification原生 ACS Python SDK与agentmeshAgentMesh 平台是 Lab 1、Lab 2 分别依赖的核心库。实验脚本位于 docs/workshop/labs/。注Lab 1 的 Rego 策略由 OPA 执行需确保opaCLI 在PATH中原生 ACS 包未安装、manifest 中 bundle 路径被改动而未同步移动 Rego 文件是讲师手册 facilitator-notes.md 中列出的两个最常见问题。二、Lab 1原生 ACS 策略Native ACS Policy2.1 实验文件与目标Lab 1 涉及三个文件文件作用docs/workshop/labs/lab1-manifest.yamlACS 清单声明策略引擎、Rego bundle、干预点绑定docs/workshop/labs/lab1-policy.regoRego 策略定义三个 deny 条件与默认 allowdocs/workshop/labs/lab1_first_policy.pyPython 宿主加载 manifest驱动多组工具型输入做裁决目标运行原生 manifest观察对工具形态输入tool-shaped input的 allow / deny 裁决。ACS 的思想是策略决策由清单声明、由宿主强制宿主在每个干预点把完整快照交给 ACS 运行时再执行返回的裁决见 docs/tutorials/55-agent-control-specification.md 的 How ACS fits in AGT 一节。2.2 阅读 manifest识别input干预点绑定打开 lab1-manifest.yaml核心结构如下agent_control_specification_version: 0.4.0-alpha.1 metadata: name: workshop-lab1 version: 1.0 extends: [] policies: workshop: type: rego bundle: . query: data.agt.workshop.lab1.result intervention_points: input: policy_target: $.input.body policy: id: workshop逐项解读policies.workshop声明一个名为workshop的 Rego 策略bundle: .表示从 manifest 同目录加载 bundlequery指向 Rego 包内data.agt.workshop.lab1.result这个查询结果。intervention_points.input定义名为input的干预点。宿主在输入进入会话这一时点把快照交给策略引擎。policy_target: $.input.bodyJSONPath 表达式指明策略引擎实际看到的快照切片——即宿主输入快照的input.body字段对应宿主传入的body{tool_name: ..., token_count: ...}。policy.id: workshop把input干预点绑定到上面的 Rego 策略。这个设计回答了实验讨论题为什么由 manifest 拥有策略绑定干预点与策略的绑定关系是声明式配置宿主代码只负责在什么时机调evaluate策略如何裁决、绑定到哪个策略全部收敛在 manifest 中换策略不需要改宿主代码。2.3 阅读 Rego 策略识别三个 deny 条件打开 lab1-policy.regopackage agt.workshop.lab1 import rego.v1 result : { decision: deny, reason: code_execution_blocked, } if { input.policy_target.value.tool_name execute_code } else : { decision: deny, reason: write_operation_blocked, } if { startswith(input.policy_target.value.tool_name, write_) } else : { decision: deny, reason: token_budget_exceeded, } if { input.policy_target.value.token_count 2000 } else : { decision: allow, reason: safe, }三个 deny 条件按优先级从上到下短路求值代码执行拦截tool_name execute_code→deny / code_execution_blocked。直接命中高风险代码执行工具。写操作拦截startswith(tool_name, write_)→deny / write_operation_blocked。任何以write_开头的工具名都被视为写操作并拒绝这是前缀匹配的批量拦截模式。预算超限拦截token_count 2000→deny / token_budget_exceeded。按输入快照中携带的 token 计数做预算管控。都不命中时落到默认allow / safe。注意策略读取的字段input.policy_target.value.tool_name与.token_count——这正是 manifest 中policy_target: $.input.body决定的切片结构value即 body 本身这是实验第 5 步要求你解释的策略读了哪个输入字段的答案。2.4 运行实验并核对裁决执行脚本python docs/workshop/labs/lab1_first_policy.py脚本核心逻辑lab1_first_policy.py定义了 5 组场景(tool_name, token_count)SCENARIOS ( (read_customer_data, 100), (execute_code, 50), (write_database, 200), (read_reports, 3000), (read_inventory, 150), )随后通过 ACS 宿主 API 加载 manifest 并逐条裁决manifest Path(__file__).with_name(lab1-manifest.yaml) runtime AgentControl.from_path(str(manifest)) session HostSession( runtime, agent_idworkshop-agent, session_idlab1, ) for tool_name, token_count in SCENARIOS: evaluation session.input( body{tool_name: tool_name, token_count: token_count} ) print( f{evaluation.verdict:5} f{tool_name:20} ftokens{token_count:4} f{evaluation.verdict.reason} )对照三个 deny 条件可预期输出read_customer_data/ tokens100 →allow非写操作、未超预算execute_code/ tokens50 →denyreasoncode_execution_blocked尽管 token 少条件 1 优先命中write_database/ tokens200 →denyreasonwrite_operation_blockedread_reports/ tokens3000 →denyreasontoken_budget_exceededread_前缀放行但预算超限read_inventory/ tokens150 →allow这段代码也印证了 docs/quickstart.md 中的标准宿主模式AgentControl.from_path()构建运行时HostSession(runtime, agent_id..., session_id...)打开会话session.input(...)等价于干预点evaluate返回带verdict与reason的评估结果。2.5 扩展练习新增 deny 条件实验第 5 步要求向 lab1-policy.rego 增加一个 deny 条件并重跑。例如拦截所有读取财务类数据的操作可新增} else : { decision: deny, reason: sensitive_read_blocked, } if { startswith(input.policy_target.value.tool_name, read_) contains(input.policy_target.value.tool_name, finance) }重跑脚本后read_finance_ledger这类输入将命中sensitive_read_blocked。这个练习验证了 Rego 的增量 else 链语法新条件只要插在默认 allow 之前即可按优先级参与裁决。2.6 源码佐证会话计数器与运行时职责分离实验讨论题还问了为什么由HostSession拥有计数器和如果策略调度器或 OPA 进程失败会怎样。从源码看HostSession是会话级状态的载体而AgentControl运行时本身不持有会话计数。框架适配层 agent-governance-python/agent-os/src/agent_os/integrations/_native_adapter_runtime.py 中的NativeAdapterRuntime._session_for()展示了这一点会话按session_id or agent_id缓存通过session.builder提升tool_call_count/token_count计数器max()保证不回退并在evaluate_pre_tool_call后调用session.builder.record_tool_call()计费——连被拒绝的尝试也会先计费quickstart 明确Attempted tool calls are charged before evaluation, including denied attempts。这保证了预算审计不会因策略拦截而漏记。至于失败语义Agent Governance Toolkit 遵循fail closed失败即拒绝原则策略评估出错、运行时/审批出错、动作与身份不匹配时一律 deny且对外错误信息经过脱敏参见 docs/quickstart.md 的PolicyViolationError处理与 slides 的 Fail closed 一页。因此OPA 进程挂掉的后果不是放行而是拒绝——这正是治理系统的安全默认值。三、Lab 2多智能体信任Multi-Agent Trust3.1 实验文件与目标Lab 2 只有 docs/workshop/labs/lab2_multi_agent_trust.py 一个文件它是一个带TODO标记的模板要求参与者补全四个函数。前置依赖为pip install agentmesh-platform。目标创建两个 AgentMesh 身份执行信任握手通过正向行为积累信誉最后吊销凭证并验证下一次握手失败。这与 Lab 1 形成对照ACS 决定当前动作是否允许AgentMesh 决定对端是谁、双方是什么关系——身份与策略是两个正交的控制平面facilitator-notes 中特别强调的要点。3.2 Step 1创建两个身份create_agents()AgentIdentity.create(name, sponsor, capabilities)是创建受治理智能体的主要工厂方法。在 agent-governance-python/agent-mesh/src/agentmesh/identity/agent_id.py 的源码中create()会校验name非空、sponsor为合法邮箱格式然后生成Ed25519 密钥对ed25519.Ed25519PrivateKey.generate()公钥做 Base64 编码通过AgentDID.generate(name, organization)生成DIDdid:mesh:...形式由公钥哈希生成key-sha256 前 16 位的密钥 ID私钥保存在内存不参与序列化供后续sign()使用。按注释要求补全 TODOdef create_agents() - tuple: orchestrator AgentIdentity.create( nameorchestrator, sponsoraliceexample.com, capabilities[orchestrate:agents, read:data], ) worker AgentIdentity.create( nameworker, sponsorbobexample.com, capabilities[read:data, write:reports], ) return orchestrator, worker每个身份都带一组能力声明capabilities这是后续握手时必需能力校验的依据。3.3 Step 2信任握手attempt_handshake()信任握手是Ed25519 质询/响应协议见 agent-governance-python/agent-mesh/src/agentmesh/trust/handshake.py 的模块文档。其流程在源码中可清晰还原发起方创建TrustHandshake(initiator..., responder_did..., required_capabilities..., min_trust_score...)握手生成HandshakeChallenge包含challenge_id、32 字节随机nonce、时间戳与 30 秒过期时间若require_freshnessTrue还会带上 RFC 9334 的 freshness nonce用于证据活性证明对应 ADR-0005/0009 的 liveness 机制响应方返回HandshakeResponse回显 challenge、声明agent_did、capabilities、trust_score并用自身 Ed25519 私钥对载荷签名校验通过后产出HandshakeResultverified、peer_did、trust_score、trust_level枚举verified_partner / trusted / standard / untrusted、capabilities、rejection_reason以及握手延迟latency_ms。补全 TODO模板中已给出注释掉的参考实现def attempt_handshake(initiator, responder, min_trust_score: int) - bool: result TrustHandshake( initiatorinitiator, responder_didstr(responder.did), required_capabilities[read:data], min_trust_scoremin_trust_score, ).execute() if result.trusted: print(f[OK] Handshake succeeded — session_token: {result.session_token}) return True print(f[FAIL] Handshake failed — {result.rejection_reason}) return False主流程第一次调用使用min_trust_score700。而 AgentMesh 的常量定义agent-governance-python/agent-mesh/src/agentmesh/constants.py显示TRUST_SCORE_DEFAULT 500、TIER_TRUSTED_THRESHOLD 700、TIER_VERIFIED_PARTNER_THRESHOLD 900。新建身份的默认信任分是 500低于 700 的信任层级阈值因此第一次握手必然失败——这正是实验设计的预期expected: fail目的是让参与者先观察低信任度如何阻止协作再通过 Step 3 把分数养上去。3.4 Step 3用正向行为建立信誉build_trust()RiskScoreragent-governance-python/agent-mesh/src/agentmesh/identity/risk.py提供持续风险评分分数区间 0–1000越高越安全由身份、行为、网络、合规四个分量构成并按严重度critical/high/medium/low/info加权聚合风险信号。补全 TODO循环记录 10 条正向事件def build_trust(agent, num_events: int 10) - int: scorer RiskScorer() for i in range(num_events): scorer.record_event( agent_didstr(agent.did), event_typepolicy_compliant_action, detailsfCompleted task {i 1}, ) score scorer.get_score(str(agent.did)) print(f[INFO] Trust score after {num_events} events: {score.total_score}) return score.total_score主流程随后用min_trust_score540重试握手。由于 orchestrator 的分数已从默认 500 因合规行为上升通常能通过 540 的阈值若仍失败脚本会提示增加事件数或降低阈值。3.5 Step 4吊销并验证拒绝revoke_and_verify()补全最后的 TODO吊销发起方凭证后再次握手确认返回credentials revoked原因def revoke_and_verify(initiator, responder) - None: print([INFO] Revoking initiator credentials...) initiator.revoke() attempt_handshake(initiator, responder, min_trust_score400)源码层面AgentIdentity.revoke(reason)与IdentityRegistry.revoke(did, reason)见 agent_id.py负责吊销标记被吊销的身份即使信任分足够也会在握手阶段被拒绝——吊销是比信任分更高优先级的硬性拦截这是实验第 4 步要验证的握手失败行为。facilitator-notes 提醒的常见问题是忘记记录信誉事件、阈值始终高于最新分数、以及在握手成功后未测试吊销——补全时留意这三点。3.6 讨论题要点哪些控制属于 AgentMesh 而非 ACS密码学身份DID/密钥对、信任与信誉评分、能力授予、跨智能体传输属于 AgentMesh策略定义与干预点属于 ACS见下文 Wrap-up 表格。为什么策略评估与身份验证必须分离两者回答不同问题ACS 回答这个动作在绑定策略下是否被允许AgentMesh 回答对端是谁、信任关系如何。合并会引入单点失效和职责耦合——策略层挂了不能影响身份层判定反之亦然。重建跨智能体决策需要哪些审计字段至少需要双方 DID、握手时间与延迟、能力集合、信任分与阈值、吊销状态、事件类型与详情这些字段共同构成可回放replay的决策证据链。仓库中 agent-governance-python/agent-compliance/src/agent_compliance/policy_test.py 的replay()展示了同类思路用 fixture 快照对 manifest 重放并核对预期裁决。四、总结两个实验展示的分离控制平面按 lab-guide.md 的 Wrap-up 表格两个实验完整覆盖了以下独立控制平面及其归属控制项归属方策略定义与干预点Native ACS manifest会话计数器HostSession智能体身份与信任AgentMesh框架生命周期编排Agent OS adapter资源与网络隔离SandboxConfig这套职责划分贯穿整个 Toolkit策略管能不能做身份管你是谁、可不可信会话管花了多少预算adapter 管生命周期在哪一步拦截沙箱管隔离边界。Workshop 的两个实验正是把前两块从理论落到可运行的代码。继续深入学习可前往快速开始 Quickstart —— 标准宿主模式与框架接入Framework Integrations —— 生命周期编排与适配器Agent Control Specification —— ACS 清单与 Rego 策略的完整教程Trust and Identity 与 Audit and Compliance —— 信任与审计纵深Workshop 配套材料slides.md、facilitator-notes.md、prerequisites.md【免费下载链接】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），仅供参考