NIST CSF 2.0 AI Compliance Checklist: 10 Outcomes to Evidence for AI Traffic

A CSF 2.0 Profile is a claim, and claims get tested. NIST released Cybersecurity Framework 2.0 on 26 February 2024 written as outcomes rather than prescriptions, which means a team can write an ambitious target Profile in an afternoon and produce nothing that supports it. When AI traffic is in scope, the supporting evidence has to come from the request path.

These ten items follow dependency order rather than the Function wheel, because items 4 through 10 produce artifacts about a service account until item 2 is done. Each names the category it serves and a completion test somebody outside the security team could run.

1. Build the AI asset inventory from observed traffic

This item serves ID.AM, which expects assets inventoried and managed according to criticality.

Model endpoints are assets and so are the agents calling them. A registry built from a survey lists what people remembered to register. Derive the list from egress telemetry instead and reconcile it against the registry. Netwrix found that only 37% of organizations have any detection or governance policies for AI usage, which sets a realistic expectation for the first pass.

Done when: a dated reconciliation exists between 30 days of observed model-endpoint egress and the registered inventory, with every difference explained.

2. Carry the originating identity to the model call

This item serves PR.AA, which expects access granted to authenticated identities commensurate with assessed risk.

Everything after this depends on it. The common pattern authenticates the user at the application, then calls the model with one system-level API key holding the combined privileges of every user of that application. PR.AA is satisfied at the front door and the identity is gone one layer before the request leaves. That is the post-authentication gap stated as a control test.

Done when: a sampled AI request from each production system resolves to a named person or agent rather than a shared credential.

3. Classify prompt content on the request

This item serves PR.DS, which expects data protected in transit and in use.

Classification designed for documents at rest reads a file. A prompt assembles fragments from several sources inside one context window and ships them as a single HTTPS payload. IBM's Cost of Data Breach research found customer PII exposure reached 65% in shadow AI breaches against 53% across all breaches, and those breaches ran 247 days to detection.

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

4. Turn the written AI policy into enforced rules

This item serves GV.PO, which expects policy to be established and communicated, and GV.RM for risk appetite.

A signed PDF evidences the communication half. Enforcement evidences that the policy is in force, and the artifact is a set of dated denials with the rule named in each one. An assessor reading a quarter with zero enforcement events will ask whether anything is being evaluated.

Done when: a deliberately non-compliant test request is denied, and the denial record names the rule that produced it.

5. Set the failure mode to deny

This item serves PR.AA and GV.RM together.

Ambiguity resolves one of two ways and only one is defensible in a report. Fail closed when classification is uncertain, the destination is unregistered, or the policy service is unreachable.

Done when: disabling the policy service in staging stops AI traffic instead of passing it through.

6. Monitor the payload, not the flow

This item serves DE.CM, which expects continuous monitoring of assets for anomalies and adverse events.

TLS to a provider API leaves a flow record holding a destination, a byte count, and a timestamp. That evidences connectivity while the content stays opaque, which is why network telemetry offered against DE.CM for AI assets gets discounted.

Done when: a per-request record exists containing the prompt content, the classification, the destination and model version, and the response disposition.

7. Record the response as well as the request

This item serves DE.CM and PR.DS on the return path.

Sensitive data leaves in prompts and arrives in responses, and where a response feeds an automated process it becomes external input entering a trusted context. The provider's safety documentation covers the provider's environment and stops at the API boundary.

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

8. Move the record off the calling application's write path

This item serves DE.AE, which expects adverse events to be analysed on evidence that holds up.

A log written by the component under review sits in the same trust domain as the thing it attests to. Selective logging of the successful path, modification by the failing component, and loss on crash between the model response and the commit all become available. The argument sits in full 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.

9. Prove you can answer a blast-radius question

This item serves RS.AN for incident analysis and RC.RP for recovery plan execution.

The question is always the same shape: during this window, which principals sent what to which endpoints. Run it as a drill on a random past date rather than discovering the answer during an incident.

Done when: a worked example exists for an arbitrary 24-hour window in the last quarter, produced from one store.

10. Reconcile providers against the approved list every month

This item serves GV.SC, which expects suppliers to be known, assessed, and monitored.

Item 1 was a snapshot. This is the recurring control that catches the endpoint a team added in March, and it is the artifact GV.SC actually wants, since a model provider receiving prompts in real time is a supplier with a live data flow rather than a procurement record.

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

What these ten items leave out

Ten items cover the categories where AI traffic lands. A CSF 2.0 Profile spans considerably more than that, and pretending otherwise would send a team into an assessment carrying a gap they had been told was closed.

GV.RR for roles and authorities, GV.OV for oversight, and PR.AT for awareness and training are organisational work with their own owners. ID.RA for risk assessment methodology and ID.IM for improvement are programme functions. PR.PS for platform security and PR.IR for infrastructure resilience reach far past AI traffic. RS.CO for response communication, including regulatory notification, is a legal and communications process. Model validation and training data provenance belong to the teams who build and select models.

My candid view on ordering: nearly every team starts at item 6, because turning on logging feels like progress and needs nobody else's approval. Records generated before item 2 is done carry a service account in the identity field, which buys a year of storage costs and an artifact that answers a question nobody asked. Items 1 and 2 come first even though they are the two that depend on somebody else's roadmap.

DeepInspect

This is the gap DeepInspect closes across items 2 through 10. 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.

Because the per-decision record is written by the enforcement layer rather than by the calling application, item 8 becomes a configuration rather than an architecture debate, and items 6, 7 and 9 read from the same store. The category mapping and the evidence walkthrough cover the Function-by-Function detail. Book a technical deep dive at deepinspect.ai.