Does NIST CSF 2.0 cover AI systems?

It covers them the same way it covers everything else, through outcomes rather than technologies. CSF 2.0 contains no AI-specific subcategories, and an organisation running AI traffic is expected to meet the existing outcomes under GV.SC, ID.AM, PR.AA, PR.DS, DE.CM, DE.AE and RS.AN for that traffic. NIST publishes the AI Risk Management Framework separately for AI-specific risk.

What changed between CSF 1.1 and CSF 2.0?

The most significant change was the addition of GOVERN as a sixth Function when 2.0 was released on 26 February 2024. GOVERN sits at the centre of the Framework and informs how IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER are implemented. CSF 2.0 also broadened the intended audience beyond critical infrastructure and expanded supply chain risk management.

Which CSF category does AI access control fall under?

PR.AA, which covers identity management, authentication, and access control. The outcome expected is that access is granted to authenticated identities commensurate with assessed risk, which for AI traffic means the authorization decision has to reference the principal who originated the request rather than the service credential the application happens to call with.

How does CSF 2.0 relate to the NIST AI RMF?

They answer different questions and are designed to be used together. CSF addresses cybersecurity outcomes across an organisation. The AI Risk Management Framework addresses risks arising from AI systems themselves, including fairness, validity, and explainability, which CSF does not attempt. A team running AI in production usually has obligations against both.

Can one control satisfy multiple CSF categories?

Frequently, and AI traffic is a clear case. A per-decision record produced on the request path supplies the PR.AA authorization evidence, the DE.CM monitoring data, the DE.AE analysis input, the RS.AN incident history, and the RC.RP blast-radius calculation. The economy comes from producing the record once, on the path, rather than reconstructing it from five systems afterwards.

Does CSF 2.0 require continuous monitoring of AI traffic specifically?

DE.CM asks for continuous monitoring of assets to find anomalies and adverse events, and model endpoints and the agents calling them are assets under ID.AM. The Framework does not name AI traffic, and an organisation that has inventoried those assets has accepted the monitoring outcome that follows for them.

NIST CSF 2.0 AI Controls Mapping: Where AI Traffic Lands Across the Six Functions

NIST released Cybersecurity Framework 2.0 on 26 February 2024, and the headline change was structural. Version 1.1 had five Functions. Version 2.0 added GOVERN and placed it at the centre of the wheel, informing how the other five get implemented rather than sitting alongside them.

That change is the reason CSF 2.0 handles AI better than most people expect from a framework written before hosted models entered daily use. CSF describes outcomes rather than technologies. An organisation running AI traffic between authenticated callers and model endpoints is expected to produce the same outcomes it produces for any other channel, and the categories that ask for them already exist.

I want to walk the categories where AI traffic actually lands, because the alternative is a mapping that shows every subcategory in green and tells a security programme nothing.

GOVERN: GV.SC and GV.RM

GV.SC covers cybersecurity supply chain risk management. A model provider joins your supply chain the moment a prompt reaches its endpoint, and the relationship is unusual in one respect: the data crosses in real time, continuously, in a payload assembled by an end user rather than by a procurement process.

The outcome GV.SC expects is that suppliers are known, assessed, and monitored. The artifact for AI traffic is a destination log naming every model endpoint actually called during the period, reconciled against the list of providers anyone approved. That reconciliation is where the interesting findings live. GV.RM asks that risk appetite be established and communicated, and a policy expressed as enforceable rules on the request path is the version of risk appetite that holds when somebody disagrees with it at 4pm on a Friday.

IDENTIFY: ID.AM

ID.AM asks that assets be inventoried and managed according to their criticality. Every model endpoint you call is such an asset. So are the agents calling them, which is the harder half, because an agent gets created by a developer in an afternoon and inherits a credential nobody registered against it.

An inventory built from a survey returns the endpoints people remember. An inventory built from observed egress returns the endpoints in use. Running both and reconciling them is shadow AI discovery arriving under an asset-management heading. Only 37% of organizations have any detection or governance policies in place for AI usage, according to Netwrix, which sets a realistic expectation for what a first pass finds.

PROTECT: PR.AA and PR.DS

PR.AA covers identity management, authentication, and access control, and it is the category that carries the most weight in an AI mapping. The outcome expected is that access is granted to authenticated identities commensurate with assessed risk.

Most AI deployments satisfy the first half and drop the second. A user authenticates at the application, and the outbound call to the model carries a single service credential holding the combined privileges of everyone who uses that application. Identity, in the sense PR.AA means it, stops one layer before the request leaves the boundary. Everything downstream then reports on a service account. This is the post-authentication gap: authentication answered who is calling, and nothing then answered what this caller may do with this content right now.

PR.DS covers data security, and prompt content is where it bites. Data classification designed for documents at rest reads a file. A prompt assembles fragments from several sources inside a context window and ships them as one HTTPS payload, which means classification has to happen on the request. IBM's Cost of Data Breach research found customer PII exposure reached 65% in shadow AI breaches against 53% across all breaches.

DETECT: DE.CM and DE.AE

DE.CM asks for continuous monitoring of assets to find anomalies and potentially adverse events. Applied to AI traffic that means monitoring the requests themselves rather than the network they travel over, because TLS to a provider API renders the payload opaque to anything sitting underneath it.

DE.AE covers adverse event analysis, and it depends entirely on what DE.CM captured. An analyst reconstructing an incident needs the prompt, the principal, the policy state in force, the endpoint, and the response. A record missing any one of those turns the analysis into an inference.

RESPOND and RECOVER: RS.AN, RS.MI and RC.RP

RS.AN covers incident analysis, and it reads from what DE.CM captured. RS.MI covers mitigation, and for AI traffic the mitigation that matters is the ability to change a rule and have it apply to the next request rather than to the next deployment. RC.RP covers recovery plan execution, which for an AI incident means knowing the exact blast radius: which principals sent what to which endpoints during the affected window.

All three read from the same store. The record produced under DE.CM is the input to RS.AN, the scope input to RC.RP, and the evidence that RS.MI worked.

The category mapping

What CSF 2.0 asks for that a gateway does not deliver

GV.RR for roles, responsibilities and authorities, GV.PO for policy, GV.OV for oversight, and PR.AT for awareness and training are organisational work. ID.RA for risk assessment methodology and ID.IM for improvement are programme functions. PR.PS covers platform security and PR.IR covers infrastructure resilience, both of which reach well past AI traffic. RS.CO covers response communication, including regulatory notification, which is a legal and communications process.

Naming those matters more in CSF than in a control catalogue, because CSF's Organizational Profile format invites a team to claim a target state across every category at once. A profile showing AI coverage across all six Functions from one component is a profile that will not survive its first tabletop exercise.

My candid view: the GOVERN function is the best thing in 2.0 and the most commonly reduced to a document exercise. Its point is that governance decisions constrain the other five Functions, and a governance decision about AI usage that lives in a PDF constrains nothing. The version that constrains is a rule that denies a request. Teams that write the policy first and the enforcement never have satisfied GV.PO and left PR.AA exactly where it was.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request and response it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass or block decision before the traffic reaches the model.

Against a CSF 2.0 profile that fills PR.AA with per-request authorization bound to the originating principal, PR.DS with classification inside the context window, DE.CM and DE.AE with a signed per-decision record the calling application never had custody of, and GV.SC with a destination log that reconciles against the approved provider list. The related NIST AI RMF mapping for AI gateways covers the AI-specific framework alongside this one. Book a technical deep dive at deepinspect.ai.