Secure Microsoft Foundry Projects with RBAC and Managed Identity

In this blog post Secure Microsoft Foundry Projects with RBAC and Managed Identity we will explain how to stop AI projects accumulating excessive access, shared credentials and unclear ownership as they move from testing into production.

The high-level idea is simple. Role-based access control, or RBAC, decides who can perform an action and where they can perform it. Managed identities give Azure-hosted applications and projects their own secure login, without requiring your team to store passwords or API keys.

Used together, these controls help ensure that a finance assistant cannot quietly access HR files, a test project cannot modify production data, and a departing developer does not leave behind credentials that still work.

Why Foundry access becomes difficult so quickly

A single Microsoft Foundry proof of concept may involve only two developers and one model. Six months later, the same environment could contain multiple projects, agents, data connections, storage accounts and business teams.

The common response is to grant broad access whenever somebody encounters a permission error. That gets the project moving again, but it also creates a growing security and compliance problem.

Microsoft Foundry separates resource management from runtime activity. In plain English, the permission to configure an Azure resource is different from the permission to read data, run a model or interact with an agent.

This distinction matters because Azure Contributor access does not automatically provide every runtime permission. Conversely, a user who can run an agent should not necessarily be able to change networking, deploy models or assign access to other people.

The technology behind RBAC and managed identities

RBAC controls who can do what

Azure RBAC is Microsoft Azure’s permission system. A role contains a set of allowed actions, while a scope defines where those actions apply.

Scopes can include an entire subscription, a resource group, a Foundry resource or an individual project. Permissions assigned at a higher level are generally inherited by the resources below it.

Microsoft Foundry provides roles for different responsibilities. For example, Foundry User supports normal development activity, while Foundry Agent Consumer is designed for people or applications that only need to interact with an existing agent.

You may still see older names such as Azure AI User while Microsoft completes its role-name changes. The important point is to confirm the role’s permissions rather than relying on its label alone.

Managed identity replaces stored credentials

A managed identity is a Microsoft Entra ID identity created for an Azure resource. Azure manages the underlying credentials and token renewal, so your team does not need to place passwords, client secrets or access keys in source code.

When a Foundry project needs to access Azure Storage, Azure AI Search or another service, its managed identity requests a short-lived access token. The target service checks the identity’s RBAC permissions before allowing the request.

Our guide to using managed identity in production and Azure CLI locally explains the broader passwordless pattern. Across Foundry projects, the next step is making sure every identity receives the correct role at the narrowest practical scope.

A practical access model for Foundry projects

1. Separate people, projects and agents

Do not treat every identity as interchangeable. Your developers, project managed identity, deployment pipeline and individual agents may each require different access.

• People need access based on their job, preferably through Microsoft Entra security groups rather than individual assignments.
• The project managed identity needs access to the Foundry resource and approved supporting services.
• Deployment automation needs permission to create or update resources, but should not retain permanent administrator access.
• Agent identities need only the permissions required for the tools and business systems they call.

This separation improves auditability. When an unusual action occurs, your security team can identify whether it came from a person, a project, a deployment process or an agent.

2. Make the project your normal access boundary

Each Foundry project should represent a clear workload, team or environment. Development, testing and production should not share one large project simply because it is easier to set up.

Assigning Foundry User to a development group at the individual project scope limits what that team can reach. Granting the same role across the entire Foundry resource may unintentionally provide access to other projects.

There will be exceptions. Some older Foundry tools still require permissions at the parent resource level, so test the complete workload before finalising your access design.

The business outcome is containment. A mistake or compromised account in one project is less likely to affect every AI workload in the organisation.

3. Grant data access to the project identity

The project identity needs separate runtime permissions for the services it uses. For example, an agent that reads documents from an Azure Storage container may need Storage Blob Data Reader, while a process that writes files may require Storage Blob Data Contributor.

Azure AI Search has similar distinctions between reading an index and creating or updating one. Standard agent deployments using your own Storage, Search and Cosmos DB services will require roles on each supporting resource.

A basic Azure CLI pattern looks like this:

# Grant the project identity access to its Foundry resource
az role assignment create \
 --assignee-object-id "$PROJECT_MI_OBJECT_ID" \
 --assignee-principal-type ServicePrincipal \
 --role "Foundry User" \
 --scope "$FOUNDRY_RESOURCE_ID"

# Allow the project to read and write approved blob data
az role assignment create \
 --assignee-object-id "$PROJECT_MI_OBJECT_ID" \
 --assignee-principal-type ServicePrincipal \
 --role "Storage Blob Data Contributor" \
 --scope "$PROJECT_STORAGE_ID"

# Give the development team access only to this project
az role assignment create \
 --assignee-object-id "$DEVELOPER_GROUP_OBJECT_ID" \
 --assignee-principal-type Group \
 --role "Foundry User" \
 --scope "$FOUNDRY_PROJECT_ID"

Replace the example roles with the minimum permissions your workload requires. A query-only application should not receive write access just because Contributor removes a permission error.

4. Remove keys from production workflows

API keys are convenient during early testing, but possession of a key commonly grants broad access without identifying the individual user. Keys can also be copied into scripts, emails, configuration files and developer laptops.

Use Microsoft Entra ID authentication and managed identities for production wherever the target service supports them. Store unavoidable third-party credentials in Azure Key Vault, which securely stores sensitive information, and allow only the required workload identity to retrieve them.

This becomes especially important when agents connect to external services. Our articles on connecting Foundry agents to external A2A endpoints and connecting agents to business systems with MCP and OpenAPI cover those integration boundaries in more detail.

5. Automate assignments and review them regularly

Manual role assignments are difficult to reproduce and easy to forget. Define projects, identities and role assignments through Bicep, Terraform or another approved infrastructure deployment process.

Record four items for every assignment: the identity, required action, target resource and scope. If the business owner cannot explain why an assignment exists, it should be investigated.

# Review direct and inherited assignments for a project identity
az role assignment list \
 --assignee "$PROJECT_MI_OBJECT_ID" \
 --all \
 --include-inherited \
 --output table

Review production access quarterly and when people change roles. This supports the Essential Eight, the Australian government’s cybersecurity framework, particularly its focus on restricting administrative privileges and controlling access to sensitive systems.

What this looks like in a growing business

Consider a 200-person professional services company running separate Foundry projects for document review, customer support and internal HR assistance. Initially, every developer is given broad Contributor access and the projects share one storage account.

Under a safer model, developers receive project-level access through security groups. Each project identity receives access only to its own storage containers, search indexes and approved business systems.

The HR agent cannot retrieve customer-support records. The customer agent cannot open employee documents. Deployment administrators retain elevated access only when needed, while normal users can interact with agents without being able to modify them.

The result is not simply better security. Troubleshooting is faster, access reviews are clearer, employee changes are easier to manage, and the organisation has stronger evidence for customers, auditors and cyber insurers.

Start with an access map before adding more agents

RBAC and managed identities are most effective when designed before dozens of projects exist. Start by mapping each project’s owners, users, runtime identity, data sources and external connections.

Then remove shared credentials, move assignments to the lowest practical scope and test both permitted and blocked actions. A successful security test should prove not only that the agent works, but also that it cannot reach data outside its responsibilities.

CloudProInc combines more than 20 years of enterprise IT experience with hands-on Microsoft Foundry, Azure and cybersecurity work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations turn access-control theory into practical environments that teams can actually operate.

If you are unsure whether your Foundry projects have accumulated excessive access, shared keys or unclear identities, we are happy to review the current setup and identify the highest-priority risks — no strings attached.