Skip to content
Cordum
Cordum
Deep Dive

In-Process vs Out-of-Process AI Agent Governance

Trust boundary separation is what regulated buyers' auditors expect — and what most of the new agent governance category cannot deliver.

Deep Dive12 min readMay 2026

Short answer for 2026

In-process AI agent governance runs the policy decision inside the agent's own process. That is the architecture of Microsoft Agent Governance Toolkit (shipped 2026-04-02), Galileo Agent Control (2026-03-11), APort's Open Agent Passport reference implementation, Guild.ai, NeMo Guardrails, and most LangChain callback systems. It is fast, easy to integrate, and sufficient for prototypes and single-tenant deployments where the agent runtime and the policy decision can share a trust boundary.

Out-of-process AI agent governance runs the policy decision in a separate process, behind a network boundary, with its own identity and audit trail. That is the architecture of Cordum's Safety Kernel (separate gRPC service behind mTLS), Microsoft's own Authorization Fabric for Entra-protected agents, and CyberArk's Secure AI Agents Solution. It is the same pattern that drove enterprise adoption of hardware security modules over in-process key management and Kubernetes admission controllers over in-pod policy.

The difference is decision-relevant for regulated buyers. Financial services and healthcare auditors increasingly expect the policy decision point to live outside the workload's trust boundary. If the agent is compromised — by prompt injection, dependency exploit, or runtime escalation — an in-process governance layer can be bypassed. An out-of-process control plane survives because the policy engine has its own identity, its own logs, and its own failure domain.

TL;DR
  • -Most products in the new agent governance category run in-process Python middleware.
  • -Out-of-process governance is the PEP+PDP pattern: enforcement in the workload, decision outside it.
  • -Trust boundary separation is what survives agent compromise; in-process governance cannot, by construction.
  • -Regulated industry auditors increasingly expect the policy decision to live outside the workload — same logic as HSMs vs in-process keys.
  • -For prototypes and low-stakes single-tenant deployments, in-process governance is fine. For regulated, multi-tenant, or audit-sensitive deployments, it is not.
On this page
Scope

This is an architectural deep dive for engineers and security architects evaluating AI agent governance for regulated, multi-tenant, or audit-sensitive deployments. It does not cover individual product feature comparisons; for those see the Cordum vs Microsoft AGT, Cordum vs Galileo, and Cordum vs Guild.ai comparison pages.

Trust Boundary

An out-of-process control plane survives compromise of the agent process; an in-process middleware cannot.

PEP / PDP Split

Policy Enforcement Point inside the workload calls a Policy Decision Point that lives outside it. Standard pattern in regulated systems.

Auditor View

Financial and healthcare auditors increasingly expect the policy decision to live outside the workload's process — same logic as HSMs vs in-process keys.

What "out-of-process" means

In access control vocabulary, the policy enforcement point (PEP) is the component that intercepts an action and asks "is this allowed?" The policy decision point (PDP) is the component that answers. In-process governance puts both in the agent's own process — the PEP is a decorator and the PDP is a function call. Out-of-process governance keeps the PEP inside the agent (because the action is taken by the agent) but moves the PDP to a separate process, separate identity, separate failure domain.

The PEP+PDP split is older than agentic AI. It is what XACML standardized in 2003. It is what Kubernetes admission controllers do (the API server is the PEP; the admission webhook is the PDP). It is what hardware security modules do for key operations. It is what banks have done for transaction authorization for decades. The novelty in 2026 is applying it to AI agents, not the pattern itself.

For an AI agent, "out-of-process" means: when the agent decides to call a tool, hit an API, modify state, or hand work to another agent, the decision to permit that action is rendered by a service the agent does not control. The agent receives back ALLOW, DENY, REQUIRE_APPROVAL, or ALLOW_WITH_CONSTRAINTS. The decision is signed, logged outside the agent, and attestable independently.

What runs in-process today

The agent governance category exploded between February and May 2026, and most of what shipped runs in-process. The honest list:

ProductArchitectureReleased
Microsoft Agent Governance Toolkit (MS AGT)Python middleware inside agent runtime2026-04-02, MIT
Galileo Agent ControlControl library + observability backend2026-03-11, Apache 2.0
APort / Open Agent Passport (OAP)Apache 2.0 reference impl, in-process authorization layerMar 2026 paper
Guild.aiSaaS-first control plane with managed integrations2026-04-29
NeMo GuardrailsPython rails inside LLM runtimePre-existing
Guardrails AIPython validators inside agent runtimePre-existing

