What is deterministic AI governance?

What is the difference between deterministic AI governance and runtime governance?

Deterministic AI governance is the category, meaning the discipline of deciding by policy whether an AI-proposed action may execute. Runtime governance is the mechanism, meaning that the decision happens at the point of execution rather than at design time or after the fact. Execution-bound governance is ExecLayer's named architecture for implementing it. They are three levels of the same idea, not three competing ones.

The vocabulary in this field is still fragmenting. The same architecture is being called deterministic AI governance, runtime governance, agent governance, execution control, an agent control plane, pre-execution guardrails, runtime enforcement, and runtime consent. Buyers searching for one of those terms and vendors answering in another is the reason the category reads as noisier than it is.

Three names, three jobs, and each has its own page here.

What makes an enforcement decision deterministic?

Four properties. Policy is a versioned signed artifact rather than a prompt. Evaluation happens before execution rather than after. Every decision emits a receipt binding the request, the policy version, and the outcome. And the decision replays: feeding the same request and policy version back through evaluation returns the same result.

All four have to hold. Drop any one and the decision stops being reproducible.

Policy is a versioned artifact, not a prompt. Rules live in signed bundles with change history, so “which policy was in force” always has exactly one answer. A policy expressed as natural-language instruction to a model is not a policy, because the model is free to interpret it differently on the next call.

Evaluation happens before execution. The action is checked against policy at the moment it is requested, and a refused action never runs. Logging an action after it completes is record keeping, not governance.

Every decision produces a receipt. The receipt binds the request, the policy version, and the outcome into one signed record. Not a log line that a process with write access can edit afterward.

Receipts replay. Feed the same request and policy version back through evaluation and you get the same decision. That replay is what turns a compliance claim into evidence, because it lets someone who does not trust you re-derive the result themselves.

Determinism here is a property of the enforcement path, not of the model. The model stays probabilistic. That is what models are for. The requirement is that the boundary deciding whether its output may act is not.

Is deterministic AI governance the same as guardrails?

No. Guardrails are probabilistic classifiers that inspect text and can return different verdicts for the same input on different days. Deterministic governance inspects the proposed action and its authority, decides by rule rather than by model, and returns the same verdict every time. Guardrails reduce the rate of bad output. Deterministic governance bounds what may execute.

The categories are routinely conflated because they both sit near the model. The difference is what gets inspected, when, and whether the answer is reproducible.

Guardrails inspect text. They classify a prompt or a completion as acceptable or not, using a model to judge a model. That is useful and worth having, but a classifier returns a probability, and a probability can land on either side of a threshold for the same input on two different days.

Deterministic execution governance inspects the proposed action and the authority behind it. Not whether the wording looks risky, but whether this actor is permitted to perform this operation on this resource under the policy version currently in force. That question has a rule-based answer, so it has the same answer every time.

Approach	What it inspects	When it acts	Reproducible?	Evidence produced
Deterministic execution governance	The proposed action and the authority behind it	Before execution	Yes, by rule	Signed receipt per decision, replayable
LLM guardrails and content filters	Prompt and completion text	Around the model call	No, probabilistic	Classifier scores and logs
AI gateway or proxy	Traffic, keys, quotas, routing	In transit	Partly, for the traffic layer	Request logs and usage metering
Observability and monitoring	Traces and outputs	After execution	Not applicable	Mutable telemetry
GRC and policy documentation	Written controls and attestations	Design time and audit time	Not applicable	Documents and questionnaires

These are complements, not substitutes. A gateway still meters traffic. Guardrails still reduce bad output. Monitoring still explains incidents. None of them can refuse an unauthorized action and prove afterward that the refusal happened, which is the specific job of a deterministic execution boundary.

Each row above corresponds to a category with real products in it, compared directly here: action gating versus environment sandboxing for the guardrails row, execution authority versus observability for the monitoring row, enforcement versus detection for agent-monitoring platforms, and execution layer versus governance layer for the GRC row.

What does a governance receipt actually contain?

A receipt is the artifact that makes the decision checkable by someone who does not trust the system that produced it. To do that job it has to bind together everything the decision depended on:

• The request. The canonicalized action that was proposed, so that two textually different but semantically identical requests do not produce two different records.
• The authority. Which actor, which grants, and which operating bounds applied at the moment of the decision.
• The policy version. The exact signed bundle that was in force, not merely the name of a policy that has since changed.
• The outcome. Allow, refuse, or escalate, with the rule that produced it.
• The signature. An ED25519 signature over the whole record, verifiable offline against a published key.

The last property is the one that matters most for auditors, and it is the one most often missing: verification must not require the vendor. If checking a receipt means calling an API owned by the company whose behavior is being audited, the receipt is an assertion, not evidence. Offline verification against a published key is what makes it independent.

How do you measure whether governance is actually enforced?

Claims about runtime governance are testable, which means they should be tested rather than asserted.

AGB, the Agentic Governance Benchmark, scores runtime governance capability across six weighted dimensions: policy determinism, enforcement latency, receipt provenance, scope containment, jurisdictional enforcement, and override integrity. The composite maps to a maturity tier from Ungoverned to Sovereign. The published paper presents a self-assessed reference implementation and recommends independent third-party assessment to strengthen its evidentiary value.

OHB, the Override Health Benchmark, covers the human half. Deterministic enforcement is only half of governance if human override has quietly decayed into rubber-stamping. OHB examines whether human oversight remains meaningful, durable, and timely as autonomous systems push toward action.

AGB evaluates runtime governance capability, including human override integrity. OHB asks whether human authority remains operationally real. A high capability score does not guarantee good governance outcomes.