Using Citadel to Make Microsoft Foundry Governance Real

I have been experimenting with Microsoft’s Foundry Citadel Platform because AI governance gets vague very quickly.

It is easy to say that agents should use approved models, protect sensitive data, follow least privilege, log their actions, and stay inside a defined risk boundary. The harder question is where each rule is enforced. Is it an Azure Policy assignment, an identity role, an API gateway policy, a network route, a Foundry guardrail, a deployment check, or code inside the agent?

If the answer is “the agent prompt,” there probably is not a control yet.

Citadel is useful because it turns the discussion into architecture. It puts a central governance hub in front of models, tools, and agents, then gives workloads separate spoke environments where teams can build without owning the entire platform. Observability crosses both sides. Identity and the wider Microsoft security stack supply another set of controls around them.

That does not make Citadel a turnkey compliance product. It is an opinionated reference pattern assembled from Azure services, samples, templates, and guidance. Some features are still in preview. Some choices are intentionally left to the operator. The root Citadel repository is primarily the architectural map, while the deployable parts live in related projects.

That distinction matters. I am not testing whether a diagram looks complete. I am testing whether the pattern can produce enforceable boundaries, useful evidence, and a deployment path that people can actually operate.

First, a note about the name

Microsoft now calls the platform Microsoft Foundry. A lot of code, resource names, documentation paths, and conversations still say Azure AI Foundry. The current Foundry overview describes one place to deploy models, build and publish agents, register outside agents, connect tools, run evaluations, and monitor the resulting systems.

I use “Foundry” for the current product and “Azure AI Foundry” where that is still the name used by a template or resource.

This is more than a naming cleanup. Foundry is moving from a development workbench toward a control surface for AI assets that may run in several places. That includes models from different providers, agents hosted inside or outside Foundry, and tools exposed through MCP or ordinary APIs.

The governance problem therefore is not limited to one model endpoint. It includes:

• who can create and operate projects;
• which models may be deployed, in which regions, and at what capacity;
• which identities agents use;
• which data sources and tools projects can connect to;
• how traffic is authenticated, limited, inspected, and attributed;
• what is recorded in traces;
• who can read those traces;
• how an agent is disabled, its access revoked, and its state investigated.

Foundry supplies capabilities in many of these areas. Citadel tries to arrange them into a repeatable platform.

Citadel has two useful views of the same system

The Citadel material describes a broad governance stack in four layers:

1. Governance Hub: a runtime enforcement plane built around Azure API Management and a shared registry.
2. AI Control Plane: Foundry inventory, evaluations, tracing, compliance, and fleet operations.
3. Agent Identity: unique identity, ownership, access, and lifecycle controls.
4. Security Fabric: Microsoft Entra, Defender, Purview, Content Safety, and related services that protect the other layers.

Its technical guide describes the deployable shape a little differently. There is a central Citadel Governance Hub, or CGH, and one or more Citadel Agent Spokes, or CAS environments. Governance and security live mainly in the hub. Development happens mainly in the spokes. Observability and compliance span both.

These views are not contradictory. One describes governance responsibilities. The other describes where Azure resources are deployed.

I find the second view easier to reason about during implementation:

Area	Primary job	Typical components
Governance hub	Mediate shared access to models, tools, and agents	API Management, API Center, Foundry, Content Safety, Language service, Event Hub, Log Analytics, Application Insights, Cosmos DB
Agent spoke	Host one workload or a related set of agent workloads	Foundry account and project, Container Apps, AI Search, Storage, Cosmos DB, Key Vault, Container Registry, workload identity
Security fabric	Apply identity, data, threat, and infrastructure controls	Entra ID, Azure Policy, Defender, Purview, network controls, managed identities
Evidence path	Connect a request to policy decisions and effects	Gateway logs, OpenTelemetry traces, evaluations, platform diagnostics, alerts, deployment records

The hub and spoke split is a familiar cloud pattern, but the traffic is different. This hub is not only moving packets. It is mediating prompts, model responses, token consumption, tool requests, agent APIs, and potentially MCP traffic. Those payloads can contain both sensitive data and hostile instructions.

The Citadel repository is an umbrella, not the whole deployment

This was one of the most useful findings from reading the repositories instead of stopping at the architecture image.

The main Foundry Citadel repository explains the combined platform. It then points to two other bodies of work for implementation:

• the AI Gateway Labs for Azure API Management policies and patterns used by the central hub;
• the AI Landing Zones for the workload and Foundry spoke infrastructure.

