Agent Governance Toolkit Rust 能力与所有权清单一份源码驱动的治理能力盘点与演进路线图【免费下载链接】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 ToolkitAGT中Rust 能力面capability surface的权威盘点它逐一记录每条 Rust 能力的实现状态、仓库归属owner、对应的规范契约或实现范例、以及变更状态所需的证据。本文结合agentmeshcrate 源码、agt操作员 CLI 实现、policy-engine重定向记录与各集成适配器逐行解读该清单的五种状态、证据规则、源优先级并给出每条能力的实测命令与实现细节帮助读者快速判断哪些能力已经落地、哪些只是部分实现、哪些仍在等待上游决策。清单的定位源码驱动的库存而非认证声明rust-capability-manifest.md 开篇即明确这是一份source-backed inventory源码支撑的库存不是 certification认证、compliance statement合规声明或 production-readiness claim生产就绪声明。这意味着清单中的每一行状态都必须能在仓库的源码、测试、规范或官方一致性向量中找到对应证据仅有一个公开的类型、示例或文档页面不足以支撑shipped状态清单记录的是能力是否存在、完整到什么程度而不是产品是否通过某认证。因此阅读本清单的正确姿势是把它当作导航图shipped表示可以直接依赖的已实现面partial表示存在可用子集但有明确缺口missing表示尚未实现但有明确归属blocked/deferred表示受外部条件或所有权决策制约。证据规则五种状态与各自的证据门槛清单允许且仅允许五种状态shipped、partial、missing、blocked、deferred。每种状态都有明确的证据要求状态必备证据shipped该行声明范围内完整能力存在于当前 main 分支行内链接适用的规范性工件或给出N/A及理由并同时链接实现代码与行为测试或官方一致性向量。仅公开类型、示例或文档页不足为凭partial存在有用的已实现子集但某个命名的工作流、执行边界、打包路径或证据要求不完整行内链接现有证据、局限说明和跟踪项missing当前没有任何 Rust 实现满足该能力行内指明唯一归属仓库和一个跟踪项blocked预期工作必须等待某个已命名的外部决策或前置条件解决行内链接阻塞项与跟踪项deferred该能力在等待所有权、需求或排序决策之前被有意搁置行内给出该决策的唯一当前负责人与一个跟踪项清单还强调两点治理约束每行有且仅有一个当前负责人owner避免能力无人认领或重复建设契约变更的归属边界清晰涉及 agent context、verdicts、approval、composition、interception records 或 CTK 的契约变更属于responsibleai/agent-hooks涉及 ACS manifests、evaluation、dispatchers、effects 或 interceptor 语义的变更属于responsibleai/agent-control-specAGT 则拥有自己的 CLI、audit、replay、compliance、dashboards、SRE 工作流与 AGT 集成。AGT 集成可以消费规范契约但不得 fork 它们。源优先级证据冲突时的裁决顺序当不同来源给出的结论不一致时按以下优先级取第一个适用的来源规范性规范和机器可读 schema官方一致性向量与报告规范 Rust 实现及其行为测试AGT 集成源码与行为测试仅在以上来源都沉默时Python 才能作为 UX 或工作流范例exemplar。这里有一个值得注意的设计意图Python 代码在本仓库中只承担先例prior art角色——例如 Python 的agtCLI、replay 工作流、合规 CLI 都只是 UX 范例不能作为 Rust 能力是否实现的证据。这正是源码驱动精神的体现判断能力状态时永远以最高优先级的规范工件和规范实现为准。当前与提议架构从嵌入式引擎到外部化契约清单的Current and proposed architecture一节记录了 AGT Rust 政策平面的一次关键架构变迁AGT main 现在依赖已发布的agent-control-spec0.4.0-alpha.3 运行时与 agent-hooks 主机契约此前嵌入在仓库内的 ACS 0.3.1-beta 引擎已在后续 PR 中移除详细的迁移记录保存在 acs-retarget.md其中说明了迁移了什么、剩余的上游缺口、以及取代前置条件的注册表所有权决策特别强调agentmesh操作员 CLI 仍然使用 crate 内本地基于规则的PolicyEngine求值它不建立 AGENT-HOOKS-0.1 主机一致性声明同样仅仅依赖已发布的引擎也不等于自动获得一致性声明。依赖引脚与重定向细节从 policy-engine/sdk/rust/Cargo.toml 可以看到当前的实际依赖[dependencies] agent-control-spec { version 0.4.0-alpha.3, default-features false, features [opa, cedar, default-dispatchers] } agent-hooks-sdk 0.1.0-alpha.5版本采用精确锁定0.4.0-alpha.3并显式default-features false避免上游默认特性静默改变本仓库 API 的可执行选择、bundle 处理或策略行为agent_control_specification_core以path方式引用本地../../core承担 AGT 专属的工件校验C ABI 暴露依赖url 2.5.8有明确理由SSRF 防护与上游加载器使用同一个 URL 解析器保证对 fetch 目标做规范化判断时结果一致。acs-retarget.md 还记录了重定向带来的几个核心契约变化理解这些有助于读懂清单中的partial行Verdict 从五个收敛为三个。新Decision只有Allow、Deny、Transform旧的warn语义映射为allow加上warnings[]Verdict::warn只是构造语法糖旧的escalate语义映射为携带approval块的可提升deny。原因命名空间也被拆分引擎只能发出runtime_error:*host_error:*保留给主机host拦截器永远不得发出后者。清单manifest有三个破坏性变更且已在全仓库应用agent_control_specification_version必须是0.4.0-alpha.1引擎在解析期拒绝其他任何值路径根$policy_target改名为$target清单语法不带别名旧根会被以unknown path root拒绝bundle_url、system_prompt_file、system_prompt_url三个字段被移除。第三点是安全相关的关键行为上游 0.4.0-alpha.3 从未实现过这三个字段但adapter_config等是开放 map旧引擎的 fail-closed 检查在新引擎中全部变成了静默接受——远程 bundle 会被静默丢弃、annotator 会静默使用默认系统提示词、rego 策略会以无诊断的runtime_error:policy_invocation_failed拒绝所有请求。AGT 的reject_removed_manifest_fields现在在validate_manifest_yaml、validate_manifest_overlay_yaml、每个AgentControl构造函数、manifest_from_url以及所有 C ABI / Python / Node 构造器路径上主动拒绝这些字段返回带位置的runtime_error:manifest_invalid。迁移方式是把值内联进清单system_prompt_file/system_prompt_url变为system_promptbundle_url变为本地bundle路径。manifest_from_url 的 SSRF 防护重定向后Manifest::from_url在新引擎中不再存在sdk/rust用manifest_from_url在公开表面上重建了该能力并叠加了一层 SSRF 防护。防护逻辑值得细读早期移植版本手工切分 authority 后调用str::parse::IpAddr只接受点分十进制写法导致127.1、2130706433、0x7f000001、0177.0.0.1、127.0.0TAB.1等变体全部漏过并被 fetcher 规范化到127.0.0.1后成功连接。修复后的防护使用urlcrate 解析并检查Url::host()测试用例manifest_from_url_blocks_ssrf_targets覆盖上述所有变体manifest_from_url_never_connects_to_a_blocked_literal则绑定回环监听器断言没有连接到达。被阻止的目标包括loopback、未指定地址与0.0.0.0/8、广播、链路本地169.254.0.0/16、fe80::/10、RFC 1918 私网、共享地址空间100.64.0.0/10、IPv6 唯一本地fc00::/7与站点本地fec0::/10以及localhost、*.localhost、*.local主机名。IPv4-mapped、IPv4-compatible 与 NAT64 前缀的 IPv6 字面量会按内嵌 IPv4 地址检查。该防护的局限也如实记录主机名不做 DNS 解析解析进被禁网段、DNS rebinding 需要 fetcher 内做解析时检查重定向跳数不再复查alpha.3 把重定向交给 HTTP 客户端max_manifest_url_redirects默认 5嵌套extendsURL 不做目标检查。文档的结论是把防护当作针对明显情况的屏障而不是边界。需要跨重定向保持防护的主机应把max_manifest_url_redirects设为 0。Rust 能力清单逐行解读核心与操作员能力以下是清单中Core, operator, and SRE capabilities表的完整内容与源码级佐证能力状态规范契约或范例实现与证据核心agentmesh治理原语partialAGT 自有的 identity、trust、audit、MCP、rings、lifecycle 原语为N/A声称 AGT 5 政策拦截器时适用 ACSagentmesh/src/lib.rs 及其行为测试在 AGT 中采用已发布的 ACS 0.4 与 agent-hookspartial上方链接的规范、schema、覆盖度与 CTK 报告main 通过 sdk/rust/Cargo.toml 依赖agent-control-spec0.4.0-alpha.3统一 Rustagt操作员 CLIpartialN/APython CLI 仅为工作流先例特性门控的 cli.rs、main.rs 与 cli 测试本地规则agt check与agt policyshippedN/A——仅声明 AGT 本地PolicyEngine范围不做 ACS 声明check.rs、policy.rs 与行为测试agt audit tail与agt audit exportpartialN/A——AGT 专属操作员传输 UXaudit.rs 与行为测试agt trust show与agt trust setshippedN/A——AGT 专属文件支撑 trust store UXtrust.rs 与行为测试确定性 replay 工作流missingN/APython replay 仅为 UX/工作流先例当前 main 上无 Rust replay 命令或受限 replay 信封agt doctor、策略 lint、合规与 OWASP 验证missingagent-hooks CTK 与 ACS 一致性工件对各自范围有权威性Python 合规 CLI 仅为展示先例当前 main 上无 Rustdoctor、verify、lint-policy命令Dashboard 与广泛治理可观测性partialOpenTelemetry 规范agent-hooks 明确是控制平面而非遥测平面可选的 telemetry.rs 策略 span 与 telemetry 测试policy-engine 工作区另有 OTel 指标桥agtCLI 的总体形态与退出码契约agt二进制由agentmeshcrate 以clifeature 门控提供默认关闭库构建不引入参数解析器、不产生二进制。构建与安装方式见 agent-governance-rust/README.md# 工作区内直接运行不安装 cargo run -p agentmesh --features cli --bin agt -- check --policy path/to/policy.yaml --input {action:data.read} # 安装 agt 到 PATH cargo install --path agentmesh --features cli从 main.rs 可以看到入口的极简设计main只做两件事——用 clap 解析参数用法错误自动以退出码 2 退出把run的结果映射为进程退出码run成功时返回意图中的退出码check用它编码策略决策失败时返回结构化的CliErrorfail-closed。注释明确所有逻辑都在run/cmd::*中对用户输入永不 panic。退出码契约退出码含义0成功对check而言表示动作被允许1操作失败对check而言表示动作未被允许2参数/输入用法错误未知子命令、坏 flag、非法check输入错误统一以error:前缀写到 stderr。整个 CLI 是fail-closed的非法输入绝不静默成功绝不默认放行。check策略求值并以退出码编码决策shippedcheck.rs 实现了check子命令读取--policy file与--input json把一行 JSON 结果打印到 stdout动作被允许时退出0、否则退出1而真正输入错误非法--input、缺少action、策略不可读/非法则以退出码2fail-closed。agt check --policy path/to/policy.yaml --input {action:data.read} # → {allowed:true,action:data.read,decision:allow,detail:null} (exit 0) agt check --policy path/to/policy.yaml --input {action:shell:rm,context:{trust_score:800}} # → {allowed:false,...,decision:deny,...} (exit 1)--input是一个 JSON 对象要求action字段context可选。run内部先把输入反序列化为CheckInput { action, context: OptionHashMapString, serde_yaml::Value }然后构造PolicyEngine::new()、load_from_file(policy)最后evaluate(action, context)把四种PolicyDecision映射为稳定标签allow、deny、requires_approval、rate_limited后者带retry_after_secs详情。CLI 求值的底层是 crate 内的本地规则引擎 policy.rs。PolicyEngine提供四路决策allow / deny / requires-approval / rate-limit规则按优先级求值、首个匹配生效未加载 profile 时默认全部放行。规则类型包括capabilityallowed_actions/denied_actions列表支持shell:*这类通配approvalactionsmin_approvals触发RequiresApprovalrate_limitactionsmax_callswindow超出后触发RateLimited。例如测试中的标准策略来自 cli.rs 测试version: 1.0 agent: test-agent policies: - name: allow-read type: capability allowed_actions: - data.read denied_actions: - shell:*CLI 是现有 crate API 的薄消费者不新增库面也绝不削弱库的行为——这也是清单把check/policy列为shipped的依据实现完整、测试完备policy_validate_ok、policy_validate_malformed_exit1、policy_validate_missing_file_exit1等用例覆盖了成功与各种 fail-closed 路径。policy校验与解释shippedpolicy.rs 提供两个子命令# 解析并校验策略文件schema/正则错误时退出 1 agt policy validate path/to/policy.yaml # 展示示例动作可选 context的决策 agt policy explain path/to/policy.yaml --action data.read agt policy explain path/to/policy.yaml --action deploy.prod --context {env:prod} --format jsonexplain在输入合法时即使得到deny也退出0——deny 是结果不是 CLI 失败。这一点与check的退出码语义形成对照check用退出码编码决策本身policy explain只报告决策。Format枚举支持text默认与json两种输出。audittail 与 exportpartialaudit.rs 读取由agentmesh::audit::AuditLogger::export_json产出的审计日志 JSON 数组并重新输出agt audit tail path/to/audit.json # 默认打印最后 20 条 agt audit tail path/to/audit.json --limit 5 agt audit export path/to/audit.json # 默认单 JSON 数组 agt audit export path/to/audit.json --format ndjsontail的--limit默认 20且用saturating_sub保证limit 大于日志长度时是安全钳制export支持jsonpretty-printed 数组与ndjson每行一个条目对象两种结构化格式。该行状态是partial局限写得很直白CLI 读取并重新发射序列化日志但不验证哈希链或内嵌控制记录。原因在源码注释中AuditLogger::verify操作内存态且哈希是私有的所以tail/export只把文件当作序列化传输介质。换句话说哈希链完整性验证仍停留在库 API 层面lib.rs 中execute_with_governance每次执行都会写审计条目并维护previous_hash链操作员 CLI 尚未暴露链验证能力这一缺口由跟踪项 #3680 记录。trust文件支撑的信任分shippedtrust.rs 是最能体现CLI 层补强库层 fail-closed 语义的例子。库层TrustManager的持久化是best-effort 且静默的忽略..路径、吞掉写 IO 错误、把损坏的 store 当空 store 处理、且磁盘类型AgentState是私有的——所以 fail-closed 语义不能委托给库必须在 CLI 层强制agt trust show agent-1 --store trust.json agt trust show agent-1 --store trust.json --format json agt trust set agent-1 800 --store trust.jsonCLI 层强制了四条规则拒绝..store 路径库会静默跳过预校验已存在的 store 必须能解析为 JSON 数组拒绝而非覆写损坏的 store分数范围检查拒绝 1000不做静默钳制——注意库内部会静默钳制CLI 拒绝是更严格的行为set后读回验证用全新的TrustManagerall_agents()确认值真的落盘写未确认时返回失败。MAX_SCORE: u32 1000是显式常量。show的 text 输出包含agent、score、tier、interactions四行json 输出用to_string_pretty。清单强调该行shipped仅覆盖已记录的文件支撑分数工作流这不是外部身份或授权协议的声明。信任分更新与PolicyDecision的联动在 lib.rs 的execute_with_governance中可见Allow触发record_success、Deny触发record_failure、RequiresApproval保持分数不变有对应测试test_approval_required_action_preserves_trust_and_audits_label断言审计标签为requires_approval且分数不变。missing行确定性 replay 与agt doctor两行missing状态的解读要点确定性 replay没有 Rust replay 命令或受限 replay 信封。Python 的 agent-sre/replay 只是 UX 与工作流先例。实施前提被明确写出在实现前先定义覆盖规范记录的主机自有信封host-owned envelope。agt doctor、策略 lint、合规与 OWASP 验证没有 Rustdoctor/verify/lint-policy命令。约束同样是概念性的必须把一致性证据与认证区分开任何 attestation 都必须绑定到已验证的输入。这两行共同提醒读者清单的missing不是不知道要不要做而是知道归属、知道前提、尚未排期实现。主机契约与现有集成Host contract and existing integrations第二张表记录 AGT 与外部主机/框架的集成状态能力状态实现与证据关键局限AGT Rust 主机适配器与 CTK 一致性声明missing上游已有规范 Rust SDK 与 CTK但 AGT 无生产路径 harness 或已接受的逐部分报告包存在 ≠ 主机一致性一致性 ≠ 安全认证Rig 工具集成partial真实 rig-core 适配器与 guarded_tool 测试覆盖 allow/deny/transform/approval/bypass/concurrency工作区 crate 是publish false构建在agent-control-spec0.4.0-alpha.3 之上官方 MCP Rust SDK 集成partial真实 rmcp 适配器与测试覆盖工具前/后执行强制与规范 agentmesh-mcp 不同不得重复实现OpenAI Rust 工具集成partial真实 async-openai 适配器与测试覆盖 allow 与前后工具拒绝OpenAI 客户端类型只是传输集成不构成策略语义OpenTelemetry 集成partialagentmesh 的 span sink带 测试与 policy-engine 的 metrics bridge 及 exampleACS 桥无 crate 本地行为测试两条路径都未覆盖更广的 dashboard 面Goose/ACP 主机集成deferred无 AGT Goose/ACP 生产路径适配器或 CTK 报告AGT 拥有是否接受参考集成的决策权若维护者拒绝实现应移入消费方 Goose 仓库且不得改变规范语义从 Rig 适配器看部分实现的真实形态rig 适配器 是一个理解partial含义的绝佳样本它真实可用——GuardedRigTool包装一个 Rig 工具使其参数与输出流经pre_tool_call/post_tool_call干预点直接实现rig::tool::ToolDyn从而让 transform 后的参数在内层工具分发前真正生效完整变更覆盖而非提示钩子的仅建议行为deny阻断调用escalate咨询审批解析器可 per-tool 覆盖无解析器时 fail-closed 阻断。但它仍然是partial原因与能力无关而与发布形态有关该 crate 当前publish false只作为工作区成员构建在agent-control-spec0.4.0-alpha.3 与 AGT 主机 SDK 之上打包与规范栈决策仍在 #3680 跟踪。这正是清单证据规则的意义——实现存在与能力完整交付是两个不同的事实。deferred的正确打开方式Goose/ACPGoose/ACP 是唯一的deferred行。它不是说永远不会做而是说在所有权达成一致前不要实现。决策的当前负责人是 AGT 维护者如果维护者最终拒绝接受该参考集成实施工作应转移到消费方 Goose 仓库进行——前提是不得改变规范语义。对读者而言这意味着即使你有能力在 AGT 里实现一个 Goose 适配器在清单更新之前这也不是当前应该做的事。如何更新这份清单五步流程清单末尾给出了修改行的操作规范这也是源码驱动精神的最终落点搜索全部三个归属仓库中已开与已关闭的 issue 与 PR避免重复已有工作检查当前默认分支、适用的规范、schema、向量、实现与测试每行保持且仅有一个 owner对每个不完整状态都链接一个局限说明与一个跟踪项使用shipped之前必须有实现加上行为测试或官方一致性证据同步更新包矩阵与 Rust README当操作员可见的状态或可发现性变化时agent-governance-rust/README.md 必须跟随更新该 README 本身就链接回本清单形成双向引用闭环。阅读与实践建议把本清单作为决策工具使用可以总结出三条实用准则区分库能力与CLI 能力agentmeshcrate 的库面非常完整identity、policy、audit 哈希链、trust、rings、protocol facets、prompt injection 检测等模块在 lib.rs 全部公开但agtCLI 只是其中check/policy/audit/trust四个子集的薄封装——库有能力不等于 CLI 已暴露审计哈希链验证就是最典型的例子。区分依赖与一致性依赖agent-control-spec0.4.0-alpha.3依赖行存在与AGT 建立了 AGENT-HOOKS-0.1 主机一致性声明缺失行是两个不同的事实。前者是 Cargo.toml 里的一行依赖后者需要生产路径 harness 与被接受的 CTK 报告。把partial/missing当路线图而非缺陷每一行都附带了明确的局限描述与跟踪项编号例如统一 CLI 的partial明确点名缺少doctor、replay、离线完整性验证、合规/OWASP 验证与 dashboard 工作流。这份清单因此同时充当了能力盘点与演进路线图——而它的一切结论都以当前仓库的源码、测试与规范工件为唯一证据来源这正是它区别于一般 README 特性宣传的价值所在。【免费下载链接】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 Rust 能力与所有权清单：一份源码驱动的治理能力盘点与演进路线图
Agent Governance Toolkit Rust 能力与所有权清单一份源码驱动的治理能力盘点与演进路线图【免费下载链接】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 ToolkitAGT中Rust 能力面capability surface的权威盘点它逐一记录每条 Rust 能力的实现状态、仓库归属owner、对应的规范契约或实现范例、以及变更状态所需的证据。本文结合agentmeshcrate 源码、agt操作员 CLI 实现、policy-engine重定向记录与各集成适配器逐行解读该清单的五种状态、证据规则、源优先级并给出每条能力的实测命令与实现细节帮助读者快速判断哪些能力已经落地、哪些只是部分实现、哪些仍在等待上游决策。清单的定位源码驱动的库存而非认证声明rust-capability-manifest.md 开篇即明确这是一份source-backed inventory源码支撑的库存不是 certification认证、compliance statement合规声明或 production-readiness claim生产就绪声明。这意味着清单中的每一行状态都必须能在仓库的源码、测试、规范或官方一致性向量中找到对应证据仅有一个公开的类型、示例或文档页面不足以支撑shipped状态清单记录的是能力是否存在、完整到什么程度而不是产品是否通过某认证。因此阅读本清单的正确姿势是把它当作导航图shipped表示可以直接依赖的已实现面partial表示存在可用子集但有明确缺口missing表示尚未实现但有明确归属blocked/deferred表示受外部条件或所有权决策制约。证据规则五种状态与各自的证据门槛清单允许且仅允许五种状态shipped、partial、missing、blocked、deferred。每种状态都有明确的证据要求状态必备证据shipped该行声明范围内完整能力存在于当前 main 分支行内链接适用的规范性工件或给出N/A及理由并同时链接实现代码与行为测试或官方一致性向量。仅公开类型、示例或文档页不足为凭partial存在有用的已实现子集但某个命名的工作流、执行边界、打包路径或证据要求不完整行内链接现有证据、局限说明和跟踪项missing当前没有任何 Rust 实现满足该能力行内指明唯一归属仓库和一个跟踪项blocked预期工作必须等待某个已命名的外部决策或前置条件解决行内链接阻塞项与跟踪项deferred该能力在等待所有权、需求或排序决策之前被有意搁置行内给出该决策的唯一当前负责人与一个跟踪项清单还强调两点治理约束每行有且仅有一个当前负责人owner避免能力无人认领或重复建设契约变更的归属边界清晰涉及 agent context、verdicts、approval、composition、interception records 或 CTK 的契约变更属于responsibleai/agent-hooks涉及 ACS manifests、evaluation、dispatchers、effects 或 interceptor 语义的变更属于responsibleai/agent-control-specAGT 则拥有自己的 CLI、audit、replay、compliance、dashboards、SRE 工作流与 AGT 集成。AGT 集成可以消费规范契约但不得 fork 它们。源优先级证据冲突时的裁决顺序当不同来源给出的结论不一致时按以下优先级取第一个适用的来源规范性规范和机器可读 schema官方一致性向量与报告规范 Rust 实现及其行为测试AGT 集成源码与行为测试仅在以上来源都沉默时Python 才能作为 UX 或工作流范例exemplar。这里有一个值得注意的设计意图Python 代码在本仓库中只承担先例prior art角色——例如 Python 的agtCLI、replay 工作流、合规 CLI 都只是 UX 范例不能作为 Rust 能力是否实现的证据。这正是源码驱动精神的体现判断能力状态时永远以最高优先级的规范工件和规范实现为准。当前与提议架构从嵌入式引擎到外部化契约清单的Current and proposed architecture一节记录了 AGT Rust 政策平面的一次关键架构变迁AGT main 现在依赖已发布的agent-control-spec0.4.0-alpha.3 运行时与 agent-hooks 主机契约此前嵌入在仓库内的 ACS 0.3.1-beta 引擎已在后续 PR 中移除详细的迁移记录保存在 acs-retarget.md其中说明了迁移了什么、剩余的上游缺口、以及取代前置条件的注册表所有权决策特别强调agentmesh操作员 CLI 仍然使用 crate 内本地基于规则的PolicyEngine求值它不建立 AGENT-HOOKS-0.1 主机一致性声明同样仅仅依赖已发布的引擎也不等于自动获得一致性声明。依赖引脚与重定向细节从 policy-engine/sdk/rust/Cargo.toml 可以看到当前的实际依赖[dependencies] agent-control-spec { version 0.4.0-alpha.3, default-features false, features [opa, cedar, default-dispatchers] } agent-hooks-sdk 0.1.0-alpha.5版本采用精确锁定0.4.0-alpha.3并显式default-features false避免上游默认特性静默改变本仓库 API 的可执行选择、bundle 处理或策略行为agent_control_specification_core以path方式引用本地../../core承担 AGT 专属的工件校验C ABI 暴露依赖url 2.5.8有明确理由SSRF 防护与上游加载器使用同一个 URL 解析器保证对 fetch 目标做规范化判断时结果一致。acs-retarget.md 还记录了重定向带来的几个核心契约变化理解这些有助于读懂清单中的partial行Verdict 从五个收敛为三个。新Decision只有Allow、Deny、Transform旧的warn语义映射为allow加上warnings[]Verdict::warn只是构造语法糖旧的escalate语义映射为携带approval块的可提升deny。原因命名空间也被拆分引擎只能发出runtime_error:*host_error:*保留给主机host拦截器永远不得发出后者。清单manifest有三个破坏性变更且已在全仓库应用agent_control_specification_version必须是0.4.0-alpha.1引擎在解析期拒绝其他任何值路径根$policy_target改名为$target清单语法不带别名旧根会被以unknown path root拒绝bundle_url、system_prompt_file、system_prompt_url三个字段被移除。第三点是安全相关的关键行为上游 0.4.0-alpha.3 从未实现过这三个字段但adapter_config等是开放 map旧引擎的 fail-closed 检查在新引擎中全部变成了静默接受——远程 bundle 会被静默丢弃、annotator 会静默使用默认系统提示词、rego 策略会以无诊断的runtime_error:policy_invocation_failed拒绝所有请求。AGT 的reject_removed_manifest_fields现在在validate_manifest_yaml、validate_manifest_overlay_yaml、每个AgentControl构造函数、manifest_from_url以及所有 C ABI / Python / Node 构造器路径上主动拒绝这些字段返回带位置的runtime_error:manifest_invalid。迁移方式是把值内联进清单system_prompt_file/system_prompt_url变为system_promptbundle_url变为本地bundle路径。manifest_from_url 的 SSRF 防护重定向后Manifest::from_url在新引擎中不再存在sdk/rust用manifest_from_url在公开表面上重建了该能力并叠加了一层 SSRF 防护。防护逻辑值得细读早期移植版本手工切分 authority 后调用str::parse::IpAddr只接受点分十进制写法导致127.1、2130706433、0x7f000001、0177.0.0.1、127.0.0TAB.1等变体全部漏过并被 fetcher 规范化到127.0.0.1后成功连接。修复后的防护使用urlcrate 解析并检查Url::host()测试用例manifest_from_url_blocks_ssrf_targets覆盖上述所有变体manifest_from_url_never_connects_to_a_blocked_literal则绑定回环监听器断言没有连接到达。被阻止的目标包括loopback、未指定地址与0.0.0.0/8、广播、链路本地169.254.0.0/16、fe80::/10、RFC 1918 私网、共享地址空间100.64.0.0/10、IPv6 唯一本地fc00::/7与站点本地fec0::/10以及localhost、*.localhost、*.local主机名。IPv4-mapped、IPv4-compatible 与 NAT64 前缀的 IPv6 字面量会按内嵌 IPv4 地址检查。该防护的局限也如实记录主机名不做 DNS 解析解析进被禁网段、DNS rebinding 需要 fetcher 内做解析时检查重定向跳数不再复查alpha.3 把重定向交给 HTTP 客户端max_manifest_url_redirects默认 5嵌套extendsURL 不做目标检查。文档的结论是把防护当作针对明显情况的屏障而不是边界。需要跨重定向保持防护的主机应把max_manifest_url_redirects设为 0。Rust 能力清单逐行解读核心与操作员能力以下是清单中Core, operator, and SRE capabilities表的完整内容与源码级佐证能力状态规范契约或范例实现与证据核心agentmesh治理原语partialAGT 自有的 identity、trust、audit、MCP、rings、lifecycle 原语为N/A声称 AGT 5 政策拦截器时适用 ACSagentmesh/src/lib.rs 及其行为测试在 AGT 中采用已发布的 ACS 0.4 与 agent-hookspartial上方链接的规范、schema、覆盖度与 CTK 报告main 通过 sdk/rust/Cargo.toml 依赖agent-control-spec0.4.0-alpha.3统一 Rustagt操作员 CLIpartialN/APython CLI 仅为工作流先例特性门控的 cli.rs、main.rs 与 cli 测试本地规则agt check与agt policyshippedN/A——仅声明 AGT 本地PolicyEngine范围不做 ACS 声明check.rs、policy.rs 与行为测试agt audit tail与agt audit exportpartialN/A——AGT 专属操作员传输 UXaudit.rs 与行为测试agt trust show与agt trust setshippedN/A——AGT 专属文件支撑 trust store UXtrust.rs 与行为测试确定性 replay 工作流missingN/APython replay 仅为 UX/工作流先例当前 main 上无 Rust replay 命令或受限 replay 信封agt doctor、策略 lint、合规与 OWASP 验证missingagent-hooks CTK 与 ACS 一致性工件对各自范围有权威性Python 合规 CLI 仅为展示先例当前 main 上无 Rustdoctor、verify、lint-policy命令Dashboard 与广泛治理可观测性partialOpenTelemetry 规范agent-hooks 明确是控制平面而非遥测平面可选的 telemetry.rs 策略 span 与 telemetry 测试policy-engine 工作区另有 OTel 指标桥agtCLI 的总体形态与退出码契约agt二进制由agentmeshcrate 以clifeature 门控提供默认关闭库构建不引入参数解析器、不产生二进制。构建与安装方式见 agent-governance-rust/README.md# 工作区内直接运行不安装 cargo run -p agentmesh --features cli --bin agt -- check --policy path/to/policy.yaml --input {action:data.read} # 安装 agt 到 PATH cargo install --path agentmesh --features cli从 main.rs 可以看到入口的极简设计main只做两件事——用 clap 解析参数用法错误自动以退出码 2 退出把run的结果映射为进程退出码run成功时返回意图中的退出码check用它编码策略决策失败时返回结构化的CliErrorfail-closed。注释明确所有逻辑都在run/cmd::*中对用户输入永不 panic。退出码契约退出码含义0成功对check而言表示动作被允许1操作失败对check而言表示动作未被允许2参数/输入用法错误未知子命令、坏 flag、非法check输入错误统一以error:前缀写到 stderr。整个 CLI 是fail-closed的非法输入绝不静默成功绝不默认放行。check策略求值并以退出码编码决策shippedcheck.rs 实现了check子命令读取--policy file与--input json把一行 JSON 结果打印到 stdout动作被允许时退出0、否则退出1而真正输入错误非法--input、缺少action、策略不可读/非法则以退出码2fail-closed。agt check --policy path/to/policy.yaml --input {action:data.read} # → {allowed:true,action:data.read,decision:allow,detail:null} (exit 0) agt check --policy path/to/policy.yaml --input {action:shell:rm,context:{trust_score:800}} # → {allowed:false,...,decision:deny,...} (exit 1)--input是一个 JSON 对象要求action字段context可选。run内部先把输入反序列化为CheckInput { action, context: OptionHashMapString, serde_yaml::Value }然后构造PolicyEngine::new()、load_from_file(policy)最后evaluate(action, context)把四种PolicyDecision映射为稳定标签allow、deny、requires_approval、rate_limited后者带retry_after_secs详情。CLI 求值的底层是 crate 内的本地规则引擎 policy.rs。PolicyEngine提供四路决策allow / deny / requires-approval / rate-limit规则按优先级求值、首个匹配生效未加载 profile 时默认全部放行。规则类型包括capabilityallowed_actions/denied_actions列表支持shell:*这类通配approvalactionsmin_approvals触发RequiresApprovalrate_limitactionsmax_callswindow超出后触发RateLimited。例如测试中的标准策略来自 cli.rs 测试version: 1.0 agent: test-agent policies: - name: allow-read type: capability allowed_actions: - data.read denied_actions: - shell:*CLI 是现有 crate API 的薄消费者不新增库面也绝不削弱库的行为——这也是清单把check/policy列为shipped的依据实现完整、测试完备policy_validate_ok、policy_validate_malformed_exit1、policy_validate_missing_file_exit1等用例覆盖了成功与各种 fail-closed 路径。policy校验与解释shippedpolicy.rs 提供两个子命令# 解析并校验策略文件schema/正则错误时退出 1 agt policy validate path/to/policy.yaml # 展示示例动作可选 context的决策 agt policy explain path/to/policy.yaml --action data.read agt policy explain path/to/policy.yaml --action deploy.prod --context {env:prod} --format jsonexplain在输入合法时即使得到deny也退出0——deny 是结果不是 CLI 失败。这一点与check的退出码语义形成对照check用退出码编码决策本身policy explain只报告决策。Format枚举支持text默认与json两种输出。audittail 与 exportpartialaudit.rs 读取由agentmesh::audit::AuditLogger::export_json产出的审计日志 JSON 数组并重新输出agt audit tail path/to/audit.json # 默认打印最后 20 条 agt audit tail path/to/audit.json --limit 5 agt audit export path/to/audit.json # 默认单 JSON 数组 agt audit export path/to/audit.json --format ndjsontail的--limit默认 20且用saturating_sub保证limit 大于日志长度时是安全钳制export支持jsonpretty-printed 数组与ndjson每行一个条目对象两种结构化格式。该行状态是partial局限写得很直白CLI 读取并重新发射序列化日志但不验证哈希链或内嵌控制记录。原因在源码注释中AuditLogger::verify操作内存态且哈希是私有的所以tail/export只把文件当作序列化传输介质。换句话说哈希链完整性验证仍停留在库 API 层面lib.rs 中execute_with_governance每次执行都会写审计条目并维护previous_hash链操作员 CLI 尚未暴露链验证能力这一缺口由跟踪项 #3680 记录。trust文件支撑的信任分shippedtrust.rs 是最能体现CLI 层补强库层 fail-closed 语义的例子。库层TrustManager的持久化是best-effort 且静默的忽略..路径、吞掉写 IO 错误、把损坏的 store 当空 store 处理、且磁盘类型AgentState是私有的——所以 fail-closed 语义不能委托给库必须在 CLI 层强制agt trust show agent-1 --store trust.json agt trust show agent-1 --store trust.json --format json agt trust set agent-1 800 --store trust.jsonCLI 层强制了四条规则拒绝..store 路径库会静默跳过预校验已存在的 store 必须能解析为 JSON 数组拒绝而非覆写损坏的 store分数范围检查拒绝 1000不做静默钳制——注意库内部会静默钳制CLI 拒绝是更严格的行为set后读回验证用全新的TrustManagerall_agents()确认值真的落盘写未确认时返回失败。MAX_SCORE: u32 1000是显式常量。show的 text 输出包含agent、score、tier、interactions四行json 输出用to_string_pretty。清单强调该行shipped仅覆盖已记录的文件支撑分数工作流这不是外部身份或授权协议的声明。信任分更新与PolicyDecision的联动在 lib.rs 的execute_with_governance中可见Allow触发record_success、Deny触发record_failure、RequiresApproval保持分数不变有对应测试test_approval_required_action_preserves_trust_and_audits_label断言审计标签为requires_approval且分数不变。missing行确定性 replay 与agt doctor两行missing状态的解读要点确定性 replay没有 Rust replay 命令或受限 replay 信封。Python 的 agent-sre/replay 只是 UX 与工作流先例。实施前提被明确写出在实现前先定义覆盖规范记录的主机自有信封host-owned envelope。agt doctor、策略 lint、合规与 OWASP 验证没有 Rustdoctor/verify/lint-policy命令。约束同样是概念性的必须把一致性证据与认证区分开任何 attestation 都必须绑定到已验证的输入。这两行共同提醒读者清单的missing不是不知道要不要做而是知道归属、知道前提、尚未排期实现。主机契约与现有集成Host contract and existing integrations第二张表记录 AGT 与外部主机/框架的集成状态能力状态实现与证据关键局限AGT Rust 主机适配器与 CTK 一致性声明missing上游已有规范 Rust SDK 与 CTK但 AGT 无生产路径 harness 或已接受的逐部分报告包存在 ≠ 主机一致性一致性 ≠ 安全认证Rig 工具集成partial真实 rig-core 适配器与 guarded_tool 测试覆盖 allow/deny/transform/approval/bypass/concurrency工作区 crate 是publish false构建在agent-control-spec0.4.0-alpha.3 之上官方 MCP Rust SDK 集成partial真实 rmcp 适配器与测试覆盖工具前/后执行强制与规范 agentmesh-mcp 不同不得重复实现OpenAI Rust 工具集成partial真实 async-openai 适配器与测试覆盖 allow 与前后工具拒绝OpenAI 客户端类型只是传输集成不构成策略语义OpenTelemetry 集成partialagentmesh 的 span sink带 测试与 policy-engine 的 metrics bridge 及 exampleACS 桥无 crate 本地行为测试两条路径都未覆盖更广的 dashboard 面Goose/ACP 主机集成deferred无 AGT Goose/ACP 生产路径适配器或 CTK 报告AGT 拥有是否接受参考集成的决策权若维护者拒绝实现应移入消费方 Goose 仓库且不得改变规范语义从 Rig 适配器看部分实现的真实形态rig 适配器 是一个理解partial含义的绝佳样本它真实可用——GuardedRigTool包装一个 Rig 工具使其参数与输出流经pre_tool_call/post_tool_call干预点直接实现rig::tool::ToolDyn从而让 transform 后的参数在内层工具分发前真正生效完整变更覆盖而非提示钩子的仅建议行为deny阻断调用escalate咨询审批解析器可 per-tool 覆盖无解析器时 fail-closed 阻断。但它仍然是partial原因与能力无关而与发布形态有关该 crate 当前publish false只作为工作区成员构建在agent-control-spec0.4.0-alpha.3 与 AGT 主机 SDK 之上打包与规范栈决策仍在 #3680 跟踪。这正是清单证据规则的意义——实现存在与能力完整交付是两个不同的事实。deferred的正确打开方式Goose/ACPGoose/ACP 是唯一的deferred行。它不是说永远不会做而是说在所有权达成一致前不要实现。决策的当前负责人是 AGT 维护者如果维护者最终拒绝接受该参考集成实施工作应转移到消费方 Goose 仓库进行——前提是不得改变规范语义。对读者而言这意味着即使你有能力在 AGT 里实现一个 Goose 适配器在清单更新之前这也不是当前应该做的事。如何更新这份清单五步流程清单末尾给出了修改行的操作规范这也是源码驱动精神的最终落点搜索全部三个归属仓库中已开与已关闭的 issue 与 PR避免重复已有工作检查当前默认分支、适用的规范、schema、向量、实现与测试每行保持且仅有一个 owner对每个不完整状态都链接一个局限说明与一个跟踪项使用shipped之前必须有实现加上行为测试或官方一致性证据同步更新包矩阵与 Rust README当操作员可见的状态或可发现性变化时agent-governance-rust/README.md 必须跟随更新该 README 本身就链接回本清单形成双向引用闭环。阅读与实践建议把本清单作为决策工具使用可以总结出三条实用准则区分库能力与CLI 能力agentmeshcrate 的库面非常完整identity、policy、audit 哈希链、trust、rings、protocol facets、prompt injection 检测等模块在 lib.rs 全部公开但agtCLI 只是其中check/policy/audit/trust四个子集的薄封装——库有能力不等于 CLI 已暴露审计哈希链验证就是最典型的例子。区分依赖与一致性依赖agent-control-spec0.4.0-alpha.3依赖行存在与AGT 建立了 AGENT-HOOKS-0.1 主机一致性声明缺失行是两个不同的事实。前者是 Cargo.toml 里的一行依赖后者需要生产路径 harness 与被接受的 CTK 报告。把partial/missing当路线图而非缺陷每一行都附带了明确的局限描述与跟踪项编号例如统一 CLI 的partial明确点名缺少doctor、replay、离线完整性验证、合规/OWASP 验证与 dashboard 工作流。这份清单因此同时充当了能力盘点与演进路线图——而它的一切结论都以当前仓库的源码、测试与规范工件为唯一证据来源这正是它区别于一般 README 特性宣传的价值所在。【免费下载链接】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），仅供参考