AI Vendor Risk for Defense Contractors Starts at the CUI Route

An engineering agent retrieves a marked specification and sends four paragraphs to a commercial model endpoint. The HTTPS request has now placed covered defense information on an external provider's infrastructure for processing. DFARS 252.204-7012 says that an external cloud provider used to store, process or transmit covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline and comply with the clause's incident, reporting and forensic-support requirements. AI vendor risk defense contractors starts with the route carrying the data.

I want to connect that clause to CMMC scoping, show why a vendor assurance pack leaves a request-level gap, and define the evidence a contractor needs before an assessor follows the CUI flow.

TL;DR

• The DFARS safeguarding clause places specific security and incident duties on external cloud providers handling covered defense information.
• CMMC treats assets that process, store or transmit CUI as CUI assets and brings qualifying external service providers into scope.
• A vendor review proves the provider's posture; a request record proves which marked data reached which endpoint under whose authority.
• Inline enforcement can block an unapproved route or send the request to an authorized model deployment before CUI leaves the contractor boundary.

The DFARS trigger is processing, storage or transmission

The DFARS safeguarding clause defines a covered contractor information system as an unclassified system that processes, stores or transmits covered defense information. Covered defense information includes marked or contract-identified CUI provided by DoD and information collected or developed for contract performance when safeguarding controls apply.

Paragraph (b)(2)(ii)(D) addresses external cloud service providers directly. When the contractor intends to use one to store, process or transmit covered defense information, the contractor must require and ensure FedRAMP Moderate-equivalent security. The provider also has to comply with the clause's cyber-incident reporting, malicious-code handling, media-preservation and forensic-access obligations.

Model inference counts as processing because the endpoint must read the plaintext request to generate a completion. TLS protects the request in transit, and a region setting answers where the workload runs while leaving the provider obligations intact. Shadow AI in defense contractors describes how unsanctioned routes appear. Vendor risk decides which discovered routes qualify for contract work.

CMMC follows CUI onto provider assets

32 CFR Part 170 establishes the CMMC programme for contractor and subcontractor protection of Federal Contract Information and CUI. Its definitions call assets that can process, store or transmit CUI "CUI Assets."

Part 170 also defines an External Service Provider as external people, technology or facilities used to provide and manage IT or cybersecurity services on behalf of the organization. For CMMC, CUI or Security Protection Data such as logs and configuration data must be processed, stored or transmitted on the provider's assets for that provider to count as an ESP.

The scoping consequence depends on the service and data. A model endpoint receiving CUI plainly changes the system picture even if the procurement record calls the service a writing assistant. An observability vendor that receives prompt logs may also handle CUI or Security Protection Data. The contractor's assessor follows the data, so the architecture diagram and asset inventory must follow it too. CMMC AI controls mapping provides the broader control view.

Vendor evidence must match the exact deployment

A provider may operate several products under different authorization boundaries, regions and terms. The contractor has to review the deployment actually receiving contract data.

The record should identify the endpoint, tenant, region, approved model versions, data-retention mode, administrator access, incident-notification path, subcontractor chain and evidence for FedRAMP Moderate equivalence. It should also show how the provider will support the 72-hour DFARS reporting clock and the clause's requirement to preserve relevant monitoring or packet-capture data for at least 90 days after a report.

A generic security page fails to establish those details. So does a contract that names the provider while leaving browser chat and API routes interchangeable. My opinion is blunt: putting "FedRAMP" in a vendor spreadsheet while engineers can select an unapproved endpoint from a dropdown is paperwork pretending to be boundary control.

The concrete test is visual: put the CUI data-flow diagram on a wall and trace the thick red line from the marked drawing, through the authenticated agent, to the exact model hostname and evidence store. Any dotted mystery line is unfinished scope.

Request records make the vendor review provable

DFARS defines a compromise to include disclosure to unauthorized persons, a policy violation or copying to unauthorized media. If a model request creates that concern, the contractor needs to identify the specific data and user accounts involved as part of its review.

A per-request record should carry the authenticated user or agent, contract and programme context, calling application, CUI category and marking, provider endpoint, tenant, region, resolved model version, policy version, decision, timestamp, and integrity reference for request and response. A service account alone gives the investigator the wrong actor. The initiating engineer or delegated agent belongs in the identity chain.

The evidence store needs its own CMMC scoping analysis because logs can contain CUI or Security Protection Data. Content minimization helps: keep the fields required to prove the decision, protect any content reference appropriately and avoid turning the audit system into a second prompt archive. AI audit log chain of custody covers the integrity mechanism.

Inline routing enforces the approved boundary

Training tells an engineer which model route is approved. An inline policy point checks the request before transmission.

For marked CUI, policy can require a specific authorized endpoint and tenant, verify the caller's programme role, pin an approved model version and block every other destination. A request containing Security Protection Data can follow a separate route with its own retention and access conditions. Public drafting material can use a broader set of models without carrying the contract boundary into every task.

The outcome record ties the vendor decision to actual use. It shows that the approved endpoint received the permitted class of data, or that the enforcement point refused the call. This is the operational layer behind AI vendor risk management. The provider assessment remains necessary. The policy decision proves the contractor used that provider within the assessed conditions.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP traffic between users or agents and LLM endpoints. It evaluates identity, programme context, CUI classification, destination, tenant and model version before a request leaves the contractor's control. Policy can block the request or route it to an approved deployment.

Each decision creates a signed audit record with the caller, application, classification, endpoint, model version, policy version, outcome and timestamp. Those records support the CUI flow, asset inventory and incident reconstruction without claiming to confer FedRAMP status on a provider. DeepInspect covers authenticated HTTP AI traffic. CUI marking, provider authorization, CMMC scope, contract flow-down and DFARS reporting remain with the contractor.

Book a demo today.