Microsoft has assembled one of the most complete platform-native agent governance stacks available, per its public documentation and announcements: Entra Agent ID gives agents first-class identities in the directory, Purview extends data security and compliance tooling to AI interactions, Copilot Studio and Azure AI Foundry ship with administrative controls, content filtering, and monitoring for the agents built on them — and, since April 2026, an open-source Agent Governance Toolkit extends runtime security beyond the Microsoft estate entirely. For an organization building agents in or near the Microsoft ecosystem, this is real governance, not marketing.

This post is deliberately not an "alternatives to Microsoft" pitch. For Microsoft-estate agents, the native stack is the default answer and often the right one. The useful engineering question is about boundaries: where does platform-native governance stop, and what does an independent control plane add for the estates — most enterprise estates — that are not homogeneous? Disclosure: Praesidia, our product, is an independent control plane, so we have a position here; we argue it with public claims and explicit boundaries. As of July 2026, verify Microsoft capabilities against Microsoft's current documentation — this stack evolves quickly.

What the Microsoft stack covers, in its own terms

From Microsoft's public materials, the stack addresses:

  • Agent identity. Entra Agent ID assigns agents identities within Microsoft Entra, bringing them into the same directory, governance, and conditional-access world as users and service principals.
  • Data security and compliance. Purview's public scope extends discovery, DLP, sensitivity labeling, and audit to AI interactions across Microsoft's AI surfaces.
  • Platform controls. Copilot Studio and Azure AI Foundry document admin governance for the agents built on them: environment policies, content filters, monitoring, and lifecycle management.
  • Security integration. Defender and Sentinel surface AI-related signals into the SOC tooling many enterprises already run.

The design center is coherent: if your agents are built in Microsoft tools, run on Azure, and touch Microsoft-managed data, governance arrives with the platform.

The open-source Agent Governance Toolkit

The newest piece of the stack deliberately breaks that estate boundary. On April 2, 2026, Microsoft announced the Agent Governance Toolkit on the Microsoft Open Source Blog: an MIT-licensed, open-source runtime security layer for AI agents that is explicitly not tied to Entra or Purview. Per the announcement and project documentation, it provides:

  • Runtime enforcement primitives. Deterministic policy enforcement with sub-millisecond evaluation, cryptographic agent identity, and execution sandboxing — the in-band control classes this site groups under AI agent runtime security.
  • OWASP Agentic coverage. Compliance mapping to all ten categories of the OWASP Agentic Top 10, from goal hijack through rogue agents.
  • A component suite. Modules including Agent OS, Agent Mesh, Agent Runtime, Agent SRE, and Agent Compliance, covering execution, inter-agent connectivity, operations, and evidence.
  • Broad language and framework reach. SDKs for Python, TypeScript, Rust, Go, and .NET, with framework-agnostic integrations for LangChain, AutoGen, and the Microsoft Agent Framework.

Two implications are worth stating plainly. First, this is a serious, capability-complete open-source entry in the runtime-governance category — teams evaluating build-vs-buy or assembling an open-source stack should shortlist it. Second, it changes the shape of the Microsoft conversation: the historical objection that platform-vendor governance only reaches the vendor's own estate no longer applies to this component, because the toolkit is designed to govern agents wherever they run.

As with the rest of the stack — and as with our own claims — verify current scope against the project's documentation; it is new and moving quickly.

Where the estate edge bites

Enterprise reality is heterogeneous, and each heterogeneity crosses the boundary of platform-native governance:

  • Agents built elsewhere. Engineer-built agents on open frameworks, agents embedded in third-party SaaS, agents calling Anthropic or open-weight models directly — Entra Agent ID, by design, governs only what authenticates through Entra.
  • Non-Microsoft models and tools. Multi-model strategies are the norm; guardrails and filtering attached to one platform's model endpoints do not follow traffic to others.
  • Third-party MCP servers. The tool ecosystem your agents call is vendor-neutral by design; vetting, scoping, and inspecting those connections needs a layer that speaks MCP natively, wherever the server lives.
  • Cross-cloud and on-prem. Agents touching AWS, GCP, and internal systems carry risk in exactly the places single-vendor telemetry ends.

