What Microsoft Actually Built — and What They Didn't

On 2 April 2026, Microsoft published a blog post announcing the Agent Governance Toolkit — described as "open-source runtime security for AI agents." Within hours it was circulating in every AI safety Slack channel, LinkedIn feed, and security mailing list I follow. The headline was compelling. The GitHub repository was substantial. And the timing, coming just weeks after the OWASP Agentic Top 10 and four months before EU AI Act enforcement begins, felt deliberate.

I spent the better part of three days reading the code. Not the README. The code.

What I found is genuinely impressive in places, genuinely concerning in others, and — most importantly — widely misunderstood in the coverage I have read since. So this is my attempt to give you an honest account of what Microsoft actually built, what it does not do, and what it means for the teams I work with in healthcare, defence, and regulated industries.

First, the Scale of the Thing

The announcement said "seven packages." The repository contains eleven. That is not a criticism — the additional packages include an agent hypervisor and a VSCode extension that are arguably the most interesting parts of the whole project. But it tells you something about how quickly this space is moving, and how hard it is to communicate the full scope of a project like this in a blog post.

The eleven packages are:

Nine thousand five hundred tests. Fifteen framework integrations. Support for Python, TypeScript, .NET, Rust, and Go. This is not a prototype. Someone at Microsoft has been thinking about this problem seriously for a long time.

What It Actually Does Well

The Saga Orchestrator is the most practically useful component in the entire toolkit for anyone deploying agents in regulated environments. The Saga pattern — borrowed from distributed systems — solves a problem that keeps me up at night when I think about AI agents in clinical settings: what happens when an agent takes an action that cannot be undone?

The answer, in most governance frameworks, is silence. You log it, you alert on it, and you hope the human catches it in time. The Saga Orchestrator gives you a structured compensation mechanism — a defined sequence of rollback actions that execute automatically when a transaction fails or is cancelled. For an agent that has written an EHR entry, sent a procurement order, or modified a configuration file, this is the difference between a recoverable incident and a serious one.

The Agent-Lightning flight recorder is the only tool I have seen that governs the reinforcement learning training loop, not just the deployed model. Every other governance framework I have reviewed — including our own work at Periculo — focuses on the inference-time behaviour of a deployed agent. Agent-Lightning captures policy violations during training, records them as LightningSpan telemetry events, and can terminate training episodes when violations exceed a defined threshold. If you are training agents on sensitive data or in environments where reward hacking could have real-world consequences, this matters enormously.

The DID/Ed25519 identity layer in AgentMesh Platform is the right foundation for multi-agent trust. Decentralised identifiers and Ed25519 signatures give you cryptographically verifiable agent identity without a centralised certificate authority. In a world where agents are spawning sub-agents, delegating tasks, and operating across organisational boundaries, this is the architecture you want. The SPIFFE/SVID integration for service mesh environments is a particularly thoughtful addition.

The four-tier privilege ring model in AgentMesh Runtime applies a principle that has been fundamental to operating system security since the 1970s — least privilege, enforced at the hardware level — to AI agent execution. Ring 0 (system operations) through Ring 3 (user-level operations) with capability-based access control at each boundary. It is not novel, but it is correct, and correctness matters more than novelty in security architecture.

Where It Falls Short

The GovernanceVerifier is compliance theatre. I want to be precise about this, because it is a serious claim. The GovernanceVerifier in agent-compliance checks whether governance modules are importable — whether the Python packages are installed and can be loaded. It does not check whether they are configured. It does not check whether they are active. It does not check whether the policies they enforce are appropriate for the deployment context.

A system that imports agent-os-kernel but has no policies defined, or has policies that allow everything, will receive a passing governance verification. The compliance grade (A through F) is calculated from these checks. An "A" grade does not mean your agent is well-governed. It means your governance packages are installed.

This is not a minor implementation detail. It is a fundamental misrepresentation of what compliance means. In healthcare, a DCB0129 clinical safety case cannot be satisfied by confirming that a governance library is importable. In defence, a MOD AI Assurance Framework submission cannot be completed by running an import check. The organisations most likely to rely on this toolkit — large enterprises with compliance obligations — are the ones most likely to be misled by a letter grade that does not reflect the actual governance posture of their systems.

The Math.random() problem in the VSCode extension. The Agent-OS-VSCode extension includes a compliance grade display that, in the version I reviewed, uses Math.random() to generate demonstration scores. This is a development placeholder that should never have been shipped in a public release. It is a small thing, but it is symptomatic of a broader issue: the gap between the architectural ambition of the toolkit and the production-readiness of its components.

