Deterministic Governance for Forward-Deployed AI

When AI is forward-deployed into safety- and security-critical systems, the model cannot be its own assurance mechanism. The control that holds is an external, deterministic, pre-execution gateway — the AARM-aligned Protocol Gateway pattern.

By Containment.ai Research  ·  Published June 27, 2026  ·  Product status: Trust page →
Mission Authorization Gateway — five enforcement planes. An AI-mediated request passes through five planes — interception and ingestion, parsing and canonicalization, deterministic policy evaluation, enforcement (ALLOW, DENY, MODIFY, STEP_UP, DEFER), and audit and replay — before crossing the mission, safety, or security boundary. Designed against NSA cross-domain standards; not NSA-certified.
FIG. A — THE FIVE ENFORCEMENT PLANESCONTAINMENT.AI

AI is moving to the forward edge. It is being embedded in operational technology, in robotics, in industrial control, and in the disconnected and contested environments where defense autonomy actually operates. As it moves, something underneath it moves too: the security boundary. It is no longer the model's output that carries the most risk. It is the model's action — the tool call, the command, the change to a real system — taken at machine speed, often where no human is watching and no network is reachable.

This is a pillar piece. It lays out the thesis behind how we build, and why we now lead with a deterministic enforcement gateway as our flagship. We will be explicit throughout about what exists today and what is on the roadmap, because the buyers in this space do real diligence and a credible vendor does not blur that line.

The model cannot be its own assurance mechanism

The dominant pattern for "AI safety" in production is to ask a model to check a model: a second LLM, or the same model with a stricter prompt, judges whether an action looks acceptable. It is appealing because it is easy to add. It is also structurally unable to provide assurance.

A probabilistic system asked to certify a probabilistic system inherits every weakness of the thing it is certifying. It is non-deterministic — run it twice on the same input and you can get two answers. It cannot be replayed to prove what happened. And it produces no artifact an accreditor, an auditor, or an incident reviewer can independently test. "The model judged it safe" is the same unfalsifiable claim as "the model behaved safely," moved one box to the left.

The same reasoning that rejects "the model felt it was fine" in a commercial audit rejects it outright at a safety or classification boundary. Assurance has to come from somewhere the model is not.

The boundary moved from outputs to actions

For the last few years the practical concern about AI was what it would say — leak a secret, hallucinate a fact, emit something toxic. That concern is real, but it is a content problem, and content problems are recoverable. You can review the transcript afterward.

Agentic AI changes the shape of the risk. When a model can call tools, execute code, move data across a boundary, or actuate a physical process, the consequential event is no longer a sentence — it is an action, and actions are frequently irreversible and run faster than any human review loop. Perimeter defense (keep bad input out) and post-hoc forensics (find out what went wrong later) are both structurally inadequate against an irreversible action taken in milliseconds. By the time the log is reviewed, the data has crossed, the command has fired, the actuator has moved.

If the dangerous moment is the action, then the control has to sit at the action, before it executes. Not at the prompt. Not in the log. At the point of execution, in the path, with the authority to stop it.

The shape of the control: intercept, evaluate, enforce, attest

The control that meets this bar has a specific shape. It is an external, deterministic, pre-execution enforcement layer that does four things on every governed action:

  1. Intercept. Every governed AI interaction and every agent tool call passes through the layer before it executes. In the path, not beside it.
  2. Evaluate against policy and intent. The action is checked against an explicit, versioned policy and against the declared intent of the task — by a deterministic policy engine, not by a model. Same inputs and same policy version produce the same decision, every time.
  3. Enforce one of five decisions. The engine returns exactly one of: ALLOW, DENY, MODIFY (transform the action into a safe form — redact, downscope, strip), STEP_UP (require stronger authorization or a human in the loop before proceeding), or DEFER (hold for asynchronous review). There is no sixth "the model decided" path.
  4. Attest. The ruling is written to a decision record with a product-specific signing and verification method. Policy can be re-evaluated only when the exact input, context, and policy bundle are retained; record integrity is a separate check.

This is the AARM "Protocol Gateway" pattern — the runtime-governance architecture described by the Cloud Security Alliance's Agentic AI Runtime Mediation work. It is also, deliberately, exactly what our Mission Authorization Gateway is built to be. The point of naming the pattern is that this is not a containment.ai invention to take on faith; it is an emerging architectural consensus about where AI governance has to live, and we are building to it.

No AI model makes the enforcement decision. An AI model may inform upstream context — surfacing a classification, extracting an entity — but deterministic policy alone returns the enforcement ruling. The decision is deterministic policy over canonical inputs. That property lets the policy decision be re-evaluated and tested when the exact input, context, and policy bundle are retained; accreditation still depends on the broader system and evidence set.

Why the forward edge makes this non-optional

