Updated from my May 2025 post, “Leveraging Hubs and Projects in Azure AI Foundry.”

When I first wrote about organizing work in what was then Azure AI Foundry, the structure was hubs and projects. The platform is now Microsoft Foundry, and the model is simpler. As described in the Microsoft Foundry architecture documentation, a Foundry resource sits at the top and handles governance. Projects sit inside it and give teams their own space to build. Connected Azure services supply storage, search, and secrets management.

The goal from my original post still holds: centralize the shared setup and give each team a focused place to work. The pieces that do it have changed.

The Foundry Resource: Governance in One Place

The Foundry resource is the top-level Azure resource. This is where you manage networking, security, connections, and model deployments. In Azure it’s a Microsoft.CognitiveServices/accounts resource of kind AIServices, and it brings agents, evaluations, Azure OpenAI, Speech, Vision, Language, and Content Understanding together under one resource.

Because it shares the Microsoft.CognitiveServices resource provider namespace with Azure OpenAI and the other Foundry Tools, it uses the same management APIs, similar Azure RBAC actions, the same networking configuration, and the same Azure Policy aliases. That makes upgrading from Azure OpenAI straightforward: your existing custom policies and RBAC continue to apply.

For platform and security teams, this is the control point. You set the guardrails once, and every project inside the resource works within them. If you’re planning this across an organization, Microsoft’s Foundry rollout guidance is a good companion read.

Projects: Focused Development Spaces

A Foundry project is a subresource of the Foundry resource (Microsoft.CognitiveServices/accounts/projects). It serves as the development boundary where a team builds and evaluates a specific use case.

The main benefit is speed. Projects reuse the resource’s model deployments and connections, so a new team can start prototyping in an environment that’s already configured, without waiting on IT for each new setup. Project assets such as files, agents, and evaluations are scoped to the project, which keeps work separated by use case without creating extra Azure resources.

Developers work against a single project endpoint in this format:

https://<resource-name>.services.ai.azure.com/api/projects/<project-name>

The Foundry SDK exposes the project APIs through that endpoint, and higher-level frameworks build on top of it. If you work in an editor, the Foundry Toolkit for Visual Studio Code lets you browse projects, deploy models, and test agents without leaving VS Code.

In my original post, I gave examples of project work using Custom Vision, Document Intelligence, and Translator. A modern version of that list would include a customer-support agent in one project, a document-processing workflow using Content Understanding in another, and an evaluation workspace comparing model candidates in a third, all sharing the same model deployments and governance.

Plan around API scope. Most new APIs are available at the project level. Some capabilities that came from the original Azure OpenAI, Speech, Vision, and Language services are available only at the Foundry resource level. Translator is one example. Check which scope each workload needs before you design your layout.

Connected Resources: Separate Boundaries

Storage, Key Vault, and Azure AI Search connect to the Foundry resource, but they remain independent Azure resources with their own governance. You manage their networking, access policies, and compliance settings separately.

You also have more choice here than before:

• Storage. By default, Foundry uses Microsoft-managed, logically separated storage for file uploads in scenarios like OpenAI models and agents. You can bring your own storage accounts so tools like evaluations and batch processing read from and write to them.
• Agent state. With the basic agent setup, threads, messages, and files live in Microsoft-managed storage. With the standard setup, you bring your own Azure resources for all customer data, and that data is isolated by project.
• Secrets. Connection secrets go into a managed Key Vault by default. If you prefer to manage them yourself, one Key Vault connection on the Foundry resource covers secrets for the resource and all its projects.
• Encryption. Data is encrypted at rest with Microsoft-managed keys by default. You can switch to customer-managed keys if your compliance requirements call for it.

Security Through Separation of Concerns

Foundry separates management operations from development operations, and role-based access control for Microsoft Foundry follows the same split. Control-plane actions, such as creating deployments and projects, are distinct from data-plane actions, such as building agents, running evaluations, and uploading files. You can assign roles, including managed identities, at either the resource or the project scope.

A good least-privilege starting point is to grant Foundry User at the resource scope to each developer and to each project’s managed identity. Note that Microsoft recently renamed these roles. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager used to be named “Azure AI User,” “Azure AI Owner,” and so on. The role IDs and permissions didn’t change.

Networking, Monitoring, and Isolation

• Networking. For agents that reach into private systems, you can bring your own VNet with a delegated subnet for full control, or use a managed virtual network for a simpler setup with fewer customization options. Some fully private configurations must be set up through the SDK or CLI rather than the portal. See How to configure a private link for Foundry.
• Monitoring. Azure Monitor splits metrics by scope. Token usage, latency, request counts, and error rates are reported at the resource level. Evaluation outcomes, agent invocations, and file activity are reported at the project level.
• Tenant isolation. Each Foundry resource’s workloads run in a logically isolated environment, and customer code doesn’t share runtime containers with other tenants.
• Guardrails. Content safety runs inline with model and agent requests and can be configured per deployment. See the guardrails and controls overview.

How Many Resources and Projects?

A few rules of thumb from the documentation:

• Single developer exploring: one Foundry resource with one project is the recommended default.
• Multiple teams: one resource with multiple projects gives each team isolation while sharing deployments and central governance.
• Multi-region needs: Foundry doesn’t fail over across regions automatically, so deploy separate Foundry resources in each region and handle routing at the application layer. Your choice of deployment type (global, data zone, or regional) also determines where inference data is processed.
• Completions only: if you don’t need agents or evaluations, a standalone Azure OpenAI resource might be enough.

Before you provision, check feature availability across regions and review Azure OpenAI quotas and limits and Agent Service limits.

Getting Started

The quickest route is the Foundry portal. As covered in Create a project, creating a project in the portal also creates the Foundry resource for you. Starting in a new resource group makes it easy to manage everything together. If you prefer the command line, Azure CLI 2.80.0 or later includes the az cognitiveservices account project commands. The quickstart for setting up Foundry resources walks through creating a project, deploying a model, and granting team access.

The Takeaway

The two-level idea from my original post is still the right way to think about Foundry: shared governance at the top and focused development below. What’s changed is that a single Foundry resource now covers models, agents, evaluations, and Foundry Tools, and projects give teams a ready-to-use space inside it. IT controls the resource, developers own their projects, and connected services stay under their own governance.

Further Reading

• What is Microsoft Foundry?
• Microsoft Foundry architecture
• Foundry rollout across your organization
• Create a project
• Quickstart: Set up Microsoft Foundry resources
• Role-based access control for Microsoft Foundry
• Get started with Microsoft Foundry SDKs and endpoints
• Microsoft Foundry documentation home