The PII leakage paradox in CMVK. The multi-model consensus verification system in the VSCode extension — which uses GPT-4, Claude, and Gemini to cross-check code for policy violations — has a fundamental contradiction at its core. The system is designed to prevent data leakage. To do so, it sends your code to three external APIs. If your code contains sensitive data, credentials, or proprietary logic, CMVK will exfiltrate it to three separate cloud providers in the process of checking whether it should be exfiltrated. The irony is not lost on me.

The fail-open defaults. Several components in the toolkit default to allowing operations when the governance layer is unavailable or returns an error. This is a pragmatic choice for developer experience — you do not want a network timeout to bring down a production system — but it is the wrong default for regulated environments. In healthcare and defence, the correct default when governance is unavailable is to deny, not to allow.

The hardware attestation gap. The IntegrityVerifier in agent-compliance uses SHA-256 bytecode hashing to verify that agent components have not been tampered with. This is better than nothing, but it is software-based attestation — it can be bypassed by an attacker with sufficient access to the system. For high-assurance deployments, you need hardware-backed attestation via TPM or HSM. The toolkit has no support for this.

The Healthcare Lens

I have spent years working on AI governance in NHS and digital health settings. When I read the toolkit through that lens, several things stand out.

The Saga Orchestrator is genuinely valuable for clinical AI. An agent that can write an EHR entry needs a compensation mechanism. The toolkit provides one. But the clinical safety implications go further than the toolkit addresses. DCB0129 requires a clinical safety case — a structured argument, supported by evidence, that a system is acceptably safe for its intended use. The toolkit can provide some of that evidence (audit trails, policy enforcement logs, promotion gate records), but it cannot produce the safety case itself.

The PII redaction mechanism — redact_pii — uses regex pattern matching. This is not adequate for clinical de-identification. The Safe Harbour method under HIPAA requires the removal of 18 specific identifiers. The Expert Determination method requires a qualified statistician to certify that re-identification risk is very small. Regex can catch obvious patterns — NHS numbers, dates of birth in standard formats — but it will miss free-text clinical notes, unusual date formats, and indirect identifiers.

The most significant gap for NHS deployments is the human-in-the-loop requirement. When an AI agent is blocked by a policy violation in a clinical context, the toolkit stops the agent. It does not create a workflow for a clinician to review the decision and override it if appropriate. In many clinical scenarios, a blocked action is not the end of the story — it is the beginning of a clinical decision-making process.

The Defence Lens

The defence and national security context surfaces a different set of concerns.

The most immediate is the air-gapped deployment problem. Several components in the toolkit make outbound network calls — to external trust providers, to the three LLM APIs in CMVK, to package registries for supply chain scanning. In classified environments, outbound network calls are not permitted. The toolkit can be deployed in a restricted mode, but the documentation for doing so is sparse, and several components simply do not function without network access.

The hardware attestation gap I mentioned earlier is particularly acute in defence. The MOD's AI Assurance Framework (published February 2026) explicitly requires evidence of system integrity. Software-based bytecode hashing does not provide this evidence.

What This Means for the Market

Microsoft's release of this toolkit is significant for reasons that go beyond the toolkit itself. It is a signal that the major cloud providers have concluded that AI agent governance is a real problem that requires real infrastructure — not just guidelines, not just best practices documents, but code.

What the toolkit is not is a complete governance solution. It is infrastructure. It gives you the plumbing — the policy engine, the audit trail, the identity layer, the SLO monitoring. What it does not give you is the governance — the policies themselves, the regulatory mappings, the human review workflows, the compliance reporting, the clinical safety case, the board-level accountability framework.

My Honest Assessment

If you are a platform engineering team building AI agent infrastructure for a large enterprise, this toolkit is worth serious evaluation. The architectural decisions are sound, the test coverage is substantial, and the multi-language support means you can use it across a heterogeneous stack.

If you are a CISO, a compliance officer, or a Clinical Safety Officer trying to govern AI agents in a regulated environment, the toolkit is a starting point, not a destination. The compliance grades it generates are not regulatory compliance. The audit trails it produces are not forensic evidence. The PII redaction it offers is not clinical de-identification.

The most important thing I can tell you is this: do not let the sophistication of the toolkit — eleven packages, nine thousand tests, fifteen framework integrations — give you false confidence that governance is solved. It is not. The hard work of AI governance is not writing the policy engine. It is deciding what the policies should be, ensuring they reflect your legal and ethical obligations, building the human processes that sit alongside the technical controls, and maintaining all of it as your systems and your regulatory environment evolve.

If you need help with that conversation, that is what we do at Periculo.