Agent Governance Toolkit v4 策略语言移除的依赖变更审计从 npm 锁文件到 pip 哈希固定与 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 Toolkit 仓库中docs/dependency-audits/2026-07-27-v4-policy-language-removal.md这份依赖审计文档展开详细解析移除 v4 策略语言legacy policy language时涉及的依赖面变更TypeScript 侧新增 first-party ACS npm 包、Python 策略测试环境补齐pygments哈希固定、随示例删除的requirements.txt以及与 Rust 侧对应审计的联动。读完本文你将理解该项目在引入v4→ACS(v5) 策略层这一用户可见破坏性变更的同时如何通过精确的锁文件与哈希策略把依赖面风险控制在最小范围并掌握审计文档所要求的三大必填章节变更与原因、安全公告相关性、破坏性变更风险评估的实际写法。背景为什么移除 v4 策略语言会牵动依赖面Agent Governance ToolkitAGT正在移除其 legacy 的 v4 策略语言使 ACSv5策略层成为整个工具包中唯一的策略契约。正如 docs/v4-removal.md 所述v4 构造只能存活在单向迁移工具内部——该工具把 v4 项目转换为 v5 ACS manifest这对 v4 用户是一次明确的破坏性变更而BREAKING_CHANGES.md记录了所有需要消费者侧同步升级的条目。策略引擎本身的替换是主线但它并非孤立的代码删除而是牵动了多个语言生态的依赖图。2026-07-27-v4-policy-language-removal.md这份审计文档记录的正是这些依赖面副作用它明确说明没有升级任何第三方依赖变更只包含四件事一个 first-party ACS npm 包进入 TypeScript 锁文件一个缺失的传递依赖pygments被哈希固定四个随示例删除的requirements.txt被移除Rust crate 的 ACS 依赖由姊妹文档 2026-07-27-rust-acs-dependency.md 单独审计。该审计文档遵循 docs/dependency-audits/README.md 中规定的结构——任何改动锁文件或 vendored 内容的 PR 都必须附带一份YYYY-MM-DD-short-description.md命名的审计文档且必须包含三个章节Which dependencies changed and why、Security advisory relevance、Breaking change risk assessment。下面按这三个维度展开。一、哪些依赖变了、为什么变TypeScript 侧mastra-agentmesh锁文件纳入 ACS npm 包agentmesh-integrations/mastra-agentmesh/package-lock.json新增了agent-control-specification0.3.1-beta.0。原因是 TypeScript 策略面现在直接求值 ACS manifest而不是走 vendored 的 v4 路径。从源码可以印证这一点package.json 中dependencies明确声明agent-control-specification: 0.3.1-beta.0其 README 以import { AgentControl } from agent-control-specification为入口AgentControl正是 ACS 运行时的托管面package-lock.json 中可以看到该包解析为 npm registry 上的agent-control-specification-0.3.1-beta.0.tgz并带有跨平台的原生二进制与 OPA 引擎子包agent-control-specification-*-{darwin,linux,win32}-*。这里的关键点是该依赖是 first-party本项目自己的包且 MIT 许可包名agent-control-specification已注册在本项目名下。锁文件固定的 beta 版本与项目其他 TypeScript 策略面正在使用的版本一致因此并没有引入任何第三方供应链变动。Python 侧ci-policy-test.txt哈希固定pygments2.20.0Python 侧的唯一改动是 agent-governance-python/requirements/ci-policy-test.txt 固定了pygments2.20.0。原因链条值得展开该文件声明pytest9.0.3pytest9.0.3要求pygments2.7.2该文件以--require-hashes模式安装文件头注释也写明是 Scorecard Pinned-Dependencies 合规未固定哈希的传递依赖会被 pip 拒绝。换句话说pygments此前一直是 pip 在解析pytest依赖时自动带入的只是缺少哈希导致安装失败本次变更把它显式固定并不改变 CI 运行时实际安装的软件集合——只是把实际已在用但没哈希变成有哈希的显式声明。从文件内容可以看到完整的固定方式——每条依赖都带 wheel 与 sdist 双哈希# Hashed CI policy-test dependencies (Scorecard Pinned-Dependencies compliance) pyyaml6.0.2 \ --hashsha256:3ad2a3decf9aaba3d29c8f537ac4b243e36bef957511b4766cb0057d32b0be85 \ --hashsha256:80bab7bfc629882493af4aa31a4cfa43a4c57c83813253626916b8c7ada83476 \ --hashsha256:d584d9ec91ad65861cc08d42e834324ef890a082e591037abe114850ff7bbc3e pytest9.0.3 \ --hashsha256:2c5efc453d45394fdd706ade797c0a81091eccd1d6e4bccfcd476e2b8e0ab5d9 \ --hashsha256:b86ada508af81d19edeb213c681b1d48246c1a91d304c6c81a427674c17eb91c # pytest transitive dependencies pygments2.20.0 \ --hashsha256:81a9e26dd42fd28a23a2d169d86d7ac03b46e2f8b59ed4698fb4785f946d0176 \ --hashsha256:6757cd03768053ff99f3039c1a36d6c0aa0b263438fcab17520b30a303a82b5f iniconfig2.3.0 \ --hashsha256:f631c04d2c48c52b84d0d0549c99ff3859c98df65b3101406327ecc7d53fbf12 pluggy1.6.0 \ --hashsha256:e920276dd6813095e9377c0bc5566d94c932c33b27a3e3945d8389c374dd4746 packaging25.0 \ --hashsha256:29572ef2b1f17581046b3a2227d5c611fb25ec70ca1ba8554b24b0e69331a484审计文档还给出了一个值得注意的细节策略测试任务只在触碰策略路径的 PR上运行因此这个缺失哈希的缺口此前一直没有浮出水面——它直到本次变更触及策略路径时才暴露。这提醒我们CI 门禁的执行范围本身也会影响依赖问题的发现时机。删除的四个requirements.txt四个requirements.txt随其对应的示例一起被删除。审计文档特别强调没有任何包从任何已发布面上被移除——被删除的只是示例目录的自带依赖清单不影响任何 shipped surface 的依赖契约。二、安全公告相关性无 CVE但审计逻辑值得细读审计文档明确给出结论本变更不涉及任何 CVE 或安全公告。但两处论证体现了该仓库的供应链安全方法论pygments的冷却期与双哈希。pygments 2.20.0发布于 2026-03-29远超该仓库要求的七天冷却期seven-day cooling-off period且以精确版本 wheel/sdist 双哈希固定。由于 pip 此前已经把pygments作为pytest的依赖解析进来本次固定没有改变 CI 的运行时安装集合——它解决的只是缺哈希导致安装失败。ACS npm 包是 first-party。agent-control-specification是 MIT 许可的 first-party 包包名已注册在本项目名下。对--require-hashes这类严格供应链策略而言区分第三方新增与自有包回归是评估风险的关键第一步。三、破坏性变更风险评估对依赖消费者低风险审计结论是对依赖消费者风险低且与本次栈所携带的破坏性变更无关。npm 锁文件固定的 beta 版本与项目其他 TypeScript 面正在使用的 SDK 版本一致没有引入版本分叉pygments固定只影响 CI并且已在干净虚拟环境中以--require-hashes实际安装验证过真正面向用户的破坏性变更是v4 策略语言本身的移除这一点由 BREAKING_CHANGES.md 覆盖——例如策略引擎迁移到agent-control-spec与三值裁决契约allow/deny/transform其中warn归一化为带warnings[]的allowescalate归一化为携带approval块的deny、agt.policies包装层被移除、TrustMiddleware强制签名请求等条目。也就是说依赖审计关注的是锁文件/依赖面的连锁反应而用户可见的行为破坏由独立的破坏性变更文档统一管理二者职责分离。四、姊妹审计Rust 侧的 ACS 工作区依赖与本文档同一天发布的 2026-07-27-rust-acs-dependency.md 记录了 Rust 侧的对应变更agent-governance-rust/Cargo.lock新增agent_control_specification因为agentmeshcrate 现在通过 ACS 引擎求值策略而不是走 vendored v4 路径。它与本审计的几个交叉点值得注意路径依赖而非 registry 版本。该依赖是路径条目指向本仓库内的policy-engine/sdk/rust——正如 agent-governance-rust/Cargo.toml 工作区依赖所声明的agent_control_specification { path ../policy-engine/sdk/rust, version 0.4.0-beta.0 }。锁文件以cargo generate-lockfile --offline重新生成并用cargo metadata --offline --locked校验——后者在锁文件与 manifest 不一致时会直接失败。三方语言共享同一引擎。Python、TypeScript、Rust 三个面现在都对同一个 ACS 引擎求值三个面不再可能对同一个策略结果产生分歧。这与本文档中 TypeScript 锁文件纳入同一agent-control-specification包形成呼应——跨语言策略一致性的收益正是本次依赖面改动的核心动机之一。传递依赖成本不免费。Cargo.lock新增 66 个包条目2 个 first-party crateagent_control_specification、agent_control_specification_core 64 个此前不在工作区图中的第三方 crate。这些依赖聚成两大簇manifest 校验jsonschema带来fancy-regex、fraction、num*、referencing以及经idna/url进入的icu_*unicode 表HTTP 与 TLS 栈更值得关注ureq、rustls、ring、webpki-roots全部进入依赖图。它们之所以出现是因为 ACS Rust SDK 的 core features 固定包含openai_moderation、perspective、llama_guard、lakera_guard、auto并且 SDK 中存在Manifest::from_url。agentmesh无法选择性退出——feature 集是在 SDK crate 内部固定的不由消费者选择。审计文档对此给出的诚实结论是agentmesh中没有任何代码调用远程 annotator 或from_url所以实际上没有新增网络出口但网络能力已经被链接进来了——对于一个治理库这值得直说而不是把变更描述成什么都没引入。收缩 SDK feature 集、让宿主可以不构建网络栈构建属于 ACS crate 的后续工作而非本 PR 的职责。同时文档要求发布前针对新依赖集确认cargo deny与cargo audit的覆盖。风险评估同样为低工作区内的路径依赖不改变下游 crate 的任何已发布版本约束cargo check --offline --workspace可编译通过。五、从审计文档反观整个移除流程把这份审计放回更大的上下文可以看到它处在 docs/v4-removal.md 所描述的分阶段移除计划内部 strangler 模式 一次原子性公开破坏性发布的收尾环节v4 语义盘点与 CI 棘轮scripts/check_v4_ratchet.py按文件盘点每个残存的 v4 符号并强制执行严格棘轮——任何变更不得新增 v4 用法、不得把 v4 标记移入新文件、每符号计数不得上升Python 检测是 AST 与 import 感知的字符串和注释不会误计数。scripts/v4_ratchet_baseline.json是提交的基线最终阶段会把非迁移总数驱动到零v4 构造的单一合法居所迁移工具agent-governance-python/agt-policies/src/agt/cli/migrate.py及同类模块读取 v4 项目一次并输出扁平 ACS manifest 与 bundles运行时模块只接受 ACS/AGT manifest组合使用原生 ACSextends依赖面收尾正如本文档所示移除的最后一英里还包括把各语言锁文件/哈希清单与ACS 成为唯一策略引擎这一事实对齐。结语一份依赖审计文档应该回答什么从这份文档可以提炼出该仓库对依赖审计文档的验收标准变更要逐条说清每条依赖、每个文件、为什么、安全相关性要明确表态有无 CVE无则论证为何安全、破坏性风险要分级评估区分依赖消费者风险与用户可见破坏并且把跨语言的姊妹变更互相引用、彼此闭环。对于任何维护多语言 monorepo、且正处在策略引擎迁移期的项目这份2026-07-27-v4-policy-language-removal.md与其姊妹文档 2026-07-27-rust-acs-dependency.md 是一组值得对照阅读的范本它们证明了一次彻底的引擎替换可以在依赖面上做到——不升级任何第三方依赖、不改变 CI 运行时安装集合、不破坏任何 shipped surface同时把真实存在的传递依赖成本哪怕只是被链接进来而未被使用诚实地记录在案。【免费下载链接】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），仅供参考