企业官网建设流程全解析

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 Toolkit（AGT）如何以 Sidecar 容器形态部署到 Azure Container Apps。阅读本文后，你将掌握从创建 Container Apps 环境、构建并推送治理 Sidecar 镜像、编排双容器应用，到通过 Azure Files 挂载治理策略、基于 Log Analytics 监控治理事件与配置弹性伸缩的完整实战链路。

架构：治理 Sidecar 与 Agent 共驻一个 Container App

Azure 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）、信任引擎与指标暴露三部分能力，对外提供以下关键端点：

Agent 容器将治理流量指向localhost:8081，即架构图中的通信路径：Agent（localhost:8080）→ 治理 Sidecar（localhost:8081）。

前置条件

开始部署前，请确认以下环境就绪：

• Azure CLI 2.60+，并安装containerapp扩展
• Azure Container Registry（ACR）或其他可访问的容器镜像仓库
• Docker（用于在本地构建镜像）

# 安装/更新 Container Apps 扩展 az extension add --name containerapp --upgrade az provider register --namespace Microsoft.App az provider register --namespace Microsoft.OperationalInsights

Microsoft.App与Microsoft.OperationalInsights两个资源提供者分别对应 Container Apps 服务本身及其日志分析依赖，注册后即可正常创建环境。

环境搭建：一键创建容器环境、镜像仓库与日志工作区

1. 创建 Container Apps Environment

以下命令依次创建资源组、容器镜像仓库、Log Analytics 工作区（用于接收治理指标）以及 Container Apps Environment：

RESOURCE_GROUP="rg-agent-governance" LOCATION="eastus" ENVIRONMENT="agent-gov-env" REGISTRY="agentgovregistry" # 资源组 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_ID（customerId）与LOG_ANALYTICS_KEY（primarySharedKey）两个变量会在环境创建时以--logs-workspace-id/--logs-workspace-key传入，确保后续 Sidecar 输出的日志与指标自动落入该工作区，这是第 5 节监控查询的数据前提。

2. 构建并推送治理 Sidecar 镜像

仓库中提供了两个可直接构建的 Dockerfile：

• agent-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 会用到其中部分）：

镜像还通过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.ingress：external: true将应用暴露为公网入口，targetPort: 8080指向 Agent 容器端口；Sidecar 无需对外暴露。
• configuration.registries：使用identity: system表明通过系统分配的托管标识拉取 ACR 镜像，避免在 YAML 中明文存放凭据。
• Agent 容器环境变量：
  • GOVERNANCE_ENDPOINT=http://localhost:8081：指定治理 Sidecar 地址，Agent 的 SDK 会将每一次工具调用前检查发送至此；
  • AGENT_ID=my-agent-001：声明当前 Agent 的唯一标识，用于策略按 Agent 维度生效（策略评估时依据该标识匹配约束与配额）。
• Sidecar 容器环境变量：
  • POLICY_DIR=/policies：策略目录，与下方policy-volume的挂载点对应（对应镜像实现中的AGT_POLICY_DIR）；
  • OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318：OpenTelemetry OTLP HTTP 导出端点，Sidecar 的治理指标经此上报；
  • TRUST_SCORE_THRESHOLD=0.6：信任分数阈值，低于该值的 Agent 请求将被拒绝或降级处理；
  • RATE_LIMIT_PER_MINUTE=100：每分钟调用次数上限，属于策略引擎的配额维度。
• template.scale：minReplicas: 0允许缩容到零（开发环境省钱），maxReplicas: 10限制峰值副本；HTTP 伸缩规则以concurrentRequests: "50"（并发请求数 50）为触发指标。注意：Container Apps 的副本是整组伸缩的，即一个副本始终包含 Agent 与 Sidecar 两个容器。
• template.volumes：policy-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_status（complete/degraded/not_loaded）记录策略集状态，便于审计与排障。

示例策略（policies/default.yaml）

version: "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: 100+window: 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 FROM；
• SQL 注入防护：自动剥离注释、检测多语句拼接、阻断破坏性操作。

对于条件式访问控制（ABAC），Condition支持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-sidecar），policy_decision是每次策略评估产生的决策事件，DENIED则是被拒绝调用的标记，二者组合即可形成"谁在什么时间被拦下了什么操作"的完整审计视图。若需要更丰富的指标（如策略决策计数、被拦截的工具调用数、信任分数、治理时延直方图），可将治理中间件的指标通过 Azure Monitor OpenTelemetry Exporter 上报，参见 Azure Foundry Agent Service 集成指南。

弹性伸缩配置

Container Apps 会将 Agent 与治理 Sidecar 作为一个整体伸缩（一个副本包含两个容器）。关键伸缩参数建议：

作为参考，仓库中的 Kubernetes Sidecar 示例 k8s-sidecar.yaml 为治理容器给出的资源下限是64Mi内存 /50mCPU（上限128Mi/200m），可见治理 Sidecar 的资源足迹非常轻量；在 Container Apps 上适当放宽到0.25核 /0.5Gi是为了容纳策略引擎热加载与指标聚合的峰值余量。

与 AKS 部署的对比

选型建议：如果你的场景是单 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