Private LLM chat for defense contractors handling CUI

Why a private LLM chat assistant can pull a defense contractor into CMMC scope

Engineers and program staff want an assistant that can summarize specifications, draft test plans and answer questions from contract documents, but much of that material is controlled unclassified information (CUI) that cannot leave the enclave. The short answer: a hosted AI service that receives CUI becomes part of the environment the contractor has to assess, so the self-hosted chat stack must meet Level 2 requirements too. Self-hosting removes the vendor from the data path, but it does not remove the chat platform, its logs, its file uploads or its model servers from scope. Those components are where CUI will actually sit. The flow-down is the mechanism. Under 32 CFR 170.23, CMMC applies to prime contractors and subcontractors at all tiers that will process, store or transmit federal contract information (FCI) or CUI in performing the contract, and primes must flow the requirements down. For CUI, the relevant standard is Level 2, which the rule ties to the 110 requirements of NIST SP 800-171 Revision 2. Before you approve a chat pilot, confirm with your contracting officer and prime which Level applies to each contract, and whether the chat tool is inside the boundary described in your System Security Plan.

The current phase status does not lower the bar. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and the obligations of DFARS 252.204-7012 remain in place, and a DoW class deviation tells contracting officers to name Revision 2 explicitly while Phase II is suspended. Ask your contracting officer which revision your contract references, and track the pending FAR overhaul rule, which proposes Revision 3 with DoW-published parameter values. A chat deployment designed to Revision 2 today should be mapped to Revision 3 before it goes into production.

When the assistant puts systems into scope

Four decisions determine whether a staff chat assistant becomes part of the CMMC assessment boundary. Each one changes which systems hold CUI, who can reach them, and which NIST SP 800-171 requirements apply, so settle them before the first user pastes a document.

Hosted or self-hosted model

A chat assistant that calls a hosted model service sends every prompt and attached file to a system outside your enclave. That service then processes CUI in performing the contract, which brings it into scope. A self-hosted model served with Ollama or vLLM on your own servers keeps prompts inside the boundary you already assess. Confirm where inference runs, where model weights are stored and whether any feature phones home.

Chat logs and uploads as CUI

Chat history, uploaded documents, retrieval indexes and embeddings all inherit the classification of what users paste into them. Treat the whole conversation store as CUI storage until a data owner proves otherwise. Decide which fields are retained, who can read other users' chats and how deletion is verified. The chat database and file storage are part of the assessed scope in the same way as any other CUI repository.

Vendor service access to CUI

Any external party that can read prompts, logs or files, including a hosted model provider, a managed database, a support engineer or an interface vendor's telemetry, becomes a potential external service provider in your assessment. Ask each vendor whether it stores, processes or can view CUI, and whether a DFARS 252.204-7012 flow-down applies to its service. Where the answer is yes, the vendor's own assessment evidence becomes part of your evidence request.

Subcontractor access to the tool

Under 32 CFR 170.23, CMMC requirements flow down to subcontractors at every tier that process, store or transmit CUI. A subcontractor who receives an account, a shared workspace or an API key to the assistant becomes a user inside your boundary. Define which partners get accounts, how their identities are federated, and whether their access is limited to projects that carry no CUI they should not see.

Rev. 2 now, Rev. 3 pending

NIST SP 800-171 Rev. 2 is what the CMMC Level 2 rule and current DFARS clauses enforce, with its 110 requirements. Rev. 3 contains 97 requirements and is named in a FAR overhaul proposed rule that was not final as of October 2026. Map your chat platform controls to Rev. 2 now and keep a crosswalk to Rev. 3, so a later change does not force a redesign. Confirm the active version with your contracting officer before you scope the audit evidence.

Which NIST SP 800-171 Rev. 2 requirements the chat platform must meet

This table maps the CMMC Level 2 requirements most often tested against a chat platform to what the stack must do and the evidence an assessor expects. The 110 Level 2 requirements are counted in 32 CFR 170.4, and the wording here is a working summary, so check each requirement against the NIST SP 800-171A Rev. 2 assessment objectives before you scope the system. The main takeaway is that identity, logging and encryption gaps cause most chat deployment failures, often through local admin accounts, default logs and plaintext hops inside the network.

