Agent Governance Toolkit 在 Azure Container Apps 上的 Sidecar 部署指南【免费下载链接】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导读本文面向希望在 Azure 上以 Serverless 方式托管 AI Agent、并为其引入策略执行、零信任身份、执行沙箱与可靠性治理的开发者完整讲解 Agent Governance ToolkitAGT如何以 Sidecar 容器形态部署到 Azure Container Apps。阅读本文后你将掌握从创建 Container Apps 环境、构建并推送治理 Sidecar 镜像、编排双容器应用到通过 Azure Files 挂载治理策略、基于 Log Analytics 监控治理事件与配置弹性伸缩的完整实战链路。架构治理 Sidecar 与 Agent 共驻一个 Container AppAzure Container Apps 原生支持 Sidecar 容器模式。AGT 治理组件agent-os内核、agentmesh网格身份、agent-sre可靠性观测被打包为独立的治理 Sidecar与你的 Agent 容器共同运行在同一个 Container Apps Environment 中。两个容器共享网络命名空间通过localhost完成进程间通信无需暴露任何公网服务┌─────────────────────────────────────────────────────┐ │ Container Apps Environment │ │ │ │ ┌────────────────────────────────────────────────┐ │ │ │ Container App │ │ │ │ ┌──────────────────┐ ┌────────────────────┐ │ │ │ │ │ Agent Container │ │ Governance │ │ │ │ │ │ │ │ Sidecar │ │ │ │ │ │ Your AI agent │ │ agent-os │ │ │ │ │ │ (any framework) │ │ agentmesh │ │ │ │ │ │ │ │ agent-sre │ │ │ │ │ │ localhost:8080 ──────► localhost:8081 │ │ │ │ │ └──────────────────┘ └────────────────────┘ │ │ │ └────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Key Vault │ │ Log Analytics│ │ Container │ │ │ │ │ │ Workspace │ │ Registry │ │ │ └─────────────┘ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────┘从仓库源码看治理 Sidecar 的 HTTP 服务定义在 sidecar.py它同时组合了策略服务器Policy Server、信任引擎与指标暴露三部分能力对外提供以下关键端点端点用途GET /health、GET /healthz存活探针供平台健康检查使用GET /ready、GET /readyz就绪探针/ready会返回当前已加载的策略数量与策略集状态GET /metricsPrometheus 指标端点供可观测平台抓取POST /api/v1/policy/evaluate策略评估入口Agent 每次工具调用前向 Sidecar 发起评估请求GET /api/v1/policies查询已发现/已加载的策略文件清单与策略集 IDPOST /api/v1/policy/reload触发策略热加载重新扫描策略目录并生成新的策略集Agent 容器将治理流量指向localhost:8081即架构图中的通信路径Agentlocalhost:8080→ 治理 Sidecarlocalhost:8081。前置条件开始部署前请确认以下环境就绪Azure CLI 2.60并安装containerapp扩展Azure Container RegistryACR或其他可访问的容器镜像仓库Docker用于在本地构建镜像# 安装/更新 Container Apps 扩展 az extension add --name containerapp --upgrade az provider register --namespace Microsoft.App az provider register --namespace Microsoft.OperationalInsightsMicrosoft.App与Microsoft.OperationalInsights两个资源提供者分别对应 Container Apps 服务本身及其日志分析依赖注册后即可正常创建环境。环境搭建一键创建容器环境、镜像仓库与日志工作区1. 创建 Container Apps Environment以下命令依次创建资源组、容器镜像仓库、Log Analytics 工作区用于接收治理指标以及 Container Apps EnvironmentRESOURCE_GROUPrg-agent-governance LOCATIONeastus ENVIRONMENTagent-gov-env REGISTRYagentgovregistry # 资源组 az group create --name $RESOURCE_GROUP --location $LOCATION # 容器镜像仓库 az acr create --name $REGISTRY --resource-group $RESOURCE_GROUP --sku Basic --admin-enabled true # Log Analytics 工作区用于治理指标 az monitor log-analytics workspace create \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs LOG_ANALYTICS_ID$(az monitor log-analytics workspace show \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs \ --query customerId -o tsv) LOG_ANALYTICS_KEY$(az monitor log-analytics workspace get-shared-keys \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs \ --query primarySharedKey -o tsv) # Container Apps 环境 az containerapp env create \ --name $ENVIRONMENT \ --resource-group $RESOURCE_GROUP \ --logs-workspace-id $LOG_ANALYTICS_ID \ --logs-workspace-key $LOG_ANALYTICS_KEY \ --location $LOCATION注意LOG_ANALYTICS_IDcustomerId与LOG_ANALYTICS_KEYprimarySharedKey两个变量会在环境创建时以--logs-workspace-id/--logs-workspace-key传入确保后续 Sidecar 输出的日志与指标自动落入该工作区这是第 5 节监控查询的数据前提。2. 构建并推送治理 Sidecar 镜像仓库中提供了两个可直接构建的 Dockerfileagent-os内核镜像见 agent-os/Dockerfile默认以 MCP stdio 模式启动也支持python -m mcp_kernel_server.cli以 HTTP 模式监听8080端口并带健康检查统一治理 Sidecar 镜像见 Dockerfile.sidecar将策略评估、信任校验与 Prometheus 指标合入一个轻量容器默认监听8081端口。按文档指引从agent-os目录构建并推送# 从仓库根目录进入 agent-os cd agent-os # 构建治理 sidecar 镜像 docker build -t $REGISTRY.azurecr.io/agent-governance-sidecar:latest . # 推送至 ACR az acr login --name $REGISTRY docker push $REGISTRY.azurecr.io/agent-governance-sidecar:latest从 Dockerfile.sidecar 的源码注释可以确认该镜像支持以下环境变量本文后续部署 YAML 会用到其中部分环境变量默认值说明AGT_POLICY_DIR/etc/agt/policiesYAML 策略文件目录AGT_PORT8081服务监听端口AGT_HOST0.0.0.0绑定地址AGT_LOG_LEVELinfo日志级别AGT_SERVICE_NAMEagt-sidecarOpenTelemetry 服务名镜像还通过tini做信号转发以非 root 用户agt运行并内置HEALTHCHECK每 15 秒探测http://localhost:8081/health这些细节与 Container Apps 的健康探针天然兼容。部署治理 Sidecar双容器编排与参数详解3. 以 Sidecar 模式部署Azure Container Apps 原生支持 Sidecar 容器治理 Toolkit 作为 Sidecar 与你的 Agent 一同部署az containerapp create \ --name my-governed-agent \ --resource-group $RESOURCE_GROUP \ --environment $ENVIRONMENT \ --image your-registry.azurecr.io/your-agent:latest \ --target-port 8080 \ --ingress external \ --min-replicas 0 \ --max-replicas 10 \ --registry-server $REGISTRY.azurecr.io \ --yaml container-app.yaml完整的container-app.yaml编排文件如下properties: configuration: ingress: external: true targetPort: 8080 registries: - server: agentgovregistry.azurecr.io identity: system template: containers: # 主容器你的 AI Agent - name: agent image: agentgovregistry.azurecr.io/your-agent:latest resources: cpu: 1.0 memory: 2Gi env: - name: GOVERNANCE_ENDPOINT value: http://localhost:8081 - name: AGENT_ID value: my-agent-001 # Sidecar治理工具包 - name: governance-sidecar image: agentgovregistry.azurecr.io/agent-governance-sidecar:latest resources: cpu: 0.25 memory: 0.5Gi env: - name: POLICY_DIR value: /policies - name: OTEL_EXPORTER_OTLP_ENDPOINT value: http://localhost:4318 - name: TRUST_SCORE_THRESHOLD value: 0.6 - name: RATE_LIMIT_PER_MINUTE value: 100 volumeMounts: - volumeName: policy-volume mountPath: /policies scale: minReplicas: 0 maxReplicas: 10 rules: - name: http-rule http: metadata: concurrentRequests: 50 volumes: - name: policy-volume storageType: AzureFile storageName: policy-share编排 YAML 关键参数解读configuration.ingressexternal: true将应用暴露为公网入口targetPort: 8080指向 Agent 容器端口Sidecar 无需对外暴露。configuration.registries使用identity: system表明通过系统分配的托管标识拉取 ACR 镜像避免在 YAML 中明文存放凭据。Agent 容器环境变量GOVERNANCE_ENDPOINThttp://localhost:8081指定治理 Sidecar 地址Agent 的 SDK 会将每一次工具调用前检查发送至此AGENT_IDmy-agent-001声明当前 Agent 的唯一标识用于策略按 Agent 维度生效策略评估时依据该标识匹配约束与配额。Sidecar 容器环境变量POLICY_DIR/policies策略目录与下方policy-volume的挂载点对应对应镜像实现中的AGT_POLICY_DIROTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318OpenTelemetry OTLP HTTP 导出端点Sidecar 的治理指标经此上报TRUST_SCORE_THRESHOLD0.6信任分数阈值低于该值的 Agent 请求将被拒绝或降级处理RATE_LIMIT_PER_MINUTE100每分钟调用次数上限属于策略引擎的配额维度。template.scaleminReplicas: 0允许缩容到零开发环境省钱maxReplicas: 10限制峰值副本HTTP 伸缩规则以concurrentRequests: 50并发请求数 50为触发指标。注意Container Apps 的副本是整组伸缩的即一个副本始终包含 Agent 与 Sidecar 两个容器。template.volumespolicy-volume使用AzureFile类型挂载名policy-share对应下一步在环境中注册的 Azure Files 存储。配置治理策略Azure Files 挂载与策略文件编写4. 通过 Azure Files 挂载策略策略文件集中放在 Azure Files 共享中以只读方式挂载进 Sidecar# 创建存储账户与文件共享 az storage account create \ --name agentgovpolicies \ --resource-group $RESOURCE_GROUP \ --sku Standard_LRS az storage share create \ --name policies \ --account-name agentgovpolicies # 上传策略文件 az storage file upload-batch \ --destination policies \ --source ./policies/ \ --account-name agentgovpolicies # 将存储链接到 Container Apps 环境 az containerapp env storage set \ --name $ENVIRONMENT \ --resource-group $RESOURCE_GROUP \ --storage-name policy-share \ --azure-file-account-name agentgovpolicies \ --azure-file-account-key $(az storage account keys list --account-name agentgovpolicies --query [0].value -o tsv) \ --azure-file-share-name policies \ --access-mode ReadOnly--access-mode ReadOnly保证运行时无法篡改策略文件策略变更统一走重新上传文件 → 触发 Sidecar 重新加载的受控流程。Sidecar 的策略热加载端点/api/v1/policy/reload与/api/v1/policies见 sidecar.py正是为此设计的加载时会保留 YAML 优先于 JSON 的同名文件优先级并以policy_set_id对策略内容做 SHA-256 摘要与policy_set_statuscomplete/degraded/not_loaded记录策略集状态便于审计与排障。示例策略policies/default.yamlversion: 1.0 policies: - name: rate-limit type: rate_limit max_calls: 100 window: 1m - name: read-only type: capability allowed_actions: - read_* - search_* - list_* denied_actions: - delete_* - write_production_* - name: content-safety type: pattern blocked_patterns: - ignore previous instructions - DROP TABLE - rm -rf策略语义与底层能力策略文件中的type字段对应策略引擎中不同类型的治理规则仓库的完整策略模型可参考 agent-os 策略模式参考rate_limit限流配额max_calls: 100window: 1m表示每分钟最多 100 次调用。底层ResourceQuota还支持max_requests_per_hour、max_execution_time_seconds、max_concurrent_executions等更细粒度的配额维度并可通过allowed_action_types限定允许的动作类型code_execution、file_read、file_write、api_call、database_query、database_write、workflow_trigger。capability能力白名单/黑名单allowed_actions为允许列表设置了即只允许这些动作隐式拒绝其余一切denied_actions为始终封禁的拒绝列表二者可叠加实现默认拒绝 显式放行的最小权限模型。pattern内容模式阻断blocked_patterns命中即拦截典型场景是抵御提示注入如ignore previous instructions与危险指令如DROP TABLE、rm -rf。策略引擎还内置了始终生效的安全防护无需显式配置路径穿越防护自动阻断包含..的路径、系统目录/etc/、/sys/、/proc/、/dev/以及 Windows 系统路径C:\Windows\System32危险代码模式在code_execution中自动阻断rm -rf、磁盘格式化、DROP TABLE / DROP DATABASE、TRUNCATE TABLE、无WHERE条件的DELETE FROMSQL 注入防护自动剥离注释、检测多语句拼接、阻断破坏性操作。对于条件式访问控制ABACCondition支持eq、ne、gt、lt、gte、lte、in、not_in、contains、starts_with、not_starts_with、not_contains共 12 种比较算子可基于attribute_path如args.amount、context.user_role实现仅已验证用户、且金额不超过 $1000 才允许退款这类细粒度规则。监控在 Log Analytics 中查询治理事件Sidecar 会自动将 OpenTelemetry 指标导出到 Container Apps 环境关联的 Log Analytics 工作区即第 1 节创建的环境所绑定的工作区无需额外接入配置。查询治理事件ContainerAppConsoleLogs_CL | where ContainerName_s governance-sidecar | where Log_s contains policy_decision | project TimeGenerated, Log_s | order by TimeGenerated desc | take 100查询策略违规按小时聚合ContainerAppConsoleLogs_CL | where ContainerName_s governance-sidecar | where Log_s contains DENIED | summarize ViolationCount count() by bin(TimeGenerated, 1h) | render timechart其中ContainerName_s governance-sidecar用于精确过滤出 Sidecar 容器日志对应部署 YAML 中的容器名governance-sidecarpolicy_decision是每次策略评估产生的决策事件DENIED则是被拒绝调用的标记二者组合即可形成谁在什么时间被拦下了什么操作的完整审计视图。若需要更丰富的指标如策略决策计数、被拦截的工具调用数、信任分数、治理时延直方图可将治理中间件的指标通过 Azure Monitor OpenTelemetry Exporter 上报参见 Azure Foundry Agent Service 集成指南。弹性伸缩配置Container Apps 会将 Agent 与治理 Sidecar 作为一个整体伸缩一个副本包含两个容器。关键伸缩参数建议设置项建议值说明minReplicas开发环境0生产环境2开发环境缩容到零以节省成本maxReplicas按负载评估每个副本都包含 Agent 与 Sidecar 两个容器Sidecar CPU0.25核治理开销极低p99 时延 0.1msSidecar 内存512Mi足够承载策略引擎与信任评分作为参考仓库中的 Kubernetes Sidecar 示例 k8s-sidecar.yaml 为治理容器给出的资源下限是64Mi内存 /50mCPU上限128Mi/200m可见治理 Sidecar 的资源足迹非常轻量在 Container Apps 上适当放宽到0.25核 /0.5Gi是为了容纳策略引擎热加载与指标聚合的峰值余量。与 AKS 部署的对比能力Container AppsAKS运维复杂度低Serverless较高需管理集群缩容到零✅ 原生支持❌ 需要 KEDAHelm Chart 支持❌ 仅 YAML✅ 完整 Helm自定义网络受限完整的 VNet 控制多 Agent 网格基础✅ 完整的 AgentMesh 与 IATP适用场景单 Agent、原型验证生产级多 Agent 系统选型建议如果你的场景是单 Agent 原型验证、希望以最小运维成本获得策略执行与治理观测能力Container Apps 是最佳起点——你仍能获得与 AKS 完全一致的策略行为Toolkit 不绑定任何云厂商同一份策略与镜像可无缝迁移。对于需要完整 AgentMesh 身份体系与 IATP交互式身份与信任握手的生产级多 Agent 系统则建议采用 AKS 部署。下一步深入学习 治理策略模式参考了解 YAML 声明式配置与 Python API 两种策略定义方式以及从 YAML 迁移到PolicyEngine编程式配置的完整示例阅读 AgentMesh 身份体系为多 Agent 场景配置零信任身份与网格通信参考 agent-sre 可靠性工程启用 SLO 监控与服务等级目标跟踪若需在 Kubernetes 上部署完整 Sidecar含存活/就绪探针与 ConfigMap 策略挂载示例可对照 k8s-sidecar.yaml 与 AKS 部署指南对生产多 Agent 场景参考 Azure Foundry Agent Service 集成 实现进程内中间件治理或将 Container Apps Sidecar 与进程内中间件组合形成纵深防御。【免费下载链接】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 在 Azure Container Apps 上的 Sidecar 部署指南
Agent Governance Toolkit 在 Azure Container Apps 上的 Sidecar 部署指南【免费下载链接】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导读本文面向希望在 Azure 上以 Serverless 方式托管 AI Agent、并为其引入策略执行、零信任身份、执行沙箱与可靠性治理的开发者完整讲解 Agent Governance ToolkitAGT如何以 Sidecar 容器形态部署到 Azure Container Apps。阅读本文后你将掌握从创建 Container Apps 环境、构建并推送治理 Sidecar 镜像、编排双容器应用到通过 Azure Files 挂载治理策略、基于 Log Analytics 监控治理事件与配置弹性伸缩的完整实战链路。架构治理 Sidecar 与 Agent 共驻一个 Container AppAzure Container Apps 原生支持 Sidecar 容器模式。AGT 治理组件agent-os内核、agentmesh网格身份、agent-sre可靠性观测被打包为独立的治理 Sidecar与你的 Agent 容器共同运行在同一个 Container Apps Environment 中。两个容器共享网络命名空间通过localhost完成进程间通信无需暴露任何公网服务┌─────────────────────────────────────────────────────┐ │ Container Apps Environment │ │ │ │ ┌────────────────────────────────────────────────┐ │ │ │ Container App │ │ │ │ ┌──────────────────┐ ┌────────────────────┐ │ │ │ │ │ Agent Container │ │ Governance │ │ │ │ │ │ │ │ Sidecar │ │ │ │ │ │ Your AI agent │ │ agent-os │ │ │ │ │ │ (any framework) │ │ agentmesh │ │ │ │ │ │ │ │ agent-sre │ │ │ │ │ │ localhost:8080 ──────► localhost:8081 │ │ │ │ │ └──────────────────┘ └────────────────────┘ │ │ │ └────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Key Vault │ │ Log Analytics│ │ Container │ │ │ │ │ │ Workspace │ │ Registry │ │ │ └─────────────┘ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────┘从仓库源码看治理 Sidecar 的 HTTP 服务定义在 sidecar.py它同时组合了策略服务器Policy Server、信任引擎与指标暴露三部分能力对外提供以下关键端点端点用途GET /health、GET /healthz存活探针供平台健康检查使用GET /ready、GET /readyz就绪探针/ready会返回当前已加载的策略数量与策略集状态GET /metricsPrometheus 指标端点供可观测平台抓取POST /api/v1/policy/evaluate策略评估入口Agent 每次工具调用前向 Sidecar 发起评估请求GET /api/v1/policies查询已发现/已加载的策略文件清单与策略集 IDPOST /api/v1/policy/reload触发策略热加载重新扫描策略目录并生成新的策略集Agent 容器将治理流量指向localhost:8081即架构图中的通信路径Agentlocalhost:8080→ 治理 Sidecarlocalhost:8081。前置条件开始部署前请确认以下环境就绪Azure CLI 2.60并安装containerapp扩展Azure Container RegistryACR或其他可访问的容器镜像仓库Docker用于在本地构建镜像# 安装/更新 Container Apps 扩展 az extension add --name containerapp --upgrade az provider register --namespace Microsoft.App az provider register --namespace Microsoft.OperationalInsightsMicrosoft.App与Microsoft.OperationalInsights两个资源提供者分别对应 Container Apps 服务本身及其日志分析依赖注册后即可正常创建环境。环境搭建一键创建容器环境、镜像仓库与日志工作区1. 创建 Container Apps Environment以下命令依次创建资源组、容器镜像仓库、Log Analytics 工作区用于接收治理指标以及 Container Apps EnvironmentRESOURCE_GROUPrg-agent-governance LOCATIONeastus ENVIRONMENTagent-gov-env REGISTRYagentgovregistry # 资源组 az group create --name $RESOURCE_GROUP --location $LOCATION # 容器镜像仓库 az acr create --name $REGISTRY --resource-group $RESOURCE_GROUP --sku Basic --admin-enabled true # Log Analytics 工作区用于治理指标 az monitor log-analytics workspace create \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs LOG_ANALYTICS_ID$(az monitor log-analytics workspace show \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs \ --query customerId -o tsv) LOG_ANALYTICS_KEY$(az monitor log-analytics workspace get-shared-keys \ --resource-group $RESOURCE_GROUP \ --workspace-name agent-gov-logs \ --query primarySharedKey -o tsv) # Container Apps 环境 az containerapp env create \ --name $ENVIRONMENT \ --resource-group $RESOURCE_GROUP \ --logs-workspace-id $LOG_ANALYTICS_ID \ --logs-workspace-key $LOG_ANALYTICS_KEY \ --location $LOCATION注意LOG_ANALYTICS_IDcustomerId与LOG_ANALYTICS_KEYprimarySharedKey两个变量会在环境创建时以--logs-workspace-id/--logs-workspace-key传入确保后续 Sidecar 输出的日志与指标自动落入该工作区这是第 5 节监控查询的数据前提。2. 构建并推送治理 Sidecar 镜像仓库中提供了两个可直接构建的 Dockerfileagent-os内核镜像见 agent-os/Dockerfile默认以 MCP stdio 模式启动也支持python -m mcp_kernel_server.cli以 HTTP 模式监听8080端口并带健康检查统一治理 Sidecar 镜像见 Dockerfile.sidecar将策略评估、信任校验与 Prometheus 指标合入一个轻量容器默认监听8081端口。按文档指引从agent-os目录构建并推送# 从仓库根目录进入 agent-os cd agent-os # 构建治理 sidecar 镜像 docker build -t $REGISTRY.azurecr.io/agent-governance-sidecar:latest . # 推送至 ACR az acr login --name $REGISTRY docker push $REGISTRY.azurecr.io/agent-governance-sidecar:latest从 Dockerfile.sidecar 的源码注释可以确认该镜像支持以下环境变量本文后续部署 YAML 会用到其中部分环境变量默认值说明AGT_POLICY_DIR/etc/agt/policiesYAML 策略文件目录AGT_PORT8081服务监听端口AGT_HOST0.0.0.0绑定地址AGT_LOG_LEVELinfo日志级别AGT_SERVICE_NAMEagt-sidecarOpenTelemetry 服务名镜像还通过tini做信号转发以非 root 用户agt运行并内置HEALTHCHECK每 15 秒探测http://localhost:8081/health这些细节与 Container Apps 的健康探针天然兼容。部署治理 Sidecar双容器编排与参数详解3. 以 Sidecar 模式部署Azure Container Apps 原生支持 Sidecar 容器治理 Toolkit 作为 Sidecar 与你的 Agent 一同部署az containerapp create \ --name my-governed-agent \ --resource-group $RESOURCE_GROUP \ --environment $ENVIRONMENT \ --image your-registry.azurecr.io/your-agent:latest \ --target-port 8080 \ --ingress external \ --min-replicas 0 \ --max-replicas 10 \ --registry-server $REGISTRY.azurecr.io \ --yaml container-app.yaml完整的container-app.yaml编排文件如下properties: configuration: ingress: external: true targetPort: 8080 registries: - server: agentgovregistry.azurecr.io identity: system template: containers: # 主容器你的 AI Agent - name: agent image: agentgovregistry.azurecr.io/your-agent:latest resources: cpu: 1.0 memory: 2Gi env: - name: GOVERNANCE_ENDPOINT value: http://localhost:8081 - name: AGENT_ID value: my-agent-001 # Sidecar治理工具包 - name: governance-sidecar image: agentgovregistry.azurecr.io/agent-governance-sidecar:latest resources: cpu: 0.25 memory: 0.5Gi env: - name: POLICY_DIR value: /policies - name: OTEL_EXPORTER_OTLP_ENDPOINT value: http://localhost:4318 - name: TRUST_SCORE_THRESHOLD value: 0.6 - name: RATE_LIMIT_PER_MINUTE value: 100 volumeMounts: - volumeName: policy-volume mountPath: /policies scale: minReplicas: 0 maxReplicas: 10 rules: - name: http-rule http: metadata: concurrentRequests: 50 volumes: - name: policy-volume storageType: AzureFile storageName: policy-share编排 YAML 关键参数解读configuration.ingressexternal: true将应用暴露为公网入口targetPort: 8080指向 Agent 容器端口Sidecar 无需对外暴露。configuration.registries使用identity: system表明通过系统分配的托管标识拉取 ACR 镜像避免在 YAML 中明文存放凭据。Agent 容器环境变量GOVERNANCE_ENDPOINThttp://localhost:8081指定治理 Sidecar 地址Agent 的 SDK 会将每一次工具调用前检查发送至此AGENT_IDmy-agent-001声明当前 Agent 的唯一标识用于策略按 Agent 维度生效策略评估时依据该标识匹配约束与配额。Sidecar 容器环境变量POLICY_DIR/policies策略目录与下方policy-volume的挂载点对应对应镜像实现中的AGT_POLICY_DIROTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318OpenTelemetry OTLP HTTP 导出端点Sidecar 的治理指标经此上报TRUST_SCORE_THRESHOLD0.6信任分数阈值低于该值的 Agent 请求将被拒绝或降级处理RATE_LIMIT_PER_MINUTE100每分钟调用次数上限属于策略引擎的配额维度。template.scaleminReplicas: 0允许缩容到零开发环境省钱maxReplicas: 10限制峰值副本HTTP 伸缩规则以concurrentRequests: 50并发请求数 50为触发指标。注意Container Apps 的副本是整组伸缩的即一个副本始终包含 Agent 与 Sidecar 两个容器。template.volumespolicy-volume使用AzureFile类型挂载名policy-share对应下一步在环境中注册的 Azure Files 存储。配置治理策略Azure Files 挂载与策略文件编写4. 通过 Azure Files 挂载策略策略文件集中放在 Azure Files 共享中以只读方式挂载进 Sidecar# 创建存储账户与文件共享 az storage account create \ --name agentgovpolicies \ --resource-group $RESOURCE_GROUP \ --sku Standard_LRS az storage share create \ --name policies \ --account-name agentgovpolicies # 上传策略文件 az storage file upload-batch \ --destination policies \ --source ./policies/ \ --account-name agentgovpolicies # 将存储链接到 Container Apps 环境 az containerapp env storage set \ --name $ENVIRONMENT \ --resource-group $RESOURCE_GROUP \ --storage-name policy-share \ --azure-file-account-name agentgovpolicies \ --azure-file-account-key $(az storage account keys list --account-name agentgovpolicies --query [0].value -o tsv) \ --azure-file-share-name policies \ --access-mode ReadOnly--access-mode ReadOnly保证运行时无法篡改策略文件策略变更统一走重新上传文件 → 触发 Sidecar 重新加载的受控流程。Sidecar 的策略热加载端点/api/v1/policy/reload与/api/v1/policies见 sidecar.py正是为此设计的加载时会保留 YAML 优先于 JSON 的同名文件优先级并以policy_set_id对策略内容做 SHA-256 摘要与policy_set_statuscomplete/degraded/not_loaded记录策略集状态便于审计与排障。示例策略policies/default.yamlversion: 1.0 policies: - name: rate-limit type: rate_limit max_calls: 100 window: 1m - name: read-only type: capability allowed_actions: - read_* - search_* - list_* denied_actions: - delete_* - write_production_* - name: content-safety type: pattern blocked_patterns: - ignore previous instructions - DROP TABLE - rm -rf策略语义与底层能力策略文件中的type字段对应策略引擎中不同类型的治理规则仓库的完整策略模型可参考 agent-os 策略模式参考rate_limit限流配额max_calls: 100window: 1m表示每分钟最多 100 次调用。底层ResourceQuota还支持max_requests_per_hour、max_execution_time_seconds、max_concurrent_executions等更细粒度的配额维度并可通过allowed_action_types限定允许的动作类型code_execution、file_read、file_write、api_call、database_query、database_write、workflow_trigger。capability能力白名单/黑名单allowed_actions为允许列表设置了即只允许这些动作隐式拒绝其余一切denied_actions为始终封禁的拒绝列表二者可叠加实现默认拒绝 显式放行的最小权限模型。pattern内容模式阻断blocked_patterns命中即拦截典型场景是抵御提示注入如ignore previous instructions与危险指令如DROP TABLE、rm -rf。策略引擎还内置了始终生效的安全防护无需显式配置路径穿越防护自动阻断包含..的路径、系统目录/etc/、/sys/、/proc/、/dev/以及 Windows 系统路径C:\Windows\System32危险代码模式在code_execution中自动阻断rm -rf、磁盘格式化、DROP TABLE / DROP DATABASE、TRUNCATE TABLE、无WHERE条件的DELETE FROMSQL 注入防护自动剥离注释、检测多语句拼接、阻断破坏性操作。对于条件式访问控制ABACCondition支持eq、ne、gt、lt、gte、lte、in、not_in、contains、starts_with、not_starts_with、not_contains共 12 种比较算子可基于attribute_path如args.amount、context.user_role实现仅已验证用户、且金额不超过 $1000 才允许退款这类细粒度规则。监控在 Log Analytics 中查询治理事件Sidecar 会自动将 OpenTelemetry 指标导出到 Container Apps 环境关联的 Log Analytics 工作区即第 1 节创建的环境所绑定的工作区无需额外接入配置。查询治理事件ContainerAppConsoleLogs_CL | where ContainerName_s governance-sidecar | where Log_s contains policy_decision | project TimeGenerated, Log_s | order by TimeGenerated desc | take 100查询策略违规按小时聚合ContainerAppConsoleLogs_CL | where ContainerName_s governance-sidecar | where Log_s contains DENIED | summarize ViolationCount count() by bin(TimeGenerated, 1h) | render timechart其中ContainerName_s governance-sidecar用于精确过滤出 Sidecar 容器日志对应部署 YAML 中的容器名governance-sidecarpolicy_decision是每次策略评估产生的决策事件DENIED则是被拒绝调用的标记二者组合即可形成谁在什么时间被拦下了什么操作的完整审计视图。若需要更丰富的指标如策略决策计数、被拦截的工具调用数、信任分数、治理时延直方图可将治理中间件的指标通过 Azure Monitor OpenTelemetry Exporter 上报参见 Azure Foundry Agent Service 集成指南。弹性伸缩配置Container Apps 会将 Agent 与治理 Sidecar 作为一个整体伸缩一个副本包含两个容器。关键伸缩参数建议设置项建议值说明minReplicas开发环境0生产环境2开发环境缩容到零以节省成本maxReplicas按负载评估每个副本都包含 Agent 与 Sidecar 两个容器Sidecar CPU0.25核治理开销极低p99 时延 0.1msSidecar 内存512Mi足够承载策略引擎与信任评分作为参考仓库中的 Kubernetes Sidecar 示例 k8s-sidecar.yaml 为治理容器给出的资源下限是64Mi内存 /50mCPU上限128Mi/200m可见治理 Sidecar 的资源足迹非常轻量在 Container Apps 上适当放宽到0.25核 /0.5Gi是为了容纳策略引擎热加载与指标聚合的峰值余量。与 AKS 部署的对比能力Container AppsAKS运维复杂度低Serverless较高需管理集群缩容到零✅ 原生支持❌ 需要 KEDAHelm Chart 支持❌ 仅 YAML✅ 完整 Helm自定义网络受限完整的 VNet 控制多 Agent 网格基础✅ 完整的 AgentMesh 与 IATP适用场景单 Agent、原型验证生产级多 Agent 系统选型建议如果你的场景是单 Agent 原型验证、希望以最小运维成本获得策略执行与治理观测能力Container Apps 是最佳起点——你仍能获得与 AKS 完全一致的策略行为Toolkit 不绑定任何云厂商同一份策略与镜像可无缝迁移。对于需要完整 AgentMesh 身份体系与 IATP交互式身份与信任握手的生产级多 Agent 系统则建议采用 AKS 部署。下一步深入学习 治理策略模式参考了解 YAML 声明式配置与 Python API 两种策略定义方式以及从 YAML 迁移到PolicyEngine编程式配置的完整示例阅读 AgentMesh 身份体系为多 Agent 场景配置零信任身份与网格通信参考 agent-sre 可靠性工程启用 SLO 监控与服务等级目标跟踪若需在 Kubernetes 上部署完整 Sidecar含存活/就绪探针与 ConfigMap 策略挂载示例可对照 k8s-sidecar.yaml 与 AKS 部署指南对生产多 Agent 场景参考 Azure Foundry Agent Service 集成 实现进程内中间件治理或将 Container Apps Sidecar 与进程内中间件组合形成纵深防御。【免费下载链接】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），仅供参考