Defense already solved "what is allowed to cross a boundary"
Every discussion of governing AI in classified and tactical environments talks as if the problem is brand new. It isn't. The U.S. government has spent years building a rigorous discipline for exactly one question — what is allowed to cross a boundary between two security domains, and how do you prove it held?
It's called Raise the Bar. Defense-AI vendors standing up agentic systems on program networks should read it before writing another word of their security roadmap — it is the readymade blueprint for the AI enforcement boundary they're about to need.
What Raise the Bar actually is
The National Cross Domain Strategy and Management Office (NCDSMO) sits inside the NSA. It was, per an October 2024 Department of Defense briefing, "formally stood up on 15 February 2019 by a joint DOD and IC CIO memorandum" and operates under National Security Directive 42 authorities; National Security Memorandum 8 (NSM-8), dated 19 January 2022, "assigns [NCDSMO] its CDS authorities at a national level" (DoD, Fundamentals of Cross Domain Solutions, Oct 2024).
A Cross Domain Solution (CDS) is, in NIST's words quoted by that briefing, "a form of controlled interface... that provides the ability to manually and/or automatically access and/or transfer information between different security domains." And Raise the Bar (RTB) is, verbatim, "the NCDSMO's security requirements for the design, development, assessment, and deployment of CDS to improve the security and capabilities for the protection of [National Security Systems]." It "is updated annually" and "applies to all USG-operated CDS" as well as "all CDS developed for sale as part of a Foreign Military Sales (FMS) activity." A Sandia National Laboratories briefing adds that RTB targets "all cross domain solutions used to protect U.S. Government classified information" (Sandia/DOE, 2022). NCDSMO maintains a public baseline list of RTB-compliant products — and getting onto it is not a checkbox, it is a formal, lab-assessed evaluation.
RAIN: the four principles that matter for AI
At the architectural core of RTB are four non-negotiable concepts. When the NSA released the 2019 Raise the Bar baseline, a NAVAIR solicitation records that "the RTB policy identifies four foundational concepts for a CDS, which are Redundant, Always Invoked, Independent Implementations, and Non-Bypassable (RAIN)" (Navy SBIR N212-110).
Read those four words as design requirements for any boundary that decides what may cross:
- Redundant — no single point of failure in the enforcement path. If one check fails, another catches it; security does not degrade silently.
- Always Invoked — every transfer, every time. No bypass, no administrative shortcut that lets something cross unfiltered.
- Independent Implementations — the verification layers are genuinely separate, so a single flaw doesn't defeat all of them at once.
- Non-Bypassable — the boundary is not optional and cannot be routed around.
That is not a list of nice-to-haves. It is the distilled, decades-hardened answer to "how do you trust a boundary in an actively contested environment." And it maps almost word-for-word onto what an AI enforcement layer has to be.
The thing crossing the boundary changed
RTB was written for a world where the thing crossing a domain boundary is data — a file, a message, a video feed. The same DoD briefing already contemplates that CDS run "in a... Size, Weight, Power, and Cooling (SWaP-C) constrained environment," with "typical deployments [including] satellites, human-wearable, aircraft, ground vehicles, and naval vessels," and the tactical case explicitly assumes "an environment where communications capabilities may be interrupted." Defense already knows how to govern boundaries at the disconnected edge.
What's new is that the boundary is no longer only crossed by files. It's crossed by an AI agent's actions and outputs — a model that plans, calls tools, and takes steps at machine speed, increasingly forward-deployed to that same edge. (For the demand side of this, see our note on the Department of War's AI-first, edge-first mandate.) A model cannot be its own assurance mechanism: it is probabilistic by construction, and it gets swapped on a fast refresh cadence. So the one part of the system that governs what an agent is allowed to do — and proves what it did — has to be the deterministic part. It has to be a separate boundary, held to the same discipline RTB already demands.
What RAIN looks like applied to the AI boundary
Translate the four principles into an AI enforcement gateway and the requirements write themselves:
- Non-Bypassable → a deterministic gateway, not another model, in the decision path. The same input, policy, and context always produce the same ruling — ALLOW, DENY, MODIFY, STEP-UP, or DEFER — and a lost link or ambiguous input resolves to deny, never allow.
- Always Invoked → every prompt and every agent tool-call is intercepted and evaluated before execution, not logged after the fact. A record of an exfiltration is evidence of a breach; it is not prevention.
- Independent Implementations → layered, separable evaluators across distinct planes (parse and canonicalize → policy evaluation → enforce → audit), so no single flaw defeats the boundary.
- Redundant → orchestrated, cross-checked enforcement that fails safe rather than failing silent — and emits a signed, replayable receipt an assessor can verify.
Where Containment.AI fits — and where it doesn't yet
Containment.AI's Mission Authorization Gateway is built on exactly this thesis: an external, deterministic, pre-execution enforcement layer that intercepts an AI interaction, evaluates it against signed policy with no model in the decision path, enforces one of five rulings, and emits a tamper-evident, hash-chained decision receipt with full replay. Its engineering is explicitly designed against NCDSMO RTB v5.0 (RAIN principles), DoDI 8540.01, NIST SP 800-53 information-flow enforcement, and CNSSI 1253's Cross Domain Solution Overlay, with FIPS 140-3-capable cryptography (a validated-module lineage, not a CMVP-validated deployment — see the status line below) and a hardware data-diode interface for air-gapped postures.
To be precise — because a cross-domain authority should demand precision — the Gateway's deterministic decision engine, signed receipts, and edge action-authorization seams are running on staging today; the physical data-diode driver is pending a vendor SDK; the cryptography is FIPS 140-3-capable, with no CMVP validation of any Containment.AI deployment (see trust, which records FIPS 140-3 as ROADMAP / not validated); and NCDSMO lab assessment, baseline listing, and FedRAMP/IL5 authorization are on the roadmap, not shipped. It is designed against the standard, not certified to it — and we publish that status line so your diligence team can hold us to it.
The takeaway for primes and defense-tech vendors
If you're fielding agentic AI on a classified or tactical program, your organization already has a Cross Domain Support Element and an authorizing official who know RAIN cold. Use that. The question your security authority will ask about your AI stack is not "which model did you use." It will be: "show me the boundary that governed what the agent was allowed to do — and prove it held RAIN discipline when the link went down."
Raise the Bar already told you what a good answer looks like. Build the AI boundary to that bar before the demonstration becomes a deployment. For a second set of eyes on where your agent boundary sits against RAIN, request a boundary review.
Primary sources, all public: NSA/NCDSMO homepage; DoD OUSD(R&E), Fundamentals of Cross Domain Solutions (Oct 2024, Distribution A); Sandia/DOE, Birds of a Feather: Cross Domain Transfer Solutions (2022); Navy SBIR N212-110 (RAIN). Containment.AI capability and status claims reflect the Mission Authorization Gateway's current engineering state; "designed against" a standard is not a certification claim.