本文整理自 Microsoft Foundry 博客的 Closing the AI Agent Governance Gap with Microsoft Foundry，作者是 Alexandra Miller-Browne。

开发者上线 Agent 的速度，已经快过安全团队给它们登记造册的速度。组织从试点走向同时运行几十个甚至上百个 Agent 之后，总会反复冒出同一个问题：我到底怎么才能看清整个环境里有哪些 AI Agent？

这篇文章讲的是如何借助 Azure 的现有服务，为 AI 资产建立可见性、护栏和成本归属。读完我最大的感受是，它并没有让你另起炉灶，而是把大多数组织手上已经有的身份、网络和合规控制，接到 Agent 这套新东西上。

AI 治理大致发生在四个层面。资源层管谁能创建新的 AI 资源，构建者层管谁能在某个范围内开发和发布 Agent，行为层管 Agent 的输出怎样被评估、监控和约束，依赖层管 Agent 能接触哪些模型、工具、API 和 MCP 服务器。

难点不在于发明新的控制手段，而在于把已有的控制手段串成一套适用于 AI Agent 的运营模式。下面我按这四个层面逐一展开，看看缺口具体怎么补。

用 Azure Policy 划定边界

先从 Azure 门户里的 Azure Policy 说起。它可以限定环境中能部署什么，并对不合规的资源发出标记或直接拦截。针对 AI 工作负载，内置定义既能限制组织里的人可以部署哪些模型，也能通过启用专用终结点把网络锁起来。

可以先从这几条策略入手：

  • Foundry model deployments should only use approved models：把部署限制在组织明确批准的模型或发布者范围内
  • Foundry model deployments should meet eligibility requirements（预览）：按模型属性制定规则，比如是预览版还是正式版，以及分发来源
  • Azure AI Services resources should have key access disabled：让 Microsoft Entra ID 成为唯一的访问入口

Azure AI Services 相关的完整策略列表见这里：List of built-in policy definitions - Azure Policy | Microsoft Learn

Policy 排在第一步是有道理的。它在资源创建之前就做检查，环境因此从一开始就贴着你定的标准走，不用事后补救。

配置基于角色的访问控制（RBAC）

边界划好之后，下一步是 RBAC。越早配置，构建 Agent 的人和身份拿到的权限范围就越贴合他们真正要做的事。要注意，Foundry 角色只在使用 Microsoft Entra ID 认证时生效。如果走的是密钥认证，密钥本身就拥有完整访问权限，不受角色限制。API 密钥用来快速开发很方便，但往生产环境走的时候，首选的还是 Microsoft Entra ID。

角色可以分配在三个范围上：Foundry 资源、Foundry 项目，或者单个 Agent。下图给了一个例子，展示组织里不同角色的人如何对应到不同范围，来创建和构建 Foundry Agent。

RBAC 角色与范围示意图

图里每个角色的对比如下，按权限从低到高排列：

角色 权限级别 在 Microsoft Foundry 中的作用
Foundry Agent Consumer 最低 与项目中的 Agent 端点交互。只需要使用 Agent 的人，用这个最小权限角色就够了。
Foundry User 低 授予 Foundry 项目、Foundry 资源的读取权限，以及 Foundry 项目的数据操作权限。适合构建和测试 Agent 的开发者，是对他们最小权限的访问角色。
Foundry Project Manager 中 可以对 Foundry 项目执行管理操作，基于项目构建和开发，并且有条件地把 Foundry User 角色分配给其他用户主体。
Foundry Account Owner 较高 拥有管理 Foundry 项目和资源的完整权限，并可以把 Foundry User 角色分配给其他用户主体。
Foundry Owner 最高 拥有管理 Foundry 项目和资源、并基于项目构建开发的完整权限。还可以把 Foundry User、ACR 和监控相关角色分配给环境中的用户。

来源：Role-based access control for Microsoft Foundry - Microsoft Foundry | Microsoft Learn

至于 Agent 资源本身，建议分配托管标识，不要用 API 密钥，这样凭据泄露的风险更低。

如果你在用脚本配置 RBAC 权限，有一点要留意：这些角色最近改过名，原来叫 Azure AI User、Azure AI Owner、Azure AI Account Owner 和 Azure AI Project Manager。角色 ID 和权限都没变，所以代码里最好直接用角色定义的 GUID，免得改名逐步生效的这段时间出岔子。

Microsoft Foundry 中的可观测性

治理光靠访问控制不够，组织还需要证据，说明 Agent 到底是怎么被使用的。可观测性提供审计线索，用来排查事故、摸清使用模式、追踪成本。Foundry Control Plane 把这些可观测性和治理工具集中到一个地方，并与 Azure Monitor、Microsoft Entra、Microsoft Purview 和 Azure Policy 这些服务放在一起。

在 Foundry 门户里，可以先从追踪（tracing）开始。给项目连上 Application Insights 资源后，Foundry 会自动开启追踪，每一次运行都会被记录，包括你在 playground 里测试的那些。运行结束后，可以按 Response ID 或 Trace ID 搜索，查看对话历史、token 用量、运行步骤、工具调用，以及用户和 Agent 之间的输入输出。想要更细的查询，可以写 KQL 深入单次 Agent 运行，也可以用 Azure Monitor 里预置的 Grafana 仪表板。通过客户端追踪，还能把 trace 导出到你可能已经在用的可观测性工具，比如 Datadog 或 Jaeger。

注意： 查看这些遥测数据需要在所连接的 Application Insights 资源上拥有 Log Analytics Reader 角色。如果底层的 Log Analytics 表受到保护，还需要额外拥有 Privileged Monitoring Data Reader。

除了这些监控功能，每个 Agent 还自带内容安全护栏，也可以用评估在发布前后测试和优化 Agent 的表现。

Agent 发布到 Microsoft Teams 和 Microsoft 365 Copilot 后，Microsoft 365 管理员可以批准使用请求。这些请求还能进一步限定范围，比如只开放给一小批人做试点或某个部门使用，也可以面向全组织。

加一层 AI 网关

可观测性能告诉你 Agent 在做什么，可要怎么管住它们呢？这时候就轮到 Azure API Management 出场了。Agent、模型部署或使用它们的团队一旦超过一个，你就需要在 Agent 和它们所调用的资源之间设一个统一的执行点。在 Microsoft Foundry 前面加上 Azure API Management，可以得到：

  • 跨区域、跨模型部署的速率限制和负载均衡
  • 对模型流量和工具流量一致的认证与配额策略
  • 按团队或成本中心统计用量，方便向不同部门准确分摊费用
  • 对自定义 MCP 服务器和远程 MCP 服务器的受控访问

注意：选择 MCP 服务器时，优先从受信任、有企业级支持的来源入手（GitHub、Microsoft、内部自研的服务器等）。这类服务器应当有文档化的安全控制、企业级认证、明确的归属方和最小权限。社区 MCP 服务器在通过正式安全审查、并经组织验证之前，一律按不受信任处理。

到这里治理的全貌就齐了。Azure Policy 管能部署什么，RBAC 管谁能构建和管理 Agent，可观测性提供 Agent 在生产环境里行为表现的证据，AI 网关则把治理延伸到运行时，管 Agent 如何与模型、工具和外部系统交互。四层叠在一起，组织才有可能从单纯地构建 Agent，走到负责任地大规模运营 Agent。

把治理扩展到更大的范围

还有几个可以继续延伸的方向：

  • Azure API Center 里的 MCP 注册表。MCP 用得越来越多之后，可以建一份获批的 MCP 服务器和 API 清单，供整个组织使用。
  • Microsoft Agent 365 是微软面向企业的 AI Agent 控制平面。每个 Agent 都有自己的 Microsoft Entra Agent ID，已发布的 Foundry Agent 会自动同步到它的注册表。IT 团队可以在一个地方对租户内所有 Agent 做访问审查、生命周期策略和负责人确认，Foundry 之外发现的影子 Agent 也包括在内。
  • 在 Copilot Studio 里添加 MCP 工具时，可以把它指向 API Management 的 URL，而不是直接指向远程端点，借助网关获得更多可观测性。
  • GitHub Copilot 这边，同样的、由 AI 网关代理的 MCP 注册表也可以用在开发者一侧。
  • Microsoft Purview 负责更大范围内的数据分类、DLP、审计和 AI 交互治理。

接下来可以做什么

想快速上手的话，把上面提到的三条 Azure Policy 定义以审计模式开在一个非生产订阅上，看看有哪些资源被标记为不合规。

想设计端到端方案，可以看 Cloud Adoption Framework 里关于 AI 治理和为 AI 治理 Azure 平台服务的指导。

想深入 Agent 可观测性，可以从 Application Insights 与 Foundry 集成的两篇文章开始：Use Insights in Microsoft Foundry 和 Monitor AI Agents with Application Insights。

治理 AI Agent 不必从零开始，你在 Azure 上已经用着的身份、策略、监控和成本控制，本来就能延伸到 AI 工作负载。先挑一层做起来，再接上下一层就行。