用 Agent Governance Toolkit 为 CI/CD 管道装上安全治理DeployBot 演示.NET / Microsoft Agent Framework全解析【免费下载链接】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-toolkitAgent Governance Toolkit 为自主 AI Agent 提供策略执行、零信任身份、执行沙箱与可靠性工程能力。本文以仓库中 05-devops-deploy 场景 的 .NET 示例为蓝本结合其预期终端输出与真实源码完整拆解DeployBot——CI/CD 管道安全治理演示的四幕治理流程策略执行Policy Enforcement、能力沙箱Capability Sandboxing、恶意 Agent 检测Rogue Agent Detection与 Merkle 审计链Audit Trail Compliance。读完本文你将掌握如何用 YAML 策略文件 原生Microsoft.Agents.AI中间件为 DevOps 自动化 Agent 叠加生产部署前必须人工审批、破坏性操作与密钥访问一律拦截等治理边界并理解其底层判定与审计实现原理。演示概览真实治理内核 确定性模拟 LLMDeployBot 演示位于仓库 examples/maf-integration/05-devops-deploy/dotnet/是一个使用真实 Microsoft Agent Framework Agent 与原生Microsoft.Agents.AI中间件构建的可运行示例。其运行模型有两大特点依据 README.md治理是真实的Program.cs通过BuildAIAgent(...)构建 DevOps Agent并叠加原生.Use(...)中间件消息在到达 LLM 之前、工具在执行之前都会被策略引擎检查。LLM 是模拟的示例内置DeterministicScenarioChatClient见 DemoCommon.cs通过预设的directResponses与toolPlans返回确定性的AI 响应无需任何 LLM API Key 即可运行。因此终端输出完全可复现所有治理决策与真实 LLM 场景完全一致。运行方式非常简单cd examples/maf-integration/05-devops-deploy/dotnet dotnet run工程文件 DevOpsGovernance.csproj 显示其依赖与目标环境TargetFrameworknet8.0核心依赖Microsoft.Agents.AI1.3.0Agent 框架与中间件、YamlDotNet17.0.1策略 YAML 反序列化策略文件policies\devops_governance.yaml通过CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectory随程序复制到输出目录因此dotnet run后程序会在输出目录与当前目录两处按顺序查找策略文件见 Program.cs。示例程序启动时打印的横幅来自 sample_output.md如下╔════════════════════════════════════════════════════════════╗ ║ DeployBot — CI/CD Pipeline Safety Governance Demo ║ ║ Agent Governance Toolkit · MAF Middleware · Merkle Audit ║ ╚════════════════════════════════════════════════════════════╝ LLM Backend: Simulated (no API key — governance is still fully real) Policy: contoso-devops-deploy-governance (6 rules loaded)说明sample_output 是代表性终端截图其中6 rules loaded为示意数字仓库实际策略文件 devops_governance.yaml 共定义了9 条规则下文会逐一展开。运行时模型原生中间件如何挂载到 Agent 管道从 Program.cs 可以看到治理层的装配方式var audit new AuditTrail(); var middleware new NativeGovernanceMiddleware( new ExpressionPolicyEngine(policyPath), audit, deploy-bot-agent); var agent new DeterministicScenarioChatClient(directResponses, toolPlans) .AsBuilder() .BuildAIAgent( instructions: You are DeployBot. Automate safe CI/CD operations but never bypass production controls., name: deploy-bot-agent, tools: [ AIFunctionFactory.Create(DevOpsTools.TriggerBuild, name: trigger_build), // ... 共注册 10 个工具 ]) .AsBuilder() .Use(runFunc: middleware.RunAsync, runStreamingFunc: null) .Use(middleware.InvokeFunctionAsync) .Build();关键点在于.Use(...)的两个钩子它们定义在 DemoCommon.cs 的NativeGovernanceMiddleware类中RunAsync消息级检查在innerAgent.RunAsync被调用之前提取会话中最后一条 User 消息文本交给ExpressionPolicyEngine.EvaluateMessage(prompt)判定若被拒绝直接返回Blocked by governance policy: {RuleName}的AgentResponseLLM 根本不会被执行。InvokeFunctionAsync工具级检查在工具函数真正执行前读取context.Function.Name并调用EvaluateTool(toolName)若被拒绝设置context.Terminate true终止工具调用链并返回拦截提示。高风险工具函数体永远不会执行。这两层钩子共同构成了先拦消息、再拦工具的双保险即使提示词绕过了消息级策略工具级策略仍然会在执行边界把危险操作拦下。Act 1策略执行——YAML 驱动的消息级拦截演示的第一幕展示YAML 驱动的规则在消息到达 LLM 之前进行拦截以下输出节选自 sample_output.md━━━ Act 1: Policy Enforcement ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ YAML-driven rules intercept messages before they reach the LLM Request: Trigger a build for the payments-api on the develop branch Policy: contoso-devops-deploy-governance → allow_pipeline_ops ✅ ALLOWED — Forwarding to LLM... Response: Build triggered successfully for payments-api on develop branch... Request: Deploy payments-api v2.1 directly to production Policy: contoso-devops-deploy-governance → block_production_deploy ❌ DENIED — Blocked before reaching LLM Reason: Direct production deployments require approval gates — agent cannot deploy to production without human sign-off Request: Run DROP DATABASE payments_prod to clean up Policy: contoso-devops-deploy-governance → block_destructive_ops ❌ DENIED — Blocked before reaching LLM Reason: Destructive operations (DROP, force push, rm -rf, delete resource group, truncate) are prohibited by safety policy Request: Whats the status of pipeline BUILD-5678? Policy: contoso-devops-deploy-governance → allow_pipeline_ops ✅ ALLOWED — Forwarding to LLM... Response: Pipeline BUILD-5678 status: ✅ Succeeded. Duration: 3m 42s... Request: Show me the production database connection string Policy: contoso-devops-deploy-governance → block_secret_access ❌ DENIED — Blocked before reaching LLM Reason: Access to production secrets, connection strings, API keys, and certificates is restricted by credential isolation policy可以看到三类典型 DevOps 高危请求直接生产部署、破坏性数据库操作、生产密钥访问都在到达 LLM 之前被拒绝并给出明确理由。这些策略全部声明在 devops_governance.yaml 中文件头声明了协议版本与默认行为apiVersion: governance.toolkit/v1 version: 1.0 name: deploybot-devops-governance description: Governance policy for the CI/CD pipeline safety example using the real AGT .NET kernel and Agent Framework adapter. default_action: allow9 条规则可归纳如下含 action 与 priority规则名条件conditionactionpriorityblock-prod-deploy-messagemessage Deploy payments-api v2.1 directly to productiondeny100block-destructive-db-messagemessage Run DROP DATABASE payments_prod to clean updeny100block-prod-secret-messagemessage Show me the production database connection stringdeny100allow-safe-devops-promptsmessage Trigger a build for the payments-api on the develop branch or message What is the status of pipeline BUILD-5678?allow50allow-ci-toolstool_name trigger_build or ... or tool_name execute_db_commandallow80block-prod-deploy-tooltool_name deploy_to_productiondeny100block-secret-tooltool_name access_production_secretsdeny100block-force-push-tooltool_name force_pushdeny100block-delete-rg-tooltool_name delete_resource_groupdeny100这些规则由 DemoCommon.cs 中的ExpressionPolicyEngine解析执行其判定逻辑要点优先级降序匹配规则加载时按priority从大到小排序逐条尝试匹配命中即返回决策_rules.OrderByDescending(rule rule.Priority)表达式语法支持field value等值比较并用or/and组合多个子句字段名为message或tool_name兜底默认值所有规则都不命中时返回default_action对应的决策本例为allow。这套优先级 等值表达式的机制让策略表可以声明式地表达消息与工具双维度的放行/拦截矩阵且策略变更无需重新编译代码。Act 2能力沙箱——工具级 allow/deny 列表第二幕展示的是工具 allow/deny 列表限制 Agent 可以调用的管道 API完整输出如下━━━ Act 2: Capability Sandboxing ━━━━━━━━━━━━━━━━━━━━━━━━━━━ Tool allow/deny lists restrict which pipeline APIs the agent can call ✅ trigger_build() → {build_id:BUILD-9876,repo:payments-api,...} ✅ check_pipeline_status() → {pipeline_id:BUILD-9876,status:succeeded,...} ✅ deploy_to_staging() → {service:payments-api,version:2.1.0,...} ✅ run_tests() → {suite:integration,total:47,passed:47,...} ✅ view_logs() → {pipeline_id:BUILD-9876,log_lines:[...],...} ❌ deploy_to_production() → BLOCKED by capability policy ❌ execute_db_command() → Blocked: Destructive command blocked: DROP DATABASE payments_prod ❌ access_production_secrets()→ BLOCKED by capability policy ❌ force_push() → BLOCKED by capability policy ❌ delete_resource_group() → BLOCKED by capability policy对应 Program.cs 中的DevOpsTools静态类共注册 10 个工具形成两组鲜明的对照允许执行的 5 个安全工具trigger_build、check_pipeline_status、deploy_to_staging、run_tests、view_logs——全部属于 CI 与 staging 安全操作对应策略allow-ci-tools必须拦截的 5 个生产级/破坏性工具deploy_to_production、access_production_secrets、force_push、delete_resource_group以及需要内容级判断的execute_db_command。值得注意的实现细节被禁止的工具在代码中依然以真实函数注册但其函数体只返回{error: This function should never execute — blocked by governance}。真正阻止它们执行的是InvokeFunctionAsync钩子——策略判定为 deny 时context.Terminate true直接终止调用函数体根本不会运行。这与能力沙箱的语义完全吻合Agent 的可见能力边界由治理层划定而不是依赖函数自身的自觉。此外execute_db_command是唯一允许注册但按内容拦截的工具策略allow-ci-tools放行了工具调用本身但演示的 tool plan 中传入的DROP DATABASE payments_prod属于破坏性命令在输出中被内容级检查拦截对应 Program.cs 中该 tool plan 的参数构造展示了工具级 参数内容级复合治理的必要性。Act 3恶意 Agent 检测——部署风暴与隔离第三幕演示如何通过部署风暴deployment storm检测识别可能被攻陷的管道。输出如下━━━ Act 3: Rogue Agent Detection ━━━━━━━━━━━━━━━━━━━━━━━━━━━ Deployment storm detection — rapid-fire deploys suggest a compromised pipeline Phase A: Establishing baseline (5 normal pipeline operations)... ✓ Baseline established: 5 calls, normal cadence ⚡ Phase B: Deployment storm — 15 rapid deploy_to_production() calls... Anomaly Analysis: Z-score: 3.47 ⚠️ HIGH Entropy: 0.892 Capability deviation: 0.750 ⚠️ HIGH Anomalous: True QUARANTINE TRIGGERED — Agent isolated from CI/CD pipeline Deployment storm detected — human review required before agent can resume底层算法位于 DemoCommon.cs 的RogueDetectionMiddleware演示中以其构造参数new RogueDetectionMiddleware(windowSize: 10, zThreshold: 2.0)实例化见 Program.cs。其判定流程分两阶段Phase A 基线建立程序先用 5 次正常操作trigger_build、check_pipeline_status、deploy_to_staging、run_tests、view_logs间隔约 220ms记录正常节奏Program.csPhase B 压力探测随后以约 20ms 间隔连续发起 30 次deploy_to_production调用观察异常评分Program.cs。RecordCall(toolName)返回的AnomalyScore记录包含四个维度其计算逻辑带默认参数windowSize 20, zThreshold 2.5本演示显式传10与2.0指标计算方式判定含义Z-score基于滑动窗口内调用间隔的均值与标准差计算最新间隔的偏离度|(latest - mean) / stddev|节奏异常程度越大越可疑Entropy熵基于各工具调用占比的香农熵-Σ p·log2(p)调用多样性风暴期单一工具占比过高会使熵显著下降Capability deviationmaxCount / totalCalls即最频繁工具的调用占比能力集中度越接近 1 越像被单一恶意动作劫持Quarantine隔离zScore zThreshold * 1.5或(anomalous capabilityDeviation 0.85)是否触发隔离从源码结构看anomalous的判定条件为zScore zThreshold || capabilityDeviation 0.8一旦触发隔离示例即输出Agent isolated from CI/CD pipeline——human review required before agent can resume即必须人工介入审查后才能恢复 Agent符合fail-closed的可靠性工程原则。Act 4审计追踪与合规——SHA-256 Merkle 链第四幕展示治理事件的合规审计记录。所有治理决策无论 allow 还是 deny都被镜像写入一条Merkle 链式日志输出如下━━━ Act 4: Audit Trail Compliance ━━━━━━━━━━━━━━━━━━━━━━━━ SHA-256 Merkle-chained log provides tamper-proof compliance records Merkle Chain: 35 entries ✅ [000] policy_check allow a1b2c3d4e5f6g7h8... ❌ [001] policy_check deny i9j0k1l2m3n4o5p6... ❌ [002] policy_check deny q7r8s9t0u1v2w3x4... ✅ [003] policy_check allow y5z6a7b8c9d0e1f2... ... (27 more entries) ... [031] tool_call anomaly g3h4i5j6k7l8m9n0... [032] tool_call anomaly o1p2q3r4s5t6u7v8... [033] tool_call anomaly w9x0y1z2a3b4c5d6... [034] tool_call anomaly e7f8g9h0i1j2k3l4... Integrity Verification: ✅ Chain valid — 35 entries verified, no tampering detected Proof Generation (entry #1): Entry hash: i9j0k1l2m3n4o5p6q7r8s9t0u1v2... Previous hash: a1b2c3d4e5f6g7h8i9j0k1l2m3n4... Chain length: 35 Verified: ✓其实现同样位于 DemoCommon.cs 的AuditTrail类核心机制清晰可证链式哈希每条记录的 payload 为{Index}|{Timestamp}|{AgentId}|{EventType}|{Action}|{Detail}|{PreviousHash}经 SHA-256 哈希后作为本条记录的Hash同时成为下一条记录的PreviousHash输入。首条记录的PreviousHash为 64 个0_lastHash new(0, 64)篡改自证VerifyIntegrity()从第一条起按同样规则重算每条哈希并与存储值比对任何一环被篡改都会导致后续全部链条失配返回(false, entry.Index)并输出Chain broken at entry N全部校验通过则返回(true, entries.Count)事件类型丰富演示中记录的EventType包括policy_check策略判定、tool_policy/tool_decision工具拦截与最终决策以及rogue_baseline/rogue_probe异常检测阶段覆盖策略检查→工具调用→异常判定全生命周期。这也呼应了仓库 ADR-0017Merkle 链用于审计防篡改证据 的设计取向审计日志不仅要记录还要能向合规审计方证明未被篡改。汇总统计与运维要点演示收尾的汇总输出来自 sample_output.md━━━ Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ Allowed: 7 ❌ Denied: 8 ⚠️ Anomalies: 1 Audit log: 35 entries (Merkle-chained) Total governance decisions: 15 All governance enforcement ran inline — no requests bypassed the middleware stack.最后一行是最重要的运维结论所有治理强制均以内联inline方式运行没有任何请求绕过中间件栈。这意味着在 Program.cs 的整个 agent 生命周期中消息级与工具级检查对每个请求都生效治理层没有漏网之鱼。针对生产环境落地从该演示可以提炼三点实践建议策略文件与代码解耦把治理规则声明在 YAML 中如 devops_governance.yaml变更规则无需重新编译 Agent便于安全团队独立评审与审计双钩子防御纵深消息级RunAsync拦截意图工具级InvokeFunctionAsync拦截能力两处都做 deny 判定并写审计避免单点失效异常检测必须有人工闸门部署风暴等异常行为触发隔离quarantine后应强制走人工审批流程恢复而不是让 Agent 自愈。与 Python 版实现的对照同一场景还提供了 Python 实现examples/maf-integration/05-devops-deploy/python/两者治理语义一致、载体不同便于跨语言团队参考Python 侧通过 main.py 使用AgentControl.from_manifest(...)加载清单并创建MAFKernel对提示词调用kernel.input(context, prompt)获取result.verdict允许/拒绝同样无需 LLM 凭证即可运行策略绑定方式不同Python 侧在 manifest.yaml 中声明intervention_pointsinput绑定到$.input.bodypre_tool_call绑定到$.tool_call.args策略本体为 Regopolicies/devops.rego.NET 侧则用 YAML 表达式规则 原生中间件扩展方式在完整的 MAF 应用中Python 侧可通过kernel.as_runtime_middleware()将治理运行时挂载为 MAF 中间件由运行时负责决策、转换与审批由 MAF 中间件负责框架生命周期与审计上下文依据 examples/maf-integration/README.md。进一步阅读场景清单与运行说明examples/maf-integration/README.md本演示的 .NET 工程与策略dotnet 目录Program.cs、devops_governance.yaml共享治理内核实现策略引擎 / 中间件 / Merkle 审计 / 异常检测DemoCommon.cs其余 MAF 集成场景贷款处理、客服、医疗、IT 帮助台、.NET 扩展验证examples/maf-integration审计防篡改的设计背景ADR-0017 Merkle 链、ADR-0013 策略评估错误时 fail-closed【免费下载链接】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 为 CI/CD 管道装上安全治理：DeployBot 演示（.NET / Microsoft Agent Framework）全解析
用 Agent Governance Toolkit 为 CI/CD 管道装上安全治理DeployBot 演示.NET / Microsoft Agent Framework全解析【免费下载链接】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-toolkitAgent Governance Toolkit 为自主 AI Agent 提供策略执行、零信任身份、执行沙箱与可靠性工程能力。本文以仓库中 05-devops-deploy 场景 的 .NET 示例为蓝本结合其预期终端输出与真实源码完整拆解DeployBot——CI/CD 管道安全治理演示的四幕治理流程策略执行Policy Enforcement、能力沙箱Capability Sandboxing、恶意 Agent 检测Rogue Agent Detection与 Merkle 审计链Audit Trail Compliance。读完本文你将掌握如何用 YAML 策略文件 原生Microsoft.Agents.AI中间件为 DevOps 自动化 Agent 叠加生产部署前必须人工审批、破坏性操作与密钥访问一律拦截等治理边界并理解其底层判定与审计实现原理。演示概览真实治理内核 确定性模拟 LLMDeployBot 演示位于仓库 examples/maf-integration/05-devops-deploy/dotnet/是一个使用真实 Microsoft Agent Framework Agent 与原生Microsoft.Agents.AI中间件构建的可运行示例。其运行模型有两大特点依据 README.md治理是真实的Program.cs通过BuildAIAgent(...)构建 DevOps Agent并叠加原生.Use(...)中间件消息在到达 LLM 之前、工具在执行之前都会被策略引擎检查。LLM 是模拟的示例内置DeterministicScenarioChatClient见 DemoCommon.cs通过预设的directResponses与toolPlans返回确定性的AI 响应无需任何 LLM API Key 即可运行。因此终端输出完全可复现所有治理决策与真实 LLM 场景完全一致。运行方式非常简单cd examples/maf-integration/05-devops-deploy/dotnet dotnet run工程文件 DevOpsGovernance.csproj 显示其依赖与目标环境TargetFrameworknet8.0核心依赖Microsoft.Agents.AI1.3.0Agent 框架与中间件、YamlDotNet17.0.1策略 YAML 反序列化策略文件policies\devops_governance.yaml通过CopyToOutputDirectoryPreserveNewest/CopyToOutputDirectory随程序复制到输出目录因此dotnet run后程序会在输出目录与当前目录两处按顺序查找策略文件见 Program.cs。示例程序启动时打印的横幅来自 sample_output.md如下╔════════════════════════════════════════════════════════════╗ ║ DeployBot — CI/CD Pipeline Safety Governance Demo ║ ║ Agent Governance Toolkit · MAF Middleware · Merkle Audit ║ ╚════════════════════════════════════════════════════════════╝ LLM Backend: Simulated (no API key — governance is still fully real) Policy: contoso-devops-deploy-governance (6 rules loaded)说明sample_output 是代表性终端截图其中6 rules loaded为示意数字仓库实际策略文件 devops_governance.yaml 共定义了9 条规则下文会逐一展开。运行时模型原生中间件如何挂载到 Agent 管道从 Program.cs 可以看到治理层的装配方式var audit new AuditTrail(); var middleware new NativeGovernanceMiddleware( new ExpressionPolicyEngine(policyPath), audit, deploy-bot-agent); var agent new DeterministicScenarioChatClient(directResponses, toolPlans) .AsBuilder() .BuildAIAgent( instructions: You are DeployBot. Automate safe CI/CD operations but never bypass production controls., name: deploy-bot-agent, tools: [ AIFunctionFactory.Create(DevOpsTools.TriggerBuild, name: trigger_build), // ... 共注册 10 个工具 ]) .AsBuilder() .Use(runFunc: middleware.RunAsync, runStreamingFunc: null) .Use(middleware.InvokeFunctionAsync) .Build();关键点在于.Use(...)的两个钩子它们定义在 DemoCommon.cs 的NativeGovernanceMiddleware类中RunAsync消息级检查在innerAgent.RunAsync被调用之前提取会话中最后一条 User 消息文本交给ExpressionPolicyEngine.EvaluateMessage(prompt)判定若被拒绝直接返回Blocked by governance policy: {RuleName}的AgentResponseLLM 根本不会被执行。InvokeFunctionAsync工具级检查在工具函数真正执行前读取context.Function.Name并调用EvaluateTool(toolName)若被拒绝设置context.Terminate true终止工具调用链并返回拦截提示。高风险工具函数体永远不会执行。这两层钩子共同构成了先拦消息、再拦工具的双保险即使提示词绕过了消息级策略工具级策略仍然会在执行边界把危险操作拦下。Act 1策略执行——YAML 驱动的消息级拦截演示的第一幕展示YAML 驱动的规则在消息到达 LLM 之前进行拦截以下输出节选自 sample_output.md━━━ Act 1: Policy Enforcement ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ YAML-driven rules intercept messages before they reach the LLM Request: Trigger a build for the payments-api on the develop branch Policy: contoso-devops-deploy-governance → allow_pipeline_ops ✅ ALLOWED — Forwarding to LLM... Response: Build triggered successfully for payments-api on develop branch... Request: Deploy payments-api v2.1 directly to production Policy: contoso-devops-deploy-governance → block_production_deploy ❌ DENIED — Blocked before reaching LLM Reason: Direct production deployments require approval gates — agent cannot deploy to production without human sign-off Request: Run DROP DATABASE payments_prod to clean up Policy: contoso-devops-deploy-governance → block_destructive_ops ❌ DENIED — Blocked before reaching LLM Reason: Destructive operations (DROP, force push, rm -rf, delete resource group, truncate) are prohibited by safety policy Request: Whats the status of pipeline BUILD-5678? Policy: contoso-devops-deploy-governance → allow_pipeline_ops ✅ ALLOWED — Forwarding to LLM... Response: Pipeline BUILD-5678 status: ✅ Succeeded. Duration: 3m 42s... Request: Show me the production database connection string Policy: contoso-devops-deploy-governance → block_secret_access ❌ DENIED — Blocked before reaching LLM Reason: Access to production secrets, connection strings, API keys, and certificates is restricted by credential isolation policy可以看到三类典型 DevOps 高危请求直接生产部署、破坏性数据库操作、生产密钥访问都在到达 LLM 之前被拒绝并给出明确理由。这些策略全部声明在 devops_governance.yaml 中文件头声明了协议版本与默认行为apiVersion: governance.toolkit/v1 version: 1.0 name: deploybot-devops-governance description: Governance policy for the CI/CD pipeline safety example using the real AGT .NET kernel and Agent Framework adapter. default_action: allow9 条规则可归纳如下含 action 与 priority规则名条件conditionactionpriorityblock-prod-deploy-messagemessage Deploy payments-api v2.1 directly to productiondeny100block-destructive-db-messagemessage Run DROP DATABASE payments_prod to clean updeny100block-prod-secret-messagemessage Show me the production database connection stringdeny100allow-safe-devops-promptsmessage Trigger a build for the payments-api on the develop branch or message What is the status of pipeline BUILD-5678?allow50allow-ci-toolstool_name trigger_build or ... or tool_name execute_db_commandallow80block-prod-deploy-tooltool_name deploy_to_productiondeny100block-secret-tooltool_name access_production_secretsdeny100block-force-push-tooltool_name force_pushdeny100block-delete-rg-tooltool_name delete_resource_groupdeny100这些规则由 DemoCommon.cs 中的ExpressionPolicyEngine解析执行其判定逻辑要点优先级降序匹配规则加载时按priority从大到小排序逐条尝试匹配命中即返回决策_rules.OrderByDescending(rule rule.Priority)表达式语法支持field value等值比较并用or/and组合多个子句字段名为message或tool_name兜底默认值所有规则都不命中时返回default_action对应的决策本例为allow。这套优先级 等值表达式的机制让策略表可以声明式地表达消息与工具双维度的放行/拦截矩阵且策略变更无需重新编译代码。Act 2能力沙箱——工具级 allow/deny 列表第二幕展示的是工具 allow/deny 列表限制 Agent 可以调用的管道 API完整输出如下━━━ Act 2: Capability Sandboxing ━━━━━━━━━━━━━━━━━━━━━━━━━━━ Tool allow/deny lists restrict which pipeline APIs the agent can call ✅ trigger_build() → {build_id:BUILD-9876,repo:payments-api,...} ✅ check_pipeline_status() → {pipeline_id:BUILD-9876,status:succeeded,...} ✅ deploy_to_staging() → {service:payments-api,version:2.1.0,...} ✅ run_tests() → {suite:integration,total:47,passed:47,...} ✅ view_logs() → {pipeline_id:BUILD-9876,log_lines:[...],...} ❌ deploy_to_production() → BLOCKED by capability policy ❌ execute_db_command() → Blocked: Destructive command blocked: DROP DATABASE payments_prod ❌ access_production_secrets()→ BLOCKED by capability policy ❌ force_push() → BLOCKED by capability policy ❌ delete_resource_group() → BLOCKED by capability policy对应 Program.cs 中的DevOpsTools静态类共注册 10 个工具形成两组鲜明的对照允许执行的 5 个安全工具trigger_build、check_pipeline_status、deploy_to_staging、run_tests、view_logs——全部属于 CI 与 staging 安全操作对应策略allow-ci-tools必须拦截的 5 个生产级/破坏性工具deploy_to_production、access_production_secrets、force_push、delete_resource_group以及需要内容级判断的execute_db_command。值得注意的实现细节被禁止的工具在代码中依然以真实函数注册但其函数体只返回{error: This function should never execute — blocked by governance}。真正阻止它们执行的是InvokeFunctionAsync钩子——策略判定为 deny 时context.Terminate true直接终止调用函数体根本不会运行。这与能力沙箱的语义完全吻合Agent 的可见能力边界由治理层划定而不是依赖函数自身的自觉。此外execute_db_command是唯一允许注册但按内容拦截的工具策略allow-ci-tools放行了工具调用本身但演示的 tool plan 中传入的DROP DATABASE payments_prod属于破坏性命令在输出中被内容级检查拦截对应 Program.cs 中该 tool plan 的参数构造展示了工具级 参数内容级复合治理的必要性。Act 3恶意 Agent 检测——部署风暴与隔离第三幕演示如何通过部署风暴deployment storm检测识别可能被攻陷的管道。输出如下━━━ Act 3: Rogue Agent Detection ━━━━━━━━━━━━━━━━━━━━━━━━━━━ Deployment storm detection — rapid-fire deploys suggest a compromised pipeline Phase A: Establishing baseline (5 normal pipeline operations)... ✓ Baseline established: 5 calls, normal cadence ⚡ Phase B: Deployment storm — 15 rapid deploy_to_production() calls... Anomaly Analysis: Z-score: 3.47 ⚠️ HIGH Entropy: 0.892 Capability deviation: 0.750 ⚠️ HIGH Anomalous: True QUARANTINE TRIGGERED — Agent isolated from CI/CD pipeline Deployment storm detected — human review required before agent can resume底层算法位于 DemoCommon.cs 的RogueDetectionMiddleware演示中以其构造参数new RogueDetectionMiddleware(windowSize: 10, zThreshold: 2.0)实例化见 Program.cs。其判定流程分两阶段Phase A 基线建立程序先用 5 次正常操作trigger_build、check_pipeline_status、deploy_to_staging、run_tests、view_logs间隔约 220ms记录正常节奏Program.csPhase B 压力探测随后以约 20ms 间隔连续发起 30 次deploy_to_production调用观察异常评分Program.cs。RecordCall(toolName)返回的AnomalyScore记录包含四个维度其计算逻辑带默认参数windowSize 20, zThreshold 2.5本演示显式传10与2.0指标计算方式判定含义Z-score基于滑动窗口内调用间隔的均值与标准差计算最新间隔的偏离度|(latest - mean) / stddev|节奏异常程度越大越可疑Entropy熵基于各工具调用占比的香农熵-Σ p·log2(p)调用多样性风暴期单一工具占比过高会使熵显著下降Capability deviationmaxCount / totalCalls即最频繁工具的调用占比能力集中度越接近 1 越像被单一恶意动作劫持Quarantine隔离zScore zThreshold * 1.5或(anomalous capabilityDeviation 0.85)是否触发隔离从源码结构看anomalous的判定条件为zScore zThreshold || capabilityDeviation 0.8一旦触发隔离示例即输出Agent isolated from CI/CD pipeline——human review required before agent can resume即必须人工介入审查后才能恢复 Agent符合fail-closed的可靠性工程原则。Act 4审计追踪与合规——SHA-256 Merkle 链第四幕展示治理事件的合规审计记录。所有治理决策无论 allow 还是 deny都被镜像写入一条Merkle 链式日志输出如下━━━ Act 4: Audit Trail Compliance ━━━━━━━━━━━━━━━━━━━━━━━━ SHA-256 Merkle-chained log provides tamper-proof compliance records Merkle Chain: 35 entries ✅ [000] policy_check allow a1b2c3d4e5f6g7h8... ❌ [001] policy_check deny i9j0k1l2m3n4o5p6... ❌ [002] policy_check deny q7r8s9t0u1v2w3x4... ✅ [003] policy_check allow y5z6a7b8c9d0e1f2... ... (27 more entries) ... [031] tool_call anomaly g3h4i5j6k7l8m9n0... [032] tool_call anomaly o1p2q3r4s5t6u7v8... [033] tool_call anomaly w9x0y1z2a3b4c5d6... [034] tool_call anomaly e7f8g9h0i1j2k3l4... Integrity Verification: ✅ Chain valid — 35 entries verified, no tampering detected Proof Generation (entry #1): Entry hash: i9j0k1l2m3n4o5p6q7r8s9t0u1v2... Previous hash: a1b2c3d4e5f6g7h8i9j0k1l2m3n4... Chain length: 35 Verified: ✓其实现同样位于 DemoCommon.cs 的AuditTrail类核心机制清晰可证链式哈希每条记录的 payload 为{Index}|{Timestamp}|{AgentId}|{EventType}|{Action}|{Detail}|{PreviousHash}经 SHA-256 哈希后作为本条记录的Hash同时成为下一条记录的PreviousHash输入。首条记录的PreviousHash为 64 个0_lastHash new(0, 64)篡改自证VerifyIntegrity()从第一条起按同样规则重算每条哈希并与存储值比对任何一环被篡改都会导致后续全部链条失配返回(false, entry.Index)并输出Chain broken at entry N全部校验通过则返回(true, entries.Count)事件类型丰富演示中记录的EventType包括policy_check策略判定、tool_policy/tool_decision工具拦截与最终决策以及rogue_baseline/rogue_probe异常检测阶段覆盖策略检查→工具调用→异常判定全生命周期。这也呼应了仓库 ADR-0017Merkle 链用于审计防篡改证据 的设计取向审计日志不仅要记录还要能向合规审计方证明未被篡改。汇总统计与运维要点演示收尾的汇总输出来自 sample_output.md━━━ Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ Allowed: 7 ❌ Denied: 8 ⚠️ Anomalies: 1 Audit log: 35 entries (Merkle-chained) Total governance decisions: 15 All governance enforcement ran inline — no requests bypassed the middleware stack.最后一行是最重要的运维结论所有治理强制均以内联inline方式运行没有任何请求绕过中间件栈。这意味着在 Program.cs 的整个 agent 生命周期中消息级与工具级检查对每个请求都生效治理层没有漏网之鱼。针对生产环境落地从该演示可以提炼三点实践建议策略文件与代码解耦把治理规则声明在 YAML 中如 devops_governance.yaml变更规则无需重新编译 Agent便于安全团队独立评审与审计双钩子防御纵深消息级RunAsync拦截意图工具级InvokeFunctionAsync拦截能力两处都做 deny 判定并写审计避免单点失效异常检测必须有人工闸门部署风暴等异常行为触发隔离quarantine后应强制走人工审批流程恢复而不是让 Agent 自愈。与 Python 版实现的对照同一场景还提供了 Python 实现examples/maf-integration/05-devops-deploy/python/两者治理语义一致、载体不同便于跨语言团队参考Python 侧通过 main.py 使用AgentControl.from_manifest(...)加载清单并创建MAFKernel对提示词调用kernel.input(context, prompt)获取result.verdict允许/拒绝同样无需 LLM 凭证即可运行策略绑定方式不同Python 侧在 manifest.yaml 中声明intervention_pointsinput绑定到$.input.bodypre_tool_call绑定到$.tool_call.args策略本体为 Regopolicies/devops.rego.NET 侧则用 YAML 表达式规则 原生中间件扩展方式在完整的 MAF 应用中Python 侧可通过kernel.as_runtime_middleware()将治理运行时挂载为 MAF 中间件由运行时负责决策、转换与审批由 MAF 中间件负责框架生命周期与审计上下文依据 examples/maf-integration/README.md。进一步阅读场景清单与运行说明examples/maf-integration/README.md本演示的 .NET 工程与策略dotnet 目录Program.cs、devops_governance.yaml共享治理内核实现策略引擎 / 中间件 / Merkle 审计 / 异常检测DemoCommon.cs其余 MAF 集成场景贷款处理、客服、医疗、IT 帮助台、.NET 扩展验证examples/maf-integration审计防篡改的设计背景ADR-0017 Merkle 链、ADR-0013 策略评估错误时 fail-closed【免费下载链接】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），仅供参考