Microsoft AGT is a horizontal, MIT-licensed runtime governance layer that covers the OWASP Agentic Top 10 risks for any AI agent. Axiru is a money-specific decision layer for refunds, credits, payouts, and adjustments — with prebuilt financial rule primitives and a tamper-evident financial ledger. Different problems, and the right answer is usually both: AGT under the agent runtime, Axiru on the money exits, joined by the @axiru/agt-extension adapter.
Axiru
Microsoft AGT
Partial means the capability is possible but not turnkey. Our read based on public docs and onboarding conversations; corrections welcome.
| Capability | Axiru Money-movement decision layer | Microsoft AGT Open-source agent runtime governance |
|---|---|---|
Money-specific decision policy (refunds, credits, payouts) Axiru ships pre-built rule primitives for refund amount, customer history, time windows, goodwill caps, dispute outcomes. AGT is action-agnostic — you write the financial semantics yourself in YAML/Rego/Cedar. | ||
OWASP Agentic Top 10 runtime coverage AGT was built around this scope. Axiru leans on AGT (or its own primitives) for the agent-runtime risks below the money layer. | ||
Sub-millisecond deterministic policy engine AGT's published p99 is below 0.1 ms. Axiru's policy engine is deterministic and fast but optimized for pre-execution refund evaluation, not in-process agent kernels. | ||
Stripe Connect / native money-movement integrations Axiru has direct Stripe ingestion, refund interception, and decision receipts. AGT does not ship Stripe-specific governance. | ||
Framework-agnostic agent adapters (LangChain, CrewAI, ADK, etc.) AGT ships 20+ adapters out of the box. Axiru integrates via the @axiru/agt-extension package which sits on AGT's middleware pipeline. | ||
Cryptographic agent identity + zero-trust action authorization | ||
Human-in-the-loop approval routing with full request context Axiru routes edge-case decisions to the right approver with policy reasoning and a one-click decision receipt. AGT supports action-level approvals as primitives but does not ship a finance approver UI. | ||
Tamper-evident, append-only financial decision ledger Axiru's ledger is purpose-built for SOX / ICFR audits over outbound dollars. AGT collects audit logs but is not a financial system of record. | ||
Shadow-mode replay on the last 90 days of real Stripe activity Quantify refund leakage on your own history before turning enforcement on. Not part of AGT's scope. | ||
Per-agent kill / freeze / quarantine on money-moving actions Axiru exposes an explicit agent-state surface scoped to financial actions. AGT has runtime kill switches at the agent-OS layer. | ||
Plain-language, versioned policies with policy-version on every receipt | ||
EU AI Act / Colorado AI Act / HIPAA / SOC 2 evidence mapping AGT's Agent Compliance package automates this for general agentic risk. Axiru produces the financial-controls evidence (refund approver, policy version, dollar-amount audit trail) that AGT does not generate. | ||
Self-hostable open-source MIT package AGT is OSS by design. Axiru's commercial backend is proprietary; the @axiru/agt-extension adapter we publish is MIT. | ||
Officially supported AGT extension (drop-in adapter) @axiru/agt-extension hooks AGT's middleware pipeline and routes money-moving actions to Axiru's policy engine. See the agt-extension brief. |
We build Axiru. We also know when the other answer is the right answer. Here it is.
Pick Microsoft AGT when the core question is “how do we govern this agent runtime safely?” — rogue agent behavior, memory poisoning, goal hijacking, plugin supply chain, RL training risks, agents calling many tools across many domains. AGT was built around the OWASP Agentic Top 10 with deterministic sub-millisecond enforcement, and it's MIT licensed so you can run it in-cluster with no vendor on the path.
If you have a heterogeneous agent fleet — agents that write code, manage infra, draft customer messages, orchestrate other agents — AGT is the right layer to start with because it covers the broad runtime risks Axiru is not in the business of solving.
For teams already on Azure (Foundry Agent Service, AKS, Container Apps), AGT's first-class integrations make it the cheapest path to a production-grade agent governance posture.
Pick Axiru when the question is specifically “should this refund / credit / payout go out, who signed off, and can finance audit it?” — refund leakage, duplicate refunds, AI agents over-crediting, goodwill getting out of hand, SOX-style controls on outbound payouts.
You get money-domain rule primitives that would otherwise be hundreds of lines of Rego, an immutable financial ledger that reconciles to your books, approval routing with full charge / customer / dispute context, and shadow-mode replay against your last 90 days of real Stripe activity. None of that is in AGT's scope, by design.
Teams running an AI support agent with refund permissions get this specifically: Axiru governs the human and the agent identically, with the same policy and the same audit trail.
The clean architecture is AGT under the agent runtime, Axiru on the money exits. AGT enforces the OWASP Agentic Top 10 controls — agent identity, ring isolation, kill switches, semantic intent classification, plugin supply chain — at the runtime layer, sub-millisecond per call, on every action the agent attempts.
When the agent reaches for a money-moving tool (Stripe refunds, Connect transfers, payouts, adjustments), the @axiru/agt-extension adapter routes that specific action class to Axiru's policy engine. Axiru evaluates the money-domain rules, may route the decision to a human approver, and returns allow / deny / approval-required back to AGT — which then either executes or blocks the underlying tool call.
The extension is MIT licensed, fails closed by default, and ships the same decision-receipt format Axiru's first-party clients use. AGT's audit log and Axiru's financial ledger join 1:1 on the action ID, so your security review and your finance audit see the same truth.
Not really — they solve different problems and most teams running autonomous agents on money should run both. AGT is a horizontal runtime governance layer that addresses all ten OWASP Agentic Top 10 risks (memory poisoning, goal hijacking, rogue agents, etc.) at the agent-OS layer, sub-millisecond, framework-agnostic. Axiru is a money-specific decision layer that sits in front of refunds, credits, payouts, and adjustments — with prebuilt financial rule primitives, an immutable financial ledger, approver workflows, and Stripe-native ingestion. The clean architecture is AGT under the agent runtime and Axiru on the money exits, joined by our @axiru/agt-extension adapter.
Three things AGT was not built to provide: (1) financial decision primitives — refund amount thresholds, customer-history rules, goodwill caps, dispute-outcome conditionals — that you would otherwise hand-write in Rego/Cedar; (2) a tamper-evident financial ledger that finance and audit can reconcile against your books; (3) human-in-the-loop approval routing with refund-specific context (original charge, policy version, prior refunds, dispute history) and a one-click decision receipt. AGT gives you the runtime; Axiru gives you the money-domain rules and the audit trail finance asks for.
If you only run agents that move money on Stripe, Axiru is enough on its own — it ingests directly and intercepts the refund call. If you have agents doing many other autonomous things — code execution, infra changes, customer messaging at scale, multi-tool reasoning — AGT covers the broader OWASP Agentic Top 10 risks (rogue agent behavior, memory poisoning, goal hijacking, plugin supply chain) that are out of Axiru's scope. The two stack cleanly via the @axiru/agt-extension adapter.
It's an MIT-licensed npm package that hooks AGT's middleware pipeline. When an agent is about to call a money-moving tool (refunds.create, transfers.create, payouts.create, etc.), AGT's policy chain dispatches to the extension; the extension forwards the action to Axiru's policy engine; Axiru evaluates against your rules, may route for approval, and returns allow / deny / approval-required to AGT. The extension fails closed by default, so a network blip or Axiru outage results in a deny on money-moving calls — which is the conservative behavior finance teams want.
You can — and for very simple refund logic (amount cap, single approver) it works fine. The cost shows up when policies need to reference your business state: "refund only allowed if customer's lifetime refund total is under $200 and the order is older than 14 days and there's no open dispute." That requires lookups, joins, and finance-grade audit data — which is what Axiru's policy engine and ledger handle natively. Teams that try to push that into Rego usually end up rebuilding what Axiru already ships.
Microsoft AGT is free and open source under MIT — your cost is the engineering time to deploy, configure, and maintain the policies. Axiru is commercial: shadow mode is free, live enforcement is usage-based on governed money-moving decisions starting at $0.20 each on Growth, with Pro and Scale plans for higher volume. The two cost structures are not directly comparable — AGT charges nothing for the runtime; Axiru charges per money-decision governed.
Partially, and only inside the money-moving surface. We govern the financial actions themselves (preventing rogue refunds, enforcing policy version, requiring approver identity for high-value adjustments), which maps to several of the ten categories in the money context. For full coverage of memory poisoning, goal hijacking, plugin supply chain, RL training risks, and the broader runtime patterns AGT was designed for, run AGT alongside Axiru.
Connect Stripe in minutes, upload history, and watch shadow mode replay every refund against the policy you would have run. No code, no enforcement risk, no cost.
Start in shadow mode first. Move to live enforcement later.
Sources: Microsoft Open Source Blog (April 2, 2026)opensource.microsoft.com; AGT architecture deep-dive on Microsoft Tech Community (April 9, 2026); independent coverage on Help Net Security (April 3, 2026). Latency, OWASP coverage, and licensing claims reflect AGT's published documentation as of May 2026; we update this page when either product changes meaningfully.