Everything above is true in a data center. At the forward edge it stops being a design preference and becomes a hard constraint, for two reasons.

Connectivity is denied, degraded, intermittent, or limited (DDIL). The Department of Defense's own AI strategy assumes the network is the first casualty of the fight — dispersed teams operating autonomously, processing data at the edge, with reach-back to the cloud as the exception rather than the rule. A governance layer that depends on a round-trip to a cloud console has two bad options when the link drops: fail open and let the AI act ungoverned, or fail closed and take the mission-critical AI offline. Neither is acceptable. The governance has to make its decision locally, with no callback — which a deterministic, in-path engine can do and a cloud-hosted model-judge cannot. We wrote about this constraint in detail in The DoD Wants AI That Works Disconnected.

The cost of a wrong action is physical and often irreversible. In operational technology, robotics, and industrial control, a wrong action is not a bad paragraph — it is a valve, a motor, a setpoint, a movement. The international guidance for AI in operational technology is converging on a clear principle: AI must not make safety-critical decisions autonomously, and there must be a human able to revert the system to deterministic control inside safe operating bounds. A five-decision engine with STEP_UP and DEFER is a direct, mechanical expression of "keep a human in the loop where the stakes require it" — not a policy slogan, an enforced gate.

How this maps to the frameworks

Deterministic, pre-execution enforcement is not a detour around the recognized AI-risk frameworks — it is the part of them that actually bites at runtime.

  • NIST AI RMF. The MEASURE and MANAGE functions ask for AI risks to be assessed and actively controlled in operation. A decision record for each governed ruling is measurement you can review; a five-decision engine that can ALLOW, BLOCK, REDACT, ESCALATE, or STEP_UP in the path is management that takes effect before harm, not after.
  • CISA / allied OT guidance. The "keep AI inside safe operating bounds, with a human able to revert to deterministic control" principle maps directly onto STEP_UP (escalate before acting) and DENY (refuse the unsafe action).
  • AARM. The whole architecture is the Protocol Gateway pattern — interception, policy mediation, the decision set, and the tamper-evident receipt.

A note on a tempting but dangerous argument

There is a widely discussed "three-failure" frame for high-consequence AI command-and-control: a system can fail because it cannot control who sees what, because it cannot see what users actually do, or because it cannot verify the software doing the work. It is a useful lens for what an enforcement layer must close — visibility, mediation, and verifiability are exactly the three properties a deterministic gateway provides.

We use it only that way. We do not claim that any named system in the field is presently broken, and neither should anyone selling against this category. The failure mode is instructive; an unsupported assertion that a specific deployed program is failing is not something we can stand behind, and it is not something a serious buyer would credit. The argument for deterministic governance does not need it.

What we ship today, and what is roadmap

Plainly, so a buyer can vet it:

Today. The Mission Authorization Gateway software path is a deterministic Rust enforcement layer with a Cedar policy engine, signed policy bundles, and hash-chained Ed25519 UCEE receipts. Its authorization and output-conformance APIs, published staging key, receipt browser, and verifier run on staging. The data-diode interface and simulator are implemented; the physical Owl driver awaits vendor SDK access. Formal verification remains in progress. The system is designed toward NSA Raise the Bar guidance and maps to NIST SP 800-53; it is not certified against either.

Roadmap, and not yet true. We do not hold an Authorization to Operate. We are not FedRAMP-authorized, not CMMC-certified, not NSA-certified, and we do not claim an IL4/5/6 accreditation. Tactical-edge non-functional requirements — bounded sub-millisecond latency, validated true air-gap operation, formal non-bypassability — are targets we are actively gating against an internal hardware-grounded evaluation, not results we are reporting. We have no production customers and we publish no usage or performance metrics, because we have none to publish honestly. Anyone who tells you a pre-ATO startup has these is wrong.

The honesty is the point. A control whose entire value proposition is that it is provable cannot be sold with unprovable claims.

Where this goes

The flagship is the gateway: deterministic, in-path, non-bypassable by design, signed-receipt, five-decision, no AI model makes the enforcement decision. The browser extension, the proxy, and the dashboard are the connected tier — the same governance discipline for ordinary connected enterprise environments, feeding the same policy and audit model. The beachhead is the forward edge: operational technology and defense autonomy, where DDIL connectivity and irreversible physical action make deterministic, local enforcement the only governance that survives contact.

If you operate AI where a wrong action is irreversible and the network is not guaranteed, this is the conversation we want to have. Request a briefing and we will walk the architecture, the standards mapping, and — candidly — the accreditation roadmap for your environment.

READY TO CLOSE THE GAP?
Deterministic AI governance for regulated and mission environments.
Request a 30-minute Boundary Review → Apply to the Design Partner Program → Authorize commands at the OT boundary →