In a classified or mission-critical environment, "probably safe" is not a control.
AI governance has to be deterministic, provable, and replayable.
When AI touches a system where the cost of a wrong decision is a spill across a security boundary, you cannot govern it with a model that scores a probability. The High-Assurance Gateway is a deterministic enforcement layer for AI interactions and AI-driven actions — every decision reproducible from the same inputs and versioned policy, every decision recorded in a tamper-evident log you can replay. It is built in Rust and designed against NSA cross-domain standards, for the air-gapped and regulated end of the stack.
Deterministic, replayable AI governance — designed against NSA cross-domain standards. Not NSA-certified.
Why mission-critical AI needs a different layer
The governance that's good enough for a SaaS workflow is not good enough where a single uncontrolled byte crosses a domain boundary.
In defense, intelligence, and other high-assurance settings, AI is now in the loop — summarizing, drafting, mediating tool calls, planning multi-step actions. The standard for governing data flow in those environments is decades old and unforgiving: traffic between security domains is mediated by cross-domain solutions built and reviewed against explicit, testable requirements. AI does not get an exemption from that standard simply because it is new.
A probabilistic guardrail — a model asked whether something looks safe — cannot meet that bar. It is non-deterministic, it cannot be replayed to prove what happened, and it produces no artifact an accreditor can test. The same reasoning that rejects "the model felt it was fine" in a commercial audit rejects it outright at a classification boundary.
The High-Assurance Gateway brings AI interactions under the same discipline as a traditional cross-domain solution: deterministic policy, hardware-backed trust boundaries, and a signed, replayable record of every decision.
How it works
Five enforcement planes, from ingestion to a replayable audit trail — built in Rust so the enforcement-critical path is memory-safe by construction.
Ingestion plane
AI interactions and agent tool calls are intercepted via network mediation, SDK hooks, and sidecars before they execute.
Parsing plane
Provider formats (OpenAI, Anthropic, Gemini, MCP) are parsed into one canonical representation through parsers designed for formal verification (in progress), with schema validation — so policy is evaluated on a normalized form, not raw provider wire bytes.
Policy plane
Decisions are made by the Cedar policy engine against signed policy bundles. Same inputs, same policy version, same decision — every time.
Enforcement plane
Decisions are enforced through transforms, protocol breaks, and one-way data diodes — hardware-backed trust boundaries for air-gapped and cross-domain deployment.
Audit plane
Every decision is written as a signed, Merkle-logged record, with a replay harness that can re-derive any historical decision from the recorded inputs and policy version.
Authority & trust ladder
An authority hierarchy and trust ladder run across the planes, enforcing least authority and preventing trust-level escalation on multi-step agent plans.
The properties that make it high-assurance
Each one is a property an accreditor can test — not a claim you have to take on faith.
Deterministic & replayable
Every decision is reproducible given the same inputs and versioned artifacts, and the replay harness can re-derive it later. There is no second model whose mood changes the answer.
Cedar policy, signed bundles
Policy is authored in Cedar and distributed as signed bundles, including a Cedar entity hierarchy for tenant and authority scoping. Policy is data the gateway verifies, not code it trusts blindly.
Hardware trust boundaries
Data diodes and protocol breaks provide physical and logical separation between domains, with a vendor-abstracted diode integration for air-gapped on-premise deployment.
Parsers designed for formal verification
The parsing path is designed around parsers we are building toward formal verification (not yet attested), aimed at closing the malformed-input attack surface that ordinary deserializers leave open at a boundary that has to hold.
Designed against the cross-domain standards
We map the architecture to the standards that govern cross-domain solutions. We are explicit about what that does and does not mean.
| Standard | What we map to it |
|---|---|
| NCDSMO Raise the Bar (RTB) v5.0 | The cross-domain baseline — RAIN principles and the PIR / OSSR / SIR / FSR requirement families. The architecture is designed against these; documented in our internal compliance mapping. |
| NIST SP 800-53 | AC-4 Information Flow Enforcement, including the cross-domain control enhancements, maps to the enforcement and diode planes. |
| DoDI 8540.01 & CNSSI 1253 | DoD cross-domain policy and the CDS overlay frame the deployment and trust-boundary model for on-premise air-gapped use. |
The High-Assurance Gateway is designed against NSA cross-domain standards and maps to NIST 800-53 and RTB v5.0. It is not NSA-certified and we do not claim certification or FedRAMP authorization. Our compliance roadmap — SOC 2 Type II, ISO 27001, FedRAMP — is on the compliance page.
Who this is for
Defense & intelligence programs
You operate across security domains and need AI interactions governed with the same rigor as any other cross-domain flow — deterministic, accreditable, and replayable.
Air-gapped & on-premise deployments
Cloud-only is not an option. You need an enforcement layer that runs on-premise behind hardware data diodes, with no dependence on an external service to make a decision.
Agent tool mediation under authority control
You run multi-step agent plans (Claude Code, MCP tool calls) and need pre-execution governance with an authority hierarchy that blocks unauthorized escalation step by step.
Provider-agnostic chatbot governance
You want one canonical policy applied consistently across ChatGPT, Claude, Gemini, and others, regardless of each provider's wire format.
Stated honestly
High-assurance buyers do diligence. Here is the honest scope.
What it is
- A deterministic Rust enforcement layer for AI interactions and actions, with Cedar policy and a Merkle-logged, replayable audit trail.
- Designed against NSA cross-domain standards and mapped to NIST 800-53 and RTB v5.0, for air-gapped on-premise deployment.
- Designed around data diodes, protocol breaks, and parsers built toward formal verification (not yet attested) at the trust boundary.
What we don't claim
- Not NSA-certified. Not a FedRAMP authorization. We claim "designed against" and "maps to," and never "certified."
- It is engaged through a briefing and deployment process, not a self-serve sign-up. This is the mission-critical end of the platform.
- No invented customers, no invented metrics. Deployment posture and accreditation status are discussed under briefing.
Where it fits in the stack
The High-Assurance Gateway is the same governance discipline as the rest of the platform, taken to cross-domain rigor.
AI Chat Firewall
Governs people using AI chat assistants in the browser, in ordinary enterprise environments.
Agent Governance
Deterministic, pre-execution decisions on autonomous agent actions at the LLM-call boundary.
High-Assurance Gateway
This product. The same governance for air-gapped and cross-domain deployments, designed against NSA cross-domain standards.
Request a briefing
For defense, intelligence, and high-assurance programs. We'll walk through the architecture, the standards mapping, and the deployment model for your environment.
Evaluating runtime agent governance more broadly? See how we align with the AARM standard →