AI in CMMC Level 2: Innovation Without Control Is Risk
The first time I saw it, it was a network engineer pasting a firewall configuration into a chat window to ask why a tunnel kept dropping.
He was good at his job. He solved the problem in about four minutes, which would have taken him most of an afternoon otherwise. He was also, in those four minutes, moving a description of a CUI enclave’s boundary protections to a third party that his organization had never assessed, under terms nobody in the company had read, with no record that it happened.
Nobody was being careless. That is the part worth sitting with. This is not a story about employees behaving badly. It is a story about a control environment that was designed for a world where data left the boundary through email, file shares and USB drives, meeting a tool that does not look like any of those things.
AI adoption inside the defense industrial base is not outrunning security awareness. It is outrunning governance. Those are different failures, and only one of them is fixable with training.
The requirements did not pause
I read NIST SP 800-171 the way I was trained to read a statute: what does the text actually say, and what does it not say.
What it does not say is anything about artificial intelligence. There is no AI requirement in the 110. There is no assessment objective that mentions a model, a prompt or a large language model. People sometimes read that absence as a gap.
It is the opposite of a gap. The document is written in terms of systems, components, users, processes acting on behalf of users, and information flow. Those categories are technology-neutral on purpose. An AI tool that touches CUI is not an unregulated new thing. It is a system component, and it walked into your boundary carrying every obligation that already attaches to system components.
The practical consequence is that you do not need a new framework to start. You need to apply the one you are already being assessed against to a category of tool you did not have in scope when you wrote your SSP.
CUI does not look like CUI
Most of the exposure I see does not involve a marked document. It involves the operational exhaust that engineers work with every day and rarely think of as controlled.
Configuration files. Diagnostic output. A stack trace with hostnames and internal IP ranges. Source code written against a defense program’s requirements. A network diagram someone sketched to explain the enclave. Support tickets describing a vulnerability that has not been remediated yet. Access control details, because someone wanted help writing a policy.
Ask whether that material is CUI and you will get a shrug in most organizations. Ask whether an adversary would find it useful and the answer is immediate.
The categorization question is genuinely hard and it belongs in a scoping conversation, not a blog post. But the practical test I use with clients is simpler than the legal one: if this content describes how your CUI environment is built, protected or accessed, treat it as inside the boundary until someone can show you a defensible reason it is not.
Where this lands in the 110
When an assessor works through this, they will not have a heading called “AI.” They will find it inside requirements you already have.
Access control. 3.1.1 limits system access to authorized users and to processes acting on behalf of users. 3.1.3 controls the flow of CUI in accordance with approved authorizations. An AI assistant with an API key into your ticketing system is a process acting on behalf of a user. If nobody authorized that flow, there is nothing to point at when you are asked what the approved authorization was.
System and communications protection. 3.13.1 covers monitoring and control of communications at external boundaries. An external AI service is an external system. Whether it is inside or outside your boundary is a scoping decision with real consequences, and it needs to be documented as a decision rather than assumed.
Audit and accountability. 3.3.1 and 3.3.2 require audit records sufficient to trace actions to individual users. Most consumer AI tools give the organization nothing. No admin log, no export, no visibility into what any employee submitted. That is not a minor inconvenience. It is a structural inability to produce evidence.
Configuration management. 3.4.1 requires baseline configurations and inventories of organizational systems. If a browser extension with an AI backend is installed on an engineering workstation and it is not on your inventory, the inventory is wrong, and everything downstream of the inventory inherits that error.
Risk assessment. 3.11.1 requires periodic risk assessment. If your last one predates the tools now installed on your endpoints, it describes an environment that no longer exists.
And the one that gets forgotten: DFARS 252.204-7012 requires cloud services storing, processing or transmitting covered defense information to meet FedRAMP Moderate equivalency, plus the flow-down and reporting obligations that come with the clause. An AI vendor is a cloud service provider. The question of whether they meet that bar has an answer, and it is your job to know it before your data is in their system rather than after.
Why “we have a policy” will not survive an assessment
The reflex response to all of this is to write an acceptable use policy prohibiting AI tools, circulate it, and collect signatures.
I understand the appeal. It is fast, it is cheap, and it produces an artifact. It also fails on contact with an assessor who is trained to test implementation rather than accept assertion.
The interview question is not “do you have a policy.” It is closer to “show me how you would know if someone violated it.” If the honest answer is that you would not know, the control is not implemented. A prohibition with no enforcement mechanism and no detection capability is a statement of preference.
There is a second problem with blanket prohibition, which is that it does not work. People who are measured on delivery will use the tool that helps them deliver. A ban that everyone quietly ignores is worse than no ban, because it converts a visible, governable practice into an invisible one and leaves you attesting to something that is not true.
What actually works
Every engagement where this has gone well followed roughly the same sequence, and it did not start with a policy.
It started with finding out what is already in use. Not by sending a survey — by looking. Browser extensions on endpoints. Outbound connections to known AI service domains. SaaS products in your stack whose vendors have shipped assistant features in the last eighteen months, often enabled by default. Expense reports with individual subscriptions on them. You will find more than you expect, and the gap between what leadership believes and what is installed is usually the most useful finding of the whole exercise.
Then give people a sanctioned path. An approved enterprise tool with a contractual commitment that your data is not used for training, administrative logging you can actually export, and a boundary decision written down. The organizations that get compliance and adoption right are the ones where the compliant option is also the convenient one.
Then enforce it technically, because the assessor will ask. Restrict the unapproved services at the egress point. Manage extension installation. Make the boundary real rather than aspirational.
And then train to the specific case, not the general one. “Do not put CUI into AI tools” is useless, because the engineer pasting a firewall config does not believe he is handling CUI. Training that works uses your own data as the example, and answers the question people actually have, which is where the line sits for the work they do tomorrow morning.
Then update the SSP. The AI tools go in the system description, the boundary decision gets documented with its reasoning, and anything unresolved goes in the POA&M with a date. Documenting a known gap is a defensible position. Silence is not.
Three questions
If you want to know where you stand before an assessor tells you, start here:
- Can you produce a list of every AI-enabled tool with access to systems in your CMMC scope — including the ones your vendors turned on for you?
- For each one, can you say what happens to data submitted to it, based on the contract rather than the marketing page?
- If someone submitted CUI to one of them last Tuesday, would you know?
A no on the third question is the one to take seriously. The first two are documentation problems. The third is an evidence problem, and evidence problems are what turn into findings.
The tool is not the risk
I am not arguing that defense contractors should avoid AI. The efficiency is real, the engineers are right that it helps, and organizations that refuse it will be competing against organizations that did not.
The argument is narrower. A tool that processes your CUI is in scope. In scope means inventoried, authorized, bounded, logged and documented — the same treatment every other system component in your environment already gets.
The engineer with the firewall config was not the failure. The failure was that his organization had never told him where the line was, never given him a compliant way to do the thing he needed to do, and had no way of knowing it happened.
All three of those are governance decisions. All three can be made this quarter.
If AI tools have entered your CUI environment, the inventory is the place to start. AI governance advisory · Take the SPRS self-check · Book a scope call