Does SP 800-53 apply to AI systems today?

Yes, through the controls that already exist. Revision 5 restructured the catalogue to be outcome-based and technology-neutral, which is why an AI system placed inside an authorisation boundary falls in scope under AC, AU, IA, SC, SI and SR without needing AI-specific controls to be written first.

Should we wait for the COSAiS overlays?

The overlays will add AI-specific tailoring to families that already apply. COSAiS launched in July 2025 with a concept paper covering generative AI, predictive AI, and AI agent use cases, and an annotated outline for the predictive AI overlay followed in January 2026. Building the underlying identity binding and decision record is the larger effort, and the tailoring lands on top of it.

What is the single item most assessments fail on?

Identity binding is the one that sinks most of them. The user authenticates at the application, the outbound model call carries a shared service credential, and every audit record generated downstream names infrastructure instead of a person. That one gap converts AU-3, AC-6, and IA-2 findings into a single root cause that no amount of additional logging repairs.

How long should AI decision records be retained?

Match the longest obligation that applies to the data in the prompts rather than your default log rotation. Sector rules, contractual commitments, and litigation hold requirements routinely exceed the 30 or 90 days most logging pipelines are configured for, and AU-11 is assessed against your stated retention period.

Can a provider's compliance attestation cover these items?

A provider authorisation covers the provider's environment and ends at the API boundary. Whether a given principal in your organisation should have sent that prompt to that endpoint under your policy is a determination on your side, and no attestation produces the identity-bound record that evidences it. The same split governs FedRAMP AI audit evidence.

Which items apply to a self-hosted model?

All twelve of them apply. A self-hosted endpoint removes the third-party provider from SR-3 and SR-6 and changes nothing about AC-3, AC-4, AU-3, AU-9, IA-2 or SI-10. The request still crosses a boundary, still carries classified content, and still needs a record naming who sent it under which policy.

NIST SP 800-53 AI Compliance Checklist: 12 Items to Close Before Your Next Assessment

The fastest way to fail an assessment on an AI system is to arrive with a policy document and no records. SP 800-53 Revision 5 is assessed on evidence, and the AI-specific overlays from NIST's COSAiS project, launched in July 2025, are still in draft. The controls in force today are the ones that have been in force all along.

I have ordered these twelve items by dependency rather than by control family, because six of them produce nothing useful until the first two are done. Each item names the control it serves and a completion test somebody outside your team could run.

1. Inventory every model endpoint your systems actually call

Controls in play here are CM-8 System Component Inventory and SC-7 Boundary Protection.

Pull the destination list from egress telemetry rather than from a survey. Surveys return the endpoints people remember registering. Compare the observed list against your system security plan and expect the gap to be uncomfortable on the first pass.

Done when: a named list of model endpoints, each mapped to an owning system, reconciles against 30 days of observed egress with every difference explained.

2. Bind a named principal to every outbound AI request

This item serves IA-2 and IA-8 for user identification and IA-9 for service identification.

This is the item everything else depends on. Most deployments authenticate the user at the application and then call the model with one system-level API key, which drops identity one layer before the request leaves the boundary. Every downstream record then names a service account.

Done when: a sampled AI request from each production system resolves to a named user or agent, not to a shared credential.

3. Classify prompt content at the request, not the document

This item serves AC-4 Information Flow Enforcement and PT-2 Authority to Process PII.

Legacy DLP classifies whole files at rest. A prompt assembles fragments inside a context window and ships them as an HTTPS payload. IBM's Cost of Data Breach research found customer PII exposure reached 65% in shadow AI breaches against 53% across all breaches.

Done when: a test prompt carrying a known PII pattern produces a classification decision recorded against that request.

4. Make the policy decision before the request leaves

This item serves AC-3 Access Enforcement alongside AC-4 Information Flow Enforcement.

An assessor treats detection and enforcement as different answers. A control that recorded a violation after the prompt reached the provider produces a weaker finding than one that denied it.

Done when: a deliberately non-compliant test request is blocked, and the block appears in the record with the rule that produced it.

5. Set the default to deny

This item serves AC-3 Access Enforcement.

Ambiguity resolves one of two ways, and only one of them is defensible in writing. A fail-closed posture denies the request when classification is uncertain, the destination is unregistered, or the policy service is unreachable.