Requirement ID	What the chat stack must do	Evidence an assessor expects	Where it usually fails
AC.L2-3.1.1 (limit access to authorized users)	Authenticate staff through SSO with OIDC or LDAP and provision groups with SCIM 2.0.	Account and group roster, deprovisioning records, and the identity provider configuration.	Staff accounts persist after role changes because deprovisioning is manual.
AC.L2-3.1.2 (limit access to authorized functions)	Use Open WebUI groups and per-resource permissions to separate chat, knowledge and admin roles.	Role matrix and an exported permission configuration showing who can manage models and knowledge.	Broad default permissions let general users manage shared models or knowledge bases.
IA.L2-3.5.3 (multifactor authentication)	Enforce MFA at the identity provider for SSO and enable authenticator-app MFA for any local accounts.	Identity provider MFA policy, enrollment reports and the list of local accounts with MFA status.	Local break-glass or API-key paths skip the MFA policy applied to SSO.
AU.L2-3.3.1 (create and retain audit logs)	Record sign-ins, admin changes, model calls and file uploads, and forward them to a central store.	Sample log records, log source inventory and the retention setting approved by policy.	Logs stay on a single replica, or prompt and admin events are not captured at all.
SC.L2-3.13.8 (encrypt CUI in transit)	Use TLS between the browser, the chat front end, the gateway and every inference endpoint.	TLS configuration files, certificate inventory and a traffic test showing no plaintext listeners.	Ollama or vLLM endpoints are left on plain HTTP inside the cluster.
SC.L2-3.13.11 (FIPS-validated cryptography)	Confirm that the TLS libraries, database encryption and host operating system use FIPS-validated modules.	Validation certificate numbers from the NIST CMVP listing for each module in use.	Container images bundle general-purpose crypto libraries that were never validated.
SC.L2-3.13.1 (boundary protection)	Expose only the chat gateway and keep PostgreSQL, Redis and the vector store on private subnets.	Network diagram, firewall rule export and a segmentation test from outside the enclave.	Redis or database ports are reachable from workstation or guest networks.
MP.L2-3.8.3 (sanitize or destroy media with CUI)	Define deletion for uploads, backups, caches, vector copies and retired GPU or storage hardware.	Sanitization procedure, destruction records and a backup deletion schedule.	Vector embeddings, Redis snapshots or old backups are forgotten at decommissioning.
AT.L2-3.2.1 (security awareness)	Show the acceptable use policy and paste rules at first login, and track training completion.	Signed policy acknowledgments, training completion records and the approved list of CUI handling rules.	Staff paste CUI into the chat because the rules are not in the tool or the training.

Choosing the chat interface: Open WebUI, LibreChat or AnythingLLM

Open WebUI is the most widely deployed of the three interfaces for teams that want a ChatGPT-style front end over Ollama or vLLM. Since v0.6.6 (April 19, 2025), its code is distributed under the Open WebUI License, which is BSD-style but adds a branding clause. Clause 4 prohibits altering or removing Open WebUI branding except for deployments with no more than 50 end users in any rolling 30-day period, with written permission, or under other listed exceptions. A contractor whose user base grows past that threshold must either keep the branding or obtain an enterprise license or written permission before it changes the interface.

Branding threshold: Count end users in any rolling 30-day period, not named seats, so a pilot that expands in one month can cross the line.
Enterprise license: White-labeling and custom branding are offered under enterprise licenses, which are quoted after contacting enterprise sales with an expected seat count. No price list is published.
Identity and access features: Documented SSO through OIDC and LDAP, SCIM 2.0 provisioning, role-based access control with groups, API keys and authenticator-app MFA.
Scaling dependencies: Multi-replica deployments require PostgreSQL, Redis and shared file storage, which add components that must be inside the CUI boundary.
Version cadence: v0.12.3 was published on October 16, 2026, after v0.12.0 on October 10, so plan a documented update process.

Before selection, ask counsel to read clause 4 against your expected user count and confirm the enterprise license terms in writing.

Open-source platforms that fit a CUI enclave

A CUI enclave needs a chat interface, a model server, a gateway and a logging layer, all running inside the boundary. The cards below cover the open-source components that commonly fill those roles and the license, identity and data-flow checks to complete before any of them touches controlled information.

Open WebUI for the chat interface

Open WebUI is the most complete self-hosted chat front end in this group. It documents SSO through OIDC and LDAP, SCIM 2.0 provisioning, role-based access control with groups, API keys and authenticator-app MFA, which map to identification, access and authentication requirements in NIST SP 800-171 Rev. 2. Install with Docker, Compose or Helm inside the enclave. Check the Open WebUI License before deployment: branding can only be altered within its listed limits, and deployments above 50 users in a rolling 30-day period need an enterprise license or written permission.

