On April 2, 2026, Microsoft released the Agent Governance Toolkit — an open-source library for enforcing policy on AI agent actions before they execute. It is the first tool from a major platform vendor that takes the governance problem seriously at the runtime layer, and it's a significant piece of engineering: sub-millisecond policy evaluation, post-quantum cryptography already shipped, and a 9,500+ test corpus with continuous fuzzing.

If you're evaluating agent governance infrastructure, AGT belongs in the conversation. This post is for the enterprise architect who has read the announcement and is now asking the natural follow-up question: where does this fit, what does it cover, and what does it leave open?

The answer matters because "governance" means different things at different layers of the stack. AGT solves one well-defined version of the problem. Waxell solves the full version. Understanding the boundary between them is how you make the right infrastructure decision.

TL;DR

What AGT Is

AGT is structured as a monorepo of nine independently installable packages. The core components:

Agent OS is the policy engine. It intercepts agent tool calls and evaluates declarative rules written in YAML, OPA/Rego, or Cedar across a documented four-stage pipeline: pre_input → pre_tool → post_tool → pre_output. Microsoft's own numbers: 0.012ms on a single rule, 0.029ms at 100 rules. The evaluation happens in-process, in the same Python (or TS/.NET/Rust/Go) runtime as your agent. The pipeline's standard tool-call interception already does some work on the output side, too — Microsoft's documentation lists output sanitization (stripping PII from tool results, appending verification footers), non-JSON smuggling prevention, and per-agent, per-tool rate limiting as part of the same interception layer. Policies can also be reloaded at runtime without restarting the agent — via an explicit reload_policies() call, or automatically when OPA is running in Remote Server mode — though policies are still authored as files (YAML, OPA/Rego, or Cedar), not through a no-code interface aimed at non-technical compliance staff.

AgentMesh handles agent identity using the SPIFFE/SVID standard — the same cryptographic workload identity model used for service-to-service mTLS across cloud-native infrastructure. Messages between agents are encrypted with the Signal protocol. AgentMesh also provides the infrastructure for the kill switch: a signal that propagates across the mesh and halts a target agent.

Agent Runtime implements four privilege rings, a saga orchestrator for multi-step rollback, and the kill switch. Privilege rings control what classes of action an agent can take; the saga orchestrator ensures that if a multi-step workflow fails partway through, the completed steps can be reversed.

Agent SRE provides reliability engineering primitives: SLO definitions, chaos injection hooks for testing, and circuit breakers that can pause an agent workflow when error rates breach a threshold.

Agent Compliance ships the agt verify CLI, which maps your agent stack against the OWASP Agentic Top 10 and generates a signed attestation on every deployment. Microsoft's documentation also lists mapping support for the EU AI Act, NIST AI RMF 1.0, and SOC 2 through the same attestation approach — a broader compliance surface than at AGT's April launch.

Agent Hypervisor does reversibility verification: before a potentially irreversible action executes, the Hypervisor checks whether it can be undone. Actions that can't be reversed are blocked or require explicit override.

Agent Discovery scans processes, configs, and repositories for AI agents that haven't been registered in your governance system — the "shadow agent" detection problem.

Agent Marketplace handles plugin lifecycle management — Ed25519 signing, verification, trust-tiered capability gating, and supply-chain security for third-party agent plugins.

Agent Lightning provides governance for reinforcement learning training: policy-enforced RL runners and reward shaping that enforces zero policy violations during training.

AGT also ships a named MCP Security Gateway package — tool poisoning detection, drift monitoring, typosquatting detection, and hidden-instruction scanning — plus a dedicated .NET MCP extension package. If your governance question is specifically about MCP tool risk, this is worth knowing about rather than assuming it's uncovered.

The multi-language support is real and broad: Python has full support; TypeScript, .NET, Rust, and Go have subsets — five language packages and 21 total framework integration packages in all. The test corpus is 9,500+ tests with ClusterFuzzLite fuzzing running continuously against the policy engine. Post-quantum cryptography is already shipped: agent identities are signed with both Ed25519 and ML-DSA-65.

AGT is also clear about what it does not do. From the documentation: "This is not a prompt guardrail or content moderation system. It governs agent actions, not LLM inputs or outputs." The policy engine runs in-process — AGT's own documentation recommends container isolation as a compensating control for higher-risk deployments. Workflow-level policies (evaluating a sequence of calls rather than a single invocation) and intent declaration are on the roadmap but not yet available — that's a meaningful boundary, and it's a different boundary than "pre-execution only," which the rest of this post explains.

