CMMC and AI Tools Handling CUI: When Prompts, Outputs, and Logs Enter Scope
The scoping question defense-industrial teams actually have about AI tools is the one most guides never answer cleanly: when do prompts, outputs, embeddings, and logs become controlled unclassified information? The short answer, as of 2026-08-28: a prompt that contains CUI is CUI the moment it is composed; model output derived from CUI is CUI when it carries it; embeddings and vector indexes built from CUI should be treated as inside the CUI boundary absent a documented determination; and any log plane that captures prompt or output content becomes a CUI store. The consequence is not paperwork but scope: the AI tool, its storage, and its logging plane become CUI Assets in the CMMC Assessment Scope under 32 CFR 170.19, assessed against all Level 2 security requirements. This page walks each leg, maps the rule's asset categories to an AI deployment, explains the cloud condition of DFARS 252.204-7012, and ends in a ten-step scoping worksheet.
This page is general information about published regulations, not legal advice. Decisions about a specific contract, information flow, or assessment belong with your organization's own counsel, contracts team, and the officials who own your CMMC program.
One honest paragraph before any scoping table: no vendor and no product — PrivateStack included — can make an organization seeking assessment achieve a CMMC Status. The scope, the System Security Plan, the assessment, and the affirmation attach to your organization and are produced by your own program. A vendor can change the facts that program runs on and hand you evidence; it cannot run the program for you.
What makes information CUI in the first place
CUI is defined by what the information is, not where it sits. Under the Government-wide program at 32 CFR 2002.4, controlled unclassified information is information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls — with the CUI Registry cataloging the categories. The definition carries its own carve-out: it excludes information a non-executive-branch entity possesses in its own systems that did not come from, and was not created or possessed by or for, an executive branch agency — which is why this page's treat-as-CUI position is a conservative default, because applying that carve-out to a given piece of derived data is a documented determination for the contractor's own program, not a vendor's call. That program binds executive-branch agencies directly; it reaches contractors through contract clauses, chiefly DFARS 252.204-7012, which defines covered defense information against the same Registry and requires NIST SP 800-171 protection on the contractor systems that hold it.
Two properties of that definition drive everything on this page. First, the status travels with the information: no application, format, or storage location changes what the information is. Second, the designation is not yours to remove: a transformation performed inside an AI tool — summarizing, rephrasing, vectorizing — is not a release decision by the designating authority. Together they mean the question “is this AI tool in scope?” is really the question “can CUI reach it, and what does it do with what it receives?”
The four legs: when AI working data becomes CUI
An AI workspace turns one piece of information into four kinds of data — the prompt, the output, the derived representations, and the exhaust. Each leg has its own moment of becoming CUI and its own scoping consequence, and the legs competing guides skip — embeddings and logs — are exactly the ones where CUI persists after everyone believes the conversation was deleted.
| Leg | When it becomes CUI | Scoping consequence |
|---|---|---|
| Prompts and uploads — the input leg | Immediately, by content. CUI is defined by what the information is — information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to safeguard (32 CFR 2002.4) — not by which system it sits in. Pasting a controlled drawing extract into a chat box does not re-designate it; the prompt now contains CUI, and so does every request body, upload store, and preview cache it touches. | Every component that processes, stores, or transmits that input meets the rule's description of a CUI Asset (32 CFR 170.19, table 3), which the OSA must document in the asset inventory, the System Security Plan, and the network diagram, and which is assessed against all Level 2 security requirements. |
| Model outputs — the derivation leg | When the output contains it. A summary of a controlled specification, an answer that reproduces controlled parameters, or a generated document built from CUI input carries the CUI forward — derivation is not decontrol, and under 32 CFR 2002.18 decontrol is the designating agency's decision, not a byproduct of transformation. Treat output derived from CUI as CUI unless the information it contains is genuinely no longer controlled, and treat that call as a documented decision, not a default. | Output storage — chat history, generated files, shared conversation links — becomes a CUI store on the same terms as the input path, and inherits the same asset-category treatment and safeguarding expectations. |
| Embeddings and vector indexes — the transformation leg | Treat vectors and indexes derived from CUI as inside the CUI boundary absent a documented determination that says otherwise — a statement of position, and the same discipline this site applies to protected health information. An embedding is a transformation built to preserve the meaning of its source text; nothing in 32 CFR 2002 or 32 CFR 170 recognizes a format change as an exit from safeguarding, and a vendor that treats vectors as out of scope without documentation is making that determination for you. | A vector store built from CUI-bearing documents or conversations is an asset that stores CUI-derived data: put it in the asset inventory as a CUI Asset, extend delete-with-source behavior to it, and expect the assessor to ask where it lives and who can reach it. |
| Logs — the exhaust leg | When any log plane captures content. A full-content audit log captures CUI by design the moment a prompt contains it; application and debug logs that echo request bodies capture it by accident; error-reporting and analytics tooling capture it by integration. Separately, logs generated by or ingested by security tooling are Security Protection Data under 32 CFR 170.4 even when they hold no CUI at all. | A content-capturing log store is a CUI Asset in its own right — its access controls, encryption, and retention become assessable facts. Log and security tooling that holds only Security Protection Data still enters scope as a Security Protection Asset, assessed against the Level 2 requirements relevant to the capability it provides. |
The embeddings position deserves one more sentence, because it is a position: treat vectors derived from CUI as inside the boundary until a documented determination says otherwise. It parallels the derived-data discipline our AI vendor checklist for regulated health-data teams applies to protected health information: a representation built to preserve meaning has not stopped carrying the information it was built from, and a vendor with no written answer to the embeddings question is answering it anyway. The logging leg has its own companions: the 21-field audit log schema template makes the content plane a declared field instead of an accident, and the prompt log retention crosswalk maps how long each log plane keeps what it captures.
Where each asset lands: the 32 CFR 170.19 categories
CMMC Level 2 scoping runs on five asset categories, defined in table 3 to 32 CFR 170.19(c)(1). The table below keeps the rule's own descriptions and adds the column that matters here: what each category looks like once an AI tool is in the environment.
| Category | The rule's description | In an AI deployment | Treatment |
|---|---|---|---|
| CUI Assets | Assets that process, store, or transmit CUI. | The chat application and model-serving path once CUI enters a prompt; conversation and file stores; a vector index built from CUI; any log plane that captures prompt or output content. | Document in the asset inventory, the System Security Plan, and the network diagram of the CMMC Assessment Scope; assessed against all Level 2 security requirements. |
| Security Protection Assets | Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope. | The identity provider in front of the workspace, the logging and monitoring pipeline, gateways and firewalls on the request path — in scope even when they never see CUI, because they hold Security Protection Data. | Document the same way; assessed against the Level 2 security requirements relevant to the capabilities provided. |
| Contractor Risk Managed Assets | Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place. | A workspace tenant policy-fenced away from CUI programs — defensible only if the policy, procedures, and practices that keep CUI out are real, written, and reviewable. | Document in the inventory and System Security Plan; not assessed against other requirements if sufficiently documented, but the assessor can conduct a limited check if the documentation raises questions. |
| Specialized Assets | Assets that can process, store, or transmit CUI but are unable to be fully secured: IoT and IIoT devices, Operational Technology, Government Furnished Equipment, Restricted Information Systems, and Test Equipment. | Shop-floor OT or test rigs feeding data toward an AI workflow. A commercial AI workspace is not a Specialized Asset — the category does not exist to absorb ordinary SaaS. | Document in the inventory and System Security Plan and show the assets are managed under the contractor's risk-based security policies; the assessor reviews the SSP and does not assess them against other requirements. |
| Out-of-Scope Assets | Assets that cannot process, store, or transmit CUI and do not provide security protections for CUI Assets, physically or logically separated from CUI assets. | An AI tool genuinely fenced from CUI — no user with CUI access, no connected source that holds it, separation you can justify. The rule's own bar: prepare to justify the inability, not the intention. | No assessment requirements — but an asset that fits any in-scope category cannot be called out of scope, and 'staff are told not to paste CUI' is an intention, not an inability. |
The cloud condition: DFARS 252.204-7012 and the authorization question
When the AI vendor is a cloud service — which a hosted AI workspace is — the scoping tables hand off to a contract clause. 32 CFR 170.19(c)(2) routes any cloud service provider that processes, stores, or transmits CUI to the cloud requirements of 48 CFR 252.204-7012, and that clause's paragraph (b)(2)(ii)(D) states the condition: a contractor that intends to use an external cloud service provider to store, process, or transmit covered defense information must require and ensure that the cloud service provider meets security requirements equivalent to the Government's Moderate baseline for its cloud-authorization program, and complies with the clause's paragraphs on cyber incident reporting, malicious software, media preservation and protection, access to information for forensic analysis, and cyber incident damage assessment. An external service that holds only Security Protection Data — log streams, configuration state — enters the assessment as a Security Protection Asset instead.
State it plainly, because AI procurement gets this wrong constantly: an ordinary commercial AWS deployment — a BYOC deployment of PrivateStack included — carries no CMMC status of any kind by virtue of where it runs, and no FedRAMP authorization of any kind. Amazon Web Services' own service offerings carry their own authorizations for Amazon's services; a vendor's application deployed on those services is a different service, operated by a different party, and it inherits none of them. Whether a specific offering satisfies the DFARS 252.204-7012 cloud condition is a determination your contracts team makes against evidence — never a property of the hosting arrangement, and never a vendor's adjective.
The scoping worksheet
Ten decision prompts, in the order an organization seeking assessment (OSA) should work them — because every one of these questions gets answered eventually, and the only choice is whether you answer them in your System Security Plan or an assessor answers them for you.
01List the contracts and programs that put CUI in your environment
Scoping starts with the information, not the tool. Identify which contracts carry safeguarding clauses, which programs generate or receive CUI, and which teams touch it. If no contract or program puts CUI in your environment, stop here and document that conclusion — it is the out-of-scope justification the rule expects you to be able to produce.
02Decide, per team, whether the AI tool can receive CUI
Not 'is anyone supposed to paste it' but 'can anyone who holds it reach the input box.' If people who work with CUI can use the tool, the honest starting assumption is that CUI can enter it — policy alone moves an asset to Contractor Risk Managed at best, and only when the policy, procedures, and practices are documented and real.
03Trace the input path end to end
Request bodies, uploaded files, preview and text-extraction services, connected data sources. Name every store the input leg touches and who operates each one — you, the AI vendor, or a subprocessor behind the vendor.
04Decide how output is handled and where it lands
Chat history, exports, generated documents, shared links. If output derived from CUI is CUI, each of those landing zones is a CUI store — write down which ones exist and which are disabled.
05Ask the embeddings question in writing
Are vectors and indexes derived from customer content treated as remaining inside the customer's data boundary — same safeguards, deleted when the source is deleted? Get the vendor's position in writing, and treat 'embeddings are anonymized' without documentation as a determination someone made on your behalf without documenting it.
06Inventory every log plane: content or metadata
Audit logs, application logs, debug logs, error reporting, analytics. For each plane: does it capture prompt or output content, or only metadata? A content-capturing plane that can see CUI is a CUI store with its own retention clock and access list.
07Identify the Security Protection Data and its holders
Configuration data, log files generated by or ingested by security tooling, vulnerability data, and passwords for the in-scope environment are Security Protection Data under 32 CFR 170.4. Whoever processes, stores, or transmits it — including a log-management or monitoring service — enters scope as a Security Protection Asset.
08Place every asset in a 32 CFR 170.19 category
CUI Asset, Security Protection Asset, Contractor Risk Managed, Specialized, or Out-of-Scope — using the rule's descriptions, not your preferences. Update the asset inventory, the System Security Plan, and the network diagram to match; those three documents are what the assessor reads first.
09Apply the external-service test to the AI vendor
If the vendor processes, stores, or transmits CUI or Security Protection Data on its assets, it is an External Service Provider under 32 CFR 170.19(c)(2). If it is a cloud service provider handling CUI, the contractor must ensure the cloud service meets the security-requirement condition of DFARS 252.204-7012(b)(2)(ii)(D) — ask which specific service offering satisfies it, in writing, and get the service description and customer responsibility matrix the rule expects your SSP to reference.
10Match the assessment path to the contract, then affirm
The required CMMC level and assessment type come from the contract under 32 CFR 170 and DFARS 252.204-7021. Level 1 is self-assessed; Level 2 is the same 110 requirements either way — the contract decides whether it is self-assessed (32 CFR 170.16) or assessed by a C3PAO (170.17); Level 3 adds an assessment by DCMA DIBCAC. Results go to SPRS, and a senior official affirms continuing compliance. None of that moves to a vendor.
This worksheet scopes the deployment; it does not evaluate the vendor. For that, the AI vendor security questionnaire carries 21 scored questions across data flow, retention, logging, isolation, training use, incident response, and access control — run it alongside this worksheet, and put the embeddings and log-plane answers in writing.
How PrivateStack fits this scoping
PrivateStack's public-sector posture is built for the questions this worksheet asks, and the scoping comes first: CUI belongs behind a written agreement and a configuration review, which for CUI workloads means an Enterprise BYOC conversation — contact us first, the same rule our acceptable-use policy applies to any specially regulated data. Stated plainly: the hosted, shared tier is not offered for CUI workloads — CUI belongs on an Enterprise BYOC deployment, under a written agreement and a configuration review. Enterprise BYOC runs the data plane inside the customer's own AWS account and perimeter, under the access controls your security team already enforces — so the stores this page turns into scoping questions, from conversation history to log planes, live on infrastructure you inventory and control. 100% of requests are logged and exportable: who asked what, when, against which model — the attribution evidence an assessor asks for. The platform is built by a US-owned company based in Atlanta, GA, and on the hosted tier, inference is processed by a disclosed US-based subprocessor under contractual zero-retention terms: prompts are never stored and never used for training — disclosed precisely because an external inference path is exactly what the cloud condition above exists to make you examine.
And the limits, stated plainly: none of this defines your CMMC Assessment Scope, writes your System Security Plan, or stands in for your assessment and affirmation — no product can, and we will not tell you otherwise. Bring your security team and we'll walk the data-flow diagram together, asset by asset. The government solution page covers the deployment in detail, and the security page carries the full control set.
Questions people actually ask
- Does pasting CUI into an AI chat make the prompt CUI?
- Yes. CUI status follows the information itself: 32 CFR 2002.4 defines it by what the information is and which law, regulation, or Government-wide policy requires safeguarding — not by the system it sits in or the format it takes. A prompt that contains CUI is CUI, and every request body, cache, and store on the input path now holds it. The practical consequence is scoping: components that process, store, or transmit that prompt meet the description of CUI Assets in 32 CFR 170.19 and are assessed against all Level 2 security requirements.
- Are AI model outputs controlled unclassified information?
- When they contain it, yes. An output that reproduces, summarizes, or is substantively built from CUI carries the controlled information forward — generation is a transformation, not a release decision, and only the designating authority's framework decides when information stops being controlled. The honest operating rule: treat output derived from CUI as CUI unless a documented review says the specific output no longer contains controlled information, and store it accordingly.
- Are embeddings built from CUI inside the CMMC boundary?
- Treat them as inside the boundary absent a documented determination otherwise — that is a statement of position, and it parallels the discipline this site applies to protected health information. An embedding preserves the meaning of its source; no provision of 32 CFR 2002 or 32 CFR 170 treats a format change as an exit from safeguarding; and the vendor question is concrete: are vectors derived from our content kept within the same boundary, covered by the same safeguards, and deleted when the source is deleted? A vendor with no written answer is answering anyway.
- Does running an AI tool on AWS satisfy the cloud condition of DFARS 252.204-7012?
- No — not by itself, and this is the most common scoping mistake in AI procurement. The clause's condition attaches to the cloud service that actually stores, processes, or transmits the covered defense information. Amazon Web Services' own service offerings carry authorizations under the Government's cloud-authorization program for those offerings; a vendor's application built on them is a different service, operated by a different party, and it carries no FedRAMP authorization by inheritance — there is no such thing as authorization by hosting arrangement. What the contractor must do is require and ensure that the cloud service provider handling the CUI meets security requirements equivalent to the program's Moderate baseline and complies with the clause's incident-reporting obligations; which offering satisfies that, and on what evidence, is a written question for the vendor and a judgment for your contracts team.
- Which CMMC level applies, and who performs the assessment?
- The contract tells you, not the vendor. Under 32 CFR 170 the levels are: Level 1, an annual self-assessment against the 15 basic safeguarding requirements of 48 CFR 52.204-21 for Federal Contract Information; Level 2, the 110 security requirements of NIST SP 800-171 revision 2, met either by self-assessment or by an assessment performed by a C3PAO every three years as the contract requires; and Level 3, selected NIST SP 800-172 requirements assessed by DCMA DIBCAC after a Level 2 assessment by a C3PAO. The acquisition side, DFARS 252.204-7021 (90 FR 43560, effective November 10, 2025), phases into solicitations over three years, after which it applies to contracts involving FCI or CUI on contractor systems, except contracts solely for COTS items. Results are posted in SPRS and a senior official affirms continuing compliance annually.
Two companion reads finish the picture: the zero data retention vs no training guide maps the eight planes a single request can leave content on — the same planes this page asks you to categorize — and the closed-API comparison covers where each deployment model leaves these controls, including where the closed API wins. And once the scoping is done, the defense-contractor template in the AI acceptable-use policy templates turns this page's positions into ten adoptable clauses your workforce can be trained on.
Primary sources
Every regulatory statement above traces to one of these publications. Read the instrument before any vendor's interpretation — including ours.
- 32 CFR Part 170 — the CMMC Program rule — The program rule (89 FR 83092, effective December 16, 2024): the CMMC Model in 170.14, which pins Level 2 to NIST SP 800-171 revision 2 and Level 3 to selected NIST SP 800-172 requirements; the assessment and affirmation requirements for each level in 170.15 through 170.18; and the definitions in 170.4, including Security Protection Data and External Service Provider.
- 32 CFR 170.19 — CMMC scoping — The scoping section this page maps to: table 3's Level 2 asset categories — CUI Assets ('assets that process, store, or transmit CUI'), Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets — and the external-service-provider table at (c)(2), which routes a cloud service handling CUI to the cloud-service condition of 48 CFR 252.204-7012.
- 32 CFR 2002.4 — what CUI is — The Government-wide CUI program's definition: information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls — with the CUI Registry as the catalog of categories. The program binds agencies directly; it reaches contractors through contract clauses.
- 32 CFR 2002.18 — decontrolling CUI — The provision that answers the derivation question: CUI stays controlled until it is decontrolled by the designating agency's decision or a condition that agency established, and authorized holders may decontrol only as the designating agency permits. A transformation inside an AI tool — summarizing, rephrasing, vectorizing — is neither, which is why derived output and representations carry the control forward.
- DFARS 252.204-7012 — Safeguarding Covered Defense Information — The safeguarding clause (May 2024 edition): covered defense information defined against the CUI Registry, NIST SP 800-171 required for covered contractor information systems at (b)(2)(i), and the external-cloud condition at (b)(2)(ii)(D) — the contractor must require and ensure that a cloud service provider storing, processing, or transmitting covered defense information meets security requirements equivalent to the Government's Moderate-baseline cloud program requirements and complies with the clause's paragraphs on cyber incident reporting, malicious software, media preservation and protection, access to information for forensic analysis, and cyber incident damage assessment.
- DFARS 252.204-7021 — Contractor Compliance With CMMC Level Requirements — The acquisition clause (November 2025 edition): maintain a current CMMC status at the contract's level for the duration of the contract, affirm continuous compliance annually in SPRS, and flow the substance of the clause down to subcontractors.
- 90 FR 43560 — the final DFARS CMMC acquisition rule — The final rule (published September 10, 2025, effective November 10, 2025) that put CMMC into contracts: a phased, three-year implementation during which program offices determine inclusion, after which the requirements apply to contracts where the contractor will process, store, or transmit FCI or CUI on contractor information systems, except contracts solely for COTS items.
- NIST SP 800-171 Revision 2 — Protecting CUI in Nonfederal Systems — The 110 security requirements CMMC Level 2 assesses against. NIST published revision 3 in May 2024, but 32 CFR 170 incorporates revision 2 by reference (170.2, 170.14) — the assessment baseline is what the rule pins, not what NIST most recently shipped.