Clarion Street

The Prompt Is Now a Data Channel: Keeping CUI Out of the Model

·12 min read

For as long as the Defense Industrial Base has handled Controlled Unclassified Information, the protection problem has been about where the data sits and how it moves. Mark it, put it in an enclave, encrypt the hop between systems. Every control in NIST SP 800-171 and every DFARS clause written around CUI assumes that shape. Then generative AI showed up, and the unit of leakage changed from the file to the prompt.

That is the part I want to make concrete, because it is where the contractor-side consequences actually live. When an engineer pastes a fragment of a spec into a chatbot, or a developer points a coding assistant at a repo, the CUI does not sit somewhere and then move somewhere else. It is transmitted in the moment it is typed, and from there it is handled by provider systems the contractor does not control. Most of the commentary skips that walk. The regulator-side stopping points are already written up on this site, so I will not re-derive them here. What I have not written is what a single prompt costs a contractor, and what the defensible patterns look like today.

Three hops between you and the model

Bochner PLLC published the cleanest version of this path in early October, and I keep coming back to it because it is organized the way an engineer thinks about a data flow rather than the way a law firm usually writes. A CUI document that reaches a frontier model moves through three layers.

The first is prompt and context ingestion. Source code, CAD files, architecture documents, proposal text. Anything you paste or upload is transmitted to the provider’s servers the moment you send it. The second is inference and cache retention. Many providers log prompts and outputs for abuse monitoring and quality control, and those logs persist after the response comes back. The third is model fine-tuning and training. This is where consumer and free tiers do the real damage, because some providers may use submitted inputs to improve their models depending on the tier and the terms. An enterprise agreement with a training opt-out and a zero-data-retention term reduces that risk considerably.

Each hop has a different owner and a different obligation, and that is the point. Most of the “is AI allowed in a CUI environment” writing treats the whole thing as one yes-or-no question, when it is really three separate questions stacked on top of each other.

Hop one: the prompt is a transmission

The paragraph that decides most of this is DFARS 252.204-7012(b)(2)(ii)(D). If the contractor intends to use an external cloud service provider to store, process, or transmit Covered Defense Information, the contractor “shall require and ensure” two things: that the provider meets FedRAMP Moderate-equivalent security, and that the provider complies with the clause’s paragraphs (c) through (g), covering cyber incident reporting, malicious software, media preservation and protection, forensic access, and damage assessment. Paragraphs (c) through (g) also impose duties on the contractor for its own systems, so the provider-compliance requirement in (b)(2)(ii)(D) is a separate obligation, not a restatement of them. The burden of that equivalency sits on the contractor, not the vendor. A provider’s marketing page that says “FedRAMP authorized” is not the same thing as your contract ensuring the specific service you actually use meets the bar, and the confusion costs people.

The sharper version of this hop is what Secureframe argues about the definition of “compromise”. DFARS 7012’s definition includes “the copying of information to unauthorized media.” Secureframe’s read is that a single paste of CUI into a commercial AI tool is already a reportable cyber incident, which means a review for evidence of compromise and a report to DoD within 72 hours through DC3/DCISE. I want to flag this for what it is. It is a vendor’s and a law firm’s interpretation of a definition, not an adjudicated holding. I could not find a court or agency decision confirming that one paste into a chatbot is a reportable incident. But the reading is out there, published to a GRC vendor’s customers, and nobody has decisively ruled it out. A contractor who assumes a paste is just a policy violation is betting against an interpretation a compliance vendor is already selling.

NIST SP 800-171 sits underneath this. Requirement 3.1.20 requires you to verify and control connections to external systems, and it explicitly includes cloud services. An AI endpoint is either a verified, controlled connection or an unauthorized flow path, and there is no third category where the chatbot is just a productivity add-on.

Hop two: retention on the provider’s side

