NIST CSF 2.0 AI Audit Evidence: The Artifacts an Assessor Reads Per Function

An assessor working a CSF 2.0 profile asks a question no control catalogue quite forces: show me. Cybersecurity Framework 2.0, released 26 February 2024, states outcomes rather than requirements, so the conversation moves to evidence faster than it does under a prescriptive standard. A team claiming a target Tier for PR.AA gets asked what produced that claim.

For AI traffic, four questions carry the whole assessment. Which principal called which model. What the prompt carried across the boundary. Which rule governed the decision at that moment. Which record proves the first three, and who wrote it.

That last clause decides everything, and it is the part most AI programmes have not thought about.

GOVERN: the evidence that a policy is in force

GV.PO asks that cybersecurity policy be established and communicated. Communication takes about five minutes to evidence, since a signed PDF and a training completion report cover it.

Being in force is harder. The artifact that demonstrates it for AI traffic is a set of denied requests: dated records showing that traffic which violated the stated policy was stopped, with the rule named in each record. A policy with zero enforcement events across a quarter tells an assessor one of two things, either that the population is exceptionally well behaved or that nothing is being evaluated, and they will ask which.

GV.SC covers supply chain risk management, and the artifact is a destination log naming every model endpoint actually called during the assessment period, reconciled against the approved provider list. The reconciliation is the evidence, not the allowlist.

IDENTIFY: the evidence that the inventory is real

ID.AM expects assets inventoried and managed by criticality. Two documents get offered here and only one survives.

A registry maintained by hand lists the endpoints somebody remembered to register. An inventory derived from observed egress lists what is being called. An assessor who has done this before asks for both and reads the difference. Netwrix found that only 37% of organizations have any detection or governance policies for AI usage, which is a reasonable prior for how the first reconciliation goes. The method is shadow AI discovery presented under an asset-management heading.

PROTECT: the evidence that identity reached the decision

PR.AA expects access granted to authenticated identities commensurate with risk. The artifact is a per-request authorization record naming the principal, the role, the rule applied, and the outcome.

Sample one of those records and look at the identity field. In most AI deployments it holds a service account, because the user authenticated at the application and the outbound call carried one system-level API key. The authentication evidence is genuine and it answers a different question from the one PR.AA asks. Every artifact produced downstream inherits that substitution, which is why this single field is worth checking before anything else in the assessment. The mechanism is the post-authentication gap.

PR.DS expects data protected in transit and in use. The artifact is a classification decision recorded against the request, made on the assembled context window rather than on a source document, plus the disposition that followed.

DETECT: the evidence that monitoring covers the payload

DE.CM expects continuous monitoring of assets for anomalies. Network telemetry gets offered for this and falls short in a specific way worth stating precisely: TLS to a provider API means the flow record shows a destination, a byte count, and a timestamp, with the payload opaque. That evidences connectivity rather than content.

The artifact that satisfies DE.CM for AI traffic is a per-request record containing the prompt content, the classification, the destination and model version, and the response disposition. DE.AE for adverse event analysis reads the same store, and an analyst reconstructing an incident from records missing any one of those fields is producing an inference and should say so in the report.

RESPOND and RECOVER: the evidence that scope is knowable

RS.AN expects incident analysis to be performed. RC.RP expects recovery plan execution. Both depend on answering a blast-radius question: during the affected window, which principals sent what to which endpoints.

That question is answerable from a per-decision store in one query and unanswerable from application logs in any number of queries, because the application logs were written by systems that each recorded their own view. The evidence an assessor wants is a worked example: pick a date range, produce the list.

The property that decides whether evidence counts

Every artifact above is produced by something. Ask three questions about that something.

Start with who wrote the record. Then ask what custody the system under assessment had over it, and whether that system could have shaped what the record says. A log written by the application that made the AI call sits inside the same trust domain as the thing it attests to, and three failure modes follow: selective logging of the successful path, modification by the component that failed, 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.

CSF does not name write-path independence anywhere, and an assessor holding a record produced by the system under review will still discount it. That is a professional instinct rather than a framework requirement, which makes it harder to argue with.

The evidence set

Eight rows, one store, one query each.

My candid view: CSF 2.0's outcome-based drafting is the right design and it creates a specific failure mode in AI programmes. Because no subcategory says "log every model call," teams write a target Profile claiming PR.AA and DE.CM coverage on the strength of their SSO deployment and their network monitoring, both of which are real controls that stop at the point AI traffic gets interesting. The gap surfaces during the first incident rather than during the assessment, which is the expensive order.

DeepInspect

This is the evidence layer a CSF 2.0 assessment reaches for when AI traffic is in scope. 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, and writes a signed, tamper-evident per-decision record.

Because the record is written by the enforcement layer rather than by the application under assessment, it answers the custody question before an assessor raises it. The category-level mapping covers which Functions each artifact serves. Book a technical deep dive at deepinspect.ai.