Shadow AI and CUI: The Gap Nobody Approved

Somewhere in your company, someone has already pasted a chunk of a government contract into a chatbot. Not to be reckless — to get a rewrite of an awkward paragraph, or a summary of a fifty-page statement of work, or help drafting an email to a prime. They did it on their own laptop, on their own account, in a browser tab that left no trace in your asset inventory.

That is shadow AI, and it is the fastest-growing branch of shadow IT precisely because none of the old warning signs fire. Nothing was installed. Nothing was purchased. No ticket was opened. No admin password was needed. The employee who did it would be baffled to learn they had done anything at all, and in most small defense shops they are right that nobody ever told them otherwise.

Here is the part that matters for your compliance posture: NIST SP 800-171 never uses the word "artificial intelligence," and it already covers this.

Shadow IT without the install

The controls that catch traditional shadow IT are the ones that watch software. 3.4.8 (deny-by-exception application execution) and 3.4.9 (control and monitor user-installed software) are how you stop someone dropping an unvetted tool onto a company machine. Between them they are worth six SPRS points, and most shops that have done any hardening have them at least partly in place.

Neither one sees a website. Application allowlisting is a control on executables; a chatbot is a URL. An employee with a fully locked-down laptop, no local admin rights, and EDR watching every process can still open a tab and hand over a contract, and every one of those controls will report green while it happens.

So the software controls aren't where this lands. It lands on the data-movement controls — and those are the ones small shops most often score as "met" on the strength of an intention rather than a mechanism.

The controls that actually apply

Notice the weights. The three controls that most directly describe shadow AI — 3.1.3, 3.1.20, 3.1.22 — are one-pointers, and the standard advice, including ours, is to remediate by weight. Chase the fives first and this cluster sits untouched at the bottom of the list for a year.

That advice is still right for your score. It is wrong for your risk. Three points is a rounding error in SPRS; a statement of work sitting in a consumer account is a disclosure that cannot be recalled. This is one of the few places where the arithmetic and the actual exposure point in different directions, and it's worth knowing that about the list you're working from.

Find out what's actually in use

You cannot write a sensible rule about a thing you haven't measured. Before drafting any policy, spend an hour on this — all five of these are checks a small shop can run without buying anything:

1. Read your OAuth grants. This is the highest-yield check by a wide margin. Every time someone clicks "Sign in with Microsoft" or "Sign in with Google" on an AI product, they may be granting that product standing access to mail, files, or calendar. In Microsoft 365 those live under Entra ID → Enterprise applications; in Google Workspace, under Security → Access and data control → API controls. You will likely find applications you have never heard of, some of them with read access to a lot.
2. Look at the AI features inside tools you already approved. This is the category people miss. The meeting notetaker that auto-joins every call, the "summarize this thread" button that appeared in your email client, the PDF reader that grew a chat panel, the code assistant in your developer's IDE. Nobody went shopping for shadow AI here — a vendor shipped an update. A notetaker sitting in a call where CUI is discussed is the same exposure as a paste, minus the human decision.
3. Check browser extensions. An extension with permission to read page contents, connected to an AI service, sees whatever your people see.
4. Skim expense reports and card statements for AI subscriptions being expensed individually. A $20/month line item is a person who found the tool useful enough to pay for it, which tells you what job they were trying to do.
5. Ask, without a trap. Say plainly that you are inventorying tools and that nobody is in trouble. You will get a far better list this way than from any log, and the people who answer become the ones who tell you next time something new shows up. Open with an accusation and the practice simply moves to personal phones, where you will never see it again.

The ban that doesn't hold

The instinct is to prohibit all of it. It's a defensible instinct and it is what most first-draft policies do, but be clear-eyed about the trade: a flat ban on a tool that demonstrably saves people time relocates the behavior rather than ending it. It moves to the personal phone, the home laptop, the account you can't see. You trade a visible risk you could have scoped for an invisible one you cannot.

The alternative that holds up is narrower and harder to argue with: name a sanctioned tool, and draw a bright line around CUI. People need somewhere legitimate to go. Give them one, and the rule about what may never be pasted becomes a rule they can actually follow — because you haven't also asked them to give up something useful.

The bright line itself has to be concrete, because "don't share sensitive data" means nothing to someone who isn't sure what CUI looks like. If your team can't reliably answer whether you handle CUI at all, that question comes before the AI policy — it's the same confusion, showing up in a new place.

What the policy has to say

Assessors have started asking about this. It isn't a named requirement, so there's no checkbox for it — what they're testing is whether your data-flow controls survive contact with a tool the standard's authors didn't anticipate. A short document that answers these seven questions does that:

1. Which tools are sanctioned, by name and by account type. "ChatGPT" is not an answer; a business-tier account under company control is a different system from the same product on a personal login, with a different agreement behind it.
2. What may never go in — CUI, ITAR/export-controlled technical data, anything marked, and any contract document you have not read closely enough to be sure about. Give examples from your own work, not generic ones.
3. What is fine — and say this part out loud. Public marketing copy, generic code, general questions with no company specifics. A policy that only prohibits reads as a policy against the tool, and gets ignored wholesale.
4. Whether the vendor trains on your inputs, and where that's written down. Consumer tiers and business tiers often differ on exactly this point, which is the main reason account type belongs in the rule.
5. Who approves a new tool, and how long that takes. If the answer is "ask me, I'll get back to you this week," people will ask. If there's no path, they'll skip it.
6. What to do after a mistake — a named person, no punishment for prompt self-reporting. This clause is what converts a silent incident into a handled one.
7. Who owns the review and when. Once a year, against a tool landscape that changes monthly, means the document is decorative.

Then do the part most shops skip: put the same content in your security awareness training so 3.2.1 is genuinely satisfied, and add one line to your SSP saying where AI tools sit relative to your boundary. A policy nobody was trained on is a document, not a control.

If it already happened

Assume for a moment that the inventory turns up something real: a proposal, a drawing, a marked document, pasted into a consumer account six weeks ago. What follows is uncomfortable but survivable, and it goes much better when the sequence is decided in advance rather than in the moment.

Contain what can still be contained — delete the conversation, turn off chat history or training-on-inputs in that account's settings, revoke any OAuth grant tied to it. Then write down what went where, when, and who was involved, while the details are fresh. Understand that deletion is not recall: you are reducing further exposure, not undoing the disclosure.

Then close the loop the way an assessor would want to see: the incident recorded in your POA&M if it exposed a control gap, the policy written, the training updated, the tool sanctioned or blocked. An incident that produced a documented change is evidence of a working program. The same incident with nothing written down is the one that's hard to explain later.

Why this is on the list now

With Phase 2 suspended, your self-assessment is the enforcement mechanism, and the affirmation carries your signature. The controls above have been in Rev 2 since 2020 — none of this is a new obligation. What changed is that a tool arrived which moves company data off your systems through a browser tab, with no install, no procurement, and no signal, and it arrived faster than most small shops updated anything.

The fix is not expensive. It's an hour of inventory, a page of policy, a slide in training, and a line in the SSP. What makes it urgent is that every week without it is another week of a data flow you have no record of — and the whole premise of a self-assessment is that you know how your data moves.