StealthTech
Somewhere in your organization right now, someone is probably pasting a paragraph into ChatGPT to clean up a proposal, or asking Copilot to summarize a report before a meeting. Nobody flagged it as a security event, because it doesn’t feel like one. It feels like getting work done faster. That’s exactly why it’s become one of the fastest-growing compliance risks in the defense industrial base, and one of the questions we hear most often from contractors trying to figure out where AI fits inside a CMMC environment.
The short answer is that it depends entirely on what’s sitting behind the interface, not on which brand of chatbot your team happens to be using. This piece walks through what actually happens when CUI touches a commercial AI tool, why that tool becomes part of your CMMC assessment boundary the moment it does, and what a compliant path to AI adoption actually looks like.
It’s worth being direct about the stakes here, because this isn’t a hypothetical concern circulating in compliance circles. It’s happening across the defense industrial base right now, quietly and without anyone noticing, which is exactly what makes it different from most CMMC gaps. A missing patch or a misconfigured firewall rule tends to surface in a scan. A paragraph of CUI pasted into a chat window doesn’t show up anywhere until an assessor asks the right question in an interview, or until it’s too late to undo.
Why This Question Is Suddenly Everywhere
AI adoption inside the defense industrial base has moved faster than most organizations’ governance has kept up with. Engineers ask a copilot to refactor code. Program managers paste requirements into a chatbot to draft a response. Proposal writers feed a prior government contract into an AI tool to help structure a new bid. None of these people think they’re doing anything risky. It feels like a faster way to write an email, not a data handling decision.
That gap between how AI use feels and what it actually is has caught the attention of regulators. The FY2026 National Defense Authorization Act directs the Department of War to build a security framework specifically for AI and machine learning and fold it directly into DFARS and CMMC, extending the same rigor already applied to networks and endpoints to prompts, model outputs, and AI-connected data flows. This isn’t a future consideration. It’s a live regulatory direction, layered on top of requirements that already apply to how your organization handles CUI today.
What Actually Happens When CUI Goes Into a Commercial AI Tool
Consumer and standard commercial AI platforms are built for scale, not for controlled information. The terms of service for most of these tools grant the platform broad rights to retain, log, and in many cases use submitted content to improve future models. When an employee pastes a technical specification, a contract performance summary, or a paragraph referencing a deliverable schedule into a commercial chatbot, that text can be stored on infrastructure the organization doesn’t control, reviewed by people outside the organization, and potentially incorporated into training data the organization has no visibility into.
None of that shows up as an incident on a SIEM dashboard. There’s no alert, no failed login, no unusual network traffic. The data simply leaves the organization’s control the moment someone hits enter, which is precisely why this risk is so easy to underestimate and so hard to detect after the fact. An organization can have a well-configured firewall, enforced MFA, and a clean vulnerability scan, and still have CUI sitting in the logs of a commercial AI vendor because nobody thought to bring AI tools into the same governance conversation as everything else touching sensitive data.
AI Tools Are CMMC Assets Whether You’ve Documented Them or Not
CMMC scoping is built around a simple principle: any asset that processes, stores, or transmits CUI is in scope and belongs in the asset inventory, the network diagram, and the System Security Plan. An AI tool doesn’t get a pass just because it presents itself as a productivity feature rather than a system. If Microsoft 365 Copilot can reach a document library containing CUI, it’s in scope. The same applies to an enterprise ChatGPT deployment connected to a repository where CUI resides, or any assistant that can read a mailbox or SharePoint site holding CUI. What matters to an assessor is the data path, not the product name: where does a prompt go, what can the underlying model reach, and where does the output land.
That scoping obligation carries a specific regulatory floor. Under DFARS 252.204-7012, any cloud service that processes, stores, or transmits CUI must meet FedRAMP Moderate authorization, or a documented equivalent, at minimum. Commercial versions of ChatGPT, Gemini, and standard Copilot generally don’t carry that authorization. Our overview of what CUI is and why it matters for compliance covers the broader scoping principles this control extends into AI-specific tooling.
The FedRAMP Moderate Line: Why GCC High Copilot Is Different
This is the distinction that trips up the most organizations, because it sounds like a technicality and functions like a hard line. “We’re on Microsoft 365, so we’re covered” is not automatically true, and the gap between commercial Microsoft 365 and a government-community tenant matters enormously here. Microsoft Copilot running inside Azure Government, commonly deployed through a GCC High tenant, operates under data handling commitments and contractual protections that keep organizational data within a boundary aligned to federal requirements. Commercial Copilot, running in standard Microsoft 365, does not carry those same commitments, even though the interface looks nearly identical to an end user.
The practical rule that follows from this is straightforward to state and easy to violate in practice: CUI stays inside a properly scoped, FedRAMP Moderate-equivalent boundary, and general-purpose commercial AI tools, ChatGPT, Gemini, GitHub Copilot in a standard developer environment, browser-based writing assistants, stay entirely outside the CUI path. Employees need to understand this as a bright line, not a judgment call to be made prompt by prompt.
Moving to GCC High Doesn’t Auto-Certify Your AI Deployment
Standing up Copilot inside GCC High is a necessary step, not a finished one. The tenant and Copilot configuration still have to map to your specific NIST SP 800-171 and CMMC Level 2 control implementation, and a license purchase doesn’t do that automatically. Sensitivity labeling has to be applied consistently across CUI so Copilot respects those boundaries. Access has to be scoped so that not every employee with a Copilot license can query every CUI-adjacent document. Interactions need to be logged and reviewed as part of ongoing monitoring, not treated as a black box that runs alongside your actual security operations.
This is also where a common technical trap shows up: Copilot surfaces whatever a user’s existing permissions already allow it to reach. If SharePoint or Teams permissions are loosely configured, granting Copilot access doesn’t create a new vulnerability so much as it makes an existing one dramatically easier to exploit, since a poorly scoped permission that used to require manual searching now surfaces instantly through a natural-language query. Reviewing permissions and sensitivity labels before rolling out an AI assistant matters more than the AI deployment itself.
Where AI Tools Are Genuinely Safe to Use Right Now
None of this means AI has no place in a CMMC-compliant organization, and a blanket ban tends to fail anyway, since employees route around policies they see as slowing them down without understanding why. The safer path is drawing a clear, defensible line around what AI can touch. Framework-level drafting, writing generic policy language based on NIST SP 800-171 control descriptions, structuring a proposal outline, cleaning up grammar in a non-sensitive document, is a reasonable use of commercial AI tools as long as no CUI, contract-specific detail, or system configuration data goes into the prompt.
What stays out entirely: technical specifications, contract performance data, system architecture details, audit logs, SIEM output, and anything that would qualify as CUI or export-controlled information under your existing scoping. Audit logs deserve particular caution here, since they can reveal information useful to an attacker if disclosed, making them inappropriate for a general-purpose AI tool even when the underlying system they describe isn’t itself classified as CUI.
A useful test for employees, and one worth building directly into training rather than leaving as an abstract principle, is to ask whether the same information would be acceptable to say out loud in a public coffee shop. A generic question about how to structure a proposal outline passes that test. A paragraph copied directly from a Statement of Work containing technical specifications does not, regardless of how convenient it would be to get a quick AI-generated summary of it.
Writing an AI Acceptable Use Policy That Actually Holds Up
Assessors are increasingly asking about AI governance during CMMC Level 2 assessments, and a verbal instruction telling employees not to use ChatGPT isn’t evidence of anything. What holds up is a documented AI Acceptable Use Policy naming which tools are authorized, which categories of information are off-limits for AI input regardless of tool, and what the approval process looks like before a new AI tool gets adopted anywhere near a CUI-adjacent workflow. Every AI tool operating within the assessment boundary needs a place in the System Security Plan describing its role, its data flows, and its security posture, the same as any other in-scope system covered in our walkthrough of the CMMC assessment process.
Policy alone isn’t sufficient either. C3PAOs increasingly expect technical enforcement alongside the written policy, DNS filtering, data loss prevention rules, or browser-level restrictions that actually prevent CUI from reaching an unauthorized AI service, rather than relying on employees to remember and follow a rule under deadline pressure. Training closes the remaining gap: employees need explicit guidance that CUI handling rules don’t change because the destination is a chat window instead of an email, and that a text box that feels conversational is not a secure channel just because it doesn’t look like a system.
Turning AI Adoption Into an Asset Instead of a Liability
The organizations getting this right treat AI governance as part of their broader compliance architecture rather than a bolt-on policy nobody revisits after it’s written. That starts with an honest inventory of what AI tools are already in use, sanctioned or not, since most contractors are further along in shadow AI adoption than leadership realizes. From there, a properly scoped AI integration strategy brings productivity tools into the environment deliberately, inside a GCC High or equivalent boundary where CUI work actually requires it, rather than leaving adoption to individual employees making judgment calls under deadline pressure. A managed IT partner with direct CMMC experience configures that boundary correctly from the start and keeps the SSP current as AI tooling evolves, rather than treating it as a one-time setup project. A broader CMMC gap assessment should specifically include AI tool usage in its scope, since it’s one of the fastest-moving areas of exposure most contractors haven’t fully mapped yet.
Stealth Technology Group helps defense contractors adopt AI tools inside a properly scoped, CMMC-compliant boundary — not outside one.If your team is already using AI tools and you need to know where CUI risk actually sits, visit our compliance services page, or contact Stealth Technology Group today at (617) 903-5559 to talk with a specialist.