Where AGT Fits Next to Microsoft's Other Governance Product

AGT isn't Microsoft's only governance-adjacent release. Microsoft Agent 365 reached general availability on May 1, 2026 — a managed, four-layer framework unifying Purview, Entra ID, and Defender for tenant-level agent governance. AGT's own documentation is explicit that AGT and Agent 365 sit at different layers: AGT is the per-agent runtime enforcement library that decides whether a specific tool call is allowed; Agent 365, along with the separate Azure AI Foundry Control Plane, operates at the fleet and tenant level — discovery, attribution, and policy administration across an organization's agents, closer to what Waxell's platform-wide policy engine and Connect operate.

The upshot for this post's "toolkit vs. platform" framing: it's still accurate that AGT itself is a library you deploy, configure, and upgrade rather than a hosted service Microsoft operates for you. But it's no longer accurate to describe Microsoft's overall governance stack as toolkit-only. If your organization is standardized on Microsoft infrastructure, AGT plus Agent 365 is a more complete answer today than AGT alone was at launch — worth evaluating as a pair, not just AGT in isolation.

What Waxell Is

Waxell is a hosted, multi-tenant SaaS platform built across three product planes.

Runtime provides durable execution primitives for AI agents: spawn sub-agents, suspend for arbitrary durations, wait for human approval, resume after a signal or timer. The Envelope state machine checkpoints every agent run to Postgres after each await. If the worker process crashes, the run resumes automatically from the last checkpoint — no deterministic replay required.

Observe is the distributed tracing and cost layer. It auto-instruments 200+ libraries at process start via pip install waxell-observe[all] — LangChain, CrewAI, AutoGen, the Anthropic SDK, the OpenAI SDK, and many others. Every LLM call produces a span with token counts, latency, model, and cost. Every tool call is recorded with its arguments and output. The RunEdge DAG links every spawn, signal, resume, and cross-session bridge causally — so when Agent A spawns Agent B which calls a tool that triggers Agent C, the full causal chain is browsable in the trace explorer.

The Dynamic Policy Engine is the governance layer. Waxell's policy engine is injectable at runtime without redeployment, and it's built for authorship by the people who own the policy, not just the people who can write YAML. Waxell ships 50+ policy categories — covering data handling, cost, tool access, output content, identity, inter-agent communication, and more — each with scoping controls. Policy assignment is dynamic: different agents and fleets can run under different policy sets. The incident disposition model mirrors cloud infrastructure security: warn, block, or redact, scoped per category. A compliance officer can push a policy change through the platform UI without opening a terminal, editing a config file, or filing a deployment ticket.

The Governed Data Access Layer extends policy enforcement beyond tool calls to the data retrieval layer. Waxell's Signals and Domains schema lets teams declare which agents can access which data sources, at what granularity, under what conditions. Enforcement happens at the retrieval boundary — before the data enters the agent's context — closing a gap that tool-call governance alone cannot close.

Where AGT Has an Advantage

Multi-language support. AGT ships working policy enforcement for Python, TypeScript, .NET, Rust, and Go. If your agent fleet isn't Python-only, AGT is the policy layer that works for your whole stack. Waxell is currently Python SDK only.

Post-quantum cryptography, shipped. AGT signs agent identity with both Ed25519 and ML-DSA-65 (CRYSTALS-Dilithium). For organizations with a post-quantum compliance timeline, that checkbox is already ticked. Waxell's AXID uses Ed25519; ML-DSA-65 is on the roadmap.

Formal OWASP attestation, and broader compliance mapping. AGT ships the agt verify CLI, which produces a signed attestation mapping your deployment against all ten OWASP Agentic Top 10 risk categories. Microsoft's documentation also lists mapping support for the EU AI Act, NIST AI RMF 1.0, and SOC 2 through the same tooling. Both AGT and Waxell are built on the same underlying standards — the difference is the formal mapping and the auditable CLI artifact. If your compliance team needs that specific deliverable across multiple frameworks, AGT produces it.

Test depth and fuzzing. 9,500+ tests plus continuous ClusterFuzzLite fuzzing against the policy engine. For security-critical deployments where test coverage is an auditable artifact, that corpus is a meaningful signal.

