Alternative Comparison
Cordum vs Microsoft Agent Governance Toolkit
Out-of-process control plane vs in-process Python middleware: which architecture fits regulated AI agent deployments?
Technical Comparison8 min readMay 2026 Update
Trust Boundary
Cordum's out-of-process Safety Kernel survives agent process compromise; MS AGT's in-process middleware cannot.
PEP / PDP Split
Cordum implements the classic Policy Enforcement vs Decision Point split required by regulated industry auditors.
Audit Independence
Audit trails in Cordum are recorded by the control plane, independent of the agent's memory or emissions.
Teams searching for a Microsoft Agent Governance Toolkit alternative often focus on the trust boundary. While MS AGT is excellent MIT-licensed Python middleware for in-process governance, Cordum provides the out-of-process control plane required for regulated, multi-tenant, or audit-sensitive AI agent deployments.
Cordum is an out-of-process control plane. The Safety Kernel runs as a separate gRPC service behind mTLS, the scheduler dispatches work to capability-matched worker pools, and the policy decision point lives outside the agent's trust boundary. This page compares the two for technical buyers evaluating their agent governance stack.
Microsoft AGT vs Cordum: Comparison Grid
Compare the core architectural differences between in-process middleware and out-of-process governance.
| Evaluation Area | Cordum | Microsoft AGT |
|---|---|---|
| Trust boundary | Out-of-process. Safety Kernel runs as a separate gRPC service behind mTLS. Scheduler calls it before dispatch; the agent process never sees the policy decision being made. Compromise of the agent does not compromise the governance layer. | In-process. Microsoft's own README states the toolkit provides "application-level governance (Python middleware), not OS kernel-level isolation. The policy engine and agents run in the same process — the same trust boundary as every Python agent framework." Microsoft's recommended workaround: "Run each agent in a separate container for OS-level isolation." Trust boundary separation has to come from outside the toolkit. |
| Architecture analogue | Closer to a Kubernetes admission controller or hardware security module: separate failure domain, separate audit boundary, separate process identity. | Closer to a decorator / middleware library: same process, same memory space, same exception path. Useful for development and prototype governance. |
| Scheduler and orchestration | Built-in scheduler with capability-matched worker pools, stale job detection, pending replayer, and Redis-backed job state. Closer to Temporal-with-governance than to a guardrails wrapper. | No built-in scheduler. Assumes the agent runtime handles execution; policy is checked inline at the tool-call boundary. |
| Wire protocol | CAP v2 wire protocol with SDKs in Go, Python, Node.js, and C++. Workers and control plane communicate over NATS + gRPC; protocol is versioned, signed, and language-agnostic. | SDK packages per language (Python, TypeScript, Rust, Go, .NET) but no shared wire protocol. Each SDK speaks directly to the in-process policy engine. |
| Framework coverage | Runtime-agnostic. Any worker speaking CAP can be governed, regardless of the underlying agent framework. Native MCP server/tool/resource/action policy granularity. | Broader out-of-the-box framework integrations: LangChain, CrewAI, Google ADK, Microsoft Agent Framework, OpenAI Agents SDK, Haystack, LangGraph, PydanticAI, Dify, LlamaIndex. MCP gateway included but at coarser granularity. |
| Policy enforcement model | Pre-dispatch ALLOW / DENY / REQUIRE_APPROVAL / ALLOW_WITH_CONSTRAINTS decisions with deterministic latency budget (5ms p99 per ADR-001). Ed25519-signed policy bundles, hot-reload, simulation mode, structured decision explanations. | Pre-execution policy checks via the Agent OS package. Sub-millisecond enforcement claimed; coverage maps to all 10 OWASP agentic-AI risks. Plugin signing via Ed25519 in Agent Marketplace. |
| Multi-tenancy | Tenant overlays in policy engine: per-tenant deny lists, allow lists, and constraint sets that compose deterministically with base policy. Designed for control plane operators serving multiple isolated tenants. | Single-tenant orientation. Multi-tenancy is the integrating application's responsibility. No built-in tenant overlay model. |
| Audit and compliance | Structured run timeline with policy decisions, approval records, state transitions, and evidence pointers. Audit boundary is separate from agent process — auditor can verify the safety kernel's logs without trusting the agent's own emissions. | Agent Compliance package generates EU AI Act, HIPAA, and SOC2 evidence directly. Strong out-of-the-box mappings; audit trail lives alongside the agent process. |
| Licensing and cost | Open core. Community edition free; managed and enterprise tiers for SSO, multi-tenant ops, and audit-grade evidence retention. | MIT-licensed, free, open source. 1.4k GitHub stars, 255 forks as of 2026-04-02 launch. |
Technical Analysis (SERP & Documentation Coverage)
Mapping Microsoft's public disclosures and architectural claims against the requirements for regulated AI agent control planes.
| Source | What it covers | What it misses |
|---|---|---|
| Microsoft Agent Governance Toolkit README | Deterministic sub-millisecond enforcement, coverage of all 10 OWASP agentic-AI risks. | Does not provide trust boundary separation between agent and policy engine. |
| Microsoft Blog: Governing the Agentic Enterprise | Integration strategy across LangChain, CrewAI, and Microsoft Agent Framework. | Lacks multi-tenant overlay model for control plane operators serving isolated business units. |
| Microsoft Agent Marketplace Security Spec | Ed25519 signing for plugins and agent identity within the marketplace ecosystem. | No out-of-process audit trail that survives agent runtime compromise or memory corruption. |
MS AGT (In-process)
Middleware runs inside the agent process, sharing its memory and identity.
ms-agt-middleware.py
python
# Microsoft AGT (In-process Python middleware)
from ms_agt import GovernanceToolkit, OWASP_RISK_1
from langchain_openai import ChatOpenAI
# Middleware runs inside the agent process
toolkit = GovernanceToolkit(policies=["strict_safety"])
@toolkit.enforce(risk_map=OWASP_RISK_1)
def handle_customer_data(query):
# If the process is compromised,
# the decorator can be bypassed or patched
return agent.run(query)Cordum (Out-of-process)
Safety Kernel renders the decision before the worker is even dispatched.
cordum-dispatch.ts
typescript
# Cordum (Out-of-process CAP v2 Job)
import { CordumClient } from "@cordum/sdk";
// Safety Kernel runs in a separate process/identity
const client = new CordumClient({ mtls: true });
// Job is submitted to the control plane
// Decision happens BEFORE the worker ever starts
const job = await client.jobs.submit({
type: "customer.data.access",
payload: { query },
});When to pick which
- Pick Microsoft AGT if you are inside the Microsoft Agent Framework, want broad framework integrations and SOC2 evidence generation out-of-the-box, and the agent runtime and policy decision can share a trust boundary.
- Pick Cordum if your buyer is a CISO at a regulated company (financial services, healthcare, public sector), if you run multi-tenant agent fleets, if your auditor expects the policy decision to live outside the workload's trust boundary, or if you need scheduler-with-worker-pool orchestration semantics.
- Use both when a Cordum-governed worker uses MS AGT primitives in-process for framework-level checks. The two layers serve different jobs: MS AGT for in-flight policy at the framework boundary, Cordum for pre-dispatch policy at the orchestration boundary.
Related comparisons
Frequently Asked Questions
Is Cordum an alternative to Microsoft Agent Governance Toolkit?
Yes. Cordum is an out-of-process alternative to Microsoft AGT. While Microsoft AGT runs as in-process middleware (PEP and PDP in one trust boundary), Cordum separates the policy decision point (PDP) from the agent process, providing the trust boundary separation required for regulated AI deployments.
Why does out-of-process matter for AI agent governance?
Trust boundary separation. If the agent process is compromised — by prompt injection, dependency exploit, or runtime escalation — an in-process governance layer can be bypassed because the attacker holds the same memory, the same exceptions, and the same call stack. An out-of-process control plane sits behind a network boundary with its own identity, its own logs, and its own failure domain. Regulated industry auditors treat this distinction the same way they treat HSMs vs in-process key management: it is the architectural answer to "what happens when the workload is compromised?"
Should I use Cordum or Microsoft AGT?
Use Microsoft AGT if you are building inside the Microsoft Agent Framework or want broad framework coverage and SOC2 evidence generation in a free, MIT-licensed package. The toolkit is well-engineered and addresses all 10 OWASP agentic-AI risks. Use Cordum if your buyer is a CISO at a regulated company, you need trust boundary separation that an external auditor will accept, you run multi-tenant agent fleets, or you need scheduler-with-worker-pool semantics. The two are not mutually exclusive — Cordum can govern workers that themselves use MS AGT primitives in-process.
Is in-process governance sufficient for SOC2?
It depends on the auditor and the control objective. For Common Criteria around access control and least privilege, in-process governance can satisfy the technical control if the audit trail is tamper-evident. For control objectives that require separation of duties between the workload and the policy decision point — common in financial services and healthcare — auditors increasingly look for the policy decision to live outside the workload's trust boundary. This is the same pattern that drove enterprise adoption of out-of-process secret managers and HSMs.
Does Cordum integrate with Microsoft AGT?
Yes, on the worker side. A worker can use MS AGT's in-process primitives (policy checks, OWASP-risk coverage, framework integrations) and still be a CAP citizen governed by Cordum's Safety Kernel for cross-cutting decisions. The two layers serve different jobs: MS AGT covers in-flight policy at the framework boundary; Cordum covers pre-dispatch policy at the orchestration boundary.
What about Microsoft Authorization Fabric and Entra-protected agents?
Microsoft Authorization Fabric uses a PEP+PDP architecture for agents inside the Entra identity boundary. It is the right answer for agents whose identity, lifecycle, and authorization all live inside Microsoft Entra. Cordum is the right answer when agents need governance independent of any single identity provider, when workers run on customer-managed infrastructure across cloud boundaries, or when the audit boundary needs to be separable from the identity provider for regulatory reasons.
Is the architectural difference visible to a buyer in a demo?
Make it visible. Run a single demo where the agent is given a deliberately malformed plugin or a prompt-injection payload. With in-process governance, a sufficiently bad failure can corrupt the policy decision because they share memory. With out-of-process governance, the policy engine is unaffected — its logs continue, its decisions continue, the agent is contained. The demo is the test.
Searching for a Microsoft AGT alternative?
See how Cordum's Safety Kernel enforces policy before dispatch, with structured audit trails that survive agent compromise.