NIST SP 800-53 AI Controls Mapping: The Control IDs an AI Gateway Actually Answers

An assessor working an AI system inside an authorisation boundary opens the same catalogue they opened for the last system. SP 800-53 Revision 5 organises 20 control families, and NIST's Control Overlays for Securing AI Systems project, launched July 2025, will tailor them for AI once the drafts land. The assessment happening this quarter runs against the identifiers that already exist.

I want to work through those identifiers one at a time, because a family-level mapping ("we help with AU") survives about ninety seconds of a real assessment. The question that gets asked is which control, and what artifact.

AC-3 and AC-4: enforcement and information flow

AC-3 Access Enforcement requires that approved authorisations be enforced for logical access. AC-4 Information Flow Enforcement controls the flow of information between connected systems and within a system, according to approved authorisations.

A prompt moves data across a security domain boundary, which puts AC-4 directly in play on every AI request. The enforcement artifact is a per-request policy decision naming the principal, the rule applied, the classification found in the payload, the destination, and the outcome, with a fail-closed default. An assessor separates detection from enforcement here without much sympathy: a system that recorded a policy violation after the prompt left produces a weaker finding than one that denied the request.

AC-6 Least Privilege joins them the moment an agent enters the picture. An agent holding one service credential provisioned for the union of its user population's needs fails AC-6 by construction, and the finding is not fixed by rotating the key.

AU-3, AU-9 and AU-12: what the record contains and who protects it

AU-12 Audit Record Generation requires the system to generate records for the events defined under AU-2. AU-3 Content of Audit Records specifies what each record establishes: what happened, when, where, the source, the outcome, and the identity of any individual or subject associated with the event.

Applied to an AI call, AU-3 reads as a specification. What happened is the prompt and the policy decision. Where is the model endpoint and version. The identity associated is the principal who originated the request, which is the field most deployments have already lost by the time the call leaves.

AU-9 Protection of Audit Information is where application-controlled logging fails hardest. The control requires audit information and tooling be protected from unauthorised access, modification, and deletion. A log written by the component under assessment sits inside the same trust domain as the thing it attests to, and the three failure modes are selective logging of the successful path, modification by the failing component, and loss when the process dies between the model response and the log commit. I set the argument out in full in You Own the AI Liability, Not the Vendor.

IA-2, IA-8 and IA-9: which principal called

IA-2 covers identification and authentication of organizational users, IA-8 covers non-organizational users, and IA-9 covers service identification and authentication.

The common AI deployment authenticates the user at the application under IA-2, then calls the model with one system-level API key. IA-2 is satisfied at the front door and the identity is dropped one layer before the request leaves the boundary. Every downstream control inherits that loss, because an AU-3 record missing the identity field answers a different question from the one AU-3 specifies. IA-9 is the control that should be carrying the agent-to-service leg, and in practice it is carrying a shared secret.

SC-7 and SC-8: the boundary and the transmission

SC-7 Boundary Protection requires monitoring and control of communications at external managed interfaces. A commercial model API is an external interface. In most system security plans written before hosted models entered daily use, it appears in no diagram.

The artifact pair is a destination allowlist and a destination log naming every model endpoint actually called during the assessment period. Reconciling those two is what surfaces endpoints nobody registered, which is shadow AI discovery arriving under an SC heading rather than a security-awareness heading. SC-8 covers transmission confidentiality and integrity, and the TLS that satisfies it is the same TLS that renders the payload invisible to network DLP, which is why the inspection point has to sit above it.

SI-4 and SI-10: monitoring and input validation

SI-4 System Monitoring requires monitoring to detect attacks and indicators of potential attacks. SI-10 Information Input Validation requires the system to check the validity of information inputs.

SI-10 is the control most AI programmes have not connected to their architecture. Where a model's response feeds an automated process inside the boundary, that response is external input entering a trusted context, and the provider's safety documentation covers the provider's environment and stops at the API boundary. The artifact is a response-side inspection record joined to the request that produced it.

SR-3, SR-6, PT-2 and CM-8

SR-3 Supply Chain Controls and Processes and SR-6 Supplier Assessments engage the moment a model provider receives your data. PT-2 governs the authority to process personally identifiable information, which a prompt carrying personal data across a boundary triggers directly. CM-8 System Component Inventory covers the model endpoints themselves as components.

All four are answered by the same two artifacts already produced for the controls above: the destination log for who received what, and the per-request classification decision for what the traffic carried.

The mapping table

Where the mapping stops

Fourteen rows is the honest extent of it, and the controls a gateway contributes nothing to are worth naming so nobody builds a programme with a hole in it.

CP for contingency planning, PE for physical protection, AT for awareness and training, RA for risk assessment methodology, and CA for assessment and authorisation processes are organisational and procedural work. SA System and Services Acquisition covers the development lifecycle of the system itself. Model validation and training data provenance sit with the teams who own the model, not with a proxy on the HTTP path. A vendor mapping that shows green across all 20 families is describing a spreadsheet rather than an architecture.

My candid view: the COSAiS overlays are the most useful thing NIST has in flight on AI security, and their drafting timeline has produced a bad side effect. Teams read "the overlay is not final" as permission to defer, when the AC-4, AU-3, IA-2 and SC-7 evidence any overlay will assume is already missing from most AI deployments. Building the record now and mapping it to the overlay later costs less than the reverse.

DeepInspect

This is the enforcement and evidence layer those control identifiers reach for. DeepInspect sits inline between your users or agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. It evaluates identity, prompt classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default, inspects the response before it returns, and writes a signed, tamper-evident per-decision record.

One component produces the AC-3, AC-4, AU-3, AU-9, SC-7 and SI-10 artifacts from a single store rather than from six systems and a reconciliation spreadsheet. The 800-53 AI audit evidence walkthrough covers the family-level artifacts, and the COSAiS overlay mapping covers how the draft overlays line up against a zero-trust gateway design. Book a technical deep dive at deepinspect.ai.