A dedicated MCP security layer. The named MCP Security Gateway package addresses tool poisoning detection, drift monitoring, typosquatting, and hidden-instruction scanning, with a matching .NET MCP extension package. If MCP tool risk specifically is your concern, this is a real, named capability.

Open-source, no vendor dependency. AGT is open-source under the MIT license. No usage cost, no API key, no hosted infrastructure. If your organization's policy is to not depend on external SaaS for security-critical functions, AGT's deployment model is compatible with that constraint in a way Waxell's is not.

Microsoft distribution. If your organization runs Azure, Semantic Kernel, or AutoGen, AGT ships with native adapters and Microsoft's distribution behind it — and, as of May 2026, Microsoft Agent 365 as a managed layer above it.

Where Waxell Has the Advantage

The Execution Arc

The most fundamental difference is the boundary each system enforces around — not, as earlier versions of this comparison framed it, "before a call" versus "after a call fires."

AGT's pipeline runs four stages around each tool call — pre_input, pre_tool, post_tool, and pre_output — and its post_tool/pre_output stages already do real output-side work: sanitizing tool results, stripping PII, and appending verification footers before the agent (or the next step) sees them. That's a genuine enforcement surface after the call fires, not nothing, and earlier language in this post that described AGT as "stepping aside" once a call is allowed understated it.

What AGT's pipeline doesn't do is anything that spans turns or sessions. It evaluates and acts within the lifecycle of a single tool call. A budget that accumulates across a 40-turn spawn tree, a human review gate that suspends a run for hours or days, an output gate that blocks propagation to a different agent running in a different session — none of these fit inside a per-call pipeline, however many stages it has.

Waxell governs across that longer boundary. Pre-execution and post-tool-call evaluation work similarly to AGT's model. But Waxell also enforces mid-run, across the full spawn tree: BudgetLedger tracks spend across the entire tree in real time and can halt a run the moment a cost threshold is crossed, independent of any single tool call's outcome. Human review gates suspend a run mid-execution — for hours or days — until a reviewer acts, something no per-call pipeline can express. And Waxell governs post-execution at the run level: output gates that block propagation across a spawn boundary, audit closure, and causal graph completion.

The six failure modes that matter in production — runaway loops, scope creep, data leakage, hallucination-in-action, prompt injection, and cascade failures — mostly unfold across turns and sessions, not within a single tool call. A per-call pipeline, even a four-stage one, can catch a bad output on the call where it appears. It's a different kind of enforcement than stopping a loop that's accumulating cost across 40 turns, or gating a decision between what an agent decided in one session and what it dispatches in the next.

The Dynamic Policy Engine

AGT's policies are authored as files — YAML, OPA/Rego, or Cedar — deployed in a policies/ directory. That's still a developer-oriented authorship model: there's no interface built for a compliance officer to write or adjust a rule directly without touching a file format. But applying a change to an already-authored policy doesn't require a full redeploy cycle: AGT supports reloading policies at runtime, via an explicit reload_policies() call or automatic hot-reload when OPA runs in Remote Server mode, without restarting the agent.

The real distinction isn't "AGT requires a deployment, Waxell doesn't" — both can apply a policy change without a full redeploy today. It's who is capable of making that change. AGT's format assumes someone comfortable authoring YAML, OPA/Rego, or Cedar. Waxell's policy engine is built for a compliance or security team member working through the platform UI, with no file format standing between them and the rule they want enforced. AGT makes governance an engineering-adjacent concern — someone technical still has to author the rule. Waxell makes it a fully organizational concern.

The incident disposition model adds another dimension. Where AGT's enforcement is allow/deny (plus the output sanitization built into its post-tool stage), Waxell's disposition options are warn, block, or redact — scoped per policy category. A tool call that trips a budget threshold can generate a warning and route to human review before hard blocking. A response containing sensitive data can be redacted before it reaches the next agent in the chain rather than halting the run entirely. Proportionate response is how mature security infrastructure works.

The Data Layer

AGT governs tool calls, including some inspection of tool call outputs at its post-tool stage. It has no mechanism to enforce policy on what data an agent retrieves before that data enters the agent's context. An agent with permission to call a search or retrieval function can pull data into context that a downstream sanitization step never inspects, because sanitization in AGT's model runs against tool outputs, not against everything the agent subsequently reasons over or passes along.

