Deterministic AI Governance
Deterministic AI Governance at Runtime
Same policy input, same enforcement decision, every time, with signed evidence to prove it.
Deterministic AI governance is the property that identical inputs always produce identical enforcement decisions. The same request, evaluated against the same policy version, yields the same allow or refuse outcome every time, and each decision is recorded in a signed receipt that a third party can verify independently.
This matters because the alternative cannot be audited. A probabilistic guardrail can give two different answers to the same question on two different days. An auditor cannot sample-test a control that changes its mind. A control that cannot be replayed cannot be audited, and most of what ships as AI governance today fails that test.
The rest of this page answers the questions that follow from that definition: what makes a decision deterministic, why the check has to happen before execution, how this differs from guardrails and gateways, what the receipt contains, what happens when the enforcement layer goes down, and how you measure whether any of it is actually working.
What makes an enforcement decision deterministic?
Four properties, all of which 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.
Why does enforcement have to happen at runtime?
Because design-time review governs the system you intended to ship, not the action an agent proposes at 3am against live production data.
A traditional software control can be reviewed once, because the code paths are fixed. An autonomous system composes its next action at runtime, from context that did not exist when anyone reviewed it: the current state of a database, a tool it discovered mid-session, a chain of prior steps nobody enumerated, a document that turned out to contain instructions. The specific action was not available for review, so review cannot be the control.
That leaves exactly one place to intervene: the moment the action is requested, before it reaches the system it would affect. Earlier than that and the action does not exist yet. Later than that and it has already happened.
This is also the reason a single human approval at the start of a session is not sufficient. Approving an agent's goal is not approving the two hundred individual actions it will take pursuing that goal. Session-scoped approval grants authority for a trajectory nobody has seen. Deterministic runtime governance evaluates each action against the authority that was actually granted.
Is deterministic AI governance the same as guardrails?
No, and 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.
Does deterministic governance eliminate agent autonomy?
This is the most common objection, and it rests on a conflation: treating the freedom to decide and the freedom to act as the same freedom.
Under deterministic governance the agent keeps everything that makes it useful. It reasons, plans, searches, chains tools, revises, and proposes. What changes is that proposing and executing are separated. The agent may attempt anything. Only actions inside granted authority run.
In practice this expands what an organization is willing to let an agent do. Autonomy is usually constrained by the blast radius of the worst thing an agent could do unsupervised, so teams keep agents in read-only mode or behind a human clicking approve on everything. A boundary that provably bounds the worst case removes the reason for that ceiling. Bounded autonomy is what makes broader autonomy grantable.
The model is treated as an untrusted source of proposals, not as an authorized actor.
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.
What happens if the enforcement layer is unavailable?
It fails closed. If policy cannot be evaluated, the action does not execute.
This is not a detail, it is the property that determines whether the boundary is a control at all. A governance layer that fails open turns an outage into a bypass, which means anyone who can cause an outage can remove the control. Any adversary who understands the architecture will attack availability rather than policy, because it is the cheaper path.
Fail-closed has a real operational cost: when the boundary is unreachable, governed actions stop. That is the correct trade for operations where an unauthorized action is worse than a paused one, which is the situation in regulated finance, healthcare, industrial control, and autonomous systems generally. It is a deliberate design position rather than an implementation limitation, and it should be evaluated as one.
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, is the measurement instrument for the machine half. It tests whether an autonomous AI system actually enforces runtime governance: blocking prohibited actions, escalating uncertain decisions, and producing receipt-grade evidence rather than a log entry. The scoring methodology is published, so a result is reproducible by a third party.
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 asks whether the machine enforces governance. OHB asks whether human authority remains operationally real. A system can pass either one alone and still be ungoverned in practice.
How is this different from monitoring, observability, and GRC?
Many AI governance programs describe responsible behavior, publish policy language, and monitor activity after deployment. That work is necessary. It is not sufficient for autonomous systems, because a system can promise compliance, generate a fluent policy explanation, and still execute an unauthorized action.
Post-hoc monitoring explains what happened. Deterministic governance constrains what is able to happen. GRC platforms document which controls exist. Deterministic governance is the control. These sit at different points in the lifecycle and answer different questions, and an organization that has only the first two has monitoring evidence and documentation evidence, not enforcement evidence.
The distinguishing test is short enough to apply to any vendor claim: does the policy check occur before execution, and does the decision survive as a signed record that replays independently?
If there is no cryptographic receipt per decision, it is monitoring, not governance.
Evidence and further reading
The architecture on this page is published, DOI-registered, and citable rather than described only in marketing copy. Patent-linked disclosures cover deterministic governance enforcement, authority receipts, runtime policy bundles, and governed agent supply-chain control.
- Benton, J. Deterministic Runtime Enforcement Architecture, Foundational Trilogy. Zenodo Record 18749299.
- Benton, J. The Agentic Governance Benchmark, scoring methodology. DOI 10.5281/zenodo.20496565.
- Benton, J. Deterministic Governance for Autonomous Financial Transactions on Distributed Ledgers. DOI 10.5281/zenodo.20280613.
- Benton, J. Foundational thesis on execution-bound governance. SSRN Abstract 6290760.
- Kaptein, M., Khan, V.J., Podstavnychy, A. Runtime Governance for AI Agents: Policies on Paths. arXiv:2603.16586 (2026). arxiv.org/abs/2603.16586
- Fundamental Limits of Runtime Policy Enforcement in Multi-agent AGI Systems. Springer. DOI 10.1007/978-3-032-33195-3_21