Secure Azure AI Landing Zone for Microsoft Foundry and Azure OpenAI

An AI landing zone is Microsoft's term for an application landing zone built for AI workloads: the Foundry resource, model deployments, search index, storage, secrets and gateway, wired for private networking, identity-based access, guardrails, logging and cost control, so that every AI app lands on the same governed foundation instead of its own copy. It sits inside your platform landing zone if you have one — inheriting management groups, policy, hub connectivity and DNS — and this service is scoped to align to yours. If you have no platform landing zone, we build the AI platform as a self-contained workload spoke and say so in the design record; the enterprise-scale platform itself is a separate service.

Microsoft renamed Azure AI Foundry to Microsoft Foundry at Ignite in November 2025, and the new name became official in Microsoft's Product Terms in January 2026. Azure OpenAI is now sold as 'Azure OpenAI in Microsoft Foundry Models' — the OpenAI models are one publisher in a catalog that also carries Anthropic, Meta, Mistral, DeepSeek, xAI, Black Forest Labs and Microsoft models. The current resource model is a Foundry resource with projects as child resources; hub-based projects are the 'classic' model and Microsoft delivers new agent and model capabilities only to Foundry projects. We use the 2026 names on this page and build on the current resource model.

Usually not. Microsoft supports upgrading an Azure OpenAI resource in place to a Foundry resource, preserving its name, endpoint, API keys, network configuration, tags and existing state such as fine-tuning jobs — so your apps keep working while the resource gains the Foundry catalog, agent service and Foundry API. Two cautions we handle in the design: broad role assignments or policies that were written for 'OpenAI only' may suddenly grant access to every Foundry feature after the upgrade, so we review them first; and network injection for agents can only be set at creation, so agent workloads that need full isolation may still need a new, network-injected Foundry resource alongside the upgraded one.

Public network access is disabled on Foundry, AI Search, Storage, Key Vault and Cosmos DB, and each is reachable only through a private endpoint in your virtual network, with private DNS zones so the normal service names resolve to private addresses. Where you choose the bring-your-own virtual network option, the Foundry agent client is injected into a subnet you delegate, so agent egress also stays inside your network and your firewall rules. The reference chat app is published internally behind a private endpoint and Entra sign-in. If you later need internet-facing exposure, that is an Application Gateway with WAF in front of the app, quoted separately — the models and the index never get a public front door.

Not if the index is built the way we build it. Azure AI Search can store each document's permissions as metadata at indexing time and evaluate them against the caller's Microsoft Entra identity at query time, so a user's results — and therefore the model's citations — contain only documents they are allowed to read. For SharePoint in Microsoft 365 and for Blob or Data Lake storage this uses Microsoft's document-level access control, which is in preview at the time of writing and has limits we state plainly on this page; where it does not fit we implement the generally available security-filter pattern, in which the app passes the user's group memberships as a filter. We prove it with two of your users who hold different permissions asking the same question, and the runbook records how the permission metadata is refreshed.

Any model in the Foundry catalog that is available in your region and fits your data-residency decision; the 'From' scope includes up to two deployments, typically a chat model and an embedding model. Governance comes from Azure Policy: Microsoft ships generally available built-in definitions that restrict deployments to an approved list of models or publishers, and to eligibility rules such as 'sold directly by Azure' and 'not in preview'. We assign them at the scope you choose, so the Deploy button is disabled with a clear reason for anything off the list — and the same policies constrain model router, which only routes to models that satisfy them.

Per Microsoft's documented data-privacy commitments for its Azure-hosted AI services, your prompts, retrieval data and outputs are not used to train Microsoft's or OpenAI's foundation models; your compliance team should read the current terms for your own requirements. Where processing happens depends on the deployment type — Global Standard, Data Zone, regional Standard or Provisioned differ in the geography that serves the request — so we record that choice per model in the design record rather than defaulting to 'global'. Your documents, index, agent state and logs stay in the Storage, AI Search, Cosmos DB and Log Analytics resources in your own subscription and region.

The 'From' fee covers the design record, the infrastructure code, one Foundry resource and one project, up to two model deployments, the private networking and identity model, guardrails and the approved-models policy, logging and budgets, the API Management policy set where an instance exists, one AI Search index from one data source, the reference chat app, validation and handover — in about four weeks. It goes up with additional projects, deployments, indexes or data sources, a second reference app, provisioned-throughput sizing, public exposure through Application Gateway, or a platform team whose peering, DNS and policy processes need extra rounds. Whatever the number, it is quoted in writing before work begins and you pay after you approve delivery. Azure consumption is separate and yours.

About four weeks: design in week 1, the platform deployed as code across weeks 1–2, guardrails and gateway in weeks 2–3, the index and reference app in week 3, validation and handover in week 4. The usual schedule risks are model quota in the chosen region, platform-team lead times on peering and private DNS, and the SharePoint application permissions the indexer needs; we file the quota request and the permission requests at kickoff for exactly that reason.

No — the platform is complete without it: private endpoints, managed identities, policy, logging and budgets do not depend on a gateway. What API Management adds is per-application control: each app gets its own subscription key, token-per-minute limit and usage metric, prompts and completions can be logged centrally, and traffic can be load-balanced and failed over across deployments. If you already run APIM we configure that policy set as part of this service; if you do not, our APIM implementation service deploys it and this service configures the AI policies on it. For one or two applications, budgets and per-deployment quota are often enough to start.

The platform's running cost is Microsoft's, billed to your subscription: model tokens on the deployment types you chose, the AI Search tier and any replicas, one private endpoint per service, Cosmos DB and Storage for agent and index data, Key Vault, the APIM tier if used, Log Analytics ingestion and retention, and the reference app's hosting. We do not publish a number because it depends on your choices and usage; what we do is set budgets with alerts at the thresholds you pick, separate the cost view by component, and pick the smallest tiers that meet the design so the first month's bill is a real number you can scale from.

You do, entirely. The infrastructure code lives in a repository you own, every resource sits in your subscription, and the reference app is yours to copy or discard. There is no IT Partner component, agent or licence in the path. Our standing policy is no lock-in in either direction — you can stop using our services at any point with only previously approved invoices outstanding — and the code is written so your own engineers, or another partner, can run it.

The engagement ends with your teams able to add a model deployment, a project, an index or an application inside the guardrails, using the runbook. Production agents are built by our Foundry or Copilot Studio development services, or by your developers; the platform is run by your cloud team, or by IT Partner under a separate operations agreement — Managed AI Agent Operations covers the agents, and platform monitoring and maintenance are optional add-ons. Organizations that buy their Microsoft licensing through IT Partner already have unlimited break-fix support during business hours included.

Owner or equivalent on the target subscription for the duration of the deployment, Network Contributor on the virtual network where the private endpoints land, Private DNS Zone Contributor where the zones live, and a tenant administrator to create the app registrations and grant consents — all as time-bound, least-privilege access that you approve, following the same published policy we apply to Microsoft 365 work. We put the exact roles and the removal date in the design record.

The accelerator is Microsoft's reference implementation and it is labeled preview, partly because it may include preview services to show the latest features. We use it as the starting point for your code, not as a product you install: every resource, SKU and configuration in your deployment is pinned to generally available services unless your design record names a preview dependency — the document-level permission ingestion in AI Search is the usual one — together with the generally available fallback. That is what makes the result yours to run in production.