Waxell's Signals and Domains schema closes this gap at the retrieval boundary. Declare which agents can access which data sources, at what granularity, under what conditions. Enforcement happens before the data enters the agent's context — not after, at the point where a tool call returns. An agent can be well-governed at the AGT tool-call and output-sanitization level and still carry ungoverned data through its reasoning and into a downstream spawn. The governed data access layer is the answer to that.

Observability and Causal Lineage

AGT's observability surface is an audit log of policy events and a flight recorder for post-mortem policy replay. Both are valuable. Neither is a span-level trace.

When debugging a production incident — an agent that ran for 40 turns, consumed significant budget across LLM calls, spawned several sub-agents, and then failed — AGT tells you which policy rule fired, at which stage of its pipeline, and what the sanitized output looked like. Waxell tells you every turn, every token, every tool call, every spawn edge, in a browsable causal graph.

Production agent failures rarely announce themselves through policy violations. Policy violations are rare by design — they're the catch, not the signal. The failures that actually hurt — cost overruns, reasoning regressions, emergent behavior — don't trigger any rule. They only become visible in spans.

The RunEdge DAG goes further: when Agent A spawns Agent B which calls a tool that triggers Agent C across a different session boundary, the full causal chain is recorded with typed edge kinds (spawn, signal_fire, domain_callback, cross_session_bridge). An incident that traces back through four spawn levels across three sessions is navigable in the UI in under a minute. A sequential audit log can't answer "what caused this?" — it can only answer "what happened at each policy checkpoint?"

Cost Tracking and BudgetLedger

AGT has rate limiting (per-agent, per-tool) but no model cost table, no token aggregation, and no billing attribution. This is documented, not a criticism — rate limiting and cost tracking solve different problems. But cost attribution is a real operational need the moment you run agents at scale on behalf of customers.

Waxell's SystemModelCost records every LLM call with tokens and cost. ModelCostOverride handles custom model endpoints. Pass a session ID and you get per-user, per-tenant cost attribution without building the reporting layer yourself.

The BudgetLedger primitive adds enforcement: it's a real-time, tree-scoped cost ledger that agents can query mid-run. A policy rule that says "block this tool call if the spawn tree has spent over $10" queries the live BudgetLedger as its condition. The policy team writes the threshold; the enforcement is real-time and spans the whole tree, not just a per-agent rate.

Durable Execution

AGT's saga orchestrator handles multi-step rollback within a single session. It doesn't provide suspend-for-days. The use cases that need cross-session durable execution — wait for payment confirmation, pause for human approval, nightly batch workflows that sleep until an event — aren't addressable with a saga orchestrator.

Waxell Runtime provides native durable execution with no determinism requirement. Agent state checkpoints to Postgres after each await. If the worker crashes during a sleep, the run resumes automatically from the last checkpoint when a worker comes back up.

External Agent Coverage

AGT instruments agents running inside its supported frameworks. It has no surface for agents running in external environments — developer tooling, CI pipelines, third-party integrations — that operate outside framework instrumentation.

Waxell's external agent observability covers these cases via the Waxell installer, which drops configuration that routes structured events from external agents into the same governance surface as your framework-built agents. All three contexts — external agents, framework agents, and the agentic runtime — appear under one observability plane with unified attribution.

The Trust Boundary Question

AGT's own documentation is direct about the same-process model: the policy engine and the agent run in the same Python process. If a compromised dependency patches the evaluation function to always return allow, an in-process check can't detect it. AGT recommends container isolation per agent as a compensating control.

This is an honest statement of a real trade-off, not a weakness unique to AGT. Every in-process policy library faces the same boundary.

Waxell's out-of-process enforcement for domain endpoints works differently: for risky actions, the agent SDK sends an intent to a server-side endpoint. The server re-verifies the AXID, re-checks policy, and debits the BudgetLedger before returning. The agent process cannot bypass this by patching the SDK — it cannot proceed without the server response. The enforcement is strong for the action classes covered by domain endpoints; it is not a full OS isolation layer either.

For internal agent workloads with vetted dependencies and container-per-agent deployment, AGT's same-process enforcement is sufficient. For regulated environments where an external audit trail of enforcement is required, or for workloads running third-party tools, out-of-process enforcement for the highest-risk actions is the more defensible architecture.

Decision Framework

AGT is the right choice when:

• Your agent stack includes TypeScript, .NET, Rust, or Go and needs cross-language policy enforcement

• You have a near-term post-quantum compliance audit requirement

