The Cybersecurity Maturity Model Certification 2.0 framework was written before generative AI became a standard tool in defense contractor workflows. That gap is now a liability. C3PAO assessors are asking questions that the original CMMC documentation never anticipated: Which AI systems touch Controlled Unclassified Information? Who authorized the model? What did the agent do, and can you prove it?
This guide answers those questions in plain terms. It is written for Directors and VPs of AI Risk who need a defensible governance architecture, and for CCOs and CISOs who need to sign off on compliance posture before a third-party assessment or a contract award decision.
The CMMC contract-clause phase-in under the DoD CMMC final rule is not a soft target.DFARS 252.204-7021 is already in active contracts. The time to build audit-ready AI governance is now.
What CMMC 2.0 actually requires (and where AI creates new risk)
The three CMMC 2.0 levels and where most DIB contractors land
CMMC 2.0 consolidates the original five levels into three:
- Level 1 (Foundational): 17 practices aligned to FAR 52.204-21. Annual self-assessment. Covers basic safeguarding of Federal Contract Information (FCI).
- Level 2 (Advanced): 110 practices aligned to NIST SP 800-171. Triennial third-party assessment (C3PAO) for prioritized acquisitions, annual self-assessment for non-prioritized. Covers CUI.
- Level 3 (Expert): 110+ practices plus a subset from NIST SP 800-172. Government-led assessment. Covers the highest-value CUI programs.
The majority of Defense Industrial Base (DIB) contractors handling CUI — primes, subcontractors, and managed service providers — will be assessed at Level 2. That is the frame for this guide.
Why AI systems are not explicitly named — and why that doesn’t protect you
NIST SP 800-171, the technical backbone of CMMC Level 2, does not contain the words “artificial intelligence” or “large language model.” Assessors and contracting officers are nonetheless applying existing controls to AI systems because those systems process, store, and transmit CUI.
An AI agent that summarizes a contract proposal, a retrieval-augmented generation (RAG) pipeline that indexes engineering drawings, a code assistant that autocompletes software touching a defense system — each of these is an information system component under the CMMC definition. The absence of explicit AI language in the standard is not a safe harbor. It is an interpretation gap that assessors are filling in real time, and they are filling it conservatively.
The DFARS 252.204-7021 obligation every contractor must understand
DFARS 252.204-7021 is the contract clause that makes CMMC certification a condition of award and performance. It requires contractors to:
- Have a current CMMC certificate at the required level at time of award.
- Maintain that certification for the duration of the contract.
- Flow down the requirement to subcontractors handling CUI.
The flow-down provision is where AI risk concentrates. If a subcontractor uses an AI tool that processes CUI without a documented control boundary, the prime contractor’s certification is at risk. Primes are increasingly requiring subcontractors to produce AI system inventories as part of their supply chain risk management programs.
The 14 CMMC domains most affected by AI deployment
CMMC Level 2 organizes its 110 practices across 14 domains. Six of those domains create the most direct compliance exposure when AI systems are in scope.
Access Control (AC) and AI agent permissions
3.1.1 through 3.1.13 require that access to CUI be limited to authorized users, processes, and devices. An AI agent is a process. If that agent can read, write, or exfiltrate CUI — even as a side effect of a legitimate workflow — it must be authorized, scoped, and logged.
Practical implication: every AI agent that touches CUI needs a defined permission boundary. Shared API keys, broad IAM roles granted to AI services, and “run as admin” configurations are immediate findings in a C3PAO assessment.
Audit and Accountability (AU): logging AI actions, not just human actions
3.3.1 requires that organizational systems create and retain audit logs sufficient to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. 3.3.5 requires review and analysis of audit logs for indications of inappropriate or unusual activity.
AI systems generate actions at machine speed. A human analyst reviewing logs after the fact cannot reconstruct what a multi-step AI workflow did to CUI unless each step was logged at the time of execution. Logs that capture only the human prompt — not the intermediate agent actions, tool calls, and data retrievals — do not satisfy 3.3.1 for AI-assisted workflows.
Configuration Management (CM): AI models as configurable assets
3.4.1 requires that a baseline configuration of organizational systems be established and maintained. 3.4.7 requires that the attack surface be minimized.
AI models — including fine-tuned weights, system prompts, retrieval indexes, and API endpoint configurations — are configurable assets. They must appear in the System Security Plan (SSP). A model that was updated, swapped, or fine-tuned without a change control record is a configuration management finding.
Incident Response (IR): when the incident is an AI decision
3.6.1 requires that organizational incident handling capabilities be established. 3.6.2 requires that incidents be tracked, documented, and reported.
What constitutes an incident when an AI agent is involved? An autonomous action that exfiltrates CUI to an unauthorized endpoint. A model that hallucinates a contract clause and sends it to a government counterpart. A retrieval pipeline that returns documents outside the user’s authorization scope. Each of these is an incident under CMMC. Incident response procedures that were written for human actors need explicit extensions for AI-generated events.
Risk Assessment (RA): scoring AI-introduced threat vectors
3.11.1 requires that risk assessments be periodically refreshed. AI systems introduce threat vectors that were not present in the original risk assessment: prompt injection, model inversion, supply chain risk from third-party model providers, and data poisoning. A risk assessment that predates AI deployment in the environment is stale by definition.
System and Communications Protection (SC): data flows through AI pipelines
3.13.5 requires that CUI be encrypted in transit. 3.13.11 requires that cryptographic mechanisms be used to prevent unauthorized disclosure. AI inference pipelines — particularly those calling external APIs — create new data-in-transit paths that may not be covered by existing network security controls. Every API call from an AI agent to an external model provider is a potential CUI exfiltration path if the data boundary is not enforced upstream.
NDAA §1513 and the emerging federal AI accountability layer
What §1513 adds on top of CMMC
Section 1513 of the National Defense Authorization Act directs the Department of Defense to develop guidance on the responsible use of AI in defense acquisition. While the implementing regulations are still maturing, the direction is clear: contractors using AI in defense-relevant workflows will be expected to demonstrate that those systems are documented, tested, and governed.
For contractors already pursuing CMMC Level 2, §1513 is not a separate compliance program — it is an amplifier. The documentation practices required for CMMC (SSP, POA&M, audit logs) are the same artifacts that will satisfy early §1513 inquiries. The difference is that §1513 explicitly names AI, which means contracting officers now have a statutory basis to ask questions that CMMC alone did not clearly authorize.
How contracting officers are beginning to interpret AI use disclosures
In competitive acquisitions, some contracting officers are including AI use disclosure requirements in Requests for Proposals. Contractors who cannot produce a clear inventory of AI systems, their data access scope, and their governance controls are at a disadvantage — not just on compliance grounds, but on technical evaluation criteria that increasingly weight responsible AI practices.
The practical advice: treat AI system documentation as a competitive asset, not just a compliance burden.
Building an audit-ready AI governance program for CMMC Level 2
Step 1 — Inventory every AI system touching CUI
Start with a complete inventory. This means every AI tool, model, agent, API integration, and AI-assisted workflow that has any path to CUI — direct or indirect. Include:
- Commercial off-the-shelf AI tools (code assistants, document summarizers, meeting transcription services).
- Custom-built AI workflows and agents.
- AI features embedded in existing enterprise software (ERP, CRM, PLM systems with AI add-ons).
- Third-party AI services accessed via API.
For each system, document: the model or service provider, the data it can access, the actions it can take, who authorized it, and when it was last reviewed.
Step 2 — Map data flows and establish a CUI boundary for AI
Once the inventory exists, map every data flow. Where does CUI enter the AI system? Where does output go? Who can see it? Can the model provider use the data for training?
The CUI boundary for AI is not the same as the network perimeter. A contractor can have a perfectly segmented network and still have CUI flowing to an external model provider through an authorized user’s browser session. The boundary must be defined at the data level, not just the network level.
Step 3 — Implement pre-dispatch controls and spending caps
AI agents that operate autonomously — retrieving data, calling tools, generating outputs — need controls that fire before the action, not after. A pre-dispatch control reviews the proposed action against policy before execution. A spending cap limits the compute and API cost an agent can incur in a single session, which also limits the blast radius of a misconfigured or compromised agent.
These controls serve a dual purpose: they reduce the risk of unauthorized CUI access, and they produce a decision record that satisfies AU domain requirements.
Step 4 — Generate and preserve signed audit trails
Every AI action that touches CUI must produce a tamper-evident log entry. The log must capture: the agent identity, the action taken, the data accessed, the timestamp, the authorization basis, and the output produced. Logs must be retained in accordance with your SSP retention policy and must be available to assessors on request.
Signed audit trails — where each log entry carries a cryptographic signature — provide the strongest evidence of integrity. An assessor who finds that logs can be modified after the fact will treat the entire audit record as unreliable.
Step 5 — Assign accountability: the AI Risk Owner role
CMMC requires that roles and responsibilities be defined. For AI systems, this means a named individual — typically a Director or VP of AI Risk — who is accountable for the AI system inventory, the governance controls, and the audit trail. This person is the point of contact for assessors and the internal escalation path when an AI incident occurs.
Without a named owner, AI governance exists only on paper. Assessors know this and will ask who is responsible.
Common gaps that fail C3PAO assessments
Undocumented AI models in the System Security Plan
The SSP is the primary artifact a C3PAO assessor reviews. If an AI system is in use but not documented in the SSP, it is an immediate finding. The finding is not just about the AI system — it calls into question the completeness of the entire SSP and the organization’s configuration management discipline.
Shared API keys across AI agents
Shared credentials are a perennial CMMC finding. When those credentials are API keys used by AI agents, the problem compounds: a single compromised key can expose every CUI document that any agent using that key has ever accessed. Individual, scoped credentials for each AI agent or service account are the minimum acceptable control.
Missing incident response procedures for autonomous actions
Most incident response plans were written for human-initiated events. They describe how to respond when a person clicks a phishing link or a server is compromised. They do not describe how to respond when an AI agent takes an unauthorized action, how to determine the scope of CUI exposure from an AI incident, or how to preserve AI-specific forensic evidence. Assessors are beginning to ask for this explicitly.
No cost attribution for AI compute touching CUI environments
This is an emerging gap that will become more prominent as AI usage scales. If an organization cannot attribute AI compute costs to specific contracts, projects, or data environments, it cannot demonstrate that CUI-adjacent AI workloads are properly scoped and controlled. Cost attribution is also a practical signal of governance maturity: organizations that track what their AI systems spend are organizations that know what their AI systems are doing.
The CMMC phased rollout: what you must have in place
Phase 1 vs. Phase 2 requirements at a glance
Under the DoD CMMC final rule, the program rolls out in phases tied to contract award timelines rather than a single hard cutover.
Phase 1: CMMC Level 1 and Level 2 self-assessment requirements become active for new contracts. Contractors must submit self-assessment scores to the Supplier Performance Risk System (SPRS). Level 2 C3PAO assessments begin for prioritized acquisitions.
Phase 2: C3PAO assessments become required for all Level 2 contracts. Level 3 government-led assessments begin.
For most DIB contractors, Phase 1 means having a completed, current self-assessment on file in SPRS and being able to defend that score if a contracting officer or prime requests documentation. For contractors in prioritized acquisition programs, it means having a C3PAO assessment scheduled or completed.
Prioritizing remediation when time is short
If the gap between current posture and required posture is large, prioritize in this order:
- Complete the AI system inventory and add all AI systems to the SSP. An incomplete SSP is the fastest path to a failed assessment.
- Implement access controls and individual credentials for all AI agents touching CUI. This addresses AC domain findings directly.
- Deploy audit logging for all AI actions on CUI. This addresses AU domain findings and provides the evidence base for everything else.
- Update the incident response plan to cover AI-generated events. This is a lower-effort, high-visibility improvement.
- Conduct a refreshed risk assessment that includes AI threat vectors. This closes the RA domain gap and demonstrates governance maturity.
Frequently asked questions
Does CMMC 2.0 explicitly require AI governance?
No. CMMC 2.0 does not use the term “AI governance.” However, the existing 110 practices in NIST SP 800-171 apply to all information system components, and AI systems are information system components. The practical effect is that AI systems must be governed to satisfy CMMC, even though the standard does not name them.
Do we need a C3PAO assessment if we only use AI tools internally?
If those AI tools have any path to CUI — including through the data they process, the outputs they produce, or the systems they integrate with — they are in scope for your CMMC assessment regardless of whether they are internal or external tools.
What if our AI vendor says their product is CMMC-compliant?
Vendor compliance claims do not transfer to your organization. You are responsible for demonstrating that the AI system, as deployed in your environment, satisfies the applicable CMMC practices. A vendor’s FedRAMP authorization or SOC 2 report is evidence you can use, but it does not substitute for your own SSP documentation and control implementation.
How do we handle AI systems that were deployed before we started the CMMC process?
Document them in the SSP immediately and assess them against the applicable practices. If gaps exist, create a Plan of Action and Milestones (POA&M) with specific remediation dates. An undocumented AI system with no POA&M is a worse finding than a documented system with an open POA&M item.
Is there a specific CMMC practice that covers AI model supply chain risk?
the relevant NIST SP 800-171 Rev. 2 supply-chain risk practices (Assess the risk associated with the use of products or services from external providers) is the closest match. AI model providers — including foundation model vendors and API-based inference services — are external providers under this definition. A supply chain risk assessment that does not include AI model providers is incomplete.
Next steps
CMMC 2.0 compliance for AI-enabled defense contractors is not a single project with a finish line. It is an ongoing governance discipline that requires the same rigor applied to AI systems as to any other information system component in a CUI environment.
The contractors who will pass Phase 1 assessments with confidence are the ones who started building that discipline ahead of the phased rollout — with a complete AI system inventory, documented controls, signed audit trails, and a named owner accountable for the program.
If your current AI governance posture has gaps, the practical starting point is an honest inventory. Know what you have. Document it. Control it. Prove it.