Shadow AI in Defense Contractors: CUI, CMMC, and the Managed AI Boundary

An engineer copies a tolerance note from a controlled drawing into an AI assistant to rewrite it for a supplier. The browser sits on a laptop inside the contractor's CUI environment, and a red CUI cover sheet is visible under the keyboard. The model request can carry technical performance data alongside program context and part identifiers beyond the assessed boundary in one HTTPS exchange.

Shadow AI in defense contractors is therefore a scoping and evidence problem before it becomes a model problem. CUI protection requirements apply to systems that process or store the information, as well as systems that transmit it. CMMC assessments examine implementation within a defined environment. An unapproved AI route can expand that environment by involving an external cloud service. It can also create a record gap the system security plan never described.

TL;DR

• Defense-contractor shadow AI can transmit CUI, engineering data, proposal details, and program information to services outside the assessed environment.
• NIST SP 800-171r3 applies security requirements to nonfederal system components that process or store CUI, including components that transmit it.
• DFARS 252.204-7012 adds safeguarding and cloud-provider duties, plus incident reporting and evidence-preservation duties for covered defense information.
• DeepInspect controls authenticated HTTP AI traffic routed through it; consumer browser paths that avoid the proxy require separate endpoint and egress controls.

CUI enters prompts without its banner

CUI markings live on documents and drawings, as well as email headers and export packages. A user who copies three paragraphs into a prompt can leave the banner behind while transmitting the controlled substance. The same issue appears when an agent retrieves a chunk from a controlled repository and sends it to a model endpoint. The prompt payload carries the data even when its visual label disappears.

The shadow AI for government article discusses public-sector controls. Defense contractors add contract clauses and assessment scope, along with supplier flow-downs and technical information tied to weapon systems or programs. A useful decision needs the caller's identity and authorization context. It also needs the contract or program, CUI category, source application, and destination model.

I consider an AI acceptable-use memo with no route enforcement to be a document-control artifact, not a CUI safeguard. It may support training evidence. It cannot stop the outbound HTTP request described above.

NIST SP 800-171 defines the protected system

NIST SP 800-171 Revision 3, published in May 2024, provides security requirements for protecting CUI in nonfederal systems and organizations. Its abstract states that the requirements apply to components that process or store CUI, including components that transmit CUI and components that protect those systems.

That definition matters when a contractor introduces an AI service. If an internal application sends CUI to a model endpoint, the calling component and network path deserve scope analysis. The model service, records, and protective components do too. The contractor's CUI boundary diagram should show the approved route and external service relationship. A personal account or unknown endpoint creates an unreviewed branch in the data flow.

Revision 3 organizes requirements across families that include access control and audit and accountability. Other families cover configuration management, identification and authentication, incident response, system and communications protection, plus supply chain risk management. AI traffic touches several families in a single request. The architecture should preserve which control made the decision and which identity initiated it.

DFARS 252.204-7012 adds contract duties

The official text of DFARS 252.204-7012 requires adequate security on covered contractor information systems and points covered systems toward the applicable NIST SP 800-171 requirements. The clause also addresses cyber incident reporting and malicious-software submission. It covers media preservation and access needed for forensic analysis.

The external cloud provision is especially relevant to AI. When a contractor uses an external cloud service provider to process or store covered defense information in contract performance, including transmitting that information, the clause requires security equivalent to the FedRAMP Moderate baseline and specified incident-handling obligations. Contracting officers and counsel should determine how that language applies to each model service and contract.

A consumer AI subscription has no automatic place inside that approved structure. The contractor needs to know which endpoint receives the data and which agreement governs it. It must also know how incidents are reported and what evidence can be preserved under the provider's obligations.

CMMC turns policy into assessed practice

The Department of Defense's CMMC program information explains the program's role in verifying that defense contractors protect Federal Contract Information and CUI at levels appropriate to the information involved. The CMMC framework ties assessment requirements to the cybersecurity clauses and contract conditions that apply to the contractor.

The governing CMMC Program rule in 32 CFR Part 170 defines program requirements and assessment levels, along with affirmation and related processes. A contractor should use the rule and solicitation, together with the contract language, to determine the exact obligation for a procurement.

Shadow AI creates an assessment problem because the assessor evaluates implemented practices within the declared scope. If engineers send CUI through an unlisted model route, network diagrams and asset inventories can become inaccurate. Data-flow descriptions and the system security plan can become inaccurate too. A corrective answer needs more than adding the provider to a spreadsheet. The route requires access control and protection. It also requires logging, configuration, vendor analysis, and evidence.

Engineering, proposals, and supply chains differ