• Your compliance team needs a signed attestation across OWASP Agentic Top 10, EU AI Act, NIST AI RMF, or SOC 2, produced by a CLI

• Your organization has a policy against external SaaS dependencies for security-critical functions

• You're already standardized on Microsoft infrastructure — especially if you're pairing AGT with Microsoft Agent 365 for the tenant-level layer

Waxell is the right choice when:

• You need governance across the full execution arc — including enforcement that spans turns, sessions, and a full spawn tree, not just within a single tool call's pipeline

• Policy changes need to happen without any file format or engineering-adjacent skill in the loop — compliance and security teams need to own their own policies end to end

• Your risk surface includes data retrieval into context, not just tool dispatch and tool output

• You need hosted observability, cost tracking, and causal lineage without building the infrastructure

• Your agents need durable execution across session boundaries

• Your agent fleet spans external environments that can't run framework adapters

Frequently Asked Questions

Is AGT a replacement for Waxell?
No. AGT is a per-call policy enforcement pipeline. Waxell is a hosted platform for running, observing, and governing agents across turns, sessions, and spawn trees. AGT doesn't ship observability, cost tracking, durable execution, or data layer governance. The gap between them is real and documented.

Does Waxell have its own policy layer?
Yes — and it goes further than a companion library. Waxell's dynamic policy engine supports 50+ policy categories with scoping controls, runtime-injectable policies, per-agent and per-fleet policy assignment, and warn/block/redact disposition options. It's manageable by non-technical users directly through the platform UI, with no policy file format in between.

What is AXID?
AXID (Agent Execution Identity) is an Ed25519-signed JWT minted per run by Waxell. It carries tenant ID, agent slug, run ID, delegated sub-user ID, spawn-chain parent AXID, and a 5-minute TTL. It's attached as an HTTP header on every outbound action. AXID is distinct from AGT's AgentMesh/SPIFFE identity: SPIFFE identifies the service; AXID identifies the specific run and its causal chain.

If AGT's pipeline runs pre- and post-tool-call, what happens to mid-run failures?
AGT's four stages evaluate around a single tool call's lifecycle — they don't accumulate state across turns or sessions. A loop that's building across turns, a spawn tree that's accumulating cost past a threshold, a review gate that needs to suspend a run for hours — none of these are addressable within a per-call pipeline, no matter how many stages it has. Waxell's mid-execution enforcement (BudgetLedger, human gates) and continuous span-level tracing are designed specifically for this category of failure.

Does Microsoft have a hosted governance platform, then?
Not built into AGT itself — AGT remains a library you deploy and operate. But Microsoft Agent 365, which reached general availability May 1, 2026, is a managed, tenant-level governance layer (Purview, Entra ID, Defender) that sits above AGT and other agent frameworks. If you're evaluating Microsoft's governance stack as a whole rather than AGT specifically, Agent 365 is the piece that answers "is there a hosted option."

What does "toolkit vs platform" mean in practice?
A toolkit is a set of components you integrate and operate yourself. A platform is a service that manages infrastructure on your behalf. AGT itself requires you to deploy, configure, upgrade, and maintain it — that part of the framing still holds. Waxell is a SaaS product: you instrument, the platform operates the rest. The distinction matters most when you're evaluating build vs. buy on observability, cost attribution, durable execution, and cross-session data layer governance — all of which you'd need to build and operate yourself even with AGT and Agent 365 both in place.

Is AGT production-ready?
Microsoft labels it Public Preview as of April 2026, version 3.2.2, with active development continuing since. The test corpus and performance numbers suggest it's production-ready for early adopters. AGT's own documentation recommends container isolation for higher-risk workloads given the same-process trust boundary.

Waxell is the hosted platform for running, observing, and governing AI agents in production. Built on millions of agentic executions. See the platform overview or book a reference architecture review.

Sources

• Microsoft Agent Governance Toolkit — GitHub — primary source for all AGT component descriptions, performance numbers, and non-goals

• Introducing the Agent Governance Toolkit — Microsoft Open Source Blog, April 2, 2026

• Agent Governance Toolkit: Architecture Deep Dive — Microsoft Tech Community

• OWASP Agentic Top 10

• SPIFFE — Secure Production Identity Framework For Everyone

• Govern AI Agents on App Service with Microsoft AGT — Microsoft Tech Community

• Waxell Platform Overview

• Waxell Governance Documentation