LibreChat as an alternative interface

LibreChat is a chat interface under the MIT license, with a latest tagged version of v0.8.8. It is a credible alternative when the license terms of Open WebUI do not suit the program or when the team prefers its multi-provider configuration. Confirm the features the enclave needs before selecting it: SSO protocol support, group-based permissions, audit export and how file uploads are stored. Those capabilities are configuration-dependent, so verify them in a test deployment against your identity provider.

Ollama for local model serving

Ollama runs open-weight models on the enclave's own servers and is licensed under MIT, with v0.40.5 released October 14, 2026. Because prompts are processed locally, no CUI leaves the boundary to a commercial model API. It suits small teams and pilot concurrency. Ask the implementer to confirm how concurrent requests are queued, which model files are pulled and from where, and how the server is blocked from reaching the internet after model download.

vLLM for production inference

vLLM is an inference and serving engine under Apache-2.0, with v0.31.0 released October 5, 2026. It exposes an OpenAI-compatible endpoint and is generally the choice when many staff share GPUs and throughput matters. Its GPU sizing depends on the chosen model, context length and concurrency, so ask for a sizing test with your own prompts and file sizes. Pin the version, record it in the change log and treat each upgrade as a configuration change under the enclave's baseline management controls.

LiteLLM as the controlled gateway

LiteLLM sits between the chat interface and every model endpoint, so requests pass through one place for keys, routing, budgets and logging. Its open-source core is MIT licensed, but its enterprise directory is under separate terms, so confirm which features you rely on are outside it. Use the gateway to enforce that only approved internal endpoints are reachable and that no request is forwarded to a commercial API unless the contract and CUI handling rules allow it.

Langfuse or Phoenix for prompt logging

Langfuse and Arize Phoenix record traces of prompts, outputs and tool calls, which supports audit trails for CUI access. Langfuse is MIT licensed except its ee directories, so exclude those files from any deployment and confirm the enterprise code is not pulled in. Phoenix is under the Elastic License 2.0, which prohibits offering it to third parties as a hosted or managed service, so a contractor running it for internal staff should confirm that use fits the license. Decide what content is logged, where it is stored and who can read it.

Keeping prompts, files and logs inside the enclave

Prompts, uploaded documents, extracted text, embeddings, chat history and model answers become CUI-derived as soon as a user pastes or uploads controlled material, so each of them belongs inside the enclave boundary. The chat front end, inference servers, the PostgreSQL database that stores conversations, the vector database and the file storage behind uploads all need to run on enclave systems, and backups must stay there too. Apply least privilege: map SSO groups to chat roles, limit administrator accounts, and record who opened, shared, exported or deleted a conversation. Ask your assessor to confirm how each store is scoped in your system security plan, because embedding indexes are the component teams most often leave off the asset inventory.

Observability tooling is the most common place CUI leaves the enclave. Tracing libraries and hosted evaluation services capture full prompts and completions by default, so a SaaS trace endpoint becomes an external system holding CUI. Run any tracing platform, such as self-hosted Langfuse or Phoenix, inside the enclave, and verify that the chat interface, AI gateway and container runtime send no telemetry or crash reports to external endpoints. Langfuse is MIT licensed outside its ee directories, while Phoenix is under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. Confirm with counsel that your internal use fits that license. Route application and audit logs to the enclave's own log store, and test that trace content is excluded or redacted wherever you do not need it.

If the same assistant serves users in the EU, the EU AI Act adds logging duties for high-risk systems. Article 12(1) requires such systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. A defense supplier with no EU operations is unlikely to fall under these articles, so confirm that scope with counsel before relying on them. Even where they apply, six months is a floor. Contract terms and your own records schedule may require longer, so set one retention period for chat logs, audit records and backups, and confirm it with your assessor before rollout.

Evidence assessors ask for from the chat platform

This table maps the evidence a C3PAO or DoD assessor is likely to request for a private chat assistant to the component that produces each item. Assessors accept only final-form evidence, so each row should be treated as a document or export that exists, is dated and is current on the day of assessment.

