Foundry architecture and rollout

Microsoft Foundry stacks your AI work in layers: a top-level Foundry resource for shared governance, projects where teams build and test, and connected Azure services for storage, search, and secrets. Getting that layout right early keeps teams from stepping on each other's quotas, leaking access, or picking a deployment shape that compliance will reject later.

Concept 8 showed how to measure an agent before you ship it. This concept is about where that agent lives in Azure and how you introduce Foundry across teams without security gaps or runaway cost. Use the resource-and-project model when you want one place for model access, agent hosting, and evaluation; when several teams need isolated workspaces but shared deployments; when policy requires private networking, customer-managed encryption, or scoped permissions at both resource and project levels; or when you are moving from a standalone Azure OpenAI resource and want to keep existing policies while adding agents and evaluations.

• A single developer exploring Foundry can start with one Foundry resource and one project—the recommended default for that case.
• If you only need Azure OpenAI completions without agent hosting or evaluation, a standalone Azure OpenAI resource might still be enough.
• Before anyone provisions, agree which Foundry features and APIs each workload needs, because not every API supports the same authentication, storage encryption, or project-level isolation.

The Foundry resource is the top-level Azure account object where IT-style settings live: networking, security, model deployments, and connections to other services. A Foundry project is the workspace inside that resource where a team prototypes agents, runs evaluations, uploads files, and reuses deployments without repeating setup. Project assets—files, agents, evaluations, and related artifacts—stay scoped to that project.

Connected resources such as Azure Storage, Azure Key Vault, and Azure AI Search are separate Azure services. The Foundry resource references them through connections, but each keeps its own governance boundary. You manage networking, access policies, and compliance for those services on their own, not only inside Foundry.

• Most newer agent-centric APIs are available at project scope, so day-to-day builder work usually targets a project.
• Some older Foundry Tools capabilities remain at the Foundry resource level only—for example, the Translator API is available from the resource level, not from a project. Plan structure around the API scopes your apps call.
• Connections created on the parent Foundry resource are visible to all projects under it; connections created on a project stay scoped to that project when you want tighter isolation.

After you define nonnegotiable boundaries—business units, data domains, environment tiers, and who owns security incidents—pick how many Foundry resources you need per environment. Microsoft’s rollout guidance treats production as isolation by default and exploration as shared by default unless compliance forces separation.

Agent capabilities—including agents, responses, evaluations, datasets, indexes, files, and playground assets—fit well in project-per-use-case layouts inside a shared resource. If each team must fine-tune independently, plan separate Foundry resources, because fine-tune training is tied to the default project and fine-tuned deployments are shared across projects within a resource. If strict isolation is required for Translator or similar resource-scoped APIs, separate resources are the safer pattern.

Foundry separates who can change the platform from who can use it to build and run agents. Admin-style actions include creating projects, managing deployments, and wiring connections. Builder-style actions include chatting in the playground, uploading files, running evaluations, and invoking agents. Azure role assignments can target the Foundry resource, an individual project, or both, so you can keep permissions narrow.

• Map real people and automation accounts to the smallest role that still lets them work. Common onboarding assigns Foundry User to developer accounts at the Foundry resource scope; you can also scope roles per project when teams must not see each other's assets.
• Subscription Owner or Contributor alone does not cover every builder scenario—a person might manage Azure resources yet still need additional Foundry roles to chat with an agent in the portal.
• Role names were recently renamed (for example, Azure AI User to Foundry User); role IDs and core permissions stayed the same while the rename rolls out.
• Prefer Microsoft Entra ID and role-based access for people and services; use API keys only where coarse access is acceptable.

In the Microsoft Foundry portal, administrators use the Manage toolbar button on the current project to review Project details, Resource details, the Users tab, Connected resources, and the Projects tab on the parent resource. Switch projects with the project name dropdown in the upper left before you change settings for a different team.

Model deployments are grouped by where inference data may be processed: global (cross-region), data zone (within a defined boundary such as the US or EU), or regional (a single Azure region). That choice drives compliance more than it drives headline price. Foundry stores data at rest in the designated Azure geography; prompts and completions follow the deployment type at inference time.

Pick the strictest scope your data rules allow, then confirm the model, deployment type, Agents support, and evaluations support in your target region before you commit. Foundry does not provide automatic cross-region failover; if you need multi-region availability, deploy separate Foundry resources per region and handle routing and data sync in your application. Review quotas and rate limits for models and agents before production traffic lands.

A structured rollout moves workloads from shared exploration into stronger isolation as they prove value. Many organizations keep a co-located Foundry resource for innovation—with limited capacity and pre-connected data and tools—while only mature use cases earn dedicated dev/test or production resources with private networking and customer-managed keys where policy requires them.

• Set exploration policy to colocation for speed unless compliance demands isolation; set production policy to isolation unless a documented exception allows sharing.
• Decide networking per environment: managed virtual network for simpler secure setup, or bring-your-own virtual network when you need full control and custom routing; validate private DNS and private endpoint flows before go-live.
• Choose Microsoft-managed encryption or customer-managed keys; if you use customer-managed keys, deploy Key Vault in the same region as the Foundry resource with soft delete and purge protection enabled.
• Define who may create projects, deploy models, and attach external tools; set budgets and token-based limits before shared environments absorb production load.
• Before rollout, validate region feature support, role scopes at resource and project levels, network paths, encryption and Key Vault connections, and quota headroom.

Agents, evaluations, and batch jobs run on Microsoft-managed compute. When agents call external systems, you can use managed virtual network or inject into your own subnet for outbound isolation. Some fully private setups require the SDK or CLI instead of the portal—for example, when private endpoints block all public access.

Suppose the online shop from Concept 8 now has a evaluated support agent. The shop starts in a shared exploration Foundry resource: one project for the support team, reusing a central GPT deployment and a shared Azure AI Search index connection on the parent resource. Developers get Foundry User on that project only while IT keeps deployment creation on the resource.

• Inventory APIs: agent chat, evaluations, and file search at project scope; confirm no dependency on resource-only Tools APIs such as Translator.
• Pick a regional deployment type because return policies must stay in the chosen Azure region; verify the model and Agents feature in that region.
• Run pilots in the shared project until leadership funds production; then provision a separate Foundry resource for production with private link and customer-managed keys if policy requires them.
• Reconnect Storage and Key Vault as project-scoped connections so secrets and evaluation exports stay inside the production boundary.
• Set token limits and budget alerts on the production resource before the storefront sends live shopper traffic to the published agent endpoint.

• Assuming one Owner role on the subscription covers every portal action builders need.
• Sharing one production resource across unrelated data domains to save setup time.
• Choosing global deployments when legal already mandated a single region.
• Retrofitting private networking after agents already call public APIs from production.
• Skipping quota checks until throttling appears under peak holiday traffic.

You now have a picture of the Foundry resource, projects, connected services, topology choices, access patterns, deployment scopes, and staged rollout. Concept 10 goes deeper on models, deployments, and fine-tuning—the knobs you turn inside the resource once the shell fits your organization.

• Full hierarchy diagram, storage modes, networking models, and validation checklist. Microsoft Foundry architecture
• Enterprise rollout steps, capability matrix, security baseline, and Contoso sample topology. Foundry rollout across my organization
• Role names, scopes, and which combinations cover admin versus builder tasks. Role-based access control for Microsoft Foundry
• Deployment limits and rate limits to check before you finalize regions and models. Foundry Models quotas and limits