Foundry RBAC that prevents over-privilege

Problem

Teams over-assign roles because it is faster. One person ends up able to create projects, deploy models and publish agents because it was easier to grant a broad role once than to think about it. Foundry has built-in roles that separate these tasks, and using them well is the cheapest security improvement available. One thing to know up front: the roles were renamed. What used to be called Azure AI User is now Foundry User, and Azure AI Project Manager is now Foundry Project Manager. If your infrastructure code still uses the old names, update it.

Options and trade-offs

• Foundry User: the least-privilege developer role. It gives reader access to the project and resource plus the data actions needed to build and test agents. It does not allow deploying or managing models.
• Foundry Project Manager: everything Foundry User can do, plus creating and managing projects, publishing agents, and assigning the Foundry User role to others. It does not include model deployment.
• Foundry Account Owner and Foundry Owner: manage the account and projects, including deploying models. These are broad. Use them sparingly and for platform owners only.
• Agent consumers: callers who only need to invoke a published agent should get access to the agent endpoint, not a build or admin role.

My recommendation

Give developers Foundry User and nothing else on the resource. Give team leads Foundry Project Manager so they can create projects and invite developers without waiting on a platform team. Reserve Foundry Account Owner for the few people who actually deploy models. Review assignments on a schedule, because over-privilege creeps back.

Minimal working example

Assign roles by name at the narrowest scope that works:

SUB=<subscription-id>
RG=<resource-group>
ACCOUNT=<foundry-resource-name>
SCOPE="/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.CognitiveServices/accounts/$ACCOUNT"

# Developers: least privilege
az role assignment create \
  --assignee <developer-object-id> \
  --role "Foundry User" \
  --scope "$SCOPE"

# Team lead: can create projects, publish agents, invite developers
az role assignment create \
  --assignee <lead-object-id> \
  --role "Foundry Project Manager" \
  --scope "$SCOPE"

# Platform owner who deploys models
az role assignment create \
  --assignee <platform-owner-object-id> \
  --role "Foundry Account Owner" \
  --scope "$SCOPE"

Audit who has what:

az role assignment list --scope "$SCOPE" \
  --query "[].{principal:principalName, role:roleDefinitionName}" -o table

Test it: sign in as a Foundry User and confirm you can build and run an agent but cannot deploy a model. Sign in as a Project Manager and confirm you can publish an agent but still cannot deploy a model.

Checklist

• Start every developer at Foundry User on the resource, and elevate only for a named task.
• Check the permission tables for "manage models" and deployment before granting Account Owner or Owner.
• Remember that Project Manager can assign only the Foundry User role, which makes delegated onboarding safe.
• Give service principals and end users that only invoke agents the narrowest role that allows it.
• Update scripts and templates that still reference the old Azure AI role names.
• Review role assignments at a regular interval, and remove access when people change teams.

Where this doesn't apply

Older hub-based (classic) projects have a different role surface. If you run both, map roles carefully and do not assume names carry across.

Sources

• Role-based access control for Microsoft Foundry — https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry
• Elevated-role tasks in Microsoft Foundry — https://learn.microsoft.com/en-us/azure/foundry/concepts/administrator-guide
• Azure built-in roles for AI + machine learning — https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/ai-machine-learning

---