A defense contractor’s AI security problem is not a bank’s, and the difference is controlled unclassified information. It shows up in the first hour of any serious training you run.
Companies in the defense industrial base are deploying what everyone else is deploying: a copilot in the tenant, retrieval over the engineering share, a proposal assistant that reads past performance write-ups. Some meaningful share of that content is covered defense information, and the clause governing it was written without any of these tools in mind.
Prompts are a CUI flow
DFARS 252.204-7012 requires contractors to safeguard covered defense information under NIST SP 800-171, and where an external cloud service touches that information the clause reaches for FedRAMP Moderate equivalency and flowdown. CMMC Level 2 assessments against those 110 controls are phasing into DoD contracts now.
Read control 3.1.3, “control the flow of CUI in accordance with approved authorizations,” against an LLM deployment and the problem becomes concrete. A prompt is a flow. So is the retrieval context a RAG pipeline pulls from a document library, the application log that records both, and every inference call leaving the boundary. A network diagram review will not find any of them, because none of them look like a file transfer.
The consequence is that the interesting failure in a defense contractor is rarely an exotic attack. It is an engineer pasting a dimensioned drawing or a statement of work into a general-purpose chatbot to get help writing something. That is a spillage event. The CUI Registry at the National Archives tells you what categories you are holding; it does not tell your staff which of the 40 AI features now shipping inside their existing software stack are safe to use with it. Only training does that.
Labs with no outbound network
This is where DIB training diverges from everything else, and it is a delivery problem before it is a curriculum problem. If the people who need the training work inside a closed facility, the course has to run there, with no reachable model API and no PyPI.
Local open-weight models solve the model half. Ollama serves a model and exposes an OpenAI-compatible endpoint, which means the standard red-team tooling works unchanged against a target that never leaves the host:
ollama pull llama3.1:8b
ollama serve # OpenAI-compatible API at http://localhost:11434/v1Point garak or PyRIT at that base URL and students run real probe suites and multi-turn attacks with nothing crossing the boundary.
The dependency half is harder and gets underestimated. On a disconnected host, pip install is not an option, so every library, model weight, and dataset has to be in the image before it arrives. That is the practical reason GTK Cyber ships courses on the Centaur VM. When we ran a three-day generative AI course for a U.S. military cyber unit, the entire thing, including adversarial labs and agent building, ran with no external calls. Twenty-five operators left with code that runs against data we were never going to see.
Model artifacts are supply chain items
One skill worth calling out separately, because DIB companies already have the muscle for it and rarely apply it here.
A checkpoint downloaded from a model hub is executable content. PyTorch’s default serialization is Python pickle, so torch.load on an untrusted .bin or .pt file can run arbitrary code at load time. Preferring safetensors, pinning revisions, and hashing weights are the same practices your software supply chain program already requires, applied to a file type nobody has classified yet. MITRE’s ATLAS framework covers this as ML supply chain compromise, alongside the prompt injection and model evasion techniques (AML.T0051, AML.T0015) that show up in testing work.
Fine-tuning on program data introduces the mirror-image problem: a model trained on CUI is arguably a CUI artifact, and there is no established practice for scoping, marking, or destroying one. Nobody has a clean answer. Teams that have at least framed the question are ahead of the ones discovering it during an assessment.
What compliance will not buy
Budgeting AI security training out of a compliance line produces the wrong course. There is no CMMC control that says test your LLM for injection, so a compliance-driven request tends to return awareness slides that satisfy an artifact requirement and build no capability.
The honest framing runs the other way. This training does not prepare you for a CMMC assessment, and anyone selling it as assessment prep is selling something else. What it does is give the people who own your boundary the ability to evaluate a class of system that is being procured faster than it is being reviewed, and to write findings a prime or a program office will accept.
If your teams are testing AI features and holding CUI, the courses that map to that work are AI Red-Teaming and the AI Cyber Bootcamp, delivered on-site where the work happens. Contracting details are on the government and federal training pages.