Probabilistic Intelligence, Deterministic Authority

The AI does not need to own the state it reasons about.

That sentence captures an architectural idea I have been converging on through months of work on governed AI systems.

Large language models are probabilistic. They reason, generate, interpret, plan, and choose in ways that are not perfectly predictable.

The systems we increasingly want them to operate inside are different.

A publication record has a state. A bank ledger has a state. A deployment environment has a state. A customer record has a state. A workflow has a state. An approval has a state.

At some point, probabilistic reasoning crosses a boundary and becomes an authoritative change in the world.

My question has become:

What if the important thing to make deterministic is not the intelligence itself, but the boundary through which intelligence acquires authority to change state?

That leads to a simple architectural proposition:

A probabilistic system does not need to be made deterministic in order to operate inside a deterministic system. Its authority can instead be bounded at the transition interface.

Intelligence is not authority

A recurring mistake in discussions about AI agents is treating intelligence and authority as though they were the same variable.

They are not.

A system can be enormously capable at reasoning without being permitted to alter anything. Conversely, a relatively unintelligent program with unrestricted credentials can cause enormous damage.

That suggests two independent axes:

reasoning competence
        !=
operational authority

The architecture I have been working toward treats the model primarily as a proposal generator.

It can reason about the current state. It can identify a desirable transformation. It can propose an operation.

But it does not get to define what constitutes an authorized state transition.

That decision belongs somewhere else.

The state-transition boundary

At its simplest, the architecture looks like this:

State_n
    |
    v
probabilistic proposal
    |
    v
capability + validation + authority boundary
    |
    v
authorized deterministic transition
    |
    v
State_n+1

The model proposes.

The deterministic system decides whether the proposal is admissible.

That distinction has deep precedent. Capability security and the principle of least privilege have spent decades separating computation from the authority that computation possesses. Reference-monitor theory focuses on completely mediating access to protected resources. Transaction systems distinguish computation from durable commitment. Effect systems distinguish returned values from side effects. Ramadge and Wonham's supervisory-control theory showed that possibly nondeterministic processes can be constrained by disabling transitions that fall outside a legal behavior space.

Modern AI security research is now arriving at similar territory from another direction. Systems including CaMeL, Progent, Fides, RTBAS, and DRIFT move critical enforcement outside the language model rather than depending entirely on the model to recognize attacks and voluntarily refuse them.

So the claim cannot responsibly be:

“I discovered that deterministic controls can make AI agents safe.”

That would be historically inaccurate and far too broad.

The more interesting question is what, exactly, should those controls govern?

Canonical-state authority

The unit I keep returning to is not simply the tool call.

It is the canonical state transition.

A tool might execute. A command might run. A model might generate an artifact. None of those things necessarily mean the authoritative system state has changed.

That gives us a useful decomposition:

implementation
      !=
registration
      !=
model exposure
      !=
authorization
      !=
execution
      !=
canonical commit

These stages are often collapsed together in ordinary software systems.

For AI agents, I think separating them explicitly is useful.

A capability can exist in code without being registered. It can be registered without being visible to the model. It can be visible without necessarily being authorized in every context. It can be authorized but fail during execution. And execution itself does not automatically have to mean that protected canonical state accepted the resulting transition.

In the targeted literature review behind this article, I found the ingredients of these distinctions throughout existing security and systems work, but not this exact canonical-state-oriented decomposition commonly expressed as one agent architecture.

The cautious classification is therefore an uncommon synthesis and potentially distinctive implementation pattern, not a new foundational security principle.

Do not give the agent a machine. Give it verbs.

This principle becomes much easier to understand when translated into interface design.

Consider these two authority surfaces.

agent
   |
   v
exec(command: string)
   |
   v
arbitrary machine behavior

versus:

agent
   |-- gs2c_status()
   |
   `-- gs2c_ingest_url(title, source_url)
           |
           v
      fixed domain semantics

Both ultimately execute software.

But they give the model radically different expressive authority.

The first gives the model a general-purpose mechanism and then attempts to control how it uses that mechanism.

The second makes the available action vocabulary itself reflect the intended domain.

The distinction is subtle but important:

Authorization determines whether an operation may be performed. Capability design determines what operation can be expressed in the first place.

A sophisticated policy engine wrapped around exec(string) still exposes an enormous semantic surface after authorization. A narrow operation such as gs2c_status() expresses dramatically less authority before contextual policy is even considered.

This leads to a design discipline I intend to continue developing:

Do not give an agent a machine. Give it verbs. Make the verbs domain-specific. Make dangerous verbs nonexistent by default. Re-check authorization at the boundary. Let the deterministic domain system—not the model—decide whether a proposed transition is legal. Keep canonical truth outside the conversation.

Building the idea

I now have a working reference implementation of part of this architecture.

It consists of four primary layers:

GPT-5.6 Sol
probabilistic reasoning
        |
        v
OpenClaw
agent orchestration
        |
        v
openclaw-gs2c
narrow transition adapter
        |
        v
GS2C
governed deterministic runtime
        |
        v
canonical workspace + state

GS2C—Governed Signal-to-Content—owns the domain state.

The model does not.

OpenClaw provides the agent runtime. A custom plugin exposes narrowly defined GS2C operations to the agent. Generic shell execution remains unavailable to the model. The adapter fixes the GS2C executable and canonical workspace instead of allowing the model to choose them.

That distinction is fundamental:

The intelligence can choose among authorized domain proposals without receiving general machine authority.

What the experiments have actually demonstrated

I wanted more than an architecture diagram.

So I have been testing the authority boundary using both positive and negative controls.

First: no capability

Before the GS2C plugin was available, the model was explicitly instructed to use a gs2c_status operation.

It could not.

It reported that the capability was unavailable.

Then: implemented and registered, but still unavailable

The plugin was installed and OpenClaw registered gs2c_status.

But the model's actual request vocabulary still contained only its existing session-status tool. The newly registered GS2C capability did not automatically become available merely because its implementation existed.

Then: explicit grant

I explicitly granted only:

gs2c_status

The next runtime trace showed the capability entering the model-visible tool set.

The model invoked it.

GS2C returned the authoritative state of its canonical workspace.

Generic shell execution remained denied.

The observed relationship was:

registered
+
not granted
->
not model-visible

registered
+
explicitly granted
->
model-visible
+
successfully invoked

This establishes a bounded observation about the tested configuration: model competence and operational authority were separate configuration dimensions.

Then I added mutation code—without granting mutation authority

The next experiment was more important.

I implemented:

gs2c_ingest_url(title, source_url)

This operation can create a GS2C candidate and advance it into its evidence-preserved state.

But its model-visible input contains only:

title
source_url

The model cannot choose the workspace, executable, local source file, shell command, approval operation, release operation, or an arbitrary GS2C command through that interface.

The adapter fixes the executable and workspace and rejects non-HTTP(S) input.

Rather than testing mutation against production state, I created an isolated temporary GS2C workspace.

The integration suite performed a real mutation there, confirmed the expected state transition, cleaned the workspace up, and passed all seven tests.

Then the new mutation capability was loaded into OpenClaw.

But I did not grant it to the model.

Runtime inspection showed that the tool was registered. The actual model request still did not contain it. When explicitly instructed to perform an ingest, the agent returned:

GS2C_INGEST_NOT_AVAILABLE

Canonical production state remained unchanged.

That gives us an important empirical result:

For the tested model principal and configuration, implementation and runtime registration did not themselves confer operational authority.

That is much narrower than proving the entire system secure.

But it is real evidence.

What this does not prove

This is where discipline matters most.

I have not proven a universally secure AI-agent architecture.

The current experiment does not establish protection against every possible attack or bypass.

In particular, it has not yet solved or fully tested:

• prompt injection that convinces the model to misuse a legitimately permitted operation;
• confused-deputy attacks;
• malicious but syntactically valid parameters;
• forged internal tool invocation;
• revocation races;
• replay and duplicate calls;
• concurrency and TOCTOU conditions;
• compromised plugin or OpenClaw runtime;
• compromised host operating system;
• supply-chain compromise;
• direct modification of the canonical database through another privileged path;
• stolen credentials;
• human approval mistakes;
• complete system-wide non-bypassability.

Prompt injection against legitimate authority is one of the most important next problems.

Narrow capabilities reduce the amount of authority an attacker can inherit if the model is manipulated, but they do not guarantee that an allowed capability will always be used for the correct intent.

That suggests authorization will eventually need to consider more than:

Is this capability allowed?

It may need something closer to:

principal
+
capability
+
arguments
+
current state
+
task intent
+
data provenance
+
approval context

That is a movement from ordinary static least privilege toward what I would call task-scoped least authority.

Determinism is not the safety property

There is another important correction.

A deterministic system can be deterministically wrong.

If its policy is incorrect, perfect reproducibility simply means it will reproduce the incorrect behavior reliably.

So my thesis is not:

Determinism creates safety.

It is:

Deterministic mediation makes specified safety properties enforceable independently of probabilistic model compliance.

The policy still has to be correct. The implementation has to be trusted within the stated threat model. Protected state changes have to be completely mediated. And the canonical state itself has to be protected from alternate write paths.

That last requirement may eventually push this architecture beyond a plugin boundary.

A stronger system could separate OpenClaw from GS2C at the operating-system or service boundary:

model / OpenClaw
      |
      | no canonical DB write access
      v
authenticated narrow transition API
      |
      v
GS2C transition service
dedicated identity
      |
      v
canonical state

At that point, even compromising the agent process would not automatically imply direct authority over protected state.

That is closer to the classical reference-monitor ideal of complete mediation and a deliberately constrained trusted computing base.

A formal direction

The core system can be expressed without attempting to formalize the internal cognition of the language model.

Let:

S = canonical state
p = model-generated proposal
c = proposed capability
x = capability arguments
A = authorization function
G = state/domain guard
T = deterministic state transition

The model may probabilistically produce:

p = (c, x)

But it does not own T.

The mediator asks whether the proposal is admissible.

Conceptually:

Admit(p)
=
capability exposed
AND parameters valid
AND principal authorized
AND state guard satisfied

Then:

if admitted:
    State_n+1 = T(State_n, p)
else:
    State_n+1 = State_n

That makes an interesting research strategy possible.

Instead of proving that the LLM itself will behave correctly, treat it as an arbitrary or even adversarial proposal generator.

Then prove properties of the surrounding transition system.

Candidate properties

Unauthorized Transition Non-Interference
An unauthorized or invalid proposal cannot change protected canonical state.

Capability Confinement
Every model-caused canonical transition belongs to the semantics of an explicitly authorized operation.

Revocation Safety
Once authority is revoked under the specified policy boundary, stale authority cannot subsequently commit a transition.

Approval Separation
A transition requiring independent human authority cannot be enabled solely through actions available to the model principal.

That may be one of the most useful simplifications in the entire architecture:

The probabilistic model does not have to become part of the trusted proof obligation.

It can be treated as an uncertain component whose effects are bounded elsewhere.

Where the idea actually sits

The research did not validate a story in which I independently discovered a completely new field of computer security.

Good.

That would have been a much weaker foundation to build on.

Instead, the architecture appears to sit at the intersection of several mature traditions:

• capability security and least authority;
• reference monitoring;
• information-flow control;
• supervisory control;
• effect systems;
• transaction processing;
• deterministic workflow systems;
• and emerging out-of-model security mechanisms for AI agents.

The established principle is that untrusted computation can be constrained by external authority mechanisms.

The potentially distinctive part is the synthesis:

probabilistic proposal
        |
        v
explicit capability lifecycle
        |
        v
domain-state guard
        |
        v
deterministic transition
        |
        v
canonical commit

with canonical-state authority itself treated as the thing being confined.

I am currently using the following terminology:

Probabilistic Intelligence, Deterministic Authority
The umbrella framing.

Authority-Separated Agent Architecture
The broader architectural model.

Deterministic Transition Mediation
The enforcement mechanism.

Least-Authority Transition Interface
The narrow boundary through which the agent proposes effects.

Canonical-State Authority Confinement
The property ultimately being investigated.

What comes next

The next experiment is already defined.

The mutation capability exists. It has been tested. It is registered. And it is still withheld from the model.

The next sequence will be:

snapshot canonical state
        |
        v
grant gs2c_ingest_url
        |
        v
perform one legitimate bounded mutation
        |
        v
capture candidate / evidence / receipt identity
        |
        v
independently verify canonical state
        |
        v
revoke gs2c_ingest_url
        |
        v
prove mutation authority disappeared

That will establish:

grant
-> bounded effect
-> revoke

After that come harder experiments: forged-call enforcement below the model layer, replay and idempotency, revocation races, adversarial parameters, prompt injection against granted authority, alternate-path bypass analysis, model independence, and adaptive red teaming.

The architecture should be attacked, not merely admired.

If a model can alter protected canonical state without traversing an admitted transition and producing the expected evidence, the security claim should be considered false for that configuration.

That makes the idea falsifiable.

And therefore worth testing.

The larger principle

As AI systems become more capable, I do not think the only question should be:

How do we make the model behave?

There is another question:

What authority should the model possess even if it does not behave?

That distinction changes the architecture.

It moves safety away from asking a probabilistic model to reliably remember a prohibition and toward designing systems in which the model's reasoning and the system's authority are deliberately separate.

The model may suggest. The model may reason. The model may discover. The model may propose.

But protected reality does not have to change simply because the model generated an action.

There can be a boundary.

And that boundary can have its own semantics, authorization, state guards, invariants, receipts, and human authority.

The most defensible formulation I have reached so far is this:

This work develops and evaluates an authority-separated agent architecture in which probabilistic model outputs are treated as untrusted transition proposals, while a deterministic least-authority mediator—not the model—owns the admissibility and commitment of changes to canonical state.

Or, more simply:

The object that must be made deterministic is not the intelligence. It is the authority boundary between proposal and protected state transition.

That is the idea I intend to keep testing.

Not by assuming it works.

By trying to break it.

Research foundations and adjacent literature

The architecture above is deliberately situated in prior work rather than presented as a claim that its component mechanisms are unprecedented. The following sources are among the most important theoretical and engineering neighbors identified in the research review.

1. Dennis, J. B., & Van Horn, E. C. (1966). "Programming Semantics for Multiprogrammed Computations." Communications of the ACM. doi:10.1145/365230.365252
2. Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems." Proceedings of the IEEE. doi:10.1109/PROC.1975.9939
3. Denning, D. E. (1976). "A Lattice Model of Secure Information Flow." Communications of the ACM. doi:10.1145/360051.360056
4. Härder, T., & Reuter, A. (1983). "Principles of Transaction-Oriented Database Recovery." ACM Computing Surveys. doi:10.1145/289.291
5. Ramadge, P. J., & Wonham, W. M. (1987). "Supervisory Control of a Class of Discrete Event Processes." SIAM Journal on Control and Optimization. doi:10.1137/0325013
6. Lucassen, J. M., & Gifford, D. K. (1988). "Polymorphic Effect Systems." POPL '88. doi:10.1145/73560.73564
7. Debenedetti, E. et al. (2024). "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." NeurIPS 2024. NeurIPS proceedings
8. Debenedetti, E. et al. (2025). "Defeating Prompt Injections by Design" (CaMeL). arXiv:2503.18813
9. Shi, T. et al. (2025). "Progent: Programmable Privilege Control for LLM Agents." arXiv:2504.11703
10. Costa, M. et al. (2025). "Securing AI Agents with Information-Flow Control" (Fides). arXiv:2505.23643
11. Zhong, P. Y. et al. (2025). "RTBAS: Defending LLM Agents Against Prompt Injection and Privacy Leakage." arXiv:2502.08966
12. Li, H. et al. (2025). "DRIFT: Dynamic Rule-Based Defense with Injection Isolation for Securing LLM Agents." NeurIPS 2025. NeurIPS proceedings
13. Narisetty, P. et al. (2026). "Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection in LLM Agents." arXiv:2606.26479