Done when: disabling the policy service in a staging environment stops AI traffic rather than passing it.

6. Scope agent privileges per call rather than per credential

This item serves AC-6 Least Privilege.

An agent running with the union of every permission its user population might need fails least privilege by construction. Rotating the key changes nothing about the finding. The scope has to derive from the principal who originated the request. That is the post-authentication gap restated as a control test.

Done when: two users with different entitlements sending the same agent request produce different authorisation outcomes.

7. Generate a record for every AI request, not every error

This item serves AU-2 Event Logging and AU-12 Audit Record Generation.

Selective logging of the successful path is one of the three ways application-controlled logs fail. The event set defined under AU-2 has to include the ordinary case.

Done when: the count of records for a sampled hour matches the count of model API calls billed for that hour.

8. Populate every AU-3 field

This item serves AU-3 Content of Audit Records.

AU-3 specifies what a record establishes: what happened, when, where, the source, the outcome, and the identity of the subject associated with the event. For an AI call that reads as the prompt, the timestamp, the endpoint and model version, the calling system, the pass or block decision, and the principal.

Done when: a randomly selected record has no empty field, and the identity field holds a person or agent rather than a service account.

9. Move the write path outside the calling application

This item serves AU-9 Protection of Audit Information.

AU-9 requires audit information be protected from unauthorised modification and deletion. A log written by the component under assessment sits in the same trust domain as the thing it attests to. Selective logging, later modification, and loss on crash all become available to whatever failed. I set the argument out in You Own the AI Liability, Not the Vendor.

Done when: an operator with full administrative rights on the calling application is unable to alter or delete a decision record.

10. Sign the records and set retention

This item serves AU-9 Protection of Audit Information and AU-11 Audit Record Retention.

Tamper evidence turns a database table into an artifact. Retention has to match the longest applicable obligation rather than your default log rotation, which is usually 30 or 90 days and usually shorter than the requirement.

Done when: a record from the earliest date in your stated retention window verifies against its signature.

11. Inspect the response before it enters a trusted context

This item serves SI-10 Information Input Validation.

Where a model's response feeds an automated process inside your boundary, that response is external input arriving in a trusted context. The provider's safety documentation covers the provider's environment and stops at the API boundary, which leaves your input validation unevidenced.

Done when: a response-side inspection record exists and joins to the request that produced it.

12. Reconcile the destination log against the allowlist monthly

This item serves SC-7 Boundary Protection plus SR-3 and SR-6 for the supply chain.

Item 1 was a snapshot. This is the recurring control that catches the endpoint somebody added in March. It is also the artifact that answers SR-3 and SR-6, because the destination log names every provider that received your data.

Done when: a dated monthly reconciliation exists for each of the last three months, with each new endpoint either approved or removed.

What this checklist deliberately excludes

Six of the twelve items above are produced by one component on the request path. The rest of an 800-53 assessment is not, and a checklist that pretended otherwise would send somebody into an assessment underprepared.

Contingency planning under CP, physical protection under PE, awareness and training under AT, risk assessment methodology under RA, and the assessment and authorisation process under CA are organisational work with their own owners and their own evidence. Model validation, training data provenance, and checkpoint integrity belong to the teams who build and select the models. No proxy on HTTP traffic contributes to any of them.

My candid view on sequencing: teams almost always start at item 7, because generating logs feels like progress and costs nothing politically. Records generated before item 2 is done are records with a service account in the identity field, which is a year of storage costs buying an artifact that answers the wrong question. Do items 1 and 2 first even though they are the two that require someone else's roadmap.

DeepInspect

This is the gap DeepInspect closes on items 2 through 11. DeepInspect sits at the AI request boundary as an external enforcement layer: deterministic, identity-aware, and independent of model behaviour. Every request is evaluated against who is asking, what role they hold, what data is involved, and which endpoint is about to receive it. Enforcement happens inline and fails closed.

The per-decision record it writes carries the AU-3 fields populated, on a write path the calling application never had custody of, which is what turns item 9 from an architecture debate into a configuration. The control-ID mapping covers which identifiers each function answers, and the audit evidence walkthrough covers the artifacts family by family. Book a technical deep dive at deepinspect.ai.