The gateway repository contains hands-on examples for model routing, token rate limits, semantic caching, content safety, OAuth, MCP authorization, agent APIs, logging, tracing, and cost controls. The landing-zone project provides portal, Bicep, and Terraform paths for a production-oriented Azure environment.

That modularity is sensible. An organization may already have API Management, private DNS, a hub firewall, Log Analytics, or a container platform. Citadel should not require a second copy of every shared service.

It also means “deploy Citadel” is not one atomic action. The real work includes:

1. choosing the hub and spoke topology;
2. deciding which shared services to reuse;
3. deploying the workload landing zone;
4. configuring gateway policies;
5. onboarding models, tools, and agents;
6. assigning identities and roles at the right scope;
7. connecting telemetry and protecting it;
8. proving that the controls still work after deployment.

The one-click experience can provision resources. It cannot make those decisions on behalf of the platform owner.

The governance hub is a policy enforcement point

The central component is an AI gateway built on Azure API Management. Microsoft’s AI gateway documentation describes support for model APIs, remote MCP servers, A2A agent APIs, and self-hosted endpoints. APIM can authenticate callers, use managed identity to reach Azure services, apply content-safety checks, limit tokens and requests, balance model backends, cache responses, and emit telemetry.

This is where policy can move out of application prompts and into infrastructure.

An agent may be told to use only an approved model, but the gateway can reject every other model route. A team may be given a monthly token budget, and APIM can enforce quota by a named key or identity. An application may be expected to send ownership and cost-center metadata, and a gateway policy can require it before forwarding the request. A model endpoint can be removed or rotated without updating every client.

The gateway is also a useful choke point for tool and agent traffic. Microsoft currently documents MCP tool governance through an AI gateway as a preview capability. It can apply authentication, rate limits, IP restrictions, and audit logging to compatible MCP traffic.

There are limits to what a gateway can know. It sees the request that reaches it, not necessarily the complete intent that produced the request. It cannot determine whether a database lookup is appropriate merely because the JSON is well formed. It may not see a tool call that bypasses the governed route. It cannot repair excessive permission on the backend.

I treat the gateway as a strong enforcement point, not as the entire threat model.

The spoke is where isolation becomes expensive and useful

The Citadel Agent Spoke is based on the AI Landing Zone. Its default shape can include a Foundry account and project, model deployments, Container Apps, AI Search, Storage, Cosmos DB, Key Vault, Container Registry, Application Insights, Log Analytics, and managed identity.

Network isolation can add virtual networks, subnets, network security groups, private endpoints, private DNS zones, a firewall, NAT, Bastion, and a jumpbox. Public ingress can add Application Gateway with a web application firewall.

This is not a lightweight sandbox. It is a real application landing zone.

The benefit is separation. A workload can have its own identity, data stores, retrieval index, secrets, compute, network routes, telemetry, and lifecycle. A mistake in one project does not have to become shared infrastructure state. A high-risk workload can receive stricter controls without forcing every experiment into the same design.

The tradeoff is cost and operational load. Private endpoints need DNS. Egress rules need owners. A jumpbox needs maintenance. Logs need retention rules. Search and other provisioned services can create a meaningful idle cost before the first production request.

The landing-zone documentation has a particularly important warning in its deployed resource inventory: the standard Foundry Agent Service setup can provision a dedicated AI Search, Storage, and Cosmos DB data plane in addition to the workload’s own Search, Storage, and Cosmos resources.

That separation may be exactly what an agent workload needs. It may also surprise someone who expected a small test environment.

I want that decision to be explicit:

• Is the Foundry Agent Service required for this workload?
• Which stores belong to Foundry, and which belong to the application?
• Can an existing service be reused without weakening isolation?
• What is the minimum production shape?
• What can scale to zero in a development environment?
• Which services create a fixed cost even when the agent is idle?

Governance that nobody can afford will be bypassed. Cost architecture belongs in the security design.

Identity has to match the real scopes

Foundry’s role-based access control model distinguishes the Foundry resource, project, and individual agent scopes. Current built-in roles include Foundry Account Owner, Foundry Project Manager, Foundry User, and Foundry Agent Consumer.

That gives a platform team a reasonable starting split:

• account owners manage the Foundry resource, models, and shared connections;
• project managers create and operate projects;
• developers build inside a project;
• consumers invoke agent endpoints without receiving development access.

