← Blog

NIST SP 800-171 AI Controls Mapping: Six Requirement Families Against One Boundary Crossing

NIST SP 800-171 Revision 3 holds 97 requirements across 17 families and treats a commercial model endpoint as what it is: a system outside the assessed boundary. This maps the six families that a prompt carrying Controlled Unclassified Information engages onto the technical control that enforces each one at the AI request boundary, names the evidence produced, and identifies the families that need work elsewhere in the environment.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationcomplianceai-governancepolicy-enforcementnistai-security
NIST SP 800-171 AI Controls Mapping: Six Requirement Families Against One Boundary Crossing

Revision 3 of NIST SP 800-171 reorganised the standard into 97 requirements across 17 families when it was finalised on 14 May 2024, and it protects Controlled Unclassified Information in nonfederal systems without naming a single technology. That technology-neutral drafting is what makes an AI mapping possible, because the standard cares about where CUI goes rather than what processed it.

A commercial model endpoint sits outside the assessed boundary. A prompt carrying CUI to that endpoint is a boundary crossing, and 800-171 has a great deal to say about boundary crossings. I want to map the six families that crossing engages onto the control that enforces each one, name the evidence, and be explicit about the families where a request-path control contributes nothing.

The control point: one boundary crossing

Every mapping below resolves to the same moment. An HTTPS POST carries an assembled context window from a system inside the CUI environment to a model endpoint outside it. At that instant the caller is known, the prompt is available to classify, the destination is selected, and a record is either written or lost. The assessment boundary and the enforcement boundary are the same line, which is why so many families land on it at once.

03.05 Identification and Authentication

The family requires users and devices to be identified and authenticated before access to a system. Identity binding at the AI request boundary is the control, carrying the end user or agent identity into the policy decision rather than collapsing every caller into one organisational API key. Evidence takes the form of an identity-bound per-request record. A deployment that authenticates the user with a JWT and then calls the model with a shared key satisfies this family at the application layer and abandons it one hop before the data leaves, which is the post-authentication gap in CUI terms.

03.01 Access Control

Access Control governs who may access CUI, under which conditions, and with what least-privilege constraint. A policy decision point at the request boundary is the control, evaluating per-role and per-route rules with a fail-closed default so an ambiguous request is denied rather than passed. What falls out is a per-request policy decision record naming the rule, the role, and the outcome. That artifact is what converts a written prohibition on CUI in prompts into something an assessor can test rather than read.

03.13 System and Communications Protection

This family covers boundary protection and the monitoring of communications at external system interfaces. Destination-aware routing with an allowlist is the control, so a request reaches an approved model endpoint or fails closed. Evidence is a destination log naming every endpoint actually called during the assessment period, reconciled against the approved inventory. Boundary diagrams drawn before hosted models entered daily use tend to omit these interfaces entirely, and the reconciliation is what puts them back on the map.

03.03 Audit and Accountability

The audit family requires event logging, audit record content sufficient to reconstruct events, and protection of the records from unauthorised modification. Write-path independence is the control: the record is produced by a system the calling application has no ability to modify or suppress. That yields an externally written, signed log. Application-controlled logging fails this family through selective logging, later modification by the same system that failed, and loss on crash between the model response and the log commit, which are precisely the conditions the family exists to prevent. The reasoning sits in AI audit log immutability.

03.14 System and Information Integrity

Integrity covers monitoring for indicators of attack and protection against malicious content. Where model output feeds an automated process inside the CUI environment, that output is untrusted external input. Response-side inspection and policy evaluation is the control, applied before the output reaches the next system. Evidence is a response inspection record joined to the request that produced it.

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. The control is the same destination allowlist read for a different purpose, producing the authoritative list of model providers in the CUI path. Evidence is a supplier inventory reconciled to production traffic. Procurement holds the vendors someone bought, traffic holds the vendors the organisation uses, and until Revision 3 nobody had to compare them.

The mapping at a glance

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

The families this mapping leaves alone

Eleven of the 17 families are unaffected by AI request controls, and saying so keeps the mapping credible. Awareness and Training, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment and Monitoring, Configuration Management, Incident Response, Planning, and System and Services Acquisition all operate on the wider environment. Two of them shift in emphasis rather than substance: Incident Response gains a new channel to investigate, and Awareness and Training gains a topic that changes faster than annual training cycles handle.

My frank opinion: the most consequential requirement in this mapping is the one that reads least like a security control. Revision 3's supply chain family turns an inventory question into an assessed obligation, and an inventory built from purchase orders will not survive contact with a destination log. Contractors treating AI as a policy problem are about to find it reclassified as a supplier problem, and supplier findings are harder to close inside an assessment window than technical ones.

DeepInspect

Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, 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 indicators to an unapproved endpoint is blocked rather than recorded after the fact, inspects the response, and writes a signed per-decision record before the response returns.

For a contractor with CUI in scope, that turns the identification, access control, boundary protection, audit, integrity, and supply chain rows into running controls with a per-decision record behind each one. The audit evidence view covers what those artifacts look like under assessment, and the ten-item checklist sequences the work. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Does NIST SP 800-171 require AI-specific controls?

No requirement in Revision 3 names artificial intelligence. The standard's 97 requirements are written against CUI and the systems handling it, so AI traffic falls in scope through the general families rather than through a dedicated one. Anyone waiting for an AI-specific revision before acting is waiting on a document the standard's structure makes unnecessary.

How does this relate to the NIST SP 800-53 control overlays for AI?

They address different populations. SP 800-171 governs CUI in nonfederal systems, while SP 800-53 and its COSAiS overlays govern federal systems and are being extended with AI-specific tailoring. The controls that satisfy the six families above are the same controls the overlays describe, since both derive from the same underlying catalogue.

What if we prohibit AI tools entirely?

The prohibition becomes a control statement in the System Security Plan and an assessor will test it. Testing means asking for evidence that no CUI reached a model endpoint during the assessment period, which requires a destination log. A prohibition without telemetry is an assertion, and embedded AI features inside already-approved SaaS tools tend to falsify it quietly.

Do these controls work in front of a self-hosted model?

Yes, and the mapping simplifies. A model running inside the assessed boundary removes the external interface designation under 03.13 and the supplier row under 03.17, while identity binding, access control, audit independence, and response inspection all continue to apply to processing within the boundary.

Which revision should we build against?

Build against Revision 3's structure and confirm the assessed baseline in the contract, since CMMC Level 2 assessments have continued to reference Revision 2 and the Department of Defense had not moved DFARS to Revision 3 as of early 2026. The evidence artifacts in this mapping satisfy both revisions, because access control, identity, audit, and boundary protection expectations carry across.