Once the prompt lands, what the provider keeps depends on the provider and the service terms. Whether the contractor negotiated those terms is a question to check in the applicable agreement. Many providers log prompts and outputs for abuse monitoring and quality control, and how much of that the contractor can see depends on what the terms disclose. This is the hop where “the model answered me” and “the provider has my data” diverge, and most engineers never look at the difference.

One control that exists today is contractual: a zero-data-retention term and a training opt-out in an enterprise agreement. Bochner’s guidance is that ZDR reduces the risk considerably but does not eliminate it, and it is one lever among several, not the only one. A ZDR term is a promise, not a boundary. It does not move the service inside your perimeter. I will come back to why that matters.

Hop three: training

The training hop is where the IP consequence lives, and it is the one security teams most often miss because it is a data-rights problem, not a security problem. Under DFARS 252.227-7013 and 7014, the government gets unlimited rights in technical data or software a contractor has “released or disclosed without restrictions.” Uncontrolled AI processing can cost trade-secret protection, because courts ask whether the owner took reasonable measures to keep the secret. Whether a paste into a consumer model counts as that kind of disclosure is a fact-specific question, not something the paste settles by itself.

The data-rights question is separate from the incident question. Whether a paste becomes a reportable incident under DFARS 7012 depends on the facts, and the data-rights analysis can stay live even where the facts do not produce one. It turns on the terms you accepted, the funding and markings on the document, and how the information was actually used.

The first AI-specific clause lands tomorrow

GSA issued its final clause 552.239-7001 on September 28, and it takes effect October 19, 2026, which is tomorrow as I write this. It is the first standalone AI safeguarding clause in the federal acquisition system, and the reason it matters is the verbs it uses. It applies where LLM functionality is a “material feature” of the procurement and government data is “submitted directly to or produced by” the LLM, and it flows down to any subcontractor that “collects, processes, stores, retains, trains on, fine-tunes on, or otherwise handles” Government Data. It ties its obligations to NIST AI RMF Appendix A task categories and adds carve-outs that preserve contractor IP.

I want to be precise about what this is and is not. The clause governs GSA’s own LLM procurements, where the government is buying the system, not a defense contractor’s internal AI use. It is a procurement signal, not a CMMC control. What it signals is the direction. “Train on” and “fine-tune on” are now contract language. The NDAA Section 1513 framework I have written about was the statutory instruction to build an AI security regime into DFARS and CMMC. This clause is not that regime. It is a separate GSA procurement rule that independently arrives at similar safeguarding language. The GSA clause and the §1513 directive are parallel signals, not the same instrument. AI governance is becoming a contractual obligation instead of an inference, one clause at a time.

Three sandboxes, ranked by what an assessor can test

What does a defensible setup look like, given the three hops? Three patterns exist, and they differ on one measure: what an assessor can actually test. I will order them from weakest to strongest on that measure.

Zero-data-retention is the weakest, because it is a contract term, not a boundary. It reduces the retention and training hops but leaves hop one, the transmission, untouched. The prompt still leaves your boundary. And where that prompt transmits CDI to an external cloud service the contractor intends to use for that purpose, DFARS 7012’s FedRAMP Moderate-equivalent bar applies to that provider. ZDR is worth having, but a contract term is not a boundary.

Sovereign or authorized cloud is the pattern most contractors will land on. Azure OpenAI Service in Azure Government carries FedRAMP High plus DoD IL2/IL4/IL5 provisional authorizations, and Microsoft states that FedRAMP High-authorized Azure services conform to NIST SP 800-171 and can help deploy CUI workloads. The lesson in that phrasing is the boundary question: the same service name means different things depending on which authorization boundary it sits in. The commercial Azure OpenAI endpoint and the Azure Government one are not the same control surface, and an assessor will treat them differently. I will note that Microsoft’s conformance statement is the vendor’s own claim, and that IL5 requires additional configuration rather than being inherited by default. Still, this is the clearest worked example of “same service, different boundary,” and it is the pattern most teams should evaluate first.

