AI security defense contractors face a problem that most CMMC guidance still hasn’t caught up to: the frameworks were written before machine learning became a standard part of how defense work gets done. Today, AI systems touch controlled unclassified information (CUI), feed into operational decisions, and pull from third-party datasets and pre-trained models that nobody fully audited. The CMMC Level 2 assessment criteria and DFARS 252.204-7021 don’t have a dedicated "AI" section — but that doesn’t mean AI is out of scope. It means the security obligations land on existing controls, and it’s your job to map them correctly before a C3PAO assessor or prime contractor audit does it for you.
This post breaks down three layers of AI security that DIB contractors need to address: the model itself, the data pipeline, and the supply chain of third-party AI components. Then it covers how to pull those layers into a governance posture that holds up under scrutiny.
What "AI Security" Actually Means Under CMMC for Defense Contractors
CMMC Level 2 maps directly to NIST SP 800-171 Rev 2, which covers 110 security requirements across 14 domains. None of those domains say "machine learning" or "AI model." What they do say — repeatedly — is that organizations must protect CUI wherever it lives, control access to systems that process it, and maintain audit trails for anything that touches it.
When an AI system ingests, processes, or outputs CUI, it becomes a covered system. That triggers requirements across Access Control (3.1.x), Audit and Accountability (3.3.x), Configuration Management (3.4.x), Risk Assessment (3.11.x), and System and Communications Protection (3.13.x), among others. AI data protection CMMC compliance isn’t a separate checklist — it’s the application of existing CMMC controls to AI-specific attack surfaces.
The practical scope question is: which AI assets are in scope? The answer is any AI system that:
- Processes, stores, or transmits CUI at any point in its lifecycle (training, inference, or output)
- Runs on covered contractor information systems (CCIS) as defined under DFARS 252.204-7012
- Produces outputs that inform decisions about covered defense contracts
If your organization uses a commercial large language model to summarize contract documents, a computer vision system to inspect defense components, or a predictive maintenance model trained on operational data — and any of that data is CUI — those systems are in scope. For a deeper look at how these obligations fit into the broader compliance picture, see CMMC 2.0 AI Requirements for Defense Contractors: What You Need to Know in 2026.
AI Model Security: Validation, Integrity, and Adversarial Attack Controls
AI model security in the defense industrial base starts with a question most contractors haven’t formally answered: how do you know your model is doing what you think it’s doing, and that nobody has tampered with it?
Model integrity falls under CMMC’s Configuration Management and System Integrity domains. At minimum, this means:
- Maintaining cryptographic hashes or checksums for model weights and configuration files, so unauthorized modifications are detectable
- Applying version control to model artifacts with the same rigor applied to software source code
- Restricting write access to model storage to a defined set of authorized personnel
AI model validation security requirements go further. A model that produces systematically biased or manipulated outputs — even without obvious signs of tampering — represents a security risk if those outputs influence CUI-adjacent decisions. Validation controls should include:
- Documented baseline performance benchmarks established at deployment
- Periodic re-validation against those benchmarks, with deviation thresholds that trigger review
- Change management procedures that require re-validation after any model update or fine-tuning
Adversarial attack defense is the area where most DIB contractors have the widest gap. AI adversarial attack defense CMMC obligations aren’t spelled out explicitly, but they fall under the Risk Assessment domain (NIST SP 800-171 3.11.1–3.11.3), which requires organizations to periodically assess risk to operations and assets. Adversarial attacks on AI — prompt injection, data poisoning, model inversion, membership inference — are documented threat vectors that a reasonable risk assessment must address.
Practical controls include:
- Input validation and sanitization for AI systems that accept external or user-supplied inputs
- Monitoring for anomalous query patterns that could indicate model extraction attempts
- Red-team exercises specifically targeting AI system behavior, documented as part of the risk assessment record
None of this requires a dedicated AI security team. It requires that whoever owns your System Security Plan (SSP) understands that AI model artifacts are covered components, and documents controls accordingly.
AI Training Data Security: Protecting CUI and Sensitive Data in the ML Pipeline
The data pipeline is where most AI security failures in the defense context actually originate. AI training data security defense requirements aren’t exotic — they’re the application of CUI handling rules to a context that moves faster and touches more systems than traditional data workflows.
CUI in training data is the threshold issue. If your training dataset includes technical data, export-controlled information, or any data marked CUI, the entire pipeline — data ingestion, preprocessing, storage, training runs, and model outputs — must operate within your CMMC boundary. That means:
- Training data must reside on covered systems with appropriate access controls (NIST SP 800-171 3.1.1–3.1.3)
- Data labeling workflows, if outsourced or crowdsourced, must not expose CUI to personnel without need-to-know and appropriate clearance
- Inference outputs that could allow reconstruction of training data (a known risk with certain model architectures) must be treated as potentially CUI-bearing
Data lineage tracking is a control that most contractors haven’t formalized but that assessors are increasingly interested in. Lineage documentation answers: where did the training data come from, who had access to it, was it modified, and can you demonstrate that no unauthorized CUI left the boundary during the training process? This maps to Audit and Accountability (3.3.1–3.3.2) and supports the broader AI data protection CMMC compliance posture.
Access controls on ML infrastructure deserve specific attention. GPU clusters, notebook environments, and MLOps platforms often have permissive default configurations that conflict with least-privilege requirements. Common gaps include:
- Shared credentials for training infrastructure
- Jupyter notebooks with persistent access to CUI data stores
- Model registries without role-based access controls
- Logging disabled or insufficient to reconstruct who ran which training job against which dataset
Each of these is a finding under CMMC L2. Addressing them requires treating ML infrastructure as covered systems from the start, not retrofitting controls after the fact.
AI Supply Chain Security: Vetting Third-Party Models, Datasets, and AI Vendors
The AI supply chain is the fastest-growing attack surface in the defense industrial base, and the least governed. AI supply chain security defense contractors need to address comes in three forms: pre-trained foundation models, third-party datasets, and AI platform vendors.
Pre-trained foundation models — whether pulled from Hugging Face, accessed via API, or licensed from a commercial provider — carry risks that standard software supply chain controls don’t fully address. A model’s weights encode information about its training data. If that training data included adversarially injected content, the model may behave in ways that are difficult to detect through standard testing. Controls should include:
- Documented provenance for any third-party model used in a covered system
- Assessment of the model provider’s security practices, analogous to a vendor risk assessment
- Sandboxed evaluation environments before deploying third-party models to production systems that touch CUI
Third-party datasets present data poisoning risks. If a dataset used for fine-tuning or evaluation was manipulated before acquisition, the resulting model’s behavior may be compromised. Vetting should include source verification, integrity checks on dataset files, and documentation of any preprocessing applied before use.
Flowdown pressure from primes is the practical forcing function for most subcontractors. Prime contractors operating under DFARS 252.204-7021 are increasingly including AI-specific security requirements in their subcontract terms — requiring subcontractors to attest to the security of any AI systems used in contract performance. This mirrors the broader CMMC flowdown structure. Subcontractors who haven’t built AI supply chain due diligence into their vendor management processes will find themselves unable to respond to these attestation requests. For a detailed breakdown of what those flowdown obligations look like in practice, see Prime Contractor AI Flowdown Letters: What Subcontractors Must Do.
The NIST AI Risk Management Framework (AI RMF) provides a useful structure for supply chain risk, particularly its GOVERN and MAP functions, which address organizational accountability for third-party AI components. While the AI RMF isn’t a CMMC requirement, it’s increasingly referenced in DoD AI guidance and provides defensible documentation of a structured approach.
Building a Defensible AI Security Program: Governance, Documentation, and Audit Readiness
Model controls, data pipeline controls, and supply chain controls are only as strong as the governance structure that connects them. A C3PAO assessor reviewing your SSP isn’t going to find a dedicated AI section — they’re going to look at whether your existing controls documentation accounts for AI systems as covered components, and whether you can demonstrate those controls are operating.
Governance structure starts with ownership. Someone in your organization needs to be accountable for AI security — not just AI development or AI deployment, but the security posture of AI systems as covered components. In most 200–800 FTE DIB contractors, this lands on the CISO, a Director of AI Risk, or a combination of both. The CISO and CCO Guide to AI Governance Accountability in Defense covers how to structure that accountability across the organization.
Documentation requirements for AI systems under CMMC L2 include:
- SSP entries for each AI system that is a covered component, including system boundaries, data flows, and applicable controls
- Policies and procedures that address AI-specific risks (model integrity, data pipeline access, supply chain vetting) within existing security policy documents
- Risk assessment records that explicitly address AI threat vectors, including adversarial attacks and supply chain compromise
- Audit logs sufficient to reconstruct access to AI systems and training data
AI model validation security requirements should be documented in your configuration management and change control procedures, not treated as a separate AI-specific process. The goal is to show an assessor that your existing CM process covers model artifacts with the same rigor as software components.
Audit readiness for AI security means being able to answer, with documentation, the following questions:
- Which AI systems are in scope under CMMC, and why?
- What controls protect model integrity, and how are they tested?
- How is CUI protected throughout the AI training and inference pipeline?
- How are third-party AI components vetted before deployment?
- Who is accountable for AI security, and what is their documented authority?
Building an AI Governance Framework for Defense Contractors that addresses these questions isn’t a separate compliance program — it’s the extension of your existing CMMC compliance posture to cover AI-specific attack surfaces. The contractors who will struggle with CMMC L2 Phase 2 assessments are those who treated AI as outside the compliance boundary until an assessor told them otherwise.
For a full breakdown of the attestation obligations that underpin all of this, see DFARS 252.204-7021 AI Attestation Requirements Explained.
This post supports the pillar: CMMC AI Compliance for Defense Contractors
Assess Your AI Security Posture Before Your Assessor Does
CMMC Level 2 Phase 2 enforcement is rolling out under DoD’s CMMC program on a phased schedule. If your organization uses AI systems that touch CUI — and in our experience most DIB contractors do — the time to map those systems to your CMMC controls is now, not during assessment preparation.
Download the AI Security Readiness Checklist to assess your current posture across model integrity, data pipeline controls, and supply chain due diligence — structured around the CMMC L2 domains most likely to surface AI-related findings. Get the checklist →