The result of governing only the Microsoft slice is a familiar shape: strong controls where the platform sees, and shadow-AI dynamics everywhere else — with the audit trail fragmenting at each vendor boundary.

What an independent control plane adds

An independent control plane — Praesidia's category, described fully in what is an AI control plane — sits with the organization rather than with any platform vendor, and adds three things to a mixed estate:

  • Cross-vendor identity and policy. Every agent, application, and MCP server — Microsoft-built or not — registers as a principal with its own credentials, and one policy engine enforces authorization, budgets, and rate limits uniformly, per the runtime security model.
  • Uniform guardrails. Bidirectional content inspection applied in-band to every governed flow — regardless of which model vendor or framework is on either end — so policy is written once, not once per platform.
  • One audit trail. A single append-only, hash-chained record across the heterogeneous estate, which is what incident reconstruction and EU AI Act evidence actually require when agents span vendors.

There is also a positioning argument, and with the Agent Governance Toolkit now covering framework-agnostic runtime enforcement, it is honestly a neutrality argument rather than a capability one. Some organizations — multi-cloud estates, non-Microsoft shops, European deployments with strict residency requirements, teams that want their enforcement chokepoint operated independently of any platform they also buy compute or models from — prefer the governance layer to sit with a vendor whose only role is governance. That is a legitimate architectural preference, not a claim that platform vendors cannot build the layer. Praesidia's own operating-model choices — open-source Apache-licensed core, EU data residency, $0 free tier, per our public documentation — exist to serve exactly that preference.

The realistic architecture: both

The pragmatic enterprise answer composes the layers. Use Microsoft-native governance for what it is best at: identity and lifecycle for Copilot/Foundry agents, Purview for Microsoft-managed data, Defender/Sentinel signal into the SOC. Add an independent control plane where the estate is mixed: engineer-built agents, non-Azure models, third-party MCP servers, cross-cloud tooling — and route Microsoft-estate agents through it too where you want one policy surface and one audit trail rather than two. Sequencing follows your growth edge: if the next twelve months of agents are Copilot Studio, deepen the native stack first; if they are custom agents on heterogeneous models and tools, stand up the independent layer before that population scales ungoverned — the platform-selection guide covers the evaluation.

Common questions

Is this an 'alternatives to Microsoft' comparison? Deliberately not. For agents inside the Microsoft ecosystem, Microsoft's native governance stack is the default and often correct choice. The analysis here is about coverage boundaries — what platform-native governance cannot see beyond its estate — and how an independent control plane composes with it.

What does Microsoft's agent governance stack include? Per Microsoft's public documentation: Entra Agent ID (agent identities in the directory), Purview (data security, compliance, and audit extended to AI interactions), governance and content controls in Copilot Studio and Azure AI Foundry, AI-related signal in Defender and Sentinel, and — since April 2026 — the open-source, MIT-licensed Agent Governance Toolkit for framework-agnostic runtime security. Verify current scope against Microsoft's docs — it expands frequently.

What is the Agent Governance Toolkit? An open-source (MIT) runtime security project Microsoft announced in April 2026: deterministic sub-millisecond policy enforcement, cryptographic agent identity, execution sandboxing, and compliance mapping to all ten OWASP Agentic Top 10 risks, with SDKs across Python, TypeScript, Rust, Go, and .NET and integrations for LangChain, AutoGen, and the Microsoft Agent Framework. Unlike Entra and Purview, it is not tied to the Microsoft estate — it is a component you operate wherever your agents run.

If we are an all-Microsoft shop, do we need an independent control plane? If your agents, models, data, and tools genuinely all live inside the Microsoft estate, the native stack may be sufficient — audit the boundaries honestly (third-party MCP servers and SaaS-embedded agents are the usual leaks). The independent layer earns its place at the first durable heterogeneity.

Can the two layers conflict? They compose cleanly when responsibilities are explicit: platform-native controls govern the platform's internals; the independent plane governs cross-estate identity, policy, and audit at the traffic level. The pattern to avoid is duplicating the same control ambiguously in both layers with no defined authority — decide which layer is authoritative for each control class and record it.