In April 2026, Microsoft open-sourced the Agent Governance Toolkit (AGT) — a runtime security framework for autonomous AI agents. The problem statement in their announcement was direct: most AI agent deployments today are like "running every process as root — no access controls, no isolation, no audit trail."
That is a production readiness problem. And it is exactly the gap that release readiness is designed to close.
This post looks at what the Microsoft AGT actually provides, and how its architecture maps to the key areas a release readiness gate for agentic AI should cover — not as a product review, but as a practitioner reading of what a major platform provider built when they got serious about production governance.
What the Toolkit Is
The AGT is a monorepo of nine independently installable packages, each addressing a specific layer of agentic governance: policy enforcement, identity, execution isolation, runtime supervision, reliability engineering, compliance verification, plugin security, reinforcement learning governance, and framework integrations. It addresses all ten risk categories in the OWASP Top 10 for Agentic Applications, published in December 2025 as the first formal taxonomy of risks specific to autonomous agents, developed with input from more than 100 security researchers.
It is open-source, framework-agnostic, and integrates with over twenty agent frameworks including LangChain, CrewAI, AutoGen, and Microsoft Agent Framework via native extension points — typically a few lines of configuration rather than a rewrite.
Importantly, the AGT is not only a runtime tool. It covers the full agent lifecycle — from pre-deployment compliance checks run at the pull request stage, through provisioning and approval workflows, into runtime enforcement, and through to decommissioning. What matters for this discussion is how each layer maps to what a release readiness gate should be asking.
Release Readiness Question 1: What Is This Agent Permitted to Do?
The release readiness gate must verify that the agent's actual capability at deployment matches what was approved at design. Scope creep during development is common — tool integrations accumulate, permissions expand, and by the time an agent reaches production it may be doing far more than the original design anticipated.
The AGT's Agent OS package addresses this directly. It intercepts every tool call before execution through a stateless policy engine, using both configurable pattern matching and a semantic intent classifier. Actions classified as destructive data operations, data exfiltration attempts, or privilege escalation are blocked, routed for human approval, or trigger a trust downgrade — depending on policy configuration.
Critically, Microsoft is explicit that all policy rules and detection patterns must be reviewed and customised before production deployment. No built-in rule set should be considered exhaustive. This is exactly the kind of verification a release readiness gate formalises: confirming that the policy layer reflects the approved scope, not just a default configuration.
Release Readiness Question 2: Who Is the Agent and What Can It Be Trusted With?
Identity verification at release is not about checking that an agent has credentials. It is about confirming that those credentials are correctly scoped, cryptographically sound, and tied to human accountability.
The AGT's Agent Mesh package implements decentralised identifiers (DIDs) with Ed25519 cryptography and an Inter-Agent Trust Protocol for agent-to-agent communication. Every agent identity includes a human sponsor — accountability is not abstracted away. Delegation chains enforce scope narrowing: a parent agent cannot grant a child agent more permissions than it holds itself.
The trust decay mechanism is particularly relevant for release readiness: an agent's trust score decreases over time without positive signals. An agent trusted at last week's test may not be at the same trust level by release day. This makes the timing of the release readiness evaluation meaningful, not just its content.
Release Readiness Question 3: Is the Execution Environment Safe?
Before an agent goes to production, the release gate should confirm that its execution environment enforces boundaries — not just that the agent is expected to behave within them.
The AGT's Agent Hypervisor applies CPU privilege ring architecture to agents. New agents start in Ring 3 (read-only, sandboxed) and earn access to higher rings through demonstrated trust. The ring thresholds, resource limits, and trust score requirements are all configurable — and they should be explicitly reviewed and set at the release gate, not left at defaults.
The Hypervisor also provides saga orchestration for multi-step operations: when a sequence of agent actions fails partway through, compensating actions fire in reverse to maintain consistency. This is the agentic equivalent of transaction rollback — and confirming that it is configured and tested is a release readiness responsibility.
Release Readiness Question 4: Has the System Been Tested to Break?
Red-teaming and adversarial testing are not optional for agentic systems. Microsoft's own framing on this is worth quoting directly: prompt-level safety is "a polite request to a stochastic system." Asking an agent to follow the rules in a system prompt is not a control surface — it is probabilistic by construction.
The AGT's Agent SRE package includes nine chaos engineering fault injection templates: network delays, LLM provider failures, tool timeouts, trust score manipulation, memory corruption, and concurrent access races. The framing is deliberate: the only way to know if an agent system is resilient is to break it intentionally.
A release readiness gate should require evidence that adversarial and chaos testing has been completed — not assumed. The SRE package also defines agent-specific SLOs: when more than one percent of agent actions violate policy, capabilities are automatically restricted. Confirming these thresholds are set and tested before release is part of the gate.
Release Readiness Question 5: Can We See What the Agent Is Doing?
An agent cannot be governed in production if its actions are not observable. The release gate should confirm that logging, monitoring, and alerting are operational before the system goes live — not configured after the first incident.
The AGT exports metrics through OpenTelemetry to any compatible platform — Prometheus, Grafana, Datadog, Arize, Langfuse, and others. Key metrics include policy decisions per second, trust score distributions, ring transitions, SLO burn rates, and circuit breaker state.
These are governance metrics — the signals that tell you whether the agent is operating within its approved boundaries at runtime. Confirming they are flowing to the right dashboards and triggering the right alerts is a release readiness checkpoint, not a post-deployment task.
Release Readiness Question 6: Does the System Meet Its Compliance Obligations?
The AGT's Agent Compliance package provides automated governance grading mapped to the EU AI Act, HIPAA, and SOC 2, as well as evidence collection across all ten OWASP agentic risk categories. A separate alignment document maps AGT controls to NIST AI RMF subcategories.
For release readiness, this means compliance verification can be run against the system as it actually exists at release — not as it was designed months earlier. EU AI Act Article 9 requires a risk management system that runs throughout the full lifecycle. The release gate is where that requirement meets the production system for the first time.
What the Toolkit Doesn't Cover — And Why That Matters
Microsoft's own limitations documentation is transparent about the boundaries of what the AGT can and cannot do. Three confirmed gaps are worth understanding before relying on it as a complete governance solution.
First, the toolkit does not detect hallucinated content passed into an allowed tool. If an agent generates a plausible but incorrect value and passes it to a permitted API call, the policy engine sees a permitted action and allows it. The governance layer operates at the action level, not the content-truth level.
Second, it does not reliably catch indirect prompt injection — where malicious instructions are embedded in data the agent retrieves, rather than in the original user input. This is one of the harder unsolved problems in agentic security, and the AGT does not claim to solve it.
Third, the audit trail records what the agent attempted and whether governance allowed or denied it — it does not verify whether the action actually succeeded in the external system. A permitted API call that fails silently in the external service will appear as an allowed action in the audit log.
These are not criticisms of the toolkit — they are honest boundaries that Microsoft documents publicly. They are also the reason that the AGT, for all its coverage, is not sufficient on its own. It is a powerful technical enforcement layer. It is not a substitute for governance judgment.
The Role of Human Judgment
The AGT automates what can be automated: policy enforcement, identity verification, compliance grading, chaos testing, and audit logging. What it cannot automate is the governance decision — the considered, documented, human judgment that a system is appropriate to deploy, that the risks are understood and accepted, and that the right stakeholders have signed off.
That judgment is what release readiness formalises. A mature release readiness gate uses the AGT to generate the evidence base — policy verification outputs, identity configuration reviews, chaos test results, compliance grades, observability confirmations — and then brings a governance stakeholder into explicit sign-off.
Tools enforce policy. People make the go/no-go call. Both are necessary. Neither replaces the other.
The Practical Takeaway
Microsoft built nine packages to address the governance gap in agentic AI production deployments — and unlike most governance tooling, it covers the full lifecycle from pre-deployment checks through runtime enforcement to decommissioning. That is a significant step forward for the field.
If your organisation is deploying agentic AI, the AGT is worth evaluating seriously. And if your governance program doesn't yet have a structured release readiness gate, the architecture of this toolkit is a useful map of what one should cover — and what human judgment still needs to sit alongside it.