No external cloud service provider — a different test applies
DFARS 252.204-7012(b)(2)(ii)(D) binds only where the contractor intends to use an external cloud service provider. Run the model on systems you own or operate and there is none, so the operative requirement is paragraph (b)(2)(i): NIST SP 800-171 applied to that system, like any other system in your boundary.
Is Self-hosted open-weight model in your own CUI enclave safe for CUI?
by Your organization
As of July 27, 2026. FedRAMP authorizations, DoD Impact Level approvals and vendor data-handling terms change. Every finding below links to the primary source it came from — open it and confirm the current status before you make a boundary decision.
What this verdict rests on
The 2 sources the finding above is drawn from, quoted so you can check the reading rather than take our word for it.
Primary source
“If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline ... and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
FedRAMP
Not the applicable test
DoD Impact Level
Not the applicable test
Deployment pattern
In-boundary / self-hosted inference
Overview
Running an open-weight model on hardware inside your own CUI enclave is the pattern that removes the external cloud service provider from the question entirely. It is not a lighter compliance path — it moves the whole control burden onto you — but it is the one where the boundary is unambiguously yours to define, evidence and defend.
Where does the data physically go?
The first question in any CUI boundary decision is not whether a product is secure — it is which system boundary the data lands in, and whose authorization covers that boundary.
Data location
Prompts and outputs stay on the systems you operate. That places the deployment squarely inside the definition the clause uses: an unclassified information system owned, or operated by or for, a contractor that processes, stores or transmits covered defense information is a covered contractor information system, and carries the full requirement set.
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
Model training and retention
With no external service in the path there is no vendor to train on your data — but there is also no vendor absorbing any of the control burden. Everything the FedRAMP-authorized providers above were doing for you is now yours to implement and evidence.
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
What authorization exists?
A platform-level authorization does not automatically extend to every service running on it. What matters is whether this specific AI service is named in the authorization scope.
FedRAMP authorization
FedRAMP equivalency is not the test for this pattern, and that is a textual point rather than an opinion: the clause's cloud paragraph opens "If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information...". No external cloud service provider, no FedRAMP-equivalency obligation under that subparagraph. It is replaced, not removed — by the full NIST SP 800-171 obligation on your own system.
Primary source
“If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline ... and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
DoD Impact Level
DoD Impact Levels are a cloud-authorization construct under the DoD Cloud Computing SRG; they do not attach to a contractor-operated internal system. What attaches instead is the security requirement set the clause imports for covered contractor information systems.
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
Vendor's own position on CUI
There is no vendor position to rely on, and that cuts both ways. Nobody else is asserting a boundary for you, and nobody else is responsible for it. Your SSP, your assessment, your evidence.
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
What DFARS 252.204-7012 and NIST 800-171 require of this pattern
Quoted from the regulation itself, not paraphrased.
DFARS 252.204-7012(b)(2)(i) — NIST SP 800-171 on your own systems
Any unclassified system owned or operated by or for the contractor that processes, stores or transmits covered defense information is a "covered contractor information system" and carries the full NIST SP 800-171 requirement set. An AI assistant does not sit outside this because it is new: if CUI reaches it, the system it runs on is in scope, and the revision that applies is the one in effect when the solicitation issued.
Primary source
“Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 ... in effect at the time the solicitation is issued or as authorized by the Contracting Officer.”
Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
NIST SP 800-171 — the control set itself
The security requirements DFARS 7012 imports. Rev. 3 (May 2024) is the current final publication; which revision binds a given contract is set by the solicitation, so check the clause in your award rather than assuming. For an AI deployment the load-bearing families are access control, audit and accountability, and system and communications protection — an assistant that reaches CUI must be inside the same access, logging and boundary-protection regime as any other system that touches it.
Primary source
“This publication provides federal agencies with recommended security requirements for protecting the confidentiality of CUI when the information is resident in nonfederal systems and organizations.”
NIST Computer Security Resource Center — NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations · read 2026-07-27
NIST 800-171 controls this decision turns on
These are the controls an assessor works through when CUI reaches an AI service. They are the controls at stake, not a finding against the vendor.
The compliant pattern
Treat the inference host as a CUI system from day one, because that is what it is. It goes on the boundary diagram and in the SSP; it inherits your access control, audit logging, configuration management and boundary protection; FIPS-validated cryptography protects CUI in transit and at rest; and prompt and response logs are themselves CUI and need the same retention, access and disposal handling as any other CUI artefact — this is the step teams most often miss. Then close the two doors that quietly reopen the cloud path: the model weights must be obtained and verified through a controlled supply chain, and any outbound telemetry, evaluation callback or hosted-embedding call has to be blocked, or you have silently reintroduced an external cloud service provider.
Patterns with an authorized path for CUI
Sources for this page
Every finding above rests on one of these. Nothing on this page is asserted without one.
- Acquisition.gov (DFARS, MAY 2024 revision) — DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting · read 2026-07-27
Frequently Asked Questions
Do I need FedRAMP authorization to run an AI model on my own servers?
The FedRAMP-equivalency requirement in DFARS 252.204-7012 is written to activate where the contractor intends to use an external cloud service provider. With inference on systems you own or operate there is no such provider in the path. The system is still a covered contractor information system and still carries the NIST SP 800-171 requirements — the obligation changes shape rather than disappearing. Have counsel confirm the reading against your specific contract clauses.
What is the most commonly missed control in a self-hosted deployment?
Prompt and response logs. They contain the CUI that was in the prompt, which makes them CUI, which means they need the same access control, audit, retention and disposal treatment as any other CUI artefact. Teams routinely ship an inference stack with verbose logging into a general-purpose log store outside the boundary.
Does using an open-weight model make my system compliant?
No. It removes one question — whose cloud is holding the data — and leaves all 110 NIST SP 800-171 requirements exactly where they were. The advantage is that the boundary is yours to define and evidence, not that there is less to do.
Your AI tools are one row in the boundary
Audit the rest of the stack — storage, email, collaboration — against the same FedRAMP test.
Launch CUI AuditorGet a defensible CUI architecture
This Self-hosted open-weight model in your own CUI enclave CUI review flags the gaps. The next step is a compliance architecture review where we map your data flows to FedRAMP-authorized alternatives and CMMC-aligned controls.
Schedule architecture review