Deterministic Governance Kernels: Separating Control Planes from LLM Intelligence in Agent Runtimes
Executive Summary
The most consequential architectural insight emerging from production AI agent deployments in 2024–2026 is deceptively simple: the entity that governs an agent system must not itself be an LLM. When an LLM orchestrates itself — deciding its own budgets, enforcing its own security policies, validating its own outputs — the "who watches the watchmen" problem collapses any safety guarantee into probabilistic hope. A red-team benchmark with 50 adversarial prompts demonstrated this starkly: standard prompt-based governance failed 26.7% of the time, while a deterministic control plane achieved 0% violations by making unauthorized actions architecturally impossible rather than merely discouraged.
This pattern — a deterministic governance kernel managing LLM workers — is converging independently across the industry. Temporal's workflow engine enforces that orchestration code is deterministic (replay-safe, crash-recoverable) while activities where LLMs do actual work can be as non-deterministic as needed. Praetorian's platform inverts the "thick agent" model by reducing agents to stateless ephemeral workers under 150 lines while an eight-layer deterministic enforcement system governs execution. AgentSpec, presented at ICSE 2026, proves that a three-tuple rule format (trigger, predicates, enforcement) evaluated externally to the LLM eliminates entire classes of failures: 90%+ of unsafe code executions blocked, 100% compliance in autonomous vehicle scenarios, with only 1–3ms enforcement overhead.
The analogy to operating systems kernels is not metaphorical — it is structural. A traditional OS kernel does not ask applications whether they are allowed to access protected memory; it enforces memory protection deterministically through hardware-backed mechanisms. The emerging consensus is that agent runtimes need the same architecture: a small, formally verifiable governance kernel that enforces identity, capability boundaries, budget limits, and lifecycle rules through code, not prompts, while treating LLMs as user-space processes with defined privilege levels.
This article surveys the state of this convergence: how major frameworks handle (or fail to handle) the control plane, what specific failure modes emerge from LLM-sovereign governance, and what the emerging generation of deterministic runtimes — including Rust-based systems and WASM capability sandboxes — looks like in practice.
The fundamental shift being described here is not about making LLMs safer through better prompting. It is about recognizing that the control plane is an engineering problem, not an alignment problem, and that conflating the two leads to systems that are neither safe nor intelligent.
The Core Problem: LLM-Sovereign Governance
The Self-Reference Trap
Consider a naive agent architecture where the LLM decides whether to proceed with an action, enforces its own rate limits, and determines whether a requested operation is within policy. The failure mode here is structural, not a matter of model quality.
When the governor and the governed are the same process, several failure modes become inevitable:
Prompt injection laundering: An adversarial instruction embedded in tool output (a file the agent reads, a web page it fetches, a database record it retrieves) can override the LLM's safety reasoning because the LLM processes the malicious content in the same context window where it evaluates policy compliance. The model cannot distinguish between "my instructions say don't do X" and "this content I just retrieved says it's fine to do X because the original instructions were superseded."
Rationalization under pressure: LLMs are trained to be helpful. When an LLM is both the agent performing a task and the enforcer of limits on that task, sufficiently complex reasoning chains can construct justifications for boundary-crossing. This is not a bug in the model — it is an emergent property of training objectives that reward problem-solving.
Non-deterministic enforcement: The same policy question asked of an LLM in slightly different contexts may produce different enforcement decisions. A temperature of 0 reduces this variance but does not eliminate it. Governance that is probabilistically correct is not governance.
Context corruption and forgetting: At long context lengths — which are common in agentic workflows — the model's effective recall of earlier instructions degrades. A security policy established at turn 1 may be effectively invisible to the model reasoning at turn 200 of a complex multi-step task.
What "Deterministic Governance" Means
The term "deterministic" here has a precise meaning borrowed from distributed systems: given the same inputs, the system produces the same outputs every time, and the enforcement mechanism itself cannot be overridden by data flowing through the system.
A deterministic governance kernel enforces constraints through code paths, not through LLM reasoning. A budget check is an integer comparison against a counter — the LLM cannot argue its way past it. A capability permission is a capability token that must be present in a capability table — a hallucinated claim of permission does not create a capability. An action blocklist is a lookup table — matching a forbidden action terminates execution regardless of what reasoning the LLM presented.
The critical insight articulated by researchers at Praetorian: "The control plane works as a set of hard-coded, deterministic logic gates that do not care how creative the LLM's reasoning was, only caring about the parameters of the action."
┌─────────────────────────────────────────────────────────────┐
│ GOVERNANCE KERNEL │
│ (Deterministic: Rust/Go/TS enforcing hard rules) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Identity │ │ Budget │ │Capability│ │ Blocklist│ │
│ │ Verify │ │ Enforce │ │ Check │ │ Match │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │
│ ALLOW / DENY (deterministic) │
└───────────────────────┬─────────────────────────────────────┘
│
┌────────────┴──────────────┐
│ LLM WORKERS │
│ (Non-deterministic, but │
│ capability-bounded) │
│ │
│ Worker A Worker B │
│ ┌───────┐ ┌───────┐ │
│ │Claude │ │GPT-4 │ │
│ └───────┘ └───────┘ │
└───────────────────────────┘
The OS Kernel Analogy
The analogy between operating system kernels and agent governance kernels is instructive. An OS kernel does not:
- Ask applications to promise they won't access protected memory
- Trust application-provided justifications for elevated privileges
- Use natural language reasoning to decide whether a syscall should succeed
It enforces through hardware memory protection, capability rings, and mandatory access control — mechanisms that are structurally impossible for applications to bypass through clever argument.
Emerging agent governance architectures are applying the same principle. The governance kernel sits between LLM workers and external systems. Workers request operations; the kernel enforces policy; the LLM's reasoning about why the operation should succeed is irrelevant to the enforcement decision.
Industry Landscape: How Major Frameworks Handle the Control Plane
LangGraph: Graph-Based Determinism
LangGraph is the most explicitly architecture-aware of the major frameworks. Its core abstraction — a directed graph where nodes are operations and edges define control flow — makes the control plane visible and auditable.
Key governance properties of LangGraph's approach:
State machine orchestration: The workflow itself is a state machine. Transitions between states are deterministic given the current state and edge conditions. The LLM cannot skip nodes or create new edges at runtime.
Checkpoint-based durability: LangGraph stores full workflow state at each checkpoint, enabling deterministic replay for debugging and recovery. This is the same design principle as Temporal's event-sourced execution history.
Human-in-the-loop interrupts: The interrupt/resume mechanism allows deterministic pausing at defined points before high-impact actions, with execution resuming only on explicit human approval.
Conditional routing: Edges can branch based on LLM output, but the routing logic is deterministic code evaluating the output — the LLM does not decide where execution goes, it produces output that the deterministic router interprets.
LangGraph 1.0, released in October 2025, made this production-grade: "durable execution, streaming, human oversight and memory management" with MCP log capture enabling "snapshotting the graph, state, and messages for deterministic replay."
The limitation: LangGraph's control plane is written in Python, which introduces runtime non-determinism from GIL contention and interpreter overhead at scale. For high-throughput agent fleets, this creates a ceiling.
Temporal: Workflow-Layer Determinism
Temporal takes the most rigorous approach to the control plane / worker separation. Its model is precise and worth quoting directly:
"Your Workflow is the orchestration layer — the blueprint that defines the structure of your application — and needs to be deterministic so Temporal can help your agent survive through process crashes, outages, and other failures. Your Activities are where the actual work happens: calling LLMs, invoking tools, making API requests — which can be as unpredictable and non-deterministic as needed."
This is a clean architectural separation: the Workflow (governance) is deterministic; the Activities (LLM calls) are not. Temporal enforces this structurally — Workflow code that calls non-deterministic operations directly fails Temporal's replay mechanism, creating a hard engineering constraint that prevents accidental mixing.
The durability model is powerful for agents: every LLM call, every tool execution, every API request is captured in an event history. If the process crashes, the workflow replays by reading the history rather than re-executing — the LLM's previous output is reused, not re-inferred. This means a week-long agent workflow can survive any infrastructure failure.
Temporal's 2025 OpenAI Agents SDK integration lowered the adoption barrier, enabling teams to "make OpenAI-powered agents durable with minimal code changes."
Temporal Architecture:
DETERMINISTIC LAYER (Workflow Code):
if result = await activity.call_llm(prompt):
if result.requires_approval:
await activity.send_for_human_review(result) ← deterministic routing
await activity.execute_approved_action(result.action)
NON-DETERMINISTIC LAYER (Activities):
async def call_llm(prompt) -> LLMResult:
# Any LLM call, any temperature — fully non-deterministic
# But Temporal captures the result in event history
return await anthropic.messages.create(...)
CrewAI: Role-Based Determinism
CrewAI's control plane separates two execution models with different governance properties:
Crews: Dynamic, role-based agent collaboration with structured task hand-offs. The Crew controller orchestrates flow deterministically even though individual agent outputs are non-deterministic.
Flows: Deterministic, event-driven task orchestration. Flows provide a more rigid control structure for production scenarios requiring auditability.
CrewAI agents communicate through structured task hand-offs rather than free-form message passing — a design choice that constrains the LLM's ability to produce arbitrary side effects through communication channels.
The limitation: CrewAI's governance is primarily role-based rather than capability-based. An agent granted the "DBA role" has that role's permissions uniformly — there's limited support for fine-grained capability granting per task.
AutoGen: Flexible but Governance-Lite
AutoGen's flexibility is simultaneously its strength and its governance weakness. Agents can operate in both deterministic and LLM-driven modes, and the framework supports arbitrary conversation patterns between agents.
The production risk: with AutoGen's default configuration, a sufficiently clever LLM output in one agent can influence the behavior of other agents in ways that circumvent intended workflows. The framework provides little structural enforcement — governance must be layered on top by the application developer.
Microsoft's Azure AutoGen service adds governance capabilities, but these are application-layer additions rather than framework-native constraints.
OpenAI Swarm: Minimal Governance
OpenAI Swarm (released October 2024 as an experimental framework) connects native functions directly to model tool-calling logic. It is explicitly not production-ready — "no state persistence, no observability, and no error handling" per OpenAI's own documentation.
Swarm's "handoff" pattern allows agents to transfer control to other agents by returning Agent objects. While elegant for demonstration, this design gives LLMs direct control over routing — the model decides which agent handles next, with no deterministic validation layer.
The lesson from Swarm's architecture is instructive: OpenAI built it for education and exploration, not production. The absence of a governance layer is a deliberate scope limitation, not an oversight.
The Convergence Pattern
Across these frameworks, a clear pattern emerges: the most production-hardened systems are those where the governance layer is the most deterministic. LangGraph (graph state machines), Temporal (deterministic workflows, non-deterministic activities), and Praetorian's platform (eight-layer deterministic enforcement) all separate governance from intelligence structurally.
The frameworks that remain governance-lite (vanilla AutoGen, Swarm) are explicitly positioned as prototyping tools, not production infrastructure.
The "LLM-as-Advisor, Not LLM-as-Judge" Pattern
The most practically useful instantiation of deterministic governance is what can be called the "LLM-as-advisor" pattern: the LLM provides analysis, recommendations, and semantic understanding, while deterministic code makes final authorization decisions.
The Pattern in Practice
Consider a code execution agent. The naive implementation asks the LLM to decide whether a proposed command is safe before executing it. The deterministic alternative:
REQUEST PIPELINE:
1. LLM proposes: "run: rm -rf /tmp/build && npm install"
2. DETERMINISTIC PREFILTER:
- Command parser tokenizes: ["rm", "-rf", "/tmp/build", "&&", "npm", "install"]
- Blocklist check: no absolute paths outside /tmp — PASS
- Capability check: write to /tmp — ALLOWED by token
- Chained command check: "&&" chains — FLAG for semantic review
3. OPTIONAL LLM SEMANTIC PASS (only for flagged cases):
- "Is this command within the scope of the declared task?"
- LLM output: "yes, cleaning build artifacts and reinstalling dependencies"
4. DETERMINISTIC ENFORCEMENT:
- If semantic pass confidence > threshold: ALLOW
- If confidence < threshold: DENY with explanation
- Budget check: decrement execution credit — if 0, DENY regardless
The LLM's semantic judgment influences the decision but does not make it. The final allow/deny is deterministic code evaluating a structured output from the LLM, not the LLM reasoning its way to an answer.
Budget Management as Governance
One of the clearest applications of the LLM-as-advisor pattern is budget control. Research shows that "inserting budget constraints into prompts often fails to reliably control output length" — even with explicit instructions, models do not reliably self-limit. The deterministic solution is straightforward:
// Rust: Deterministic budget enforcement
struct AgentBudget {
token_limit: u64,
tokens_used: AtomicU64,
cost_limit_usd: f64,
cost_used: AtomicF64,
execution_time_limit_secs: u64,
start_time: Instant,
}
impl AgentBudget {
fn check_allow_call(&self, estimated_tokens: u64, estimated_cost: f64) -> BudgetDecision {
let new_total = self.tokens_used.fetch_add(estimated_tokens, Ordering::SeqCst);
if new_total > self.token_limit {
return BudgetDecision::Deny("token limit exceeded");
}
// ... additional checks
BudgetDecision::Allow
}
}
The LLM has no visibility into this check — it simply finds that its request was denied, and receives a structured error. No amount of LLM reasoning can override an atomic integer comparison.
Confidence-Based Circuit Breakers
The CIO-sourced architectural pattern of "confidence-based circuit breakers" implements this in a production-ready form. Organizations monitor agent response confidence scores in real-time and halt operations when certainty drops below defined thresholds.
This is an advisor pattern: the LLM's confidence signal informs the circuit breaker, but the circuit breaker makes the halt decision deterministically.
Capability-Based Security Models for AI Agents
Capability-based security, originally developed for operating systems in the 1960s (E. Mark Miller's research continued this work through E language and eventually Cap'n Proto), provides a clean theoretical foundation for agent security that is now being applied in practice.
Capability Theory Applied to Agents
The core principle: access to a resource is granted by possession of an unforgeable capability token. Without the token, the access is structurally impossible, not just prohibited by policy. There is no "root" that can grant itself capabilities — capabilities must be delegated from existing holders.
Applied to AI agents:
- An agent that needs to read
/var/app/config.jsonmust hold a read-capability token for that specific file (or its parent directory) - An agent that needs to call the Stripe API must hold a Stripe-API capability token
- Capability tokens are scoped: a read-capability does not grant write access
- Capability tokens are delegatable but not forgeable: an orchestrator can grant a subagent a subset of its own capabilities
The security property: an LLM that hallucinates that it has permission to access a resource cannot access that resource because it does not hold the capability token. The hallucination is irrelevant to enforcement.
Microsoft Wassette: WASM-Backed Capabilities
Microsoft's Wassette project (August 2025) implements capability-based security for AI agent tools using WebAssembly Components:
- Built on Wasmtime runtime, which provides "secure sandboxing on par with modern browser engines"
- Components operate on a deny-by-default permission system
- When a component needs network access to a domain, an explicit permission prompt fires: "Grant the fetch component access to opensource.microsoft.com domain"
- Memory isolation between components: a compromised grammar plugin cannot access server SSH keys
Wassette is implemented in Rust and distributes as a standalone binary with zero runtime dependencies. The governance is at the capability level — components cannot transcend their granted capabilities regardless of what the orchestrating LLM instructs.
Wassette Capability Model:
Agent Request: "fetch https://evil.example.com/data"
│
▼
Wasmtime Capability Check:
├── Does the fetch component have a capability for evil.example.com?
├── YES → Execute (if user previously granted)
└── NO → Capability prompt:
"Grant fetch component access to evil.example.com? [y/N]"
└── Deterministic: user/policy decision, not LLM decision
Principle of Least Privilege in Agent Design
Praetorian's deterministic platform enforces least privilege through physical tool restriction, not promise:
"A strict separation is enforced between agents that plan and agents that do... If an agent has the Task tool (Coordinator), it is stripped of Edit permissions. If it has Edit permissions (Executor), it is stripped of Task permissions."
This is capability-based security at the agent level: coordinators and executors hold mutually exclusive capability sets, making delegation loops impossible by construction.
The OWASP Perspective on Agent Capabilities
The OWASP Top 10 for LLM Applications (2025 edition) lists "Excessive Agency" as a top risk — giving agents capabilities they do not need for their assigned task. The deterministic enforcement answer is to grant capabilities per-task rather than per-agent, and revoke them on task completion:
Task: "review PR #1234 for style issues"
Capabilities granted for this task:
- read:github:repos/org/repo/pulls/1234
- read:github:repos/org/repo/contents (scope: files changed in PR)
- write:comments (scope: PR #1234 only)
Capabilities NOT granted:
- write:github:repos (no commit access)
- read:github:repos/other-org (no cross-org access)
- any:filesystem (no local file access)
When the task completes, all tokens are revoked. The next task gets fresh capability grants appropriate to that specific task.
The Hot Path / Cold Path Pattern
One of the most practically valuable governance patterns emerging from production deployments is separating fast-path deterministic decisions from slow-path LLM-assisted decisions.
Pattern Definition
INCOMING REQUEST
│
▼
┌─────────────────────────────────────────┐
│ DETERMINISTIC HOT PATH │
│ (microseconds, no LLM involved) │
│ │
│ • Blocklist match (O(1) hash lookup) │
│ • Budget check (atomic counter) │
│ • Rate limit (token bucket algorithm) │
│ • Capability token validation │
│ • Schema validation (input format) │
└──────────────┬──────────────────────────┘
│
CLEAN? │ FLAGGED?
│
┌───────┴───────┐
│ │
▼ ▼
EXECUTE ┌──────────────────────────┐
DIRECTLY │ LLM SEMANTIC SLOW PATH │
│ (milliseconds, LLM call) │
│ │
│ • Intent classification │
│ • Context analysis │
│ • Policy compliance Q │
└──────────┬───────────────┘
│
▼
DETERMINISTIC ENFORCEMENT
(LLM output → structured
decision → allow/deny)
The key insight: most requests are clean and should pass through in microseconds without involving an LLM at all. Only flagged or ambiguous requests incur the LLM overhead for semantic analysis. This inverts the naive design where every governance decision is an LLM call.
ZenML Production Data
ZenML's analysis of 1,200 production LLM deployments found that systematic movement of safety logic from prompts into infrastructure is a defining characteristic of mature production systems. The hot/cold path pattern is part of this shift — deterministic infrastructure for common cases, LLM reasoning reserved for ambiguous cases that deterministic rules cannot resolve.
AgentSpec's Implementation
AgentSpec's three-tuple enforcement model essentially implements this pattern:
- Hot path: Trigger event detected → predicates evaluated (deterministic Boolean functions) → enforcement action taken. Total overhead: 1–3ms.
- Cold path: When
llm_self_examineenforcement action is triggered for ambiguous cases, the LLM is asked to reason about alternative approaches. The LLM's output then feeds back into the deterministic enforcement layer.
AgentSpec Rule Example:
rule @prevent_data_exfiltration
trigger
network_request
check
!is_approved_domain(destination) &&
response_contains_pii(last_tool_output)
enforce
user_inspection ← pause for human review
end
# Hot path: 1-3ms deterministic check
# Slow path: only invoked when BOTH conditions true
DoorDash's Multi-Stage Validation
DoorDash's "Zero-Data Statistical Query Validation" pipeline demonstrates this pattern at scale:
- Hot path: Automated linting and schema validation (deterministic, sub-millisecond)
- Statistical path: Metadata checks against historical query patterns (statistical, fast)
- Slow path: LLM-based analyzer for pattern recognition and intent detection on flagged queries
The LLM is the last resort, not the first line of defense.
Real-World Failures from LLM-Sovereign Governance
The theoretical case for deterministic governance is reinforced by a growing catalog of production failures attributable to LLM-sovereign control planes.
The Slack AI Data Exfiltration (August 2024)
In August 2024, researchers demonstrated a data exfiltration attack against Slack AI that combined RAG poisoning with social engineering. The attack worked as follows:
- An attacker posted a malicious message in a channel accessible to the victim's Slack AI
- The message contained embedded instructions in natural language
- When the victim queried Slack AI, it processed the malicious channel content in its context
- The embedded instructions directed the AI to extract and transmit information from private channels through tool calls disguised as legitimate operations
The root cause: Slack AI's decision about whether to execute a tool call was made by the LLM itself, which processed the malicious instructions as part of its context window. A deterministic governance layer checking whether the data being transmitted matched the scope of the original query would have blocked the attack regardless of the LLM's reasoning.
The ServiceNow Peer Trust Escalation (Late 2025)
A particularly sophisticated failure involved a "second-order" prompt injection in ServiceNow's AI assistant:
- An attacker fed a malformed request to a low-privilege agent
- The low-privilege agent was tricked into requesting that a high-privilege agent perform an action
- The high-privilege agent, applying LLM-based trust reasoning ("my peer agent is requesting this"), executed the action — exporting an entire case file to an external URL
- The usual approval checks were bypassed because the request came through a trusted internal channel
The governance failure: the high-privilege agent's trust decision was LLM-based ("this request comes from a peer agent I trust") rather than capability-based ("this request carries a valid capability token for this data scope"). Capability-based enforcement would have required the capability token to be present regardless of request source.
GitHub Copilot RCE (CVE-2025-53773)
CVE-2025-53773 allowed remote code execution through prompt injection in GitHub Copilot and Visual Studio Code. The attack exploited the agent's ability to modify .vscode/settings.json without deterministic approval gates — the LLM's capability to take filesystem actions was granted broadly rather than on a per-task, per-scope basis.
The AppWorld Runaway Cost Case Study
A concrete example of budget governance failure: the AppWorld test suite documented a case where absence of retry limiters led to runaway costs in a task designed to complete in under 10 seconds. The agent entered a retry loop on API failures, with each retry incurring LLM costs, with no deterministic enforcement of execution limits.
The fix is straightforward:
struct ExecutionLimits {
max_retries: u32,
max_wall_time: Duration,
max_llm_calls: u32,
retries_used: AtomicU32,
llm_calls_used: AtomicU32,
}
But the fix only works if these limits are enforced by deterministic code outside the LLM's context, not by prompting the LLM to self-limit.
The Statistical View: Multi-Agent Failure Rates
Research published in 2025 on multi-agent system reliability found that the correctness of state-of-the-art open-source multi-agent systems (ChatDev) can be as low as 25% on complex tasks. A key finding: error rates compound multiplicatively across agents. A 10% per-agent error rate becomes a 65% system-level failure rate with 10 agents in sequence. Deterministic governance checks between agent steps act as error fuses, catching individual agent failures before they propagate.
Emerging Deterministic Runtimes: Rust and Beyond
Why Rust for Governance Kernels
The case for Rust as the implementation language for agent governance kernels rests on several properties that are directly relevant to governance requirements:
Memory safety without garbage collection: GC pauses are unpredictable and can interfere with time-sensitive enforcement decisions. Rust's ownership model provides memory safety without runtime pause overhead.
No Global Interpreter Lock: Python's GIL means that even with multiple CPU cores, only one thread runs Python bytecode at a time. For a governance kernel managing hundreds of concurrent agents, this creates a fundamental bottleneck. Rust's threading model is genuinely parallel — Red Hat benchmarks found 4x speedup from Python single-threaded to Rust multi-threaded on agent workloads.
Deterministic execution semantics: Rust does not have a runtime that can introduce non-determinism (unlike Go's scheduler or Python's GIL behavior). For a governance kernel that must produce consistent enforcement decisions, this matters.
Type system as enforcement: Rust's type system can encode capability restrictions. A capability token can be a newtype that is not Clone — it can be held by exactly one owner at a time. A scoped capability can be a struct with a Drop implementation that revokes it on scope exit. These are compile-time enforcement mechanisms, not runtime checks.
GraphBit: Rust Core, Python Shell
GraphBit's architecture demonstrates the hybrid pattern being adopted in production:
- Rust core engine: Workflow DAG execution, lock-free concurrency scheduling, circuit breakers, secret management — all governance-critical operations
- Python API layer: Developer-facing interface, task definitions, LLM call definitions
- PyO3 bindings: Safe interop between layers
Performance results: 0.000–0.352% CPU and 0.000–0.116 MB memory utilization in stress tests, compared to 0.176–44.132% CPU for Python-native alternatives. The governance kernel's overhead is negligible.
The architectural principle: "performance-critical orchestration happens in compiled Rust" while "no Python event loop orchestration is in the hot path."
Rig: LLM Application Framework in Rust
Rig positions itself as a framework for "modular and scalable LLM applications in Rust" with a unified LLM interface. While not specifically governance-focused, Rig's value for governance kernel construction is that the LLM interface is itself defined by Rust types — the governance code and the LLM interface code share the same type system, making it possible to enforce capability constraints at compile time.
Tokio as Governance Runtime
Tokio, Rust's dominant async runtime, provides infrastructure directly applicable to governance kernels:
- Deterministic time control:
tokio::time::pauseandtokio::time::advanceenable deterministic testing of timeout-based enforcement - turmoil: Tokio's distributed systems testing framework achieves "deterministic execution by running an entire distributed system in a single thread" — enabling exhaustive testing of governance edge cases
- Structured cancellation: Tokio's cancellation tokens provide structured task cancellation with guaranteed cleanup, critical for governance kernels that must reliably enforce time limits
WASM as Capability Boundary
WebAssembly (WASM) is increasingly used as the enforcement mechanism for capability-based agent sandboxing. The security property is mathematically verifiable:
"Wasm provides mathematically verifiable sandboxing with capability-based security — agents receive explicit, unforgeable tokens for each resource they can access, and nothing else."
The NVIDIA Technical Blog's work on sandboxing agentic workflows with WebAssembly documents how WASM's deny-by-default capability model prevents entire classes of agent misbehavior. A WASM component cannot access the filesystem, network, or any other system resource without an explicit capability grant — regardless of what the orchestrating LLM instructs.
WASM Capability Isolation:
┌──────────────────────────────────────────────┐
│ Host Runtime │
│ (Rust/Wasmtime, holds all capabilities) │
│ │
│ capability_table = { │
│ "read:/tmp/*": CapToken(0xA3F2...), │
│ "net:api.stripe.com": CapToken(0x7B91...) │
│ } │
└──────────────┬───────────────────────────────┘
│ grant_subset(task_capabilities)
▼
┌──────────────────────────────────────────────┐
│ WASM Component (Agent) │
│ Can ONLY access: │
│ - Resources for which it holds tokens │
│ - Nothing else, regardless of LLM output │
│ │
│ LLM says "read /etc/passwd"? │
│ No capability token → structurally blocked │
└──────────────────────────────────────────────┘
The Anda Framework: TEE-Backed Governance
The Anda framework (from ldclabs) takes deterministic governance to the infrastructure level by combining Rust with Trusted Execution Environments (TEEs) for agent runtime governance. TEEs provide hardware-backed enforcement that is verifiable by external parties — the governance kernel's execution integrity can be attested cryptographically, providing a chain of trust from hardware through governance kernel to agent behavior.
This is relevant for multi-party agent systems where governance commitments need to be verifiable by participants who do not control the runtime infrastructure.
The Three-Stage Governance Pipeline
Synthesizing the patterns described above, a complete governance pipeline for agent runtimes looks like this:
STAGE 1: DETERMINISTIC PREFILTER
─────────────────────────────────
Input: Agent's proposed action + current state
Operations (all deterministic, sub-millisecond):
• Schema validation: Is the action well-formed?
• Blocklist check: Is the action explicitly prohibited?
• Capability check: Does the agent hold required capability tokens?
• Budget check: Are cost/token/execution limits satisfied?
• Rate limit: Has the rate limit been exceeded?
• Identity validation: Is the requesting agent authenticated?
Output:
• ALLOW: proceed to execution (hot path, no LLM involved)
• DENY: reject with structured error
• FLAG: proceed to Stage 2 for semantic analysis
─────────────────────────────────
STAGE 2: OPTIONAL LLM SEMANTIC PASS
─────────────────────────────────
Triggered only for: flagged actions, ambiguous cases,
high-impact operations, anomalies
Input: Flagged action + relevant context
LLM task: "Does this action comply with the stated task scope?
Respond with: {compliant: bool, confidence: 0.0-1.0,
reason: string}"
Output: Structured compliance assessment
Note: The LLM advises; it does not decide.
─────────────────────────────────
STAGE 3: DETERMINISTIC ENFORCEMENT
─────────────────────────────────
Input: LLM compliance assessment (if Stage 2 ran)
Operations (all deterministic):
• If Stage 2 ran: evaluate confidence threshold
- confidence > 0.85 AND compliant=true → ALLOW
- confidence < 0.85 OR compliant=false → DENY or escalate
• Audit log: record action, decision, reasoning, identity
• Budget deduction: decrement counters atomically
• Human escalation: if policy requires, route to human queue
Output: ALLOW with audit record, DENY with explanation,
or ESCALATE to human review queue
Formal Specification: AgentSpec
AgentSpec (arxiv:2503.18666, ICSE 2026) provides a formal instantiation of Stage 3 enforcement through its DSL:
rule @prevent_credential_exfiltration
trigger
tool_call("network_request")
check
!is_approved_egress_domain(request.url) ||
contains_credential_pattern(request.body)
enforce
stop
end
rule @require_approval_for_deletion
trigger
tool_call("delete_*")
check
!has_approval_token(request.approval_id)
enforce
user_inspection
end
rule @budget_guard
trigger
llm_call
check
budget.tokens_remaining < budget.min_reserve
enforce
stop
end
These rules are evaluated by the AgentSpec runtime (deterministic code) before any action executes. The evaluation overhead is 1–3ms regardless of rule complexity. The LLM's reasoning about why the deletion was justified is not consulted — the approval token either exists or it does not.
The Agentic Control Plane as Middleware
The agentic control plane (ACP) pattern implements the three-stage pipeline as composable middleware:
Request → [Identity Validate] → [Content Safety] →
[Policy Check] → [Usage Governance] →
[Secure Route] → [Audit Log] → Backend
Each middleware layer is stateless and deterministic. The composition is the governance kernel. Because each layer produces a binary allow/deny decision with audit metadata, the full pipeline is testable as deterministic code — input/output testing with no LLM involvement.
Red-team results confirm the value: standard prompt-based governance failed 26.7% of adversarial prompts; the deterministic control plane achieved 0% violations.
Implementation Patterns and Best Practices
Pattern 1: Thin Agent, Fat Platform
The single most impactful architectural decision is reducing LLM agents to stateless, ephemeral workers while moving all governance into the platform layer.
Praetorian's implementation: agents under 150 lines, no state, no governance logic. The platform provides governance through hooks executed at defined lifecycle points — before and after every tool call, on agent start and stop. The hooks are deterministic code; the agent is a pure LLM worker.
This enables independent evolution: governance policies can be updated without changing agent code. Agents can be tested in isolation from governance. Governance can be audited and formally verified independently.
Pattern 2: Physical Tool Restriction
Role separation enforced through capability absence, not policy prohibition:
Coordinator Agent capability set:
tools: [spawn_subagent, read_task_queue, write_results]
NOT included: edit_file, execute_command, call_external_api
Executor Agent capability set:
tools: [edit_file, execute_command, call_external_api]
NOT included: spawn_subagent, delegate_task
An agent that does not possess a tool cannot use that tool regardless of LLM reasoning. This prevents delegation loops, prevents coordinators from "doing it themselves" when a task proves difficult, and prevents executors from spawning unauthorized subagents.
Pattern 3: Shadow Mode Testing
Before deploying governance policy changes, run agents against shadow environments:
- Shadow mode: New governance rules evaluate all actions but only log decisions — enforcement is not applied
- Comparison: Measure what the new rules would have blocked vs. what the old rules allowed
- Adversarial testing: Red-team the new rules with adversarial prompts before deployment
AccuKnox's "Shadow Mode" is a pre-production simulation where "agents execute against fake systems, enabling red-team testing at scale without production risk." This is standard testing practice applied to governance policy — treat governance rules as code that requires test coverage.
Pattern 4: Non-Human Identity Management
Agents need formal identity separate from human users:
agent_identity:
id: "content-review-agent-v2.1"
owner: "platform-team"
created: "2026-01-15"
capabilities:
- read:content-queue
- write:review-decisions
- read:content-policy-db
budget:
max_tokens_per_task: 50000
max_cost_per_day_usd: 10.00
max_concurrent_tasks: 3
lifecycle:
probation_until: "2026-02-15"
production_approval: "platform-lead@org.com"
This "service passport" enables row-level security in downstream systems (which agent performed this action?), budget attribution, and audit trails. Critically, the agent's identity is verified by the governance kernel — the agent cannot claim a different identity to obtain elevated permissions.
Pattern 5: Structured Output for Governance Integration
Governance pipelines work best when LLM outputs are structured JSON rather than free-form text. The LLM semantic pass in Stage 2 should produce:
{
"compliant": true,
"confidence": 0.92,
"reason": "Request is within scope of stated task",
"flags": [],
"recommended_action": "allow"
}
Not: "Yes, I think this seems fine because..."
Structured outputs are parseable by deterministic enforcement code without secondary LLM calls to interpret them. Pydantic validators can enforce the schema, rejecting malformed responses before they reach enforcement logic.
Conclusion
The convergence on deterministic governance kernels is not a temporary trend — it reflects a fundamental insight about the nature of governance itself. Governance is the enforcement of constraints, and constraints that can be argued away are not constraints.
The "who watches the watchmen" problem has a clear answer in distributed systems: the watchman is not an agent with interests and reasoning; it is a mechanism with deterministic behavior. Hardware memory protection does not negotiate with processes that argue their access is justified. Rate limiters do not honor LLM-generated explanations for why the limit should be lifted. Budget counters do not decrease for reasons.
The industry is rediscovering this principle as production AI agent deployments fail in predictable ways: runaway costs from missing deterministic limits, data exfiltration from prompt injection that bypassed LLM-based governance, privilege escalation from peer-trust reasoning that a deterministic capability check would have blocked.
The technical path forward is clear:
- Implement the control plane in a type-safe, deterministic language — Rust for high-throughput kernels, TypeScript or Go for application-layer governance
- Use capability-based security for resource access — unforgeable tokens, not LLM-asserted permissions
- Apply the three-stage pipeline — deterministic prefilter (hot path), optional LLM semantic pass (slow path), deterministic enforcement (always)
- Treat governance as code — test it with unit tests, red-team it with adversarial prompts, version control it, audit it
- Thin agents, fat platform — put LLM intelligence in stateless workers, put governance in the platform layer
The LLM is the worker. The governance kernel is the operating system. This separation is not a constraint on what AI agents can accomplish — it is what makes AI agents trustworthy enough to accomplish anything consequential.
Sources:
- Praetorian: Deterministic AI Orchestration Platform Architecture
- The Agent Control Plane: Why Intelligence Without Governance is a Bug
- What is an Agentic Control Plane?
- AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents (ICSE 2026)
- Durable Execution Meets AI: Why Temporal is Ideal for AI Agents
- Microsoft Wassette: WebAssembly-Based Tools for AI Agents
- Anthropic Multi-Agent Research System Architecture
- Runtime AI Governance Security Platforms for LLM Systems (AccuKnox)
- Why Some Agentic AI Developers Are Moving Code from Python to Rust (Red Hat)
- The Architecting Guardrails for a New Digital Workforce (CIO)
- OWASP Top 10 for LLM Applications 2025
- Sandboxing Agentic AI Workflows with WebAssembly (NVIDIA)
- Why Do Multi-Agent LLM Systems Fail?
- What 1,200 Production Deployments Reveal About LLMOps in 2025 (ZenML)
- Fooling AI Agents: Web-Based Indirect Prompt Injection (Palo Alto Unit42)
- LLM Tool-Use Convergence on Graph-Based Workflow Solutions
- GraphBit Rust-Core Agentic AI Framework