The built-in role name is only half the decision. Scope is the other half.

A developer who needs one project should not receive the same authority at the Foundry resource or subscription. A runtime agent that reads one index should not share an identity with the deployment pipeline. A person who can view an agent endpoint does not automatically need to view its raw traces. The service that creates role assignments should not also be the identity used by the running workload.

Citadel uses managed identities to reduce stored credentials, which is a good default. It does not remove the need to inventory permissions. A passwordless identity with broad rights is still broad.

For each agent, I want to be able to answer:

• Which principal represents the runtime?
• Which principal deploys it?
• Which permissions are inherited from a resource group or subscription?
• Which connections use shared authentication?
• Which access follows the user through delegated authorization?
• How quickly can the runtime identity be disabled?
• What breaks when it is disabled?

The last two questions are incident-response questions. They should be tested before an incident.

Connections are security boundaries

Foundry connections make external services available to projects. They are convenient because they can broker authentication to storage, search, databases, and other resources. They can also quietly enlarge a project’s reach.

A shared connection at the Foundry resource level can be appropriate for a common low-risk service. A sensitive data source should usually have a project-scoped connection and a narrowly scoped identity. User passthrough may be more appropriate where access must follow the requesting person.

This is one place where the hub and spoke diagram can hide risk. A line from “Foundry” to “data” does not show:

• whether the connection is shared or project-specific;
• whether it uses a key, service principal, managed identity, or user token;
• which operations the backend permits;
• whether the agent can choose arbitrary parameters;
• whether the route is private;
• whether data can leave through another tool.

The connection inventory needs those details. Otherwise, it is only a list of resource names.

Private networking reduces routes, not reasoning risk

Microsoft’s private-link guidance for Foundry covers private endpoints, network boundaries, DNS, and controlled outbound access. Citadel’s zero-trust deployment uses these patterns to keep Foundry and supporting services off public paths.

This is valuable. A service that cannot be reached from the public internet has fewer attack paths. An agent with no route to an arbitrary destination has fewer exfiltration options. Private DNS and egress control can make the intended service graph enforceable.

Private networking does not make the model trustworthy.

An injected instruction can still misuse an allowed internal tool. A compromised agent can still read data its identity is permitted to read. A dangerous request can still travel over a private endpoint. A permitted outbound messaging service can still become an exfiltration channel.

The goal is to combine network isolation with least agency:

• permit only required destinations;
• expose only required tool operations;
• validate tool parameters outside the model;
• separate read and write paths;
• require approval for high-impact actions;
• limit duration, volume, recursion, and spending;
• record the policy decision and resulting effect.

Network controls make harmful routes impossible. Agent controls reduce misuse of the routes that must remain.

Observability is evidence, and evidence can be sensitive

Citadel treats observability as a cross-cutting pillar. That is the right choice. A central gateway can show model usage, policy results, latency, tokens, callers, and backend selection. Agent tracing can show the internal chain from prompt to model to tool.

Microsoft Foundry tracing uses OpenTelemetry and stores data in Azure Monitor Application Insights. The tracing data guidance notes that traces can contain user prompts, model inputs and outputs, tool calls, intermediate steps, errors, token use, and other customer data. Tracing is off by default and must be explicitly enabled.

That creates two separate governance requirements.

First, the trace must be useful. I want a correlation ID to connect:

1. the original request;
2. the user and agent identities;
3. the approved goal;
4. retrieved context;
5. model and policy versions;
6. gateway decisions;
7. tool parameters;
8. human approvals;
9. downstream effects;
10. the final response.

Second, the trace store must be protected as sensitive data. Raw prompts and tool results may contain information that ordinary platform telemetry does not. Access to Application Insights and Log Analytics should not be granted simply because someone can use the Foundry project. Redaction, retention, protected tables, and tightly scoped monitoring roles belong in the design.

Logging everything without controlling who can read it is not observability. It is another data exposure.

Guardrails and policy need different jobs

Foundry guardrails can inspect user input, model output, and, for supported agents, tool calls and tool responses. Controls can look for content risks, prompt injection, and protected material.

Foundry can also create guardrail policies at a subscription or resource-group scope so model deployments have to meet minimum control settings. Azure Policy can restrict model deployments and other resource configurations. APIM policies can enforce runtime limits and routing.

These controls should reinforce one another, but they are not interchangeable.

