Microsoft open-sourced an Agent Governance Toolkit. Here's what it covers and what it doesn't
In April 2026, Microsoft released an open-source toolkit to govern autonomous AI agents. The Agent Governance Toolkit functions as a stateless policy engine that intercepts every agent action before execution, with reported p99 latency below 0.1 milliseconds.
That’s a serious technical claim. Sub-millisecond, stateless, OSS — the spec sheet is good. Worth understanding what it does and doesn’t cover, because the framing in announcements can read like Microsoft solved AI governance, and that’s a more limited claim than “we shipped a useful policy engine.”
What the toolkit ships
Reading through the available material:
- Stateless policy engine: takes (agent, action, context) → allow/deny decision. No persistent state — each call is independent. Lets it scale horizontally without coordination.
- Sub-millisecond enforcement: p99 below 0.1ms. That’s measurement-level, not aspirational — the engine is fast enough to sit inline on every tool call without latency complaints.
- Open source: self-hostable. Bring your own infrastructure. No Azure dependency.
- Designed to integrate with Microsoft Foundry: the natural deployment is alongside Foundry Agent Service, Azure API Management, and Microsoft Entra Agent IDs. Outside that ecosystem, integration is left to the implementer.
For teams that want a fast, self-hostable, OSS policy engine specifically, it’s a useful piece of infrastructure. The bar Microsoft cleared is real.
What it doesn’t ship
A policy engine is one component of agent governance. Several other components are out of scope for the toolkit and need to come from elsewhere:
1. Identity propagation. The toolkit makes a decision given an (agent, action, context). Where that context comes from — verified end-user JWT, OIDC trusted issuer, Entra Agent ID, scoped delegation chain through agent-to-agent calls — is the implementer’s problem. For Microsoft-native shops, Entra Agent ID handles a lot of it. Outside Azure, you build it.
2. Audit destination. The toolkit decides; it doesn’t store. You wire it to your SIEM, your audit lake, your dashboard. Fine for sophisticated platform teams. Less fine for “we want a control plane out of the box.”
3. PII / secret detection. Content scanning on tool inputs and outputs isn’t the toolkit’s job. Microsoft Purview can do data classification; combining Purview with the toolkit is workable but it’s two products to operate.
4. Cross-cloud reach. The toolkit is OSS, so technically you could deploy it on AWS or GCP. Practically, the documented integration paths are Azure-native. For agents that don’t run on Azure, you’re in unsupported configuration territory.
5. Cross-framework reach. The toolkit assumes you have an interception point. If your agent runs in Foundry, the interception is built in. If your agent runs in CrewAI, LangGraph, Vercel AI SDK, Pydantic AI, Mastra — those don’t have a Microsoft-native hook surface. You either:
- Wire the toolkit yourself per framework (custom integration work per framework)
- Or use a tool-layer pattern that already covers those frameworks (which is what
@governeddecorators do in ACP)
Where the toolkit and ACP overlap
Both produce per-action policy decisions for agent tool calls. Both can be configured for fine-grained access control. Both operate at sub-second latency. Both ship deny rules and audit logging.
If you self-host Microsoft’s toolkit, write your own identity propagation, wire your own audit destination, and operate Foundry-only agents, you can build something that overlaps with ACP’s value. The trade is “OSS engine + your time” vs. “managed service + 15 framework integrations + audit dashboard + identity propagation across IdPs.”
For teams that want full self-hosting and have engineering capacity to operate a policy engine, the toolkit is a viable choice — particularly if your agents are Foundry-native.
Where they don’t overlap
- Cross-cloud unified audit. Toolkit: BYO. ACP: built in.
- Cross-framework breadth. Toolkit: integrates cleanly with Foundry; integration with CrewAI/LangGraph/Vercel AI SDK/Pydantic AI/etc. is custom work. ACP: 15 framework integrations shipped.
- Coding-agent governance. Toolkit: not in scope. ACP: hooks for Claude Code, Cursor, Codex CLI, Zed.
- Identity-attributed audit out of the box. Toolkit: BYO identity propagation. ACP:
set_context()per request, dashboard surfaces actor attribution per call. - PII / secret redaction in tool outputs. Toolkit: out of scope. ACP: built into the post-tool-output hook.
- Managed service. Toolkit: self-host. ACP: managed.
The honest take
Microsoft’s toolkit is good news for the category — sub-millisecond OSS policy enforcement raises the floor on what teams should expect from agent governance infrastructure. Lots of vendors used to claim “real-time enforcement” while actually doing async webhook-after-the-fact stuff. Microsoft’s spec calls that bluff.
For Microsoft-Foundry-native shops with platform-engineering capacity, the toolkit + Foundry + Entra Agent ID + Purview / Sentinel is a real stack. Don’t underestimate it.
For everyone else — multi-cloud, multi-framework, coding-agent-in-scope, looking for a managed service rather than an OSS engine to operate — the toolkit is one component, not a whole control plane. Compose it with what you already need from elsewhere, or pick a managed alternative that ships the missing pieces.
What to do this week
- If you’re Foundry-native: try the toolkit. The OSS license + self-host + sub-ms latency is a serious value prop for Azure-internal governance.
- If you’re multi-cloud: the toolkit by itself doesn’t help. The cross-cloud unification you need lives above any single cloud’s product.
- If you have coding agents in scope: that’s a different surface — toolkit doesn’t reach there.
How ACP composes with Microsoft Foundry → · Microsoft Foundry integration → · Reference architecture →