Microsoft's Nine-Domain AI Governance Framework Enforces Policy at Runtime
In this article
Microsoft published an AI governance architecture that reframes governance as a runtime enforcement problem rather than a documentation exercise. The framework spans nine named domains and four operational functions — policy, control, visibility, and proof — and is designed to give organisations verifiable evidence that governance requirements are being met during live AI system operation, not just at design time. For engineers building production agent systems, the distinction matters: a policy document that cannot be interrogated at inference time offers no real safety guarantee.
Nine Domains, Four Functions
The nine governance domains are: policy, data governance, model governance, observability, evaluations, security, identity and access, audit and compliance, and agent governance. Microsoft positions them as an interconnected operational loop rather than independent silos. Policies establish requirements and risk classifications. Controls translate those requirements into access rules and runtime enforcement points. Observability captures system behaviour continuously. Evaluations test quality and safety both before deployment and in production. Audit processes then convert accumulated operational telemetry into compliance evidence and incident investigation material.
Anthony Bartolo, Principal Cloud Advocate at Microsoft, stated the operational logic directly: a policy is not governance until production can prove it. That framing places the burden on teams to instrument their systems so that every policy claim is backed by runtime telemetry — changing what "done" means for AI deployment.
Runtime Enforcement via Foundry and Adjacent Services
The platform layer combines Microsoft Foundry with Microsoft Purview, Microsoft Entra ID, Defender, and Azure API Management. Foundry's AI Gateway functions as the primary runtime boundary, handling authentication, token limits, quotas, and policy enforcement at the point where requests reach models and tools. Microsoft also documents using the gateway to govern Model Context Protocol (MCP) tools — providing centralised authentication, rate limiting, IP restrictions, and audit logging without requiring modifications to MCP server code or agent logic. That matters for teams running MCP-based tool ecosystems who need governance applied without re-architecting individual components.
This runtime gateway approach fits a broader pattern where pipeline architecture drives enforcement rather than model selection. Shifting control to the request path means governance scales with traffic rather than requiring per-model configuration.
Developer Obligations for Visibility and Proof
The visibility function requires capturing system behaviour continuously across users, agents, models, tools, APIs, MCP servers, and enterprise systems — not just logging errors. The proof function requires that telemetry be structured and complete enough to reconstruct any interaction for compliance or incident purposes. Both functions place instrumentation work on engineering teams rather than compliance functions.
Evaluations occupy a dual role: pre-deployment assessments against datasets using Microsoft Foundry's built-in and custom evaluators, and ongoing production monitoring after release. Teams that lack robust agentic control layers will find the proof function particularly difficult to satisfy, since multi-agent workflows with no shared contract generate fragmented telemetry that cannot easily be assembled into audit evidence.
| Function | Mechanism | Platform Component | Developer Obligation |
|---|---|---|---|
| Policy | Requirements and risk classification | Microsoft Foundry, Purview | Define and version policy rules |
| Control | Access rules, token limits, quotas, runtime enforcement | Foundry AI Gateway, Entra ID, API Management | Configure gateway enforcement points per policy |
| Visibility | Continuous behavioural capture across users, agents, tools, APIs, MCP servers | Defender, Observability stack | Instrument all interaction paths; no silent failures |
| Proof | Telemetry-to-evidence conversion for audit and incident investigation | Purview, Audit and Compliance domain | Structure logs to support reconstruction of any interaction |
Agent Governance as a Distinct Control Surface
Agent governance is explicitly separated from general model governance. The Agent Control Specification introduces checkpoints at agent inputs, model calls, tool execution, and outputs, with higher-impact actions configurable to require human approval before execution. Microsoft's open-source Agent Governance Toolkit provides runtime security capabilities including policy enforcement and interception points for autonomous agents. The framework maps to the NIST AI Risk Management Framework and its Generative AI Profile, giving teams a vendor-neutral reference for the governance concerns the platform controls implement.
The gap between policy documentation and runtime enforcement has been the central weakness in enterprise AI deployment — a close parallel to the broader verification problem that affects gated capability rollouts at the frontier. Microsoft's architecture is notable not for introducing new concepts but for assembling them into a named, structured framework that procurement and compliance teams can evaluate against. As regulatory pressure increases, the ability to produce audit evidence from production telemetry will shift from a differentiator to a baseline requirement.