Control	Good at	Not sufficient for
Azure Policy	Preventing disallowed resource and model configurations	Deciding whether one tool call matches a user’s intent
Foundry guardrail	Detecting supported content and prompt risks at defined intervention points	Backend authorization and complete prompt-injection prevention
API Management policy	Authentication, routing, quotas, transformations, logging, and runtime mediation	Knowing every action performed outside the gateway
RBAC and managed identity	Enforcing who or what may access an Azure resource	Limiting an over-broad tool operation inside that resource
Network policy	Removing unwanted routes and public exposure	Preventing misuse of an allowed route
Agent code	Preserving goals, validating schemas, and managing workflow state	Serving as its own final security authority

The best control is usually the one closest to the effect. A database should reject an unauthorized write. A gateway should reject an unapproved model. A deployment pipeline should reject a resource that violates policy. The model can explain the rule, but it should not be the final enforcement point.

Citadel through the eight AISecOps domains

Citadel is most useful to me when I map it to the same eight domains I use for the rest of the AISecOps program.

Governance and inventory

Foundry and API Center can provide an inventory of models, agents, APIs, and tools. The inventory still needs ownership, purpose, risk tier, data classification, autonomy, approved connections, current version, and retirement state. The Citadel access and publish contracts are promising patterns because they can make required dependencies and exposed capabilities reviewable in source control.

Secure development and deployment

The landing-zone templates create a repeatable baseline. CI/CD should test template changes, policy assignments, role assignments, network exposure, image provenance, guardrail configuration, and agent evaluations. A secure path should be easier than a custom deployment, or teams will build around it.

Identity and access

Foundry roles, managed identities, project scopes, agent scopes, Key Vault, and gateway authentication provide the parts. The program still has to define separation of duties, privileged access, user passthrough, identity ownership, review frequency, and revocation tests.

Data protection

Private endpoints, encryption, Purview, Content Safety, PII detection, storage controls, trace redaction, and retention can reduce exposure. Data flow mapping must include prompts, retrieval, memory, tool parameters, model output, gateway logs, and traces. The observability path is part of the data path.

Threat detection and monitoring

APIM, Application Insights, Log Analytics, Defender, and Foundry tracing can connect infrastructure events with agent behavior. Detection should focus on meaningful sequences such as a goal change followed by unusual retrieval, a new tool, privilege failure, repeated retries, and outbound transfer.

MCP and tool governance

The gateway can mediate supported MCP traffic and agent APIs. API Center can help with cataloging. The program still needs tool ownership, version pinning, provenance, scope review, schema validation, change detection, and backend authorization. A registered tool is discoverable, not automatically safe.

Incident response and adversarial testing

Citadel should make it possible to identify an agent, block its gateway access, disable its identity, preserve traces, isolate its state, and redeploy a known-good version. Those actions need playbooks and exercises. My Agent Threat Modeler can help map the components and attack paths, but the real test is whether the Azure controls stop a running workload.

Vulnerability and supply chain management

The bill of materials extends beyond containers. It includes models, SDKs, prompt packages, evaluators, policies, tools, MCP servers, base images, Bicep or Terraform modules, deployment actions, and external data sources. Citadel’s use of Azure Verified Modules helps standardize infrastructure, but module versions and transitive dependencies still need review.

The questions I am testing in my deployment

I am still experimenting with the Citadel deployment, so I do not want to present early observations as finished findings. These are the questions I am using to judge the pattern.

Can I explain every resource before I deploy it?

I want to know which resources are baseline, which are enabled by the standard agent setup, which exist only for network isolation, and which can safely reuse a shared platform service. Surprise infrastructure is a governance failure even when it is secure.

Is the hub actually on the traffic path?

An architecture can contain API Management without requiring clients to use it. I want tests that prove direct model, tool, and agent access is blocked where the gateway is meant to be mandatory.

Do project boundaries survive shared services?

Shared gateways, registries, telemetry, connections, DNS, and model deployments create efficiency. I want to verify that one project’s identity, data, logs, and policy state cannot leak into another project through those shared layers.

Can identity be traced from request to effect?

I want a request to retain both the human or service authority that started it and the agent identity that performed each step. Delegation should narrow authority rather than copy a powerful token into the next hop.

Can egress be described as an allowlist?

If nobody can state which destinations an agent needs, the firewall rule will eventually become broad. The network path should match the tool and data-flow inventory.

Does the trace tell the same story as the gateway?

Gateway telemetry and agent traces have different views. I want correlation across them so an investigation does not depend on timestamps and guesswork.

