← Blog

NIST SP 800-171 AI Audit Evidence: What an Assessor Asks When CUI Reaches a Model

NIST SP 800-171 Revision 3, finalised on 14 May 2024, carries 97 security requirements across 17 families and governs Controlled Unclassified Information in nonfederal systems. An engineer pasting CUI into a hosted model moves that data outside the assessed boundary in one HTTPS request. This walks the evidence artifacts an assessor requests once AI traffic is in scope, family by family, and names where the assessment boundary actually sits.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationcomplianceai-governanceauditnistai-security
NIST SP 800-171 AI Audit Evidence: What an Assessor Asks When CUI Reaches a Model

NIST SP 800-171 Revision 3 was finalised on 14 May 2024, cutting the requirement count from 110 to 97, raising the family count from 14 to 17, and introducing Organization-Defined Parameters that let an assessing agency set specific values. It governs the protection of Controlled Unclassified Information in nonfederal systems, which in practice means the defense industrial base and anyone else handling CUI under contract.

The AI problem arrives in a single HTTPS request. An engineer working a CUI-bearing task pastes a specification into a hosted model, and that data leaves the assessed boundary before any control in the System Security Plan gets a chance to act. Nothing in the 97 requirements mentions AI, and several of them are violated by that request anyway. I want to walk what an assessor asks for once AI traffic is acknowledged as in scope, because the artifacts are specific and most contractors have none of them.

The boundary question comes first

An assessment opens with scope. The System Security Plan defines the CUI environment, and every requirement is evaluated against what sits inside it. A model endpoint at a commercial provider sits outside, which means a request carrying CUI to that endpoint is a transfer across the boundary rather than processing within it.

The first artifact is therefore a written scoping position on AI usage, naming which model endpoints are approved, which systems may call them, and whether CUI may traverse that path at all. Most contractors I encounter have a policy prohibiting it and no mechanism producing evidence of the prohibition holding, which is a distinction an assessor is trained to find.

03.05 Identification and Authentication

The family requires system users and devices to be identified and authenticated before access. Applied to AI traffic, the question is which principal sent a specific request to a model endpoint.

The artifact is a per-request record binding a named user or agent to a prompt. A deployment authenticating the user with a JWT and then calling the model with a single organisational API key satisfies the letter of the family at the application layer and loses the identity exactly one layer before the data leaves. Closing that is the post-authentication gap in 800-171 terms.

03.03 Audit and Accountability

The family requires event logging, sufficient audit record content to reconstruct what happened, and protection of audit records from modification. An assessor reads this family looking for records that survive the system that generated them.

For AI traffic the artifact is a record holding the caller, the transmitted prompt, the classification found in it, the destination endpoint, and the outcome, written by something the calling application has no custody over. Application-controlled logging fails this family on three counts that have nothing to do with AI: selective logging of successes, modification by the same system that failed, and loss on crash between the model response and the log commit. I set that out in You Own the AI Liability, Not the Vendor.

03.01 Access Control and 03.13 System and Communications Protection

Access Control governs who may access CUI and under what conditions. System and Communications Protection governs boundary protection and the monitoring of communications at external interfaces. An outbound call to a commercial model API is precisely an external interface, and it is one most boundary designs never enumerated.

The artifacts are a destination allowlist showing which model endpoints are approved and a destination log showing which were actually called during the assessment period. That second artifact is the one that produces findings, because reconciling the two regularly surfaces endpoints nobody registered. The same reconciliation drives shadow AI discovery.

03.14 System and Information Integrity

The family covers flaw remediation, malicious content protection, and monitoring of the system for indicators of attack. Where a model's output feeds an automated process, content arriving from an external model is untrusted input entering the CUI environment.

The artifact is a response-side inspection and policy record joined to the request that produced it. An assessor reading this family for an AI-enabled workflow wants to see that something evaluated what came back before it reached the next system, rather than a description of the model provider's own safety measures.

03.17 Supply Chain Risk Management

New in Revision 3, this family asks who is in the chain and what each party is accountable for. A model provider is a supplier in the CUI path the moment CUI reaches its endpoint, whether or not procurement recorded it that way.

The artifact is a supplier inventory covering model providers, reconciled against the destination log. My candid view: this family is where AI usage will produce the most findings over the next assessment cycle, because the inventory is a procurement document and the traffic is an engineering reality, and nobody has been asked to compare them until now.

The evidence set

[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop

Every row except the first is produced by traffic passing a control point, and the first row determines whether an assessor looks for the rest.

DeepInspect

This is the evidence layer a CUI assessment reaches for once AI traffic is in scope. DeepInspect sits inline between your users or agents and the LLM APIs they call. It evaluates identity, prompt classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default so a prompt carrying CUI to an unapproved endpoint is blocked rather than logged, inspects the response, and writes a signed, tamper-evident record before the response returns.

That record holds the principal, the transmitted context window, the classification found in it, the model endpoint and version, the policy revision, and the outcome. When an assessor asks whether CUI left the boundary through a model API during the assessment period, the answer is a query with a definite result rather than a policy statement and a hope. The controls mapping view lines each family up against the enforcement point that satisfies it. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Does NIST SP 800-171 say anything about AI?

Not directly. Revision 3 contains no AI-specific requirement, and its 97 requirements across 17 families apply to CUI regardless of the technology handling it. That technology-neutral drafting is exactly why AI traffic falls in scope: a prompt carrying CUI to an external endpoint engages access control, boundary protection, identification and authentication, audit, and supply chain requirements simultaneously.

How many requirements and families are in Revision 3?

Ninety-seven security requirements across 17 families, down from 110 requirements across 14 families in Revision 2. The three added families are Planning, System and Services Acquisition, and Supply Chain Risk Management. Revision 3 also introduced Organization-Defined Parameters, which let a federal agency specify values that Revision 2 left fixed.

Which revision does CMMC assess against?

CMMC Level 2 assessments have continued to reference Revision 2, and the Department of Defense had not updated DFARS or the assessment methodology to Revision 3 as of early 2026. The practical position for a contractor is to build against Revision 3's structure while confirming the assessed baseline in the contract, since CMMC readiness work and 800-171 work share most of their evidence.

Can we just prohibit AI tools instead of controlling them?

A prohibition is a policy, and an assessor asks what evidence shows it held. Without a destination log, the answer is an assertion. Prohibitions also age poorly against embedded AI features in sanctioned SaaS tools, where a model call happens inside a product the organisation approved for other reasons and no policy statement covers it.

Does a model provider's FedRAMP authorization solve this?

It addresses the provider's environment and stops at the API boundary. Whether CUI should have been sent to that endpoint by that user under that policy is a determination on your side of the line, and no provider authorization produces the identity-bound record proving it was made. The same split applies in FedRAMP AI audit evidence, where the boundary question is the one that decides the finding.