These are not bad products. Microsoft AGT in particular addresses all 10 OWASP agentic-AI risks with deterministic sub-millisecond enforcement and ships in five language SDKs. APort's OAP paper formalizes pre-action authorization vocabulary that is genuinely useful. Galileo's observability heritage gives its control plane the strongest telemetry surface in the category. They are excellent for in-process governance.

They are also, by their own descriptions, not out-of-process control planes. Microsoft says so explicitly: "application-level governance (Python middleware), not OS kernel-level isolation." APort says so: their reference implementation "operates within the OS trust boundary—standard for authorization systems like OAuth, IAM, and policy engines." This is fair, accurate, and important.

What runs out-of-process today

ProductArchitectureNote
Cordum Safety KernelSeparate gRPC service behind mTLSPre-dispatch policy decision; sub-5ms p99
Microsoft Authorization FabricPEP+PDP for Entra-protected agentsIdentity-bound; works inside Microsoft trust
CyberArk Secure AI AgentsOut-of-process identity + authorizationNow inside Palo Alto Networks post acquisition

Microsoft Authorization Fabric and CyberArk Secure AI Agents both use out-of-process patterns inside their respective identity boundaries (Entra and PAM). They are the right answer when the agent's identity, lifecycle, and authorization all live inside the same identity provider. Cordum's Safety Kernel 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.

Why regulated buyers care

Three reasons, in order of operational importance.

1. Compromise containment. Prompt injection, dependency vulnerabilities, runtime escalation, and supply-chain compromise are all real failure modes for agent runtimes. When the policy engine and the agent share a process, a sufficiently bad failure can corrupt the policy decision because they share memory, exception state, and call stack. When they live in separate processes with separate identities, the policy engine is unaffected — its logs continue, its decisions continue, the agent is contained.

2. Audit attestability. An audit trail that the workload itself produced is weaker evidence than an audit trail produced by an independent component. Out-of-process governance gives the auditor a separate log stream that the workload cannot tamper with, signed by the policy engine's own identity. For SOC2 control objectives around separation of duties, and for financial services controls around segregation of operational and oversight functions, this distinction is increasingly the difference between a clean audit and a finding.

3. Multi-tenancy. Out-of-process governance lets one control plane serve many tenants with deterministic isolation. Tenant overlays — per-tenant deny lists, allow lists, constraint sets — compose with the base policy in a single decision engine. In-process governance pushes the multi-tenancy problem into the integrating application, where it is much harder to get right.

When in-process is fine

Most agent deployments today should not run an out-of-process control plane. In-process governance is the right answer when:

  • You are prototyping or in early development and want minimum integration overhead.
  • The agent is single-tenant, low-stakes, and not subject to a formal audit.
  • Your governance requirement is bounded to in-flight decisions inside one framework, and a tight coupling between the framework and the policy engine is desirable.
  • You are building inside the Microsoft Agent Framework and the integrated MS AGT experience is decisive.
  • You are already a Galileo observability customer and the data-model continuity matters more than trust boundary separation.

Honest acknowledgment: an in-process governance layer is dramatically better than no governance layer. The category exists because production agents without governance are dangerous. Microsoft AGT, Galileo, APort, Guild.ai, NeMo Guardrails, and Guardrails AI all make agent deployments measurably safer. The argument here is about which architecture fits which buyer — not whether the in-process products are good products.

What auditors actually expect

We have heard this question framed many ways: "does my auditor really care about in-process vs out-of-process?" The honest answer in 2026 is: increasingly yes, depending on the audit and the industry.

For SOC2 audits scoped to general security controls, in-process governance with tamper-evident logs can satisfy the technical requirement. For SOC2 audits in financial services, healthcare, or regulated SaaS — where separation of duties is a primary control objective — auditors increasingly look for the policy decision to live outside the workload. The same logic the auditor applies to your secrets manager (out-of-process) and your KMS (out-of-process) extends to your agent governance.

For EU AI Act compliance under Articles 12 and 13, the requirement is for record-keeping and transparency that can be reviewed independently. An audit trail produced by the workload itself is weaker evidence than an audit trail produced by an independent governance layer. Article 14 (human oversight) is easier to demonstrate when the policy engine — including REQUIRE_APPROVAL decisions — lives outside the workload that is being overseen.