Air-gapped self-host is the strongest, but only when it is genuinely air-gapped, and that distinction matters. Self-hosting a model on your own infrastructure is not the same thing as air-gapping it. A genuinely air-gapped or private self-hosted deployment is the case where the prompt never leaves your boundary, so hop one never happens. There is no external provider to ensure against and no vendor retention policy to negotiate. The training question does not disappear, but it moves inside your boundary, where it is your pipeline to control rather than a third party’s term to trust. It is also the most expensive and the most operationally demanding, and most contractors do not have the model supply or the staff to run it. But for CUI, an air-gapped deployment is the only pattern where the external-provider transmission problem disappears entirely rather than being mitigated by contract.

DoW Instruction 8430.01 points the same way, and I will treat it as background because I have written it up at length already. Its section 3.6 bars non-public DoW information from any generative AI service not resident on the department’s own systems, and it requires contractual guarantees against training on government data. A zero-retention contract on a vendor-hosted endpoint does not satisfy it, because the service still does not reside on the department’s systems. The instruction binds the government side, not contractors directly, but it is the clearest indicator of the residency requirement that is likely to reach contractors through DFARS. The direction is consistent: residency and a training opt-out, not a retention promise.

The playbook is evidence

Fortra’s framing is the one I would hand a program manager: treat AI as another data channel. Discover where the CUI actually lives, mark it so downstream tools can recognize it, evaluate each AI tool against data-handling and access questions, then apply soft controls like warning banners and just-in-time coaching, and hard controls like blocking CUI uploads, restricting browser and plugin access, and DLP inspection. The step that matters for CMMC is the last one: generate evidence that CUI is not entering the AI tools. The assessor’s question is not “do you have a policy.” It is “can you prove it is enforced.”

That is the contractor-side version of the story, and it is why I think the three-hop framing is the useful one. CUI protection was built as a data-at-rest and data-in-transit problem. AI turned it into a data-ingestion problem, where the transmission is a keystroke and the retention is a provider’s training pipeline. The controls are arriving one clause at a time, and tomorrow the first one takes effect.

Bottom line

A CUI document that hits a frontier model moves through three hops, and each hop carries its own obligation. When the prompt is a transmission to an external cloud provider that will store, process, or transmit CDI, DFARS 7012’s FedRAMP Moderate bar applies. The cache retention is governed by the provider’s terms, and whether the contractor negotiated them is a question to check in the applicable agreement. A zero-data-retention term is one contractual way to narrow retention, not the only one. The training pipeline is where data rights and trade-secret protection can be lost, and that question runs separately from whether any particular event is reportable. GSA’s clause 552.239-7001 takes effect October 19 and puts “train on” and “fine-tune on” into acquisition language for the first time, a procurement signal rather than a CMMC control, but the clearest one yet for where this is heading. The three defensible patterns today are zero-data-retention, sovereign or authorized cloud, and air-gapped self-host, and they rank by what an assessor can test. The first is a promise, the last is a boundary only when it is genuinely air-gapped, and most contractors will land in the middle, where the work is proving the boundary rather than writing the policy.

Sources

  1. Using AI on DoW Work: Technical Data, DFARS Data Rights, and CUI Safeguards — Bochner PLLC, October 7, 2026
  2. AI Governance for CMMC Level 2: Can You Use AI Tools in a CUI Environment? — Secureframe
  3. GSA Issues Final Rule on Large Language Model Procurements — Crowell & Moring
  4. Can Government Contractors Use AI? A Legal Guide to AI Compliance and Disclosure Requirements — Bradley
  5. Is Azure OpenAI Service in Azure Government Safe for CUI? — Cabrillo Club
  6. NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations — NIST
  7. DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting — eCFR
  8. DoW Instruction 8430.01, Accelerated Mission Software — esd.whs.mil, PDF
  9. CMMC and AI Governance: How to Keep CUI Out of AI Tools — BankInfoSecurity / Fortra