人工智能AI AgentAI 安全治理策略引擎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点击查看免费下载本篇技术指南以 policy-engine/QUICKSTART.md 为骨架完整讲解如何把 Agent Control SpecificationACS策略执行引擎接入任意 Agent Host从一张空白的 manifest 开始逐步构建出在每一个模型边界与工具边界都被策略中介mediate的 Agent 循环。文中 manifest 与策略编写步骤是语言无关的构造与评估步骤则同时给出 Rust、Python、Node、.NET 四种 SDK 的等价写法全部示例与底层原理均来自当前仓库 policy-engine/ 目录。读完后你将掌握声明 ACS manifest 与 Rego 策略、在八个干预点评估并执行判定、用编排 helper 一次性完成评估执行转换审批、通过生成器初始化合规的 ACS 制品以及如何用仓库内的测试与示例验证自己的集成。ACS 在 Host 中的定位PEP 与 PDP 分离ACS 是 Agent Governance Toolkit 的策略层定位为一个**无状态、确定性、失败即关闭fail closed**的策略决策运行时见 policy-engine/README.md。它的集成模型非常清晰Host 拥有 Agent 循环充当策略执行点PEPPolicy Enforcement Point。在每个干预点上Host 把即将发生什么的完整 JSON 快照交给 ACS例如入站请求、一次模型调用、一次具体的工具调用。ACS 充当策略决策点PDPPolicy Decision Point。它评估绑定在该干预点上的策略返回三种东西verdict判定、仅当判定为transform时可选的已转换策略目标transformed policy target、以及产生该决策的策略输入policy input。ACS 在调用之间不持有任何状态因此 Host 每次都必须提供完整快照同时 Host 负责对判定采取行动——ACS 决策Host 执行。这与 README 中声明的运行时契约一致无状态运行时不保留会影响后续判定的可变状态、确定性相同 manifest、快照、模式与 dispatcher 输出必然产生相同判定、失败即关闭运行时故障一律返回deny使用保留的运行时错误 reason且不应用任何转换。前置条件需求用途任一 SDK 工具链Rust 1.85、Python 3.11、Node 18 或 .NET 8从你的 Host 构建并调用 ACSPATH上的opa内置的、用于运行 Rego 策略的 dispatcher。仅当 manifest 使用rego策略时才需要注意OPA 只在策略通过内置 OPA dispatcher 求值时、于运行时才需要。如果 Host 自带策略 dispatcher则无需安装 OPA。Step 1. 安装 SDK四种 SDK 的常规安装方式如下SDK安装命令Rustcargo add agent_control_specificationPythonpython -m pip install agent-control-specificationNodenpm install agent-control-specification.NETdotnet add package AgentControlSpecification每个 SDK 都加载同一个原生核心Rust crate 直接链接它Python 与 Node 包携带编译好的原生扩展.NET 包则把原生库与托管程序集一起发布。如果要从本仓库源码构建而非使用已发布包请遵循 SDK 矩阵 中的构建命令。使用独立 ACS 制品包artifact kit安装如果软件包尚未发布、需要从独立制品包安装请把ACS_KIT环境变量指向包含artifacts/的制品包根目录SDK仅制品安装Rust解压agent_control_specification_core-*.crate、agent_control_specification-*.crate以及你需要的集成 crate如agent_control_specification_openai-*.crate、agent_control_specification_mcp-*.crate、agent_control_specification_rig-*.crate然后添加指向解压目录的[patch.crates-io]条目。Pythonpython -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whlNodenpm install $ACS_KIT/artifacts/agent-control-specification-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-linux-x64-gnu-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz.NETdotnet add package AgentControlSpecification --version 0.3.1-beta.0 --source $ACS_KIT/artifacts生成器python -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whl $ACS_KIT/artifacts/acs_generator-0.4.0b0-py3-none-any.whlC ABI编译时链接$ACS_KIT/artifacts/include/agent_control_specification.h链接或加载$ACS_KIT/artifacts/libagent_control_specification_core.so。两点平台注意事项Python 制品安装可能从你配置的软件包索引解析第三方 wheel 依赖除非制品包同时包含 Python 依赖 wheelhouse只有包含该依赖闭包的制品包才能配合--no-index --find-links $ACS_KIT/artifacts使用。Node 制品安装中请把agent-control-specification-linux-x64-gnu与agent-control-specification-opa-linux-x64替换为与宿主平台匹配的原生包与 OPA 包。Step 2. 声明 Manifest把策略绑定到干预点manifest 的作用是把命名策略绑定到干预点。最小的可用 manifest 声明一条 Rego 策略并守卫一个干预点。把下面的内容保存为 Host 旁边的manifest.yamlagent_control_specification_version: 0.4.0-alpha.1 metadata: name: my-agent policies: email_policy: type: rego bundle: ./policy query: data.my_agent.verdict intervention_points: pre_tool_call: policy_target: $.tool_call.args policy_target_kind: tool_args tool_name_from: $.tool_call.name policy: id: email_policy tools: send_email: type: Tool id: send_email clearance: internal字段含义policy_target是待求值值在快照中的路径tool_name_from仅在两个工具干预点上必需用于指明承载当前工具名的路径tools块是投影后的工具元数据目录策略可以读取它。manifest 模式的完整概览见 README 的 Manifest schema overview规范定义见 policy-engine/spec/SPECIFICATION.md。从 README 可以进一步了解 manifest 的顶层块块含义agent_control_specification_version非空版本字符串当前规范描述为0.4.0-alpha.1metadata自由形式的 manifest 元数据extends有序的父 manifest 路径或 HTTPS URLACS 兼容AGT Host 提交的是解析后的 manifestpolicies命名策略定义支持rego、cedar、test、custom四种类型intervention_points以八个干预点名称为键的封闭映射每个条目绑定一条策略tools投影工具元数据目录条目接受任意字段包括clearance与security_labelsannotators命名注释器声明类型为classifier、llm或endpointapproval由 AGT 拥有的升级后端escalation backend配置干预点条目字段policy_target待求值值的快照路径、policy_target_kind可选描述性标签会复制进策略输入、annotations按点选择已声明注释器及其from路径、policy含id、可选query与 Host 定义的 adapter 字段、tool_name_from仅工具干预点上的当前工具名快照路径。仓库中 policy-engine/examples/bank_agent/manifest.yaml 给出了一个绑定全部八个干预点、附带八个classifier注释器与工具目录含clearance、security_labels的完整参考 manifest是理解字段组合方式的极佳样例。Step 3. 编写策略verdict 契约与五种决策内置 dispatcher 会相对 manifest 解析bundle路径所以创建policy/my_agent.rego。下面这条策略拒绝任何参数中提到外部收件人的工具调用package my_agent import rego.v1 default verdict : {decision: allow} verdict : { decision: deny, reason: external_recipient_blocked, message: This tool may not send to external recipients., } if { args : object.get(input.policy_target, value, {}) contains(lower(object.get(args, to, )), external.example) }verdict 必须携带decision取值只能是allow、deny、warn、escalate、transform之一。其余字段约定与 README 中 verdict 成员表一致verdict 成员含义decision必填取值为allow、deny、warn、escalate或transformreason可选的低基数low cardinality错误码message可选、面向 Host 的文本transform可选主体仅transform决策需要evidence可选的不透明证据对象会传播到遥测result_labels可选标签Host 可随产出的数据一并持久化两条硬性规则策略只有在transform决策下才能返回transform主体——allow、warn、deny、escalate四种决策永不修改策略目标reason 不得使用保留的runtime_error:前缀该命名空间是运行时故障专用的详见 README 的 Reserved reasons 一节与规范第 15 节。仓库中 policy-engine/examples/bank_agent/policy/bank_agent_rego.rego 展示了更完整的策略写法用default point_verdict声明八个默认判定再以input.intervention_point分派到各点的具体规则涵盖 deny高风险输入、模型建议绕过审批、escalate大额转账需人工审批、transform插入系统提示、脱敏账号、warn关闭审计等全部五种决策形态与 Step 5-7 的语义一一对应。Step 4. 构造运行时零配置from_path使用零配置的from_path构造器。不带任何 dispatcher 参数时它会针对 manifest 相对路径的 Rego bundle 接好内置 OPA 策略 dispatcher因此 Rego Host 无需编写任何 dispatcher 代码何时需要自供 dispatcher 见 README 的 Zero-config constructionuse agent_control_specification::AgentControl; let control AgentControl::from_path(manifest.yaml)?;from agent_control_specification import AgentControl control AgentControl.from_path(manifest.yaml)const { AgentControl } require(agent-control-specification); const control AgentControl.fromPath(manifest.yaml);using AgentControlSpecification; var control AgentControl.FromPath(manifest.yaml);Step 5. 在干预点求值传入干预点与完整快照在你声明的边界处调用 SDK传入干预点与快照。结果携带verdict、transform时的已转换策略目标以及产生决策的策略输入use agent_control_specification::{Decision, EnforcementMode, InterventionPoint}; use serde_json::json; let result control.evaluate_intervention_point( InterventionPoint::PreToolCall, json!({tool_call: {id: t1, name: send_email, args: {to: userexternal.example}}}), EnforcementMode::Enforce, ); assert_eq!(result.verdict.decision, Decision::Deny);from agent_control_specification import InterventionPoint result await control.evaluate_intervention_point( InterventionPoint.PRE_TOOL_CALL, {tool_call: {id: t1, name: send_email, args: {to: userexternal.example}}}, ) assert result.verdict.decision.value denyconst { InterventionPoint } require(agent-control-specification); const result await control.evaluateInterventionPoint( InterventionPoint.PreToolCall, { tool_call: { id: t1, name: send_email, args: { to: userexternal.example } } }, );var result await control.EvaluateInterventionPointAsync( InterventionPoint.PreToolCall, System.Text.Json.JsonDocument.Parse( {tool_call:{id:t1,name:send_email,args:{to:userexternal.example}}}).RootElement.Clone());注意 API 差异Rust SDK 在evaluate_intervention_point上接收EnforcementModePython、Node、.NET SDK 求值时不带模式而是通过 Step 7 介绍的run与enforcehelper 应用执行enforcement。Step 6. 执行判定五种决策的 Host 动作evaluate_intervention_point返回判定后由 Host 决定如何处理决策Host 动作allow使用原始策略目标继续执行。warn使用原始策略目标继续执行但记录该警告。deny阻止该动作向调用方展示reason与message。escalate挂起该动作在继续前请求人类或外部权威机构审批。transform仅使用返回的已转换策略目标继续执行。当策略返回transform时运行时在enforce模式下校验转换路径、将其应用到策略目标并把转换后的值暴露在结果上。执行工具、发送模型请求、存储工具结果或披露输出之前必须读取已转换的策略目标而非原始值。脱敏redaction是最常见的用例但核心在任何情况下都不会在allow、warn、deny、escalate时修改数据。这也呼应了 README 中与上游 ACS 的一个关键分歧本引擎把 effect 机制移除、替换为transform判定类型使转换成为可审计、可验证的显式决策。Step 7. 中介整个 Agent 循环八个干预点与编排 helper真实 Host 守卫的不止一个点。在循环的对应位置接入每个相关干预点干预点何时调用agent_startup会话或运行开始时、循环开始之前input外部请求到达时、Agent 处理它之前pre_model_call模型请求组装完成后、模型调用之前post_model_call模型响应返回后、Host 处理它之前pre_tool_call具体工具调用就绪后、执行之前post_tool_call工具结果返回后、到达 Agent 或调用方之前output最终面向用户可见的响应组装完成后、发送之前agent_shutdown会话或运行结束时其中pre_tool_call与post_tool_call是仅有的两个工具干预点也是仅有的接受tool_name_from的点。手动逐点调用evaluate_intervention_point可行但每个 SDK 都内置了编排 helper把求值、执行、转换应用与审批打包进一次调用普通 Host 应优先使用Helper守卫的点run包裹一个运行可调用对象的input与outputrun_model包裹一次模型调用的pre_model_call与post_model_callrun_tool与protect_tool包裹一次工具执行的pre_tool_call与post_tool_call在 enforce 模式下这些 helper 遇到deny会抛出阻塞错误blocked error遇到escalate则咨询审批解析器approval resolver——它是 Host 侧的一个回调返回 allow、deny 或 suspend。各语言的方法名与接线细节见仓库sdk/下的各 SDK README以及制品包内附的PYTHON_README.md、NODE_README.md、DOTNET_README.md。仓库中 policy-engine/examples/bank_agent/manifest.yaml 与配套 Rego 策略是全循环中介的完整可运行参考八个干预点全部绑定策略pre_tool_call对 10000 以上电汇返回escalatepost_model_call拦截bypass approval提示output用正则把CHK-[0-9]账号脱敏为ACCOUNT-REDACTED。另有 policy-engine/integrations/openai/、policy-engine/integrations/mcp/、policy-engine/integrations/rig/ 下的 Rust 集成 crate 示例展示在真实框架的工具调用点挂上守卫的写法。Step 8. 添加注释器与脱敏有两类常见需求不需要在 Host 侧编写超出内置默认的 dispatcher 代码。注释器annotators把派生的信号如分类器评分挂到策略输入的annotations.name下供策略读取。在 manifest 的annotators块中声明它们并用annotations映射让某个干预点选入。注意内置的classifier、llm、endpoint注释器会发起网络调用因此零配置使用注释器需要一个可达的端点以及所需的凭证。参考 dispatcher 示例位于仓库 policy-engine/integrations/annotators/Rust 侧实现对应core/src/dispatchers/classifier.rs、core/src/dispatchers/llm.rs、core/src/dispatchers/endpoint.rs运行时把每个点特定的from路径对初步策略输入解析后调用 dispatcher且只在annotations.name下写入返回值。README 中的 LLM 注释器供应商指南 提供了可插拔供应商预设。脱敏redaction不需要自定义 dispatcher。返回transform判定、让transform.value携带脱敏后的策略目标然后按 Step 6 读取已转换策略目标即可。仓库示例 policy-engine/examples/support_agent/ 正是以这种方式脱敏 PII。Step 9. 验证集成制品冒烟测试与跨 SDK 一致性先确认 SDK 在你的环境中能正确对接原生核心。在制品包场景下把包安装进一个临时 Host 项目用你计划发布的 manifest 跑一个 allow 和一个 deny 冒烟测试在源码检出场景下使用项目构建说明描述的各语言测试套件。SDK制品冒烟测试Rust构建一个依赖本地.crate制品的临时 crate求值一个 manifest。Python把artifacts/中的 wheel 安装进临时虚拟环境调用NativeRuntimeClient.from_path。Node把artifacts/中的.tgz包安装进临时项目调用AgentControl.fromPath。.NET从artifacts/的本地 nupkg 源还原调用AgentControl.FromPath。在本地验证 CI 对齐时设置AGENT_CONTROL_REQUIRE_OPA1让依赖 OPA 的测试在缺失 OPA 时响亮失败而不是被跳过。仓库 policy-engine/tests/ 下的跨 SDK 一致性 fixtures 断言四个 SDK 对同一批快照给出相同判定。对于仅制品的包请从临时 Host 项目验证已安装包而不是运行仓库检出的测试套件SDK仅制品冒烟检查命令Rustmkdir crates for c in agent_control_specification_core agent_control_specification agent_control_specification_openai agent_control_specification_mcp agent_control_specification_rig; do tar -xzf $ACS_KIT/artifacts/$c-0.3.1-beta.0.crate -C crates 2/dev/null || true; done然后在cargo check之前把[patch.crates-io]指向解压出的crates/name-0.3.1-beta.0目录Pythonpython -m venv .venv .venv/bin/python -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whl .venv/bin/python -c import agent_control_specification as acs; print(acs.AgentControl)Nodenpm init -y npm install $ACS_KIT/artifacts/agent-control-specification-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-linux-x64-gnu-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz node -e const acsrequire(agent-control-specification); console.log(typeof acs.AgentControl).NETdotnet new console -n AcsSmoke cd AcsSmoke dotnet add package AgentControlSpecification --version 0.3.1-beta.0 --source $ACS_KIT/artifacts dotnet build制品校验所有 SDK 共享同一个原生实现除冒烟测试外Rust 核心还暴露validate_acs_artifacts每个语言 SDK 都委托给该实现四个 SDK 返回的结果结构完全一致——valid加上针对 manifest 模式、类型化 ACS 语义、OPA Rego 解析的结构化诊断use agent_control_specification::validate_acs_artifacts; let result validate_acs_artifacts(manifest_yaml, rego_modules, None);策略绑定通过policy.id选择一条策略Rego 策略要求在策略定义或绑定上给出query。规范 JSON Schema 位于 policy-engine/core/schema/含manifest.schema.json与approval.schema.json规范的权威契约见 policy-engine/spec/SPECIFICATION.md。用生成器初始化acs-generate init当第一套 ACS 制品应当构造即正确valid by construction而不是手工拼装时使用生成器。引导式初始化流程会询问你要中介的干预点、工具目录条目、要拦截的关键词、审批门与输出脱敏模式然后写出 manifest、Rego 策略、报告与可选的示例快照acs-generate init --non-interactive --name Demo Agent --points input,pre_tool_call,output --tool send_email:internal --deny-keyword secret --escalate-tool send_email --sample-snapshot --out build/demo-acs输出目录必须为空除非提供--force。当本地 OPA 校验必须与 CI 一致时加上--strict。安装生成器包后同一命令也可以写为acs init。生成器会写manifest.yaml、policy/slug.rego、report.md以及可选的snapshots/intervention_point.json与test_policy.py冒烟测试。生成器 READMEpolicy-engine/generator/README.md还补充了两点生产实践可重复运行--answers-file支持 CI 与重复本地运行接受与 CLI 标志一致的字段name、points、tools、deny_keywords、escalate_tools、redact_output_patterns不支持的关键字会快速失败避免 CI 静默忽略预期设置--answers-file -支持从 stdin 读取 JSON/YAML。严格模式下的 OPA仅制品包内置本地 Node 可选 OPA 包安装后把其bin目录前置到PATH再运行--strictnpm install $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz PATH$PWD/node_modules/agent-control-specification-opa-linux-x64/bin:$PATH \ acs-generate init --strict --non-interactive --name Payments Agent --out build/acs-payments生成后的叠加extends子 manifest生成之后要做增量改动时使用带extends的子 manifest。子 manifest 可以添加 metadata 键、策略、注释器、工具或新的干预点但不能用不同的值替换已有干预点的策略、目标或tool_name_from——冲突的重复项在 manifest 加载时会失败即关闭。基于文件的extends限定在顶层 manifest 根目录内把父 manifest 放在子根目录之下例如base/manifest.yaml或者当 SDK 提供 manifest-chain 构造器时用它加载并列的兄弟 manifest。这一父策略不可被替换、只能叠加的合并语义也体现在 AGT 的 ADRdocs/adr/0014-parent-deny-rules-immutable-in-merge.md中属于本项目对上游 ACS 的既定分歧之一。更进一步从 Quickstart 到生产落地阅读权威契约policy-engine/spec/SPECIFICATION.md了解 Host 义务与安全边界policy-engine/docs/security-model.md以及无状态运行时契约 policy-engine/docs/stateless-runtime.md挑选合适的 SDK 面policy-engine/docs/sdk-surfaces.md包装真实 Agent 框架参考 policy-engine/docs/adapter-matrix.md 与 README 的 Framework adapters 一节研究可运行 Host 示例仓库 policy-engine/examples/ 下按场景组织包括bank_agent全生命周期点、转换与脱敏、lifecycle_rego零配置 Rego 全流程、custom_dispatchers离线分类器/端点/LLM 注释器与自定义策略 dispatcher、manifest_extends文件式 manifest 组合、conformance_snapshotsfixture 驱动的策略评审、coding_agentRust Host 应用、ifc_agent无状态信息流控制标签流转遥测Rust 核心通过TelemetrySink输出结构化、默认脱敏的事件decision、policy_evaluation、intervention_point.transformed等四个 SDK 都内置可插拔 sink 与 OpenTelemetry 指标契约acs_intervention_{allow,deny,warn,escalate,transform}_total计数器与acs_intervention_duration_ms直方图meter 名为agent_control_specification见 policy-engine/docs/observability.md至此你已拥有一套从空 manifest 到全循环中介的完整集成路径声明策略、绑定干预点、零配置构造运行时、按五种判定执行、用编排 helper 覆盖整个 Agent 生命周期并通过制品校验、冒烟测试与生成器保证制品质量。ACS 的定义一次处处执行Define once. Enforce everywhere.理念最终落地为 Host 与策略层之间清晰、可审计、失败即关闭的决策契约。赞分享人工智能AI AgentAI 安全治理策略引擎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 原生策略运行时迁移指南从 v4 策略引擎到 ACSAgent Control Specification1.0Agent Governance Toolkit 原生策略运行时迁移指南从 v4 策略引擎到 ACSAgent Control Specification人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Agent Control Specification Python SDK将 ACS 策略判定运行时接入 Python Agent 宿主的完整指南Agent Control Specification Python SDK将 ACS 策略判定运行时接入 Python Agent 宿主的完整指南 本文基于人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Agent Control Specification .NET SDK 实战用 Rust 内核为 .NET Agent 加装策略治理Agent Control Specification .NET SDK 实战用 Rust 内核为 .NET Agent 加装策略治理 Agent Contr人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 将 Agent Control Specification 集成到 Agent Host：ACS 策略执行引擎实战指南
人工智能AI AgentAI 安全治理策略引擎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点击查看免费下载本篇技术指南以 policy-engine/QUICKSTART.md 为骨架完整讲解如何把 Agent Control SpecificationACS策略执行引擎接入任意 Agent Host从一张空白的 manifest 开始逐步构建出在每一个模型边界与工具边界都被策略中介mediate的 Agent 循环。文中 manifest 与策略编写步骤是语言无关的构造与评估步骤则同时给出 Rust、Python、Node、.NET 四种 SDK 的等价写法全部示例与底层原理均来自当前仓库 policy-engine/ 目录。读完后你将掌握声明 ACS manifest 与 Rego 策略、在八个干预点评估并执行判定、用编排 helper 一次性完成评估执行转换审批、通过生成器初始化合规的 ACS 制品以及如何用仓库内的测试与示例验证自己的集成。ACS 在 Host 中的定位PEP 与 PDP 分离ACS 是 Agent Governance Toolkit 的策略层定位为一个**无状态、确定性、失败即关闭fail closed**的策略决策运行时见 policy-engine/README.md。它的集成模型非常清晰Host 拥有 Agent 循环充当策略执行点PEPPolicy Enforcement Point。在每个干预点上Host 把即将发生什么的完整 JSON 快照交给 ACS例如入站请求、一次模型调用、一次具体的工具调用。ACS 充当策略决策点PDPPolicy Decision Point。它评估绑定在该干预点上的策略返回三种东西verdict判定、仅当判定为transform时可选的已转换策略目标transformed policy target、以及产生该决策的策略输入policy input。ACS 在调用之间不持有任何状态因此 Host 每次都必须提供完整快照同时 Host 负责对判定采取行动——ACS 决策Host 执行。这与 README 中声明的运行时契约一致无状态运行时不保留会影响后续判定的可变状态、确定性相同 manifest、快照、模式与 dispatcher 输出必然产生相同判定、失败即关闭运行时故障一律返回deny使用保留的运行时错误 reason且不应用任何转换。前置条件需求用途任一 SDK 工具链Rust 1.85、Python 3.11、Node 18 或 .NET 8从你的 Host 构建并调用 ACSPATH上的opa内置的、用于运行 Rego 策略的 dispatcher。仅当 manifest 使用rego策略时才需要注意OPA 只在策略通过内置 OPA dispatcher 求值时、于运行时才需要。如果 Host 自带策略 dispatcher则无需安装 OPA。Step 1. 安装 SDK四种 SDK 的常规安装方式如下SDK安装命令Rustcargo add agent_control_specificationPythonpython -m pip install agent-control-specificationNodenpm install agent-control-specification.NETdotnet add package AgentControlSpecification每个 SDK 都加载同一个原生核心Rust crate 直接链接它Python 与 Node 包携带编译好的原生扩展.NET 包则把原生库与托管程序集一起发布。如果要从本仓库源码构建而非使用已发布包请遵循 SDK 矩阵 中的构建命令。使用独立 ACS 制品包artifact kit安装如果软件包尚未发布、需要从独立制品包安装请把ACS_KIT环境变量指向包含artifacts/的制品包根目录SDK仅制品安装Rust解压agent_control_specification_core-*.crate、agent_control_specification-*.crate以及你需要的集成 crate如agent_control_specification_openai-*.crate、agent_control_specification_mcp-*.crate、agent_control_specification_rig-*.crate然后添加指向解压目录的[patch.crates-io]条目。Pythonpython -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whlNodenpm install $ACS_KIT/artifacts/agent-control-specification-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-linux-x64-gnu-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz.NETdotnet add package AgentControlSpecification --version 0.3.1-beta.0 --source $ACS_KIT/artifacts生成器python -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whl $ACS_KIT/artifacts/acs_generator-0.4.0b0-py3-none-any.whlC ABI编译时链接$ACS_KIT/artifacts/include/agent_control_specification.h链接或加载$ACS_KIT/artifacts/libagent_control_specification_core.so。两点平台注意事项Python 制品安装可能从你配置的软件包索引解析第三方 wheel 依赖除非制品包同时包含 Python 依赖 wheelhouse只有包含该依赖闭包的制品包才能配合--no-index --find-links $ACS_KIT/artifacts使用。Node 制品安装中请把agent-control-specification-linux-x64-gnu与agent-control-specification-opa-linux-x64替换为与宿主平台匹配的原生包与 OPA 包。Step 2. 声明 Manifest把策略绑定到干预点manifest 的作用是把命名策略绑定到干预点。最小的可用 manifest 声明一条 Rego 策略并守卫一个干预点。把下面的内容保存为 Host 旁边的manifest.yamlagent_control_specification_version: 0.4.0-alpha.1 metadata: name: my-agent policies: email_policy: type: rego bundle: ./policy query: data.my_agent.verdict intervention_points: pre_tool_call: policy_target: $.tool_call.args policy_target_kind: tool_args tool_name_from: $.tool_call.name policy: id: email_policy tools: send_email: type: Tool id: send_email clearance: internal字段含义policy_target是待求值值在快照中的路径tool_name_from仅在两个工具干预点上必需用于指明承载当前工具名的路径tools块是投影后的工具元数据目录策略可以读取它。manifest 模式的完整概览见 README 的 Manifest schema overview规范定义见 policy-engine/spec/SPECIFICATION.md。从 README 可以进一步了解 manifest 的顶层块块含义agent_control_specification_version非空版本字符串当前规范描述为0.4.0-alpha.1metadata自由形式的 manifest 元数据extends有序的父 manifest 路径或 HTTPS URLACS 兼容AGT Host 提交的是解析后的 manifestpolicies命名策略定义支持rego、cedar、test、custom四种类型intervention_points以八个干预点名称为键的封闭映射每个条目绑定一条策略tools投影工具元数据目录条目接受任意字段包括clearance与security_labelsannotators命名注释器声明类型为classifier、llm或endpointapproval由 AGT 拥有的升级后端escalation backend配置干预点条目字段policy_target待求值值的快照路径、policy_target_kind可选描述性标签会复制进策略输入、annotations按点选择已声明注释器及其from路径、policy含id、可选query与 Host 定义的 adapter 字段、tool_name_from仅工具干预点上的当前工具名快照路径。仓库中 policy-engine/examples/bank_agent/manifest.yaml 给出了一个绑定全部八个干预点、附带八个classifier注释器与工具目录含clearance、security_labels的完整参考 manifest是理解字段组合方式的极佳样例。Step 3. 编写策略verdict 契约与五种决策内置 dispatcher 会相对 manifest 解析bundle路径所以创建policy/my_agent.rego。下面这条策略拒绝任何参数中提到外部收件人的工具调用package my_agent import rego.v1 default verdict : {decision: allow} verdict : { decision: deny, reason: external_recipient_blocked, message: This tool may not send to external recipients., } if { args : object.get(input.policy_target, value, {}) contains(lower(object.get(args, to, )), external.example) }verdict 必须携带decision取值只能是allow、deny、warn、escalate、transform之一。其余字段约定与 README 中 verdict 成员表一致verdict 成员含义decision必填取值为allow、deny、warn、escalate或transformreason可选的低基数low cardinality错误码message可选、面向 Host 的文本transform可选主体仅transform决策需要evidence可选的不透明证据对象会传播到遥测result_labels可选标签Host 可随产出的数据一并持久化两条硬性规则策略只有在transform决策下才能返回transform主体——allow、warn、deny、escalate四种决策永不修改策略目标reason 不得使用保留的runtime_error:前缀该命名空间是运行时故障专用的详见 README 的 Reserved reasons 一节与规范第 15 节。仓库中 policy-engine/examples/bank_agent/policy/bank_agent_rego.rego 展示了更完整的策略写法用default point_verdict声明八个默认判定再以input.intervention_point分派到各点的具体规则涵盖 deny高风险输入、模型建议绕过审批、escalate大额转账需人工审批、transform插入系统提示、脱敏账号、warn关闭审计等全部五种决策形态与 Step 5-7 的语义一一对应。Step 4. 构造运行时零配置from_path使用零配置的from_path构造器。不带任何 dispatcher 参数时它会针对 manifest 相对路径的 Rego bundle 接好内置 OPA 策略 dispatcher因此 Rego Host 无需编写任何 dispatcher 代码何时需要自供 dispatcher 见 README 的 Zero-config constructionuse agent_control_specification::AgentControl; let control AgentControl::from_path(manifest.yaml)?;from agent_control_specification import AgentControl control AgentControl.from_path(manifest.yaml)const { AgentControl } require(agent-control-specification); const control AgentControl.fromPath(manifest.yaml);using AgentControlSpecification; var control AgentControl.FromPath(manifest.yaml);Step 5. 在干预点求值传入干预点与完整快照在你声明的边界处调用 SDK传入干预点与快照。结果携带verdict、transform时的已转换策略目标以及产生决策的策略输入use agent_control_specification::{Decision, EnforcementMode, InterventionPoint}; use serde_json::json; let result control.evaluate_intervention_point( InterventionPoint::PreToolCall, json!({tool_call: {id: t1, name: send_email, args: {to: userexternal.example}}}), EnforcementMode::Enforce, ); assert_eq!(result.verdict.decision, Decision::Deny);from agent_control_specification import InterventionPoint result await control.evaluate_intervention_point( InterventionPoint.PRE_TOOL_CALL, {tool_call: {id: t1, name: send_email, args: {to: userexternal.example}}}, ) assert result.verdict.decision.value denyconst { InterventionPoint } require(agent-control-specification); const result await control.evaluateInterventionPoint( InterventionPoint.PreToolCall, { tool_call: { id: t1, name: send_email, args: { to: userexternal.example } } }, );var result await control.EvaluateInterventionPointAsync( InterventionPoint.PreToolCall, System.Text.Json.JsonDocument.Parse( {tool_call:{id:t1,name:send_email,args:{to:userexternal.example}}}).RootElement.Clone());注意 API 差异Rust SDK 在evaluate_intervention_point上接收EnforcementModePython、Node、.NET SDK 求值时不带模式而是通过 Step 7 介绍的run与enforcehelper 应用执行enforcement。Step 6. 执行判定五种决策的 Host 动作evaluate_intervention_point返回判定后由 Host 决定如何处理决策Host 动作allow使用原始策略目标继续执行。warn使用原始策略目标继续执行但记录该警告。deny阻止该动作向调用方展示reason与message。escalate挂起该动作在继续前请求人类或外部权威机构审批。transform仅使用返回的已转换策略目标继续执行。当策略返回transform时运行时在enforce模式下校验转换路径、将其应用到策略目标并把转换后的值暴露在结果上。执行工具、发送模型请求、存储工具结果或披露输出之前必须读取已转换的策略目标而非原始值。脱敏redaction是最常见的用例但核心在任何情况下都不会在allow、warn、deny、escalate时修改数据。这也呼应了 README 中与上游 ACS 的一个关键分歧本引擎把 effect 机制移除、替换为transform判定类型使转换成为可审计、可验证的显式决策。Step 7. 中介整个 Agent 循环八个干预点与编排 helper真实 Host 守卫的不止一个点。在循环的对应位置接入每个相关干预点干预点何时调用agent_startup会话或运行开始时、循环开始之前input外部请求到达时、Agent 处理它之前pre_model_call模型请求组装完成后、模型调用之前post_model_call模型响应返回后、Host 处理它之前pre_tool_call具体工具调用就绪后、执行之前post_tool_call工具结果返回后、到达 Agent 或调用方之前output最终面向用户可见的响应组装完成后、发送之前agent_shutdown会话或运行结束时其中pre_tool_call与post_tool_call是仅有的两个工具干预点也是仅有的接受tool_name_from的点。手动逐点调用evaluate_intervention_point可行但每个 SDK 都内置了编排 helper把求值、执行、转换应用与审批打包进一次调用普通 Host 应优先使用Helper守卫的点run包裹一个运行可调用对象的input与outputrun_model包裹一次模型调用的pre_model_call与post_model_callrun_tool与protect_tool包裹一次工具执行的pre_tool_call与post_tool_call在 enforce 模式下这些 helper 遇到deny会抛出阻塞错误blocked error遇到escalate则咨询审批解析器approval resolver——它是 Host 侧的一个回调返回 allow、deny 或 suspend。各语言的方法名与接线细节见仓库sdk/下的各 SDK README以及制品包内附的PYTHON_README.md、NODE_README.md、DOTNET_README.md。仓库中 policy-engine/examples/bank_agent/manifest.yaml 与配套 Rego 策略是全循环中介的完整可运行参考八个干预点全部绑定策略pre_tool_call对 10000 以上电汇返回escalatepost_model_call拦截bypass approval提示output用正则把CHK-[0-9]账号脱敏为ACCOUNT-REDACTED。另有 policy-engine/integrations/openai/、policy-engine/integrations/mcp/、policy-engine/integrations/rig/ 下的 Rust 集成 crate 示例展示在真实框架的工具调用点挂上守卫的写法。Step 8. 添加注释器与脱敏有两类常见需求不需要在 Host 侧编写超出内置默认的 dispatcher 代码。注释器annotators把派生的信号如分类器评分挂到策略输入的annotations.name下供策略读取。在 manifest 的annotators块中声明它们并用annotations映射让某个干预点选入。注意内置的classifier、llm、endpoint注释器会发起网络调用因此零配置使用注释器需要一个可达的端点以及所需的凭证。参考 dispatcher 示例位于仓库 policy-engine/integrations/annotators/Rust 侧实现对应core/src/dispatchers/classifier.rs、core/src/dispatchers/llm.rs、core/src/dispatchers/endpoint.rs运行时把每个点特定的from路径对初步策略输入解析后调用 dispatcher且只在annotations.name下写入返回值。README 中的 LLM 注释器供应商指南 提供了可插拔供应商预设。脱敏redaction不需要自定义 dispatcher。返回transform判定、让transform.value携带脱敏后的策略目标然后按 Step 6 读取已转换策略目标即可。仓库示例 policy-engine/examples/support_agent/ 正是以这种方式脱敏 PII。Step 9. 验证集成制品冒烟测试与跨 SDK 一致性先确认 SDK 在你的环境中能正确对接原生核心。在制品包场景下把包安装进一个临时 Host 项目用你计划发布的 manifest 跑一个 allow 和一个 deny 冒烟测试在源码检出场景下使用项目构建说明描述的各语言测试套件。SDK制品冒烟测试Rust构建一个依赖本地.crate制品的临时 crate求值一个 manifest。Python把artifacts/中的 wheel 安装进临时虚拟环境调用NativeRuntimeClient.from_path。Node把artifacts/中的.tgz包安装进临时项目调用AgentControl.fromPath。.NET从artifacts/的本地 nupkg 源还原调用AgentControl.FromPath。在本地验证 CI 对齐时设置AGENT_CONTROL_REQUIRE_OPA1让依赖 OPA 的测试在缺失 OPA 时响亮失败而不是被跳过。仓库 policy-engine/tests/ 下的跨 SDK 一致性 fixtures 断言四个 SDK 对同一批快照给出相同判定。对于仅制品的包请从临时 Host 项目验证已安装包而不是运行仓库检出的测试套件SDK仅制品冒烟检查命令Rustmkdir crates for c in agent_control_specification_core agent_control_specification agent_control_specification_openai agent_control_specification_mcp agent_control_specification_rig; do tar -xzf $ACS_KIT/artifacts/$c-0.3.1-beta.0.crate -C crates 2/dev/null || true; done然后在cargo check之前把[patch.crates-io]指向解压出的crates/name-0.3.1-beta.0目录Pythonpython -m venv .venv .venv/bin/python -m pip install $ACS_KIT/artifacts/agent_control_specification-0.3.1b1-*.whl .venv/bin/python -c import agent_control_specification as acs; print(acs.AgentControl)Nodenpm init -y npm install $ACS_KIT/artifacts/agent-control-specification-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-linux-x64-gnu-0.3.1-beta.0.tgz $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz node -e const acsrequire(agent-control-specification); console.log(typeof acs.AgentControl).NETdotnet new console -n AcsSmoke cd AcsSmoke dotnet add package AgentControlSpecification --version 0.3.1-beta.0 --source $ACS_KIT/artifacts dotnet build制品校验所有 SDK 共享同一个原生实现除冒烟测试外Rust 核心还暴露validate_acs_artifacts每个语言 SDK 都委托给该实现四个 SDK 返回的结果结构完全一致——valid加上针对 manifest 模式、类型化 ACS 语义、OPA Rego 解析的结构化诊断use agent_control_specification::validate_acs_artifacts; let result validate_acs_artifacts(manifest_yaml, rego_modules, None);策略绑定通过policy.id选择一条策略Rego 策略要求在策略定义或绑定上给出query。规范 JSON Schema 位于 policy-engine/core/schema/含manifest.schema.json与approval.schema.json规范的权威契约见 policy-engine/spec/SPECIFICATION.md。用生成器初始化acs-generate init当第一套 ACS 制品应当构造即正确valid by construction而不是手工拼装时使用生成器。引导式初始化流程会询问你要中介的干预点、工具目录条目、要拦截的关键词、审批门与输出脱敏模式然后写出 manifest、Rego 策略、报告与可选的示例快照acs-generate init --non-interactive --name Demo Agent --points input,pre_tool_call,output --tool send_email:internal --deny-keyword secret --escalate-tool send_email --sample-snapshot --out build/demo-acs输出目录必须为空除非提供--force。当本地 OPA 校验必须与 CI 一致时加上--strict。安装生成器包后同一命令也可以写为acs init。生成器会写manifest.yaml、policy/slug.rego、report.md以及可选的snapshots/intervention_point.json与test_policy.py冒烟测试。生成器 READMEpolicy-engine/generator/README.md还补充了两点生产实践可重复运行--answers-file支持 CI 与重复本地运行接受与 CLI 标志一致的字段name、points、tools、deny_keywords、escalate_tools、redact_output_patterns不支持的关键字会快速失败避免 CI 静默忽略预期设置--answers-file -支持从 stdin 读取 JSON/YAML。严格模式下的 OPA仅制品包内置本地 Node 可选 OPA 包安装后把其bin目录前置到PATH再运行--strictnpm install $ACS_KIT/artifacts/agent-control-specification-opa-linux-x64-0.3.1-beta.0.tgz PATH$PWD/node_modules/agent-control-specification-opa-linux-x64/bin:$PATH \ acs-generate init --strict --non-interactive --name Payments Agent --out build/acs-payments生成后的叠加extends子 manifest生成之后要做增量改动时使用带extends的子 manifest。子 manifest 可以添加 metadata 键、策略、注释器、工具或新的干预点但不能用不同的值替换已有干预点的策略、目标或tool_name_from——冲突的重复项在 manifest 加载时会失败即关闭。基于文件的extends限定在顶层 manifest 根目录内把父 manifest 放在子根目录之下例如base/manifest.yaml或者当 SDK 提供 manifest-chain 构造器时用它加载并列的兄弟 manifest。这一父策略不可被替换、只能叠加的合并语义也体现在 AGT 的 ADRdocs/adr/0014-parent-deny-rules-immutable-in-merge.md中属于本项目对上游 ACS 的既定分歧之一。更进一步从 Quickstart 到生产落地阅读权威契约policy-engine/spec/SPECIFICATION.md了解 Host 义务与安全边界policy-engine/docs/security-model.md以及无状态运行时契约 policy-engine/docs/stateless-runtime.md挑选合适的 SDK 面policy-engine/docs/sdk-surfaces.md包装真实 Agent 框架参考 policy-engine/docs/adapter-matrix.md 与 README 的 Framework adapters 一节研究可运行 Host 示例仓库 policy-engine/examples/ 下按场景组织包括bank_agent全生命周期点、转换与脱敏、lifecycle_rego零配置 Rego 全流程、custom_dispatchers离线分类器/端点/LLM 注释器与自定义策略 dispatcher、manifest_extends文件式 manifest 组合、conformance_snapshotsfixture 驱动的策略评审、coding_agentRust Host 应用、ifc_agent无状态信息流控制标签流转遥测Rust 核心通过TelemetrySink输出结构化、默认脱敏的事件decision、policy_evaluation、intervention_point.transformed等四个 SDK 都内置可插拔 sink 与 OpenTelemetry 指标契约acs_intervention_{allow,deny,warn,escalate,transform}_total计数器与acs_intervention_duration_ms直方图meter 名为agent_control_specification见 policy-engine/docs/observability.md至此你已拥有一套从空 manifest 到全循环中介的完整集成路径声明策略、绑定干预点、零配置构造运行时、按五种判定执行、用编排 helper 覆盖整个 Agent 生命周期并通过制品校验、冒烟测试与生成器保证制品质量。ACS 的定义一次处处执行Define once. Enforce everywhere.理念最终落地为 Host 与策略层之间清晰、可审计、失败即关闭的决策契约。赞分享人工智能AI AgentAI 安全治理策略引擎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 原生策略运行时迁移指南从 v4 策略引擎到 ACSAgent Control Specification1.0Agent Governance Toolkit 原生策略运行时迁移指南从 v4 策略引擎到 ACSAgent Control Specification人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Agent Control Specification Python SDK将 ACS 策略判定运行时接入 Python Agent 宿主的完整指南Agent Control Specification Python SDK将 ACS 策略判定运行时接入 Python Agent 宿主的完整指南 本文基于人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Agent Control Specification .NET SDK 实战用 Rust 内核为 .NET Agent 加装策略治理Agent Control Specification .NET SDK 实战用 Rust 内核为 .NET Agent 加装策略治理 Agent Contr人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考