For HIPAA technical safeguards and PCI-DSS access controls, the rule of thumb auditors apply is the same one they apply to network segmentation: can the workload bypass the control? In-process governance can be bypassed by a sufficient compromise of the workload. Out-of-process governance cannot.

How to evaluate in your stack

Three concrete tests an evaluator can run today, regardless of which products are on the shortlist.

Test 1 — The compromise test. Give the agent a deliberately malformed plugin or a known prompt-injection payload. Observe what happens to the policy decision logs. With in-process governance, a sufficiently bad failure can corrupt or stop the policy decisions because the policy engine shares memory with the failing agent. 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.

Test 2 — The independent log test. Ask: where do the policy decisions get written? Can the agent process the decisions are about delete or modify them? If yes, the audit trail is workload-produced and weaker. If no — if the decisions live in a store the workload cannot reach — the audit trail is independent and stronger.

Test 3 — The identity test. Ask: does the policy engine have its own identity, separate from the agent? Can the auditor verify that a given decision came from the policy engine and not from a process pretending to be the policy engine? Out-of-process governance answers yes by construction (the policy engine authenticates with mTLS or equivalent). In-process governance answers no because there is no identity boundary between the agent and the policy engine.

FAQ

Frequently Asked Questions

What is out-of-process AI agent governance?
An architecture where the policy decision point — the component that says ALLOW, DENY, or REQUIRE_APPROVAL on an agent action — runs in a separate process from the agent runtime. The agent calls into the governance layer over a network or IPC boundary; the governance layer responds with a deterministic decision. Compromise of the agent does not compromise the policy decision because the two live in separate trust boundaries.
Which agent governance products run in-process?
Microsoft Agent Governance Toolkit (MS AGT), Galileo Agent Control, APort's Open Agent Passport (OAP) reference implementation, NeMo Guardrails, Guardrails AI, and most LangChain callbacks all run in-process. Microsoft's own README states explicitly: "This 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." That is a fair description of the entire in-process category.
Which products run out-of-process?
Cordum's Safety Kernel runs as a separate gRPC service behind mTLS — the agent calls it before dispatch, never sees the decision being made, and cannot bypass it. Microsoft's own Authorization Fabric uses a PEP+PDP split for Entra-protected agents. CyberArk's Secure AI Agents Solution runs identity and authorization out-of-process for agents inside its identity boundary. The pattern is the same one that drove enterprise adoption of HSMs and out-of-process secret managers.
Does out-of-process governance add latency?
Yes — but a small, bounded amount. A well-engineered out-of-process control plane targets sub-5ms p99 latency for the policy decision (per Cordum ADR-001). For most agent actions — tool calls, API invocations, workflow steps — that overhead is dominated by the action's own latency. The latency is the cost of admission control; it is the same tradeoff you make every time a system calls an external authorizer.
Can I get "out-of-process" by running an in-process library in a sidecar?
Sometimes, with caveats. A sidecar pattern that runs the policy engine in a separate process on the same host — communicating over Unix domain socket or localhost gRPC — gets you most of the trust boundary benefits if the sidecar has its own identity, its own logs, and an independent failure domain. What it does not give you is the isolation of running the policy engine in a separate failure domain (different host, different blast radius). For high-stakes deployments, the policy engine wants to live on infrastructure the agent process cannot touch.
What does an auditor look for?
Three things, increasingly. (1) Can the auditor read the policy decisions independently of the workload's own logs — i.e. do the decisions exist in a store the workload cannot tamper with? (2) Does the policy engine have its own identity and authentication, so its log entries are attestable? (3) If the workload is compromised, does the audit trail of policy decisions stop, get falsified, or continue uncorrupted? Out-of-process architectures answer (3) with "continue uncorrupted" because the policy engine is in a different trust boundary. In-process architectures cannot, by construction.
Is this just terminology games?
No. The same distinction drove enterprise adoption of HSMs over in-process key management. It drove Kubernetes admission controllers over in-pod policy. It drives why financial systems run policy decision points outside the trading engine. Trust boundary separation is a real architectural property with real audit and compromise-containment consequences. "Application-level governance" and "OS kernel-level isolation" — the words Microsoft used in their own README — describe a real difference.

Out-of-process control plane for regulated AI agents

Cordum's Safety Kernel runs as a separate gRPC service behind mTLS. Audit data is signed and exportable to your existing SIEM. See the architecture, or compare against Microsoft AGT, Galileo, and Guild.ai directly.

Review ArchitectureCompare vs Microsoft AGT