§1Governance stopped being a PDF
For about eighteen months the standard enterprise answer to "how do you govern autonomous agents" has been a slide deck. A principles document. A committee. Microsoft's agent-governance-toolkit is the first widely-backed attempt to answer the question in code you can actually run: policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering, mapped against all ten entries in the OWASP Agentic Top 10.
That matters, and not for the reason most coverage will give. The interesting thing is not that it covers 10/10 of the OWASP list. The interesting thing is what the toolkit has to assume already exists for any of those controls to mean anything. Strip the marketing back and you find a set of enforcement primitives that are only as trustworthy as the identity and audit substrate they sit on. Microsoft has shipped the enforcement layer. It has quietly outsourced the foundation.
§2The controls are real. The trust boundary is borrowed
Take the four pillars in turn. Execution sandboxing is the most mature and the least controversial: you isolate what the agent can touch at runtime, you cap blast radius, you make tool calls go through a broker. Good. Reliability engineering, retries, circuit-breakers, idempotency on side-effecting actions, is genuinely underdone in most agent deployments and it is welcome to see it treated as a governance concern rather than an SRE afterthought.
Policy enforcement and zero-trust identity are where the assumptions hide. Zero-trust identity for agents means every agent action carries a verifiable identity and that identity is checked at every boundary. The toolkit gives you the machinery to check. It does not, and cannot, tell you what an agent's identity is in your organisation, who issued it, who can revoke it, or how an FCA-regulated firm proves to a supervisor that the identity presented at 14:03 on a Tuesday was the one authorised by a named human. Microsoft assumes you have an identity provider and a sane mapping from agents to principals. Most regulated buyers do not. They have service accounts, shared secrets, and a spreadsheet.
Policy enforcement is worse in this respect because it looks solved. You write a policy, the engine enforces it. But a policy engine enforces the policy it is given. It has nothing to say about whether the policy is the right one, whether it was authorised, whether it can be changed without an audit trail, or whether the person who wrote it had the authority to. Under the ICO's guidance on AI and data protection (§11, accountability and governance), and under the FCA's operational resilience expectations, the regulator's question is never "did the engine enforce the rule". It is "who decided the rule, when, on what basis, and can you show me the chain". The toolkit enforces. It does not, on its own, evidence.
§3The producer must not be the guardian
Here is the sharp version. The agent-governance-toolkit is built and shipped by the same vendor that builds the agents, the runtime, the model, and the cloud they run on. That is convenient. It is also a separation-of-concerns problem that the regulated world has spent decades learning to distrust.
In financial services you do not let the trading desk also run the surveillance that watches the trading desk. In clinical settings you do not let the system that administers a decision also be the sole keeper of the record that proves the decision was safe. The principle is dull and old: the producer of an action should not be the sole guardian of the evidence about that action. Microsoft's toolkit, run inside Microsoft's runtime, against Microsoft's identity service, producing logs in Microsoft's format, collapses producer and guardian into one trust domain.
For a Local Authority subject to FOIA and the public-sector equality duty, or an FCA firm under SS1/23 on model risk, that collapse is not a technicality. It is the difference between an audit trail you control and an audit trail you rent. When the supervisor asks for evidence, "we trusted the vendor's enforcement layer" is not an answer. The substrate question every buyer should ask of this toolkit is: can I extract the identity, policy, and audit records into a store I control, in a format I can reason about, independent of the vendor that produced the agent? If the answer is no, you have bought enforcement and called it governance.
§4What this actually changes for builders
The toolkit raises the floor, and that is worth saying plainly. Anyone building agent infrastructure now has a reference implementation of sandboxing and reliability primitives that maps to a recognised risk taxonomy. The OWASP Agentic Top 10 mapping gives security teams a vocabulary to ask vendors hard questions. "Show me your coverage of A03, agent tool misuse" is a better procurement conversation than "is it safe".
But raising the floor changes where the real work is. The differentiated, defensible, regulator-facing work is no longer writing a sandbox. Microsoft has commoditised that. The work is the substrate the toolkit assumes: an agent identity authority that is independent of the agent runtime, a policy store with its own authorisation and change-audit, and an evidence layer that survives a vendor migration. Those three things are precisely what the toolkit does not give you, and precisely what a regulated buyer cannot operate without.
If you are building for this audience, the toolkit is your input, not your product. Treat it as the enforcement engine you plug a sovereign identity and audit substrate into. The moment governance ships as runnable code, the value moves down a layer to the foundations that code stands on.
§5What the toolkit does not solve
To be fair to Microsoft: the project does not claim to be a complete governance regime, and reading it as one is the reader's error, not the authors'. It is honest about being a toolkit. The OWASP mapping is a coverage claim about technical controls, not a compliance claim about any specific regulation; no GitHub repository maps cleanly to SS1/23 or the ICO accountability principle, and this one does not pretend to.
Three gaps remain open. First, identity provenance: the toolkit verifies identity but does not establish where trustworthy agent identity comes from in a multi-vendor estate. Second, evidence portability: there is enforcement logging, but no commitment to a vendor-neutral, tamper-evident audit format a supervisor would accept. Third, the human-authorisation chain: policy is enforced, but the question of who authorised the policy, under what delegated authority, and how that is proven after the fact, sits entirely outside the code. None of these are criticisms of the engineering. They are the boundary of what an enforcement toolkit can do, and the reason the substrate underneath it is still the buyer's problem to own.