Can a risky change be stopped before deployment?

A new model, tool, connection, public endpoint, role assignment, or guardrail downgrade should produce a visible policy result in the delivery path. Detection after deployment is useful, but prevention is cheaper.

Does the emergency stop really stop the system?

Disabling an identity, revoking a gateway subscription, blocking a route, or scaling down compute should have a tested and documented effect. Queued work, cached tokens, long-running tool calls, and delegated agents can outlive the first stop command.

Can the platform produce evidence without a manual archaeology project?

For a named agent version, I want the owner, risk tier, deployment record, model, tools, identities, connections, policies, evaluations, exceptions, and recent operational posture. If that takes a week of screenshots, the system is observable but not governable.

A practical adoption sequence

I would not start by enabling every Citadel component. I would build the operating loop in stages.

1. Define the workload and its boundaries

Document the purpose, owner, users, data, models, tools, identities, memory, outside inputs, actions, and maximum credible impact. Draw the path from untrusted input to privileged effect. Decide which evidence will be required.

2. Deploy a small public development baseline

Use the landing zone to learn the resource graph and role model. Keep the workload low risk. Do not confuse a public development topology with the production answer. Record actual fixed and variable cost.

3. Put the gateway in the path

Add authentication, per-client attribution, model allowlists, token limits, safe retry behavior, and useful telemetry. Test bypass attempts. Avoid logging full prompts until access, redaction, and retention are designed.

4. Separate workload identities and connections

Give the runtime, deployment pipeline, operator, and consumer distinct roles. Replace shared keys with managed identity where supported. Scope sensitive connections to the project and backend operation.

5. Add private networking and controlled egress

Decide whether to use a new or existing hub firewall, DNS zones, Bastion, and shared monitoring. Validate name resolution, private endpoint approval, outbound routes, and failure behavior. Do not add a public workaround when one private dependency is misconfigured.

6. Connect traces, evaluations, and policy evidence

Correlate gateway events with Foundry and application traces. Protect trace data. Run repeatable evaluations tied to the exact model, prompt, tool, policy, and deployment versions.

7. Exercise attacks and recovery

Test indirect prompt injection, tool misuse, connection abuse, cross-project access, token exhaustion, poisoned retrieval, policy bypass, and trace-data exposure. Disable the agent and confirm every path stops. Restore a known-good version and verify state.

8. Turn the result into a paved road

Publish approved modules, policy bundles, gateway patterns, logging defaults, evaluation suites, and evidence templates. Let low-risk workloads inherit the baseline. Reserve manual review for real exceptions and high-impact systems.

What Citadel does not solve

Citadel can provide a strong Azure platform. It does not decide:

• whether the agent should exist;
• whether its goal is well defined;
• whether a human approval is meaningful;
• whether retrieved information is correct;
• whether the model will follow an instruction;
• whether an allowed tool call is appropriate in context;
• whether a business owner accepts the residual risk;
• whether an incident has been contained;
• whether evidence is good enough to support a decision.

It also cannot eliminate change. Foundry capabilities, models, APIM features, agent protocols, SDKs, and preview services will continue to move. Infrastructure deployed today can drift away from the reference implementation. A passing evaluation can become stale when a model or tool changes.

The platform therefore needs a loop, not a finish line:

1. inventory;
2. threat-model;
3. deploy controls;
4. measure behavior;
5. monitor effects;
6. respond and recover;
7. reassess after change.

That loop is the connection between Citadel and an AISecOps program.

My current view

Citadel is valuable because it refuses to treat governance as one product feature. It spreads responsibility across the gateway, Foundry control plane, identities, workload landing zones, security services, and operating process.

Its strongest idea is the combination of central enforcement with isolated workload spokes. Platform teams can own shared policy, registry, and telemetry patterns. Workload teams can own the agent and its data without inventing the foundation each time.

Its main risk is also familiar: a complete reference architecture can look finished before the organization has made the decisions that give it meaning. Deploying APIM does not prove traffic is governed. Creating a managed identity does not prove least privilege. Enabling tracing does not prove incidents can be reconstructed. Adding private endpoints does not prove an agent cannot misuse an internal tool.

That is what I am looking for in my Citadel experiment. I want to know whether the pattern makes the secure path repeatable, whether it exposes the awkward tradeoffs early, and whether it produces evidence that can survive contact with an actual security review.

The architecture is a good start. Governance begins when every line in the diagram has an owner, a policy, a test, and a recovery path.