Microsoft Foundry provides native capabilities for building and operating AI applications and agents. As adoption expands across business units, organizations must still decide how teams share those capabilities, isolate workloads, enforce consistent policies, attribute costs, and assign operational ownership. Citadel is an opinionated reference architecture that brings Microsoft Foundry and complementary Azure services together to address these cross-team requirements. It builds on AI landing-zone foundations rather than replacing them. Its contribution is not another model runtime or agent service, but a structured approach to applying existing capabilities consistently across an enterprise. This article explains where Citadel fits, the architectural decisions it addresses, and how customers can begin adopting the approach within their Azure environments.
From AI Foundations to a Shared Operating Model
In my previous article, AI Azure Landing Zone: Shared Capabilities and Models to Enable AI as a Platform, I explored how organizations establish secure, governed environments for AI workloads. Building on that foundation requires aligning three complementary responsibilities.
1. Establish the deployment foundation
Azure landing zones establish the subscription, identity, networking, and governance foundations. AI landing-zone implementations extend these foundations with architectures for Foundry-based applications, agents, and shared AI gateways.
2.Use native AI platform capabilities
Microsoft Foundry provides model and agent services alongside capabilities for evaluation, observability, security, and governance. These are native platform capabilities—not capabilities introduced by Citadel.
3.Standardise how teams deploy and operate AI
As multiple teams adopt these services, enterprise-wide design decisions become essential:
- Which resources are shared or isolated?
- Where are access policies enforced?
- How is consumption attributed?
- Who owns onboarding, monitoring, and incident response?
Citadel brings an opinionated architectural approach to these decisions, connecting native capabilities with cross-team governance and operational practices.
These responsibilities coexist. A customer with an existing landing zone and Foundry deployment can assess Citadel’s patterns against its operational gaps rather than treating adoption as a replacement of the existing platform.
This is the role of Citadel AI Foundry:
Citadel connects landing-zone foundations, native AI services, and business applications through a shared enterprise operating model.What Is the Citadel Architecture?
Citadel is an opinionated reference architecture, documented in the Foundry Citadel Platform repository, for composing Microsoft Foundry and complementary Azure services into an enterprise AI operating model.
Its contribution is the architectural guidance connecting those services: where shared controls operate, how teams consume capabilities, and how responsibilities are divided between platform owners and application teams.
| Area | Native capabilities | Decisions addressed by the Citadel architecture |
|---|---|---|
| AI access | Model endpoints, agent services, and API Management gateway capabilities | Where to mediate access and apply consistent authentication, routing, and consumption policies. |
| Observability | Foundry tracing and evaluations, Azure Monitor, and Application Insights | How to combine application-level diagnostics with cross-team usage and operational visibility. |
| Identity | Microsoft Entra identity and access controls | How agent ownership, access, and lifecycle responsibilities are governed. |
| Security and data governance | Controls available through Azure services, Defender, and Purview | Where complementary protections apply and how they fit into the overall architecture. |
What Does a Customer Adopt?
Customers adopt selected patterns from the Citadel architecture guidance and implement them using native Azure services and the relevant implementation guidance. Adoption does not require replacing existing landing-zone or Foundry investments.
A practical starting sequence is:
- Assess the existing environment. Review current Foundry resources, identity, networking, and monitoring. Identify which foundations can be reused and where gaps remain. The AI Landing Zones repository provides reference implementations for these foundations.
- Choose one workload and one operational gap. For an HR assistant, the initial goal might be consistent model access or workload-level usage attribution. Record its data-access, isolation, and operational requirements before selecting additional components.
- Apply the relevant pattern and agree ownership. The platform team configures selected shared controls; the application team configures its assistant, tools, data permissions, and evaluations. Where a gateway is selected, use the AI gateway guidance and confirm which requests actually pass through it.
- Demonstrate the outcome before expanding. Confirm that unauthorized access is blocked, usage can be attributed to the workload, failures reach the responsible team, and response quality meets the agreed criteria. Document the onboarding steps before applying the pattern to another team.
Assess prerequisites, feature availability, preview status, and operating costs for each selected service. Citadel provides the architectural approach; the customer remains responsible for configuring and operating the resulting environment.
How AI Landing Zones, Microsoft Foundry, and Citadel Work Together
These elements address complementary responsibilities. Their scopes overlap, so they should not be compared as competing products or mutually exclusive feature sets.
| Element | Primary role | Contribution to the enterprise architecture |
|---|---|---|
| AI landing zones | Establish deployment foundations for AI workloads. | Reference architectures and infrastructure implementations covering networking, identity, security, governance, and supporting AI services. |
| Microsoft Foundry and complementary Azure services | Provide the underlying AI and platform capabilities. | Models, agents, retrieval, evaluations, observability, access controls, and other services selected for the workload. |
| Citadel architecture | Guide how those capabilities are composed and operated across teams. | Architectural patterns for shared access, policy application, agent ownership, cross-team visibility, and operational responsibilities. |
An organization can retain its existing landing-zone and Foundry investments while adopting selected Citadel patterns to address specific operational gaps.
The architectural decision is not “landing zone or Citadel?”, but “which additional patterns does our operating model require?”
Citadel Reference Architecture: Shared Governance and Workload Environments
Citadel separates shared platform responsibilities from application-team responsibilities. A shared governance hub provides selected gateway and discovery capabilities, while workload environments contain applications, agents, and their data dependencies.
The architecture brings together four governance concerns: the governance hub, AI control plane, agent identity, and security fabric. These are complementary responsibilities—not four sequential stages through which every request passes. The diagram below shows how they relate to the workload components.
Illustrative Citadel architecture showing shared governance and application-team workloads. Arrows show selected runtime paths; the panels below describe shared governance responsibilities. Gateway policies apply only to requests routed through the gateway.For the HR assistant example, the platform team establishes shared controls: approved model deployments, gateway policies for requests routed through the gateway, identity requirements, and telemetry destinations. The application team configures its assistant, approved tools, and workload-specific data permissions. During requests, these configured Azure services enforce the agreed controls—there is no separate Citadel runtime. The same onboarding and operating patterns can then be reused by other teams without granting them access to HR data.
Workload Component 1: Foundry Resource and Project Management
Microsoft Foundry provides a native resource hierarchy for organizing AI workloads. The Foundry resource is the management scope for settings such as networking, security, model deployments, and connections. Projects provide development and access boundaries for teams working with agents, files, evaluations, and related assets.
Citadel’s architectural contribution is to establish how these native scopes are used consistently across the organization.
For example, HR and Finance may use separate projects within a shared Foundry resource when their requirements permit shared networking and security settings. The platform team manages the shared setup, while each business team develops its own AI assistant.
A shared Foundry resource supporting separate team projects, approved service connections, and monitoring. Citadel standardises how this native arrangement is configured and operated.| Design area | Native capability | Decision to standardize |
|---|---|---|
| Resource organization | Foundry resources and projects | How resources and projects map to teams, environments, and isolation requirements. |
| Access control | Microsoft Entra identities, managed identities, and Azure RBAC | Who provisions resources, who develops within projects, and which identities access dependent services. |
| Connectivity | Networking configuration and service connections | Which dependencies are approved and how their access and networking are configured. |
| Operational visibility | Resource/project monitoring and diagnostic logging | Which telemetry is collected, where it is retained, and who responds to operational issues. |
Projects should not be treated as independent network-isolation boundaries. Workloads requiring different resource-level networking or security configurations may need separate Foundry resources. Connected services—including Azure AI Search, Azure Storage, and Azure Key Vault—retain their own access controls and governance boundaries.
Workload Component 2: Data, Retrieval, and Grounding
Enterprise AI applications often need information beyond a model’s pretrained knowledge. Retrieval-augmented generation (RAG) addresses this by retrieving relevant enterprise content and supplying it to the model as context when generating a response.
Azure provides native capabilities for storing source data, preparing content, generating embeddings, and retrieving information. The combination depends on the workload’s data sources, access requirements, freshness needs, and retrieval approach.
Citadel’s architectural contribution is to standardize how these capabilities are selected, connected, secured, and operated across teams.
| Design area | Native capability or implementation option | Decision to standardize |
|---|---|---|
| Data sources | Azure Storage, Azure SQL, Azure Cosmos DB, and other enterprise systems | Which sources are approved, who owns the data, and which workloads may access it. |
| Content preparation | Azure AI Search indexers and skillsets, or custom ingestion pipelines | How content is extracted, divided into chunks, refreshed, and removed when deleted at source. |
| Embeddings | Azure OpenAI embedding models, where vector retrieval is used | Which embedding models are approved and how changes trigger re-indexing. |
| Retrieval | Azure AI Search keyword, vector, and hybrid search | How indexes are organized, access is enforced, and retrieval quality is evaluated. |
| Application state and memory, where required | Azure Cosmos DB or another suitable store | What is retained, for how long, and how users’ and workloads’ data remain separated. |
For example, an HR assistant can retrieve relevant policy passages from an approved search index and supply them to the model alongside the employee’s question. The retrieval path must ensure that only content the employee is authorized to access is returned.
Source systems remain the systems of record; a search index provides a retrieval-ready representation of selected content. Copying or indexing data must not be assumed to preserve its original permissions automatically.
Conversation history and agent memory are separate concerns from grounding data. They are not mandatory components of every RAG implementation and require their own access and retention decisions.
Example RAG flow: approved content is prepared for retrieval, and relevant passages accompany the user’s question to ground the model’s answer. Retrieval permissions and source attribution require explicit configuration.
Workload Component 3: Model Selection, Deployment, and Runtime
Microsoft Foundry provides a model catalogue and deployment options for running supported models through inference endpoints. The catalogue includes models from Microsoft, Azure OpenAI, and other providers. Available capabilities, hosting arrangements, and commercial terms vary by model and deployment option.
Citadel’s architectural contribution is to standardize which models workloads may use, how they are deployed and accessed, and how performance, cost, and lifecycle changes are managed. A model’s availability in the catalogue does not automatically make it approved for enterprise use.
| Design area | Native capability or implementation option | Decision to standardize |
|---|---|---|
| Model selection | Foundry model catalogue and evaluation tools | Which models meet the workload’s quality, safety, licensing, and cost requirements. |
| Deployment and capacity | Supported deployment types, quotas, and capacity options | Which processing locations and capacity arrangements meet compliance, latency, and throughput needs. |
| Runtime access | Inference endpoints and supported authentication and networking controls | Which applications and identities may call each deployment, and through which approved paths. |
| Safety and monitoring | Supported content filters, metrics, and diagnostic capabilities | Which controls apply and who responds to errors, safety issues, performance degradation, and unexpected usage. |
| Customization, where required | Fine-tuning for supported models | Whether fine-tuning is justified, which training data is approved, and how the resulting model is evaluated. |
| Model lifecycle | Model versions and deployment management | Who approves upgrades, evaluates regressions, and prepares applications for model retirement. |
For example, an HR assistant can call an approved model deployment with the employee’s question and retrieved policy passages. Before changing the model or version, the team evaluates representative questions to compare answer quality, safety, response time, and cost.
Not every model supports the same fine-tuning, networking, filtering, or capacity features. Deployment choices must also satisfy data-processing requirements: the location of a Foundry resource alone does not establish where inference requests are processed.
An HR assistant uses an approved Foundry model to answer an employee’s question. Solid arrows show requests and responses; dotted arrows show deployment configuration and monitoring.
Workload Component 4: Agents and Orchestration
Microsoft Foundry Agent Service provides native capabilities for building and operating agents that coordinate models, retrieval, and tools. Supported capabilities depend on the agent type and hosting approach.
Citadel standardizes the operating rules around these capabilities: which tools agents may use, what permissions they receive, and how execution, state, and failures are managed.
| Design area | Native capability or implementation option | Decision to standardize |
|---|---|---|
| Agent execution | Foundry Agent Service and supported frameworks | Agent design, approved models, execution limits, and failure handling. |
| Tool integration | Retrieval tools, functions, APIs, and supported MCP integrations | Approved tools, authentication, permissions, and approvals for consequential actions. |
| Conversation state | Conversation storage and optional memory implementations | What is retained, how users’ data is separated, and when it is deleted. |
| Operational visibility | Tracing, metrics, and evaluations | How tool failures, response quality, latency, and cost are monitored. |
Multi-agent orchestration and persistent memory are optional design choices—not requirements for every assistant. The example below is read-only; submitting or changing a leave request would require a separately defined authorization and approval path.
An HR agent coordinates approved policy-search and HR-system tools, then combines their results into an answer. Each tool must enforce the requesting employee’s data permissions.
Workload Component 5: Security, Compliance, and Responsible AI
Security and responsible AI apply across every workload component—not as a final step added after an answer is generated. Microsoft provides the underlying identity, networking, data-protection, safety, and monitoring capabilities.
Citadel standardizes where these controls apply, how they are configured, and who owns exceptions, incident response, and compliance evidence.
| Design area | Native capability or implementation option | Decision to standardize |
|---|---|---|
| Identity and access | Microsoft Entra ID, Azure RBAC, and supported agent or managed identities | Which people and services may access each application, model, tool, and data source. |
| Data and connections | Service permissions, Key Vault, and supported private-networking controls | Permitted data access, secret handling, network paths, and retention requirements. |
| AI safeguards | Azure AI Content Safety, supported content filters, and evaluations | Which risks are assessed, what is blocked, and when human review is required. |
| Monitoring and evidence | Azure Monitor, Log Analytics, and Azure Activity Log | Which events are collected, how sensitive information is protected, and who investigates issues. |
Private-networking options depend on the selected services and deployment modes. Azure Activity Log records management operations; application and tool-call tracing require separate configuration. Content filters do not guarantee factual correctness, and deploying security services alone does not demonstrate compliance.
Identity, data protection, AI safeguards, and operational monitoring apply across the assistant and its connections. Dotted lines represent ongoing controls—not sequential request-processing steps.Citadel in Practice: A Day-in-the-Life Request Flow
An employee asks, “Explain my leave options.” This read-only example brings the preceding components together: access checks, permitted data retrieval, agent orchestration, an approved model, response safeguards, and operational observation.
Access must also be enforced at each data source, tool, and model endpoint; passing the initial access check does not grant unrestricted downstream permissions.
An illustrative successful request combines permitted enterprise information with an approved model and configured response safeguards. Observation spans the journey; failed access or response checks block or redirect the request rather than following the successful path.
Citadel AI Foundry Repo Link: https://github.com/Azure-Samples/foundry-citadel-platform
Microsoft