Evidence item	What it shows	Component that produces it
System security plan entries	How each NIST SP 800-171 requirement is implemented for the chat platform and its boundary	Your compliance lead, drafted from the platform design and kept current with each change
SSO and MFA configuration exports	That users authenticate through the organization's identity provider with multifactor authentication	Identity provider plus the Open WebUI or LibreChat authentication settings
Group-to-role mappings	That access to chats, files and models follows least privilege and matches HR and contract roles	Open WebUI groups and permissions, or LibreChat roles, synced from the directory
Audit log samples	That logins, administrative changes and access to CUI-bearing chats are recorded and reviewable	Chat platform logs, reverse proxy logs and the central log store inside the enclave
Backup and restore records	That chat history, uploads and configuration can be recovered and that restores were tested	Backup tooling for PostgreSQL, shared file storage and configuration files
Model and image version inventory	Which model weights, inference engine and container images are running, with versions and sources	Inference server (Ollama or vLLM), container registry and configuration management records
Boundary diagram	Where CUI enters, is stored, is processed and leaves, and which components sit inside the enclave	Your architecture team, traced against the actual network, storage and identity flows
SPRS-relevant assessment notes	Self-assessment reasoning per requirement, with evidence references, supporting the score posted to SPRS	Your assessment team, based on the SP 800-171A objectives and the evidence above

Questions defense suppliers ask before engaging a partner

Does a hosted AI model service bring our chat tool into CMMC scope?

Yes, if staff paste CUI into it. Under 32 CFR 170.23(a), CMMC applies to contractors and subcontractors at all tiers that will process, store or transmit FCI or CUI in performing the contract. A hosted assistant that receives prompts, files or chat history containing CUI processes CUI, so the service and its data flows fall inside the assessed boundary. The practical question is whether the model endpoint, logs and uploads can stay inside your CUI enclave. Keeping them there is the usual way to limit scope, but confirm the boundary with your assessor and your prime contractor before you build.

Which CMMC level applies to us right now?

It depends on the information the assistant will touch, and the current status is in flux. Level 1 covers FCI with 15 safeguarding requirements, and Level 2 covers CUI with the 110 requirements of NIST SP 800-171 Rev. 2. The DoW CIO's About CMMC page says Phase 1 implementation is paused and may only require self-assessments at Levels 1 and 2. On 13 July 2026, the Department of War suspended CMMC Phase II, which had required Level 2 C3PAO certification. Phase I self-assessments, SPRS postings, affirmations and DFARS 252.204-7012 obligations remain in place. Ask your contracting officer which level and assessment type each contract requires.

What drives the cost of a private chat for CUI work?

Five components drive most of the spend, and they split into one-time and recurring costs. The first is GPU servers or cloud GPUs in the enclave, which scale with concurrent users and model size. The second is the chat interface and any enterprise license. Open WebUI's branding clause applies above 50 users in a rolling 30-day period, and its enterprise license is quoted on request. The third is integration and hardening: SSO, groups, logging, backups and the NIST SP 800-171 control evidence. The fourth is assessment preparation, and the fifth is operations, including patching and model updates. Ask each partner for these as separate line items in the written scope.

What should a written scope and quote include for this work?

A written scope should name the systems, boundary and deliverables before any work starts. Ask for the list of in-scope components, including the model servers, chat interface, vector database, PostgreSQL, Redis, file storage and log store, plus the network paths that connect them to the CUI enclave. Require a control mapping to the requirement IDs in the CMMC Model, such as AC.L2-3.1.1, and a statement of which evidence the partner prepares versus which your assessor reviews. Also ask for the update and support terms, the exit and handover process, and what happens if the CMMC requirements change during the engagement. DeployOpen works on fixed-scope engagements agreed in writing, and quotes follow from that scope.

How much time and effort will our staff need to commit?

Expect the most staff time from the people who own identity, network segmentation and the CUI system security plan. Your team will need to supply access to the enclave, approve the data flows, confirm which users and groups get which models, and review evidence. No researched source gives a duration for this work, so ask each partner for a timeline tied to your environment and a list of named roles on your side. Also ask how long evidence collection takes, because assessment objectives under NIST SP 800-171A require final-form evidence, not drafts.

Can our internal IT team run and maintain the chat platform themselves?

Often yes, if they already operate Linux, containers, identity and the CUI enclave. Open WebUI has official install methods through Docker and Docker Compose, Kubernetes with Helm, and pip. Multi-replica deployments need PostgreSQL instead of SQLite, plus Redis and shared file storage. The harder parts are keeping the NIST SP 800-171 controls operating and documented, applying model and platform updates inside the boundary, and producing evidence on schedule. Assess your team against those tasks before choosing between in-house and partner-led operation, and consider a support retainer for the gaps.

How will Rev. 3 or the FAR overhaul change the requirements?

Neither changes your obligations today, but both could change the control set you build against. NIST published SP 800-171 Rev. 3 with 97 requirements in 17 families on 14 May 2024, and the CMMC rule still incorporates Rev. 2. Class Deviation 2026-O0025, Revision 3 names Rev. 2 explicitly, and the Department of War said it will enforce Rev. 2 in the interim. The FAR overhaul proposed rule of 23 June 2026 would require Rev. 3 with ODP values published by the DoW CIO, but it was not final as of October 2026. Design the enclave so controls map to both revisions, record your organization-defined parameters, and review the rule when it is finalized.

What the chat platform does not satisfy on its own

A chat platform can meet some NIST SP 800-171 requirements, but the assessment is made against the whole environment where CUI is handled. The cards below cover the obligations that sit outside the chat stack and that an assessor will test alongside it.

Policy and training obligations

Requirements in the awareness and training family and the policy requirements in the model require written policies, defined roles and training for staff who use the assistant. An assistant that staff can reach from any browser still needs an acceptable use rule that says which CUI may be pasted, uploaded or summarized. Ask whether your policy names the chat tool, sets the data types allowed in prompts and records who completed training before access is granted.

System Security Plan and assessment evidence

The System Security Plan describes the boundary, the components, the controls and who owns each one, and it must include the chat platform, its model servers, its databases and its backups. A requirement counts as MET only when every applicable assessment objective is satisfied with final evidence, so draft procedures and screenshots without dates will not carry the control. Confirm with your assessor which artifacts they accept and who keeps them current.

Enclave network controls outside the chat stack

The chat server can enforce login and logging, but the enclave boundary is enforced by firewalls, segmentation and egress rules around it. Model servers, vector databases and the chat application should accept traffic only from approved internal sources, and outbound connections to hosted model APIs or update servers should be blocked or explicitly approved. Ask who manages these rules and how changes to them are logged and reviewed.

Endpoint and media controls

Staff can copy CUI out of the chat window into a personal device, a browser extension or removable media, and no server-side setting stops that. Requirements on removable media, mobile devices and endpoint protection apply to the workstations used to reach the assistant. Confirm which browsers, devices and session timeouts are permitted, and whether downloads of chat exports are blocked or logged.

Organization-defined parameters under Rev. 3

Rev. 3 introduced organization-defined parameters, and NIST does not assign their values. If a federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. This matters if the FAR overhaul is finalized and contractors must use published DoW values, so the chat platform's settings for session length, retention and lockout should be recorded as explicit values that can be compared with whatever is later required.

Third-party assessment when Phase II resumes

Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Phase II, which would have required that certification, was suspended on 13 July 2026, but Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Confirm the current phase status and the contract clauses that apply with your contracting office, and plan the assessment scope so it can be extended if Phase II resumes.

Confirming which CMMC requirements apply to your contracts today

Before you size a chat platform for CUI, confirm which CMMC requirements your contracts actually impose today, because the official sources do not agree. As of 17 October 2026, the DoW CIO About CMMC page says implementation is paused in Phase 1, which began 10 November 2025, and may only require self-assessments at Levels 1 and 2. The eCFR text of 32 CFR 170.3(e) still carries the original four-phase schedule. On 13 July 2026 the Department of War suspended Phase II, which would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place.

The clause language in each contract matters more than any summary. Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names NIST SP 800-171 Revision 2 explicitly, citing a 13 July 2026 DoW CIO memorandum that requires baseline compliance with Rev. 2 while Phase II is suspended. Separately, a FAR overhaul proposed rule published 23 June 2026 would require CUI contractors to comply with Rev. 3 using ODP values published by the DoW CIO. That rule was not final as of October 2026. Ask your contracting officer which version and which clauses govern each active contract, and whether any modification is expected before renewal.

Record the answers in writing and assign an owner to re-check them, because this area changes quickly. Ask for the clause numbers and dates in each contract, confirm whether the flow-down to your subcontractors and any cloud or AI providers that touch CUI is unchanged, and ask how the Rev. 2 or Rev. 3 requirements will be assessed for the chat platform. Your compliance lead should also confirm the current state of the eCFR text of 32 CFR Part 170 against the DoW CIO page. Design the chat platform against the stricter reading until the contracting officer confirms otherwise.

How the enclave deployment proceeds from scoping to evidence

The sequence turns a contract requirement into a chat platform that keeps CUI inside a bounded enclave, with each step ending in a documented check. The output is a deployed, tested system and an evidence package an assessor can review.

Confirm contract clauses and assessment scope
Start by reading the contract for the DFARS clauses that apply, including DFARS 252.204-7012, and confirm which CMMC level and which NIST SP 800-171 revision the contracting officer has specified. Confirm the current status of CMMC Phase II and any flow-down obligations with your contracting officer and counsel, because the rules have changed during 2026. The step closes with a written scope statement that names the CUI systems, the assessment level and the revision the team will test against.
Define the enclave boundary
Map every place where CUI could be typed, uploaded, displayed, cached, logged or backed up, including the chat interface, model servers, vector stores, databases, object storage, admin workstations and backups. Decide which of these sit inside the CUI enclave and which are excluded, and document the data flows that cross the boundary. The output is a boundary diagram and a data flow register that the assessor and your system security plan can both reference.
Select and license the chat interface
Choose between Open WebUI and LibreChat (or another interface) against the boundary and the required features, and confirm the license terms before any build starts. For Open WebUI, check the branding clause, which applies above 50 users in a rolling 30-day period, and decide whether an enterprise license is needed. The step closes with a bill of materials listing each component, its version and its license, so the configuration can be tracked and patched later.
Deploy models and the gateway inside the enclave
Install the model serving layer (Ollama or vLLM) and any AI gateway on hosts inside the enclave, with no outbound calls to public model APIs. Pin versions, restrict network egress, and verify that model weights and container images were obtained through an approved and recorded transfer process. The step closes when a test request from an approved client reaches the local endpoint, and a request to any external provider is blocked and logged.
Configure identity, access and logging
Connect the interface to the organization's identity provider over OIDC or LDAP, set up groups and role-based access so that only cleared, enrolled users reach CUI workflows, and enable MFA. Configure chat history, file upload and audit log retention, and send logs to protected storage inside the enclave. The step closes with test accounts showing that access is denied outside the defined groups and that each login, upload and administrative change produces a log record.
Test controls against the SP 800-171A Rev. 2 objectives
Assess each applicable requirement against the assessment objectives in NIST SP 800-171A (June 2018), using the Rev. 2 requirement IDs that CMMC Level 2 references. Examine configurations, interview administrators and test behavior, such as attempted uploads of marked material and attempted external calls. The step closes with a gap register listing each objective as met, not met or not applicable, with the reason and the remediation owner recorded.
Collect final evidence for the assessment
Gather evidence in final form, not drafts: signed configuration baselines, the boundary diagram, access review records, log samples, change records, backup and restore results, and the system security plan. Confirm each piece matches the system as deployed. The step closes with an evidence index mapped to requirement IDs, which the organization reviews with its assessor and uses for its score posting or certification process, as applicable under the current rules.
Hand over operations with the evidence refreshed
Transfer runbooks for patching, model updates, user onboarding, log review and incident response to the internal operations team, and agree who maintains the evidence after go-live. Schedule regeneration of the evidence index after each material change, such as a model swap, a version upgrade or a new user group. The step closes when the operations team runs a supervised change through the documented process, and the evidence index is updated to match.

How DeployOpen scopes and delivers a CUI-enclave assistant

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For defense contractors, that means a chat assistant, its models and its logs are deployed within the CUI enclave boundary, and the written scope states which NIST SP 800-171 Rev. 2 requirements the platform supports and what evidence it produces.

How we scope

We confirm which systems process, store or transmit CUI and where the enclave boundary sits before any design work starts.
We record in the written scope which CMMC Level 2 requirements the chat platform, model servers and log stores must meet, using the 110 Rev. 2 requirements.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and the quote follows from that scope.

How we build

We deploy the chat interface, inference servers, gateway and log storage inside your enclave with no outbound calls to hosted model services.
We configure SSO, group-based access control and MFA so only authorized staff reach CUI-bearing chats and uploaded files.
We test the deployment against the assessment objectives of NIST SP 800-171A and record the results as evidence before handover.

How we hand over

You receive system documentation, configuration baselines, data flow diagrams and the evidence set mapped to each requirement in scope.
We document the retention, logging and backup settings, along with the runbooks your team needs to operate the platform.
We prepare systems, controls and evidence for your assessment, but independent assessors issue any certification or attestation.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We track changes to the CMMC rule, the DFARS clause and the NIST baseline, and confirm with you which version your contracts require.
We plan and test each upgrade of the chat interface and models in a staging enclave before it reaches production users.