CMMC AI Controls Mapping for CUI Flowing to a Model Endpoint

A defense contractor's engineer pastes a controlled technical drawing description into an internal assistant, and the assistant forwards it over HTTPS to a commercial model endpoint. Under the CMMC final rule published on 15 October 2024, effective 16 December 2024, that transaction sits inside the Level 2 assessment scope if the environment processes, stores or transmits CUI. A useful CMMC AI controls mapping names which requirement applies, which component enforces it, who owns that component, how it is tested against the assessment objectives, and which adjacent path stays uncovered.

I would draw the scope boundary around the AI route before mapping a single control, because an assessor's first question is whether the route was in scope at all.

TL;DR

• Section 170.14(c)(3) defines CMMC Level 2 as the 110 security requirements from NIST SP 800-171 Revision 2, and assessment criteria come from NIST SP 800-171A June 2018 with all objectives required for a requirement to count as met.
• Level 1 is the 15 requirements in FAR clause 52.204-21(b)(1), and Level 3 adds 24 selected requirements from NIST SP 800-172 February 2021.
• Access control, audit and accountability, identification and authentication, and system and communications protection are the families an AI gateway touches directly.
• A Conditional Level 2 status requires POA&M closeout within 180 days, so an open AI finding has a hard clock attached to it.

Fix scope before mapping controls

The mapping starts with the CMMC Assessment Scope under 170.19(c), because a control mapped outside the scope proves nothing and a CUI path left outside the scope is a finding. Record for each AI route whether CUI can reach it, which enclave it sits in, whether the model endpoint is a cloud service provider that processes, stores or transmits CUI, and the requirements at 170.16(c)(2) and (3) or 170.17(c)(5) and (6) that apply to external service providers.

Each mapping entry then carries six fields: the requirement identifier in DD.L#-REQ form as described in 170.14(c)(1), the control point, the owner, the test with its expected result, the retained evidence, and the boundary. Assessment criteria under 170.14(d) rest on NIST SP 800-171A June 2018 and NIST SP 800-172A March 2022, and all objectives must be met for a requirement to be considered fully implemented. The zero trust for AI guide works the same reasoning from the architecture direction.

Access control on the routed request

Requirement: limit system access to authorized users, to processes acting on their behalf, and to devices, then restrict that access to the transaction types and functions each user is permitted to execute. Both sit in the Access Control family of NIST SP 800-171 Revision 2.

Control point: the inline HTTP decision point in front of the LLM endpoint.

Owner: the AI platform owner with the IAM lead.

Test: send an authorized role, an unauthorized role, and a request with no identity context to the same route, and confirm each outcome before the request leaves the enclave. Then confirm the decision was recorded.

Evidence: versioned policy, identity and role on each event, model destination, decision, UTC timestamp, response status.

Boundary: coverage is direct for calls traversing the control point. Network and application owners prove enforced routing and bypass prevention separately. Account provisioning and role definition sit with IAM.

Information flow control toward external endpoints

Requirement: control the flow of CUI in accordance with approved authorizations, and control connections to external systems.

Control point: the classification and policy engine at the request boundary, plus the allowlist of permitted model destinations.

Owner: the CUI data owner with security engineering.

Test: send a staged request containing a CUI marking or pattern to an approved destination and confirm the policy action, then attempt the same content toward an unapproved destination and confirm the denial. Record both events.

Evidence: classification rules with version, allowlist configuration, permit and deny events, redaction records, alert history, investigation disposition.

Boundary: content that never traverses the route, such as a file uploaded from an unmanaged laptop directly to a consumer chat product, is outside this control entirely and belongs to endpoint and DLP owners. Data loss prevention on the endpoint and this control cover different halves of the same problem.

Identification and authentication of the actual caller

Requirement: identify system users, processes acting on behalf of users, and devices, and authenticate or verify those identities as a prerequisite to allowing access.

Control point: the identity provider and calling application upstream, with validation at the request point.

Owner: the IAM lead with the application owner.

Test: authenticate a staged user, validate the assertion at the request point, join that event to the AI decision by correlation identifier, then repeat with an expired assertion and confirm the denial.

Evidence: authentication record, assertion schema, validation result, role mapping, correlation identifier, denial event.

Boundary: identity proofing, authenticator management and account lifecycle stay upstream. The recurring architectural defect is an application that authenticates a person and then calls the provider through one shared service account, which leaves the provider record showing a relay. Identity discarded before the outbound call cannot be reconstructed downstream. The AI agent identity guide covers the fix.

Audit and accountability for AI transactions

Requirement: create and retain system audit logs and records to the extent needed to enable monitoring, analysis, investigation and reporting of unlawful or unauthorized system activity, and ensure that the actions of individual users can be uniquely traced so they can be held accountable.

Control point: the record writer at the request boundary and the protected store behind it.

Owner: security operations with the audit owner.

Test: produce the population for a named window including denials, select an event, and trace it to a named individual. Then alter one decision field on a copy, run the documented integrity check, and record the failure output and reviewer.

Evidence: per-decision records, population manifest, integrity mechanism description, tamper test output, access and deletion permissions on the store, retention configuration.

Boundary: audit review as a human process, correlation with other system logs, and the retention schedule itself belong to the organization's programme. The tamper-evident AI audit logs guide covers the write-path design these tests exercise.

System and communications protection on the outbound leg

Requirement: monitor, control and protect communications at external boundaries and key internal boundaries, and protect the confidentiality of CUI in transit using cryptography.

Control point: the transport configuration and the boundary component itself.

Owner: platform engineering with the cryptography owner.

Test: verify the negotiated cipher suite and certificate validation on the outbound connection, confirm provider credentials are not readable by the calling application, and confirm the boundary component denies a connection attempt that bypasses policy evaluation.

Evidence: TLS configuration, FIPS-validated module reference where required, key custody record, bypass attempt result, change ticket for the policy set.

Boundary: cryptographic module validation, certificate lifecycle and key escrow are separate functions with separate evidence.

What the map cannot claim

Physical protection, media protection, personnel security, awareness and training, maintenance, and configuration management for the wider environment run outside the request path. Incident response is partially covered: the request record contributes to detection and analysis, and the reporting obligations under the contract's DFARS clauses belong to the organization. Risk assessment and security assessment are programme activities.

Four AI paths carry no coverage at all and should be named on the first page of the map: direct provider traffic from a device outside the enclave, local model execution on a workstation, browser sessions outside the enforced route, and inference embedded inside a vendor product where the call is invisible. My preference is to list them with an assigned compensating control rather than let an assessor discover them, because an unmarked gap makes the documented parts look less trustworthy. The CMMC AI compliance overview covers the programme context, and the NIST 800-171 AI controls mapping covers the underlying requirement set in more depth.

DeepInspect

DeepInspect operates at the routed HTTP boundary between authenticated users or agents and LLM endpoints. In this mapping it is the enforcement point for access limits on the model request, the classification and information-flow decision point for CUI heading toward an external endpoint, the validation point for identity context an application supplies, and the source of per-decision records supporting unique traceability to an individual user.

Physical and media protection, personnel security, maintenance, configuration management, cryptographic module validation, the assessment itself, and the annual affirmation stay with the roles that already own them. Book a technical deep dive at deepinspect.ai.