Each workflow carries a different mix of controlled information and business context. The approved AI route must preserve those distinctions when it evaluates a request.

Engineering and technical data

Prompts can contain drawings and specifications, as well as source code and test failures. They may also include vulnerability details or manufacturing information such as bills of material and tolerances. Classification should recognize explicit CUI markings alongside program identifiers and technical patterns. Policy should bind the result to the engineer and program, as well as the source repository and approved destination.

Proposals and capture work

Proposal teams hold government-furnished information and pricing, along with staffing, solution architecture, and teammate inputs. The material may include FCI and CUI. It may also contain company proprietary data. Policy should preserve those distinctions. Contract and proposal identifiers help reviewers reconstruct the business purpose.

Program management

Status reports can expose schedule problems and readiness, along with delivery risk, test outcomes, and customer communications. A program manager asking a model to polish an executive summary may transmit operational details outside the approved service boundary. The request route should inherit the program's data-handling profile.

Suppliers and subcontractors

A prime may provide CUI to a supplier under flow-down obligations. The supplier can then introduce its own AI route. Contract terms and onboarding should identify permitted model services. Assessment evidence should identify reporting duties. The prime's gateway cannot inspect HTTP calls that occur solely inside the supplier's environment.

Identity and program context belong on every request

An approved AI application should attach the authenticated human or agent identity and relevant authorization attributes to each model request. Useful attributes include organization and facility or tenant. They also include program, contract, role, CUI category, source system, and approved purpose. The application owns this context. The enforcement layer evaluates it.

Prompt-level classification can detect CUI markings and distribution statements. It can also detect contract identifiers, controlled technical vocabulary, source-code patterns, export-control indicators, and program-specific terms defined by the contractor. Classification results then feed deterministic policy. A permitted route may require a particular model endpoint and role. Another result may trigger redaction or denial.

The NIST 800-171 AI compliance checklist gives a broader control-mapping view. For shadow AI, the key artifact connects identity and data category to the route, policy, and outcome at the request level.

Enforcement must respect the HTTP boundary

DeepInspect operates on authenticated HTTP AI traffic routed through its proxy. It can evaluate a firm-built assistant or agent when that application sends the request through the enforcement point. The same applies to a managed model access path. A blocked outbound request stops before the model receives the payload.

A browser session using a consumer AI service may take a path outside that proxy. DeepInspect cannot see or block consumer browser use that bypasses routing. Contractors need secure web gateways and enterprise-browser controls. They also need endpoint telemetry, DNS monitoring, egress monitoring, and managed-device restrictions for that surface. The shadow AI detection guide describes how discovery layers work together.

Local models and non-HTTP transports also sit outside the proxy boundary. They require endpoint and platform controls, plus application and device controls. This distinction should appear in the system security plan. An assessor needs a real data-flow boundary, not a claim that one product covers every way an employee can invoke a model.

The evidence package starts with scope

A defense contractor should be able to show an approved AI inventory and boundary diagram. The package should also include an asset list, data-flow description, provider assessment, contract analysis, policy set, training evidence, incident procedure, and system security plan updates. Operational records prove that the approved architecture ran as described.

For each routed request, evidence should identify the person or agent and program and role. It should record the detected data class, model destination, policy version, timestamp, and decision. Permitted responses should link back to the request. Denied events should remain searchable because they demonstrate preventive control activity and may reveal recurring training or configuration gaps.

The gateway record complements application and provider logs. It never replaces the contractor's full NIST SP 800-171 or CMMC evidence set. Its value is precise: an independent record of the policy decision made at the managed AI traffic boundary.

Incident handling needs route-level facts

If covered defense information reaches an unauthorized AI service, the response team needs to establish the data sent and the user or agent involved. It must also establish the provider, account, time, contract context, and subsequent provider handling. DFARS reporting and preservation decisions belong to the contractor's incident process and legal review.

A routed request produces much of that timeline at the decision point. A bypassing browser request may leave endpoint and DNS evidence, along with secure-web-gateway and provider-account evidence. That difference reinforces the case for channeling sanctioned use through authenticated infrastructure while monitoring other egress paths.

DeepInspect

DeepInspect sits inline between authenticated contractor applications or agents and HTTP-based LLM endpoints. It evaluates identity and program context supplied by the application. It classifies routed prompts and responses, then enforces per-role and per-route policy before traffic proceeds.

Each decision produces an identity-bound audit record with detected data categories and destination. The record also contains the policy version, timestamp, and outcome. Those records support evidence for the managed AI route. Browser-only consumer sessions and local models remain outside DeepInspect's enforcement boundary. So do non-HTTP transports and supplier-internal calls that bypass the proxy.

Book a demo today.