Agent governance · Where Containment.ai fits

Both products rule on the tool call.
Only one also rules on every byte crossing the LLM boundary.

Containment.ai enforces at two points for autonomous agents: an SDK that rules on every governed tool call before it executes — the same layer Microsoft's AGT occupies — and an HTTPS proxy in front of OpenAI, Anthropic, Bedrock, and Azure OpenAI that inspects every prompt and completion and decides whether the regulated content inside the call is allowed to leave. (For the highest-assurance end, the same discipline is delivered in-path by the flagship Mission Authorization Gateway.) This page is an honest, side-by-side look at where each product is stronger — and why teams shipping agents on regulated data end up needing the content-level enforcement AGT doesn't ship.

Review your agent boundary See the Agent Governance product

Looking for the product, not the comparison? Start with Agent Governance. Last reviewed 2026-07-12; revised when a release changes the comparison.

TL;DR

Both products enforce at the tool-call layer. Microsoft's Agent Governance Toolkit (AGT) does it with an in-process @govern wrapper; Containment.ai does it with the Agent Governance SDK, which rules allow / deny / modify / defer / step_up on every governed action before it executes. The difference is what sits above that layer: Containment.ai also enforces at the HTTPS boundary to the LLM provider — configurable content rules for PHI, MNPI, export-control indicators, secrets, prompt injection, and more, plus real-time redaction and a LiteLLM-based multi-provider proxy with no agent-framework lock-in.

AGT's genuine strengths are real and we name them: zero-trust agent identity (SPIFFE / DIDs), OWASP Agentic Top 10 coverage, and execution sandboxing. The honest pitch: if you ship autonomous agents on Azure Foundry, LangGraph, CrewAI, or the Microsoft Agent Framework on regulated data, AGT's identity and sandboxing primitives compose cleanly alongside Containment.ai — but only Containment.ai rules on the content the agent's calls actually carry.

Two layers of agent governance

AGT sits at the function-call boundary inside the agent process. Containment.ai sits there too — via the Agent Governance SDK — and additionally at the HTTPS boundary to the LLM provider, where content-level enforcement lives. AGT never sees that second layer.

Tool-call / action layer

Microsoft AGT

  • In-process SDK (@govern wrapper for Python, TS, .NET, Rust, Go)
  • Intercepts tool-function invocations: file ops, shell, MCP, inter-agent
  • Zero-trust agent identity (SPIFFE, Ed25519, DIDs)
  • OWASP Agentic Top 10 (10/10) + NIST AI RMF mappings
  • Decisions: allow / deny / require_approval
  • MIT, free, Microsoft-maintained
Tool-call layer + LLM-boundary layer

Containment.ai

  • ✓Agent Governance SDK rules on every governed tool call pre-execution — allow / deny / modify / defer / step_up
  • ✓HTTPS proxy in front of OpenAI, Anthropic, Bedrock, Azure OpenAI
  • ✓Inspects every prompt and completion crossing the boundary
  • ✓Configurable deterministic content rules — PHI, MNPI, export-control indicators, secrets, PII, source-code leakage, prompt injection, shadow-AI, and more
  • ✓Decisions: allow / block / redact — agent keeps working, sensitive bytes don't leak
  • ✓Audit-grade decision logs designed for SOC 2, HIPAA, ISO 27001, ITAR, and EAR evidence needs
  • ✓Built for federal and regulated workloads: single-tenant deployment, with on-prem and air-gapped delivery on the roadmap (canonical status on our Trust page)

Honest feature matrix

No marketing-speak. Where AGT is stronger, we say so. Where we are stronger, we say so. Where the gap is structural, we explain it.

Capability Microsoft AGT Containment.ai
Architecture In-process SDK / function wrapper SDK at the tool dispatch + HTTPS proxy in front of LLM providers
Interception point Tool / function calls; inter-agent messages Governed tool calls (SDK) and every byte going to or from the LLM provider (proxy)
Decision verbs allow / deny / require_approval Tool call: allow / deny / modify / defer / step_up. LLM boundary: allow / block / redact (substitute sensitive content with placeholder; agent keeps working)
Zero-trust agent identity (SPIFFE / DID / mTLS) Yes — AGT's strength. No (we identify humans and orgs, not agents)
Execution sandboxing / privilege rings Yes — AGT's strength. No
OWASP Agentic Top 10 mapping 10/10 covered Partial — prompt-injection detection at the content layer plus pre-execution tool-call rulings via the SDK; no published 10/10 mapping. Identity and sandboxing classes remain AGT strengths.
PHI (HIPAA) detection Not in shipped scope Yes — dedicated detector
MNPI / insider-trading content detection Not in shipped scope Yes — dedicated detector
Configured export-control policy matching Not in shipped scope Yes — policy-configured matching. Containment does not make export-classification determinations.
Secrets / API-key leakage detection Not in shipped scope Yes — dedicated detector
Prompt-injection detection Yes (12-vector PromptDefense evaluator) Yes (content-pattern + behavioral signals)
Shadow-AI discovery Repo / process / config scanning Actual API traffic observation (catches BYOK / personal-key bypass)
Multi-LLM provider coverage LLM-agnostic at the tool layer (no provider-specific code) LiteLLM-based proxy — OpenAI, Anthropic, Bedrock, Azure OpenAI, and any LiteLLM-supported provider; no agent-framework lock-in
Tamper-evident audit log Merkle-verified Decision BOM — AGT's strength. Append-only audit_events; cryptographic chaining on the roadmap
Primary buyer Developer / platform engineer CISO / compliance / privacy officer
License / commercial MIT, free; Microsoft-maintained (Azure pull-through) Commercial — SaaS or single-tenant deployment; on-prem and air-gapped delivery on the roadmap
AARM (CSA) conformance Not yet claimed Aligned with AARM v1.0 — see our AARM page for per-requirement status

When does each matter?

Use AGT (alone) when…

  • You ship a developer tool or internal automation agent that does not touch regulated content.
  • Your primary need is zero-trust agent identity attestation or execution sandboxing — the primitives AGT ships that we don't.
  • Your compliance frame is OWASP Agentic Top 10, not HIPAA / SEC / ITAR / GDPR.

Use Containment.ai (with or without AGT) when…

  • ✓You need pre-execution rulings on the tool calls your agents make — the Agent Governance SDK covers the dispatch layer, so adopting AGT is not a prerequisite for governing agent actions.
  • ✓Patient data, customer records, source code, or financial material could end up in an LLM prompt.
  • ✓You need real-time redaction — let the agent keep working, but strip the SSN before it reaches OpenAI.
  • ✓You need to govern BYOK / shadow-AI — engineers with personal API keys bypass any SDK governance you ship inside the app.
  • ✓HIPAA, FedRAMP, SEC Rule 17a-4, ITAR, EAR, GDPR Article 32 are in scope.
  • ✓You use more than one LLM provider and need a single policy plane across all of them.
Run both

Run both when AGT's identity and sandboxing primitives matter to you: AGT attests who the agent is and sandboxes what it can touch; Containment.ai rules on what the agent does — at the tool dispatch and at the LLM boundary — and on what its actions carry. A first-party AGT adapter — so a single policy decision can route through both layers — is on our roadmap; contact us if you want early access.

Sources

This page is researched, not generated. Primary sources behind every claim above:

We will revise this comparison as AGT releases new versions. If you spot an inaccuracy, email engineering@containment.ai and we'll fix it within one business day.

See it stop a real prompt

30-minute demo. We'll show the proxy intercepting a HIPAA-PHI paste in real time, alongside a pre-execution tool-call ruling in the same flow.

Review your agent boundary See the Agent Governance product

Or email enterprise@containment.ai directly.