← Blog

NIST SP 800-171 AI Compliance Checklist: Ten Actions Before CUI Reaches a Model API

NIST SP 800-171 Revision 3 carries 97 requirements across 17 families and never mentions AI, which is why a single prompt carrying Controlled Unclassified Information to a commercial model endpoint engages five families at once. This checklist gives ten actions for a contractor whose engineers already have access to hosted models, naming the requirement family each one serves and the artifact it produces for an assessment.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationcomplianceai-governanceauditnistai-security
NIST SP 800-171 AI Compliance Checklist: Ten Actions Before CUI Reaches a Model API

Revision 3 of NIST SP 800-171 was finalised on 14 May 2024 with 97 requirements across 17 families, and none of them mention artificial intelligence. A single prompt carrying Controlled Unclassified Information to a commercial model endpoint engages five of those families at once: access control, identification and authentication, audit and accountability, boundary protection, and supply chain risk management.

This checklist assumes a contractor whose engineers already have access to hosted models, whether or not anyone approved it. It runs in the order an assessment moves: scope first, then identity and classification, then enforcement, then evidence. Each item names the family it serves and the artifact it produces, because a System Security Plan describing a control and an assessment finding turn on whether that artifact exists.

1. Write the AI scoping position into the SSP

State whether CUI may traverse an AI request path, which model endpoints are approved, and which systems may call them. Evidence is a written scoping position in the System Security Plan. This is the first document an assessor reads and it determines whether every item below gets examined. A plan silent on AI invites the assessor to define the scope for you.

2. Enumerate model endpoints as external system interfaces

Add commercial and self-hosted model APIs to the boundary diagram under family 03.13, System and Communications Protection. Evidence is an updated boundary description naming each interface. Most boundary diagrams were drawn before hosted models were in daily use, and an interface absent from the diagram is one nobody designed a control for.

3. Bind a named identity to every model request

Route AI traffic so a named user or agent, rather than a shared organisational API key, is attached to each prompt. Evidence is a per-request record showing which principal sent which prompt to which endpoint, satisfying family 03.05 at the point the data actually leaves. Authenticating a user at the application and then calling the model with one key drops identity one layer before the boundary crossing.

4. Classify prompt content for CUI before transmission

Evaluate the context window at the boundary for CUI markings and indicators, tied to per-role policy. Evidence is a per-request classification decision. A prompt assembles fragments from several stores into a payload no document-level marking scheme ever evaluated as a unit, which is why prompt-level DLP produces this artifact and a file classification tool does not.

5. Fail closed when CUI meets an unapproved destination

Block rather than log a request carrying CUI indicators to an endpoint outside the allowlist. Evidence is a policy decision record showing the block, with the rule and the destination named. This is the difference between a control and a detection, and under family 03.01 an assessor treats the two as different answers to the same question.

6. Log every destination actually called and reconcile it

Record the endpoint and region for each AI request, then compare that list against the approved inventory. Evidence is a destination log reconciled to the allowlist, which serves families 03.13 and 03.17 at once. The reconciliation is where unregistered endpoints surface, and it is the artifact most likely to change an assessor's view of scope.

7. Inspect the response before it enters a downstream system

Apply classification and policy to model output where that output feeds an automated process. Evidence is a response-side inspection record joined to the request that produced it, serving family 03.14. Content returning from an external model is untrusted input arriving inside the CUI environment, and the integrity family reads it that way.

8. Add model providers to the supplier inventory

List every model provider in the CUI path under family 03.17, new in Revision 3, and reconcile that list against item 6. Evidence is a supplier inventory matched to traffic. Procurement recorded the vendors someone bought; the destination log records the vendors the organisation actually uses. My honest take: the gap between those two lists is where the next assessment cycle will generate most of its AI-related findings, because nobody has been required to compare them before.

9. Keep the audit record outside the application that made the call

Ensure the AI decision record is produced by a system the calling application has no ability to modify or suppress, satisfying the protection expectations in family 03.03. Evidence is an externally written, signed log. Application-controlled logging fails on selective logging, later modification, and loss on crash between the model response and the log commit, which are failure modes the audit family was written to prevent.

10. Set retention to cover the assessment period, then rehearse the query

Retain AI request records for at least the full assessment period and confirm you can answer, for any date in it, which principals sent which classifications to which endpoints. Evidence is a reconstructable timeline query with a known runtime. AI audit log retention requirements covers the periods the various regimes expect, and an assessment window is usually longer than an engineering team's default.

Where the ten items land

Items 3 through 10 fire at one moment: an HTTPS POST carrying a context window to a model endpoint. The controls mapping sets out which family lands on which enforcement point, and the audit evidence view covers what each artifact has to contain when an assessor asks.

DeepInspect

Eight of these ten items produce evidence at the boundary between your users or agents and the LLM APIs they call, and DeepInspect sits at that boundary. It binds identity to each request, classifies the assembled prompt for CUI indicators before transmission, enforces per-role and per-route policy with a fail-closed default, allowlists and records destinations, inspects the response, and writes a signed per-decision record the calling application never had custody of.

For a contractor preparing an assessment, items 5 and 9 are the two that decide how everything else reads, because failing closed turns a policy into a control and write-path independence turns a log into evidence. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Do we have to control AI usage to pass an 800-171 assessment?

You have to be able to show what happens when CUI meets an AI request path. A documented prohibition is acceptable as a control statement, and an assessor will ask what evidence demonstrates it held during the assessment period. Without a destination log, the answer is an assertion, and Revision 3's supply chain family gives the assessor a second angle on the same question.

Which 800-171 families does AI traffic engage?

Access Control (03.01), Audit and Accountability (03.03), Identification and Authentication (03.05), System and Communications Protection (03.13), System and Information Integrity (03.14), and Supply Chain Risk Management (03.17). A single prompt carrying CUI to an external endpoint touches all six, which is why the scoping position in item 1 carries so much weight.

Does this checklist satisfy CMMC as well?

It covers the AI-traffic layer of the same requirement set. CMMC Level 2 assessments have continued to reference Revision 2 of 800-171, and the underlying evidence for access control, identity, audit, and boundary protection carries across revisions. CMMC AI compliance covers the assessment mechanics that differ.

What about self-hosted models inside the boundary?

A model running inside the assessed boundary changes the answer to item 2 and leaves the rest intact. Identity binding, classification, per-role policy, audit independence, and retention all still apply, because the audit and access control families govern processing within the boundary as well as transfers across it. What drops away is the supply chain row and the external interface designation.

How do we handle AI embedded in SaaS tools we already approved?

Those calls will not appear in your own destination log, since the model call happens inside the vendor's environment. Close that contractually, requiring vendor-side records available on request, and record the vendor in the item 8 supplier inventory. This is the same exposure described in You Own the AI Liability, Not the Vendor, arriving under a CUI heading.