NIST Is Building the Federal AI Security Rulebook on 800-53. Defense Primes Should Read the Overlays Now.

NIST is writing AI security guidance on top of SP 800-53 — the same control catalog defense programs already run — and three of its five proposed overlays sit squarely on the data boundary: what your people put into the model. Here is why program security leads should read them before the initial public draft lands.

By Containment.ai Research  ·  Published July 6, 2026  ·  Reviewed July 12, 2026  ·  Product status: Trust page →
One control plane, three moments of risk. The same deterministic discipline governs three boundaries: the human prompt (AI Chat Firewall, between an employee and the AI provider), the agent action (Agent Governance, between an agent and a tool or system), and the mission boundary (Mission Authorization Gateway, between an AI system and an edge, domain, or OT environment). All three run intercept, canonicalize, evaluate, enforce, audit.
FIG. A — ONE ENFORCEMENT LAYER, THREE MOMENTS OF RISKCONTAINMENT.AI

Most defense contractors treat "AI security" as a category they will have to learn from scratch. NIST is quietly making sure they don't have to.

Since August 14, 2025, NIST has been developing "a series of NIST SP 800-53 Control Overlays for Securing AI Systems" — building AI security guidance on top of the same control catalog that already underpins federal system authorizations. On January 8, 2026 it published an annotated outline of the first overlay, Control Overlays for Securing AI Systems: Using and Fine-Tuning Predictive AI, ahead of the Cyber AI Profile Workshop #2 on January 14, 2026, and set a deadline: "Initial feedback on this annotated outline should be submitted by February 13, 2026 to ensure consideration for inclusion in the initial public draft."

The rulebook is being written now. Here is why program security leads should read it before the draft lands.

The good news: it's 800-53, not a new language

The COSAiS overlays don't ask you to adopt a new framework. Per the project, they leverage NIST SP 800-53 plus SP 800-218A, Draft NIST AI 800-1, and NIST AI 100-2e2025. An overlay, in NIST's model, is a tailored view of the existing catalog — "an implementation-focused series of guidelines that address use cases involving different types of AI systems and specific AI system components (e.g., training and test data, model weights and configuration settings)."

For a DoD prime or aerospace OEM already running an 800-53-derived control program — and, for Controlled Unclassified Information, its SP 800-171 companion — that is a rare gift. The AI rulebook maps onto controls your ISSMs, SSPs, and assessors already speak. You are not starting over; you are extending a baseline you already operate.

Five overlays — and three sit on the data boundary

NIST's concept paper proposes five use cases. The news release describes their scope plainly: the overlays "address generative AI, predictive AI, single and multi-agent AI systems, and controls for AI developers." The project page lists them precisely:

  • Adapting and Using Generative AI – Assistant/Large Language Model (LLM)
  • Using and Fine-Tuning Predictive AI
  • Using AI Agent Systems (AI Agents) – Single Agent
  • Using AI Agent Systems (AI Agents) – Multi-Agent
  • Security Controls for AI Developers

Read that list as a security lead and one pattern jumps out. The generative-AI/LLM overlay, the single-agent overlay, and the multi-agent overlay all govern systems your people feed data into — and that take action or return output based on it. NIST says the overlays are focused on protecting "the confidentiality, integrity, and availability of information and users" for each use case. At the LLM boundary, "confidentiality of information" is not an abstraction. It is whether an engineer can paste export-controlled design data into a summarization prompt, whether an agent can read a program document it was never cleared to touch, and whether you can prove afterward that it didn't.

What an overlay will — and won't — do for you

An overlay tells you which 800-53 controls apply to an LLM assistant or an agent system, and how to parameterize them for that use case. What it cannot do is enforce them at the point of use. The guidance defines the target; you still have to build the control.

And for the three data-boundary overlays, the control lives somewhere most programs have no coverage today: between the user's keyboard and the model. Most defense programs have mature controls for data at rest and data in transit across their own networks. AI introduces a fourth surface — data leaving the boundary into a model, cloud or local — and the tooling built for the first three rarely watches it.

The gap the overlays will expose

A FedRAMP-authorized model host does not close this gap: that authorization covers the service, not what your people type into it. A DLP tool tuned for email and file transfer rarely inspects a prompt box inside a browser tab. And a policy PDF that says "don't paste CUI into ChatGPT" is not a control — it is an aspiration an assessor cannot audit.

When the COSAiS overlays land as public drafts, the question your assessor asks shifts. Not "do you have an AI acceptable-use policy," but "show me the control that enforces it, and the evidence that it held." For the generative-AI and agent overlays, that evidence is a record of what data crossed the boundary, under what policy, in real time — the exact artifact most programs cannot produce today.

What to do before the initial public draft

Three moves pay off whether the draft lands next quarter or next year:

  1. Inventory where AI actually crosses your boundary — browser-based assistants, IDE copilots, agent tools acting on program data. You cannot overlay controls onto usage you cannot see.
  2. Map your existing 800-53 control set to the three data-boundary use cases. The access control (AC), audit and accountability (AU), system and communications protection (SC), and system and information integrity (SI) families are where the LLM-boundary controls will slot.
  3. Stand up enforcement and evidence at the point of use now, so that when the overlay formalizes the requirement, adoption is a documentation exercise — not a build-from-zero scramble under an assessment clock.

Where Containment.AI fits

This is the layer Containment.AI is built for. We enforce AI-usage policy where data actually crosses the boundary — in the browser and at the LLM proxy — monitoring sessions in real time, blocking sensitive data before it leaves, and generating the audit trail that turns "we have a policy" into "here is the evidence." As NIST's overlays formalize the confidentiality-integrity-availability objective for AI use, boundary-level enforcement is what makes an 800-53 AI control real instead of aspirational.

Our forward direction — a deterministic, non-bypassable, signed-receipt Mission Authorization Gateway for edge and disconnected environments — extends the same principle to the tactical, air-gapped, and OT contexts a cloud service can't reach at all.

NIST is doing defense contractors a favor by writing the AI rulebook in a language they already speak. The programs that come out ahead will be the ones that have already built the boundary control the overlays are about to require — before the initial public draft turns "should" into "shall."


Containment.AI governs the data crossing the LLM boundary — real-time policy enforcement in the browser and at the proxy, with the audit evidence defense programs need. See how it works for defense →

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 → Keep controlled data out of public AI →