身份、RBAC 与策略

为什么需要

• 同一个 Foundry 环境同时有两类操作：控制平面（创建资源、项目和模型部署）与数据平面（在项目中开发、调用 agent）。两者的权限不同，需要分开设计。

• 企业通常按团队分工授权，最小权限原则要求每个人只拿到完成工作所需的角色。

• 对模型输出的安全管控，需要在订阅或资源组层面统一下发策略，而不是逐个项目手工配置。

核心概念

内置角色速览

• Azure 通用角色中，Owner 可分配任意角色但不可直接做数据操作；Contributor 可管理资源与模型，但不能分配角色；Reader 只读。

• 页面不建议用 Cognitive Services 开头的内置角色访问 Foundry 项目，也不建议使用名为 Azure AI Developer 的角色（它面向 Azure ML 工作区）。查看配额的 Cognitive Services Usages Reader 为例外（页面说明）。

常见企业分工示例

与相邻能力的对比

护栏策略（Guardrail policy）

• 护栏策略在 Foundry（new）门户的 Operate > Compliance 中创建，用于对模型部署施加统一的安全控制。

• 控制项包括内容安全（content safety）、提示注入（prompt injection）与受保护材料（protected materials）。策略内的控制项即模型部署被视为合规的最低设置。

• 策略可作用于订阅或资源组，并可设置例外：订阅范围可为整个资源组或单个部署设置例外；资源组范围只能为单个部署设置例外。

• 合规扫描由 Azure Policy 执行，首次扫描需要一段时间，结果不会立即显示。

• 创建策略需要订阅或资源组上的 Owner 或 Resource Policy Contributor 角色。删除策略会同时删除对应的 Azure Policy 分配。

限制与待核实

• 角色更名：Foundry 角色于近期改名（例如 Azure AI User 改为 Foundry User），角色 ID 与核心权限不变，旧名称可能在部分界面仍然出现（页面说明）。脚本中建议使用角色 ID，而不是名称。

• 资源范围限制：查看与清除已删除的 Foundry 账户需要订阅范围的 Contributor；查看配额的 Usages API 需要订阅范围的角色分配，资源组或项目的分配不足以访问配额信息。

• 通过门户或 CLI 创建资源时，自动分配 Foundry User 的行为不同（页面说明），以页面为准。

• 微调模型需要同时具备数据平面与控制平面权限，页面指出只有 Foundry Owner 同时包含二者，或可组合 Foundry User 与 Foundry Account Owner（待核实）。

• Agent 范围的角色分配目前只影响 agent 端点访问，不授予控制平面权限（页面说明，预览状态待核实）。

• 护栏策略仅在新版 Foundry 门户可用（页面说明）；护栏的阈值与其他细节待核实（2026-11-05 获取）。

• 使用 Entra ID 访问 Blob 或 AI Search 等外部资源时，需要为资源的托管身份分配相应的存储或搜索角色（页面示例），具体角色名称待核实。

来源与核对

• sources：见页头 sources 列表（RBAC 概念页、SDK 概览页、护栏策略快速入门页、追踪设置页）。

• read_scope：正文已读。RBAC 概念页已通读；护栏策略页已读正文；SDK 概览页与追踪设置页仅读取其中与权限相关的段落。