NIST Cyber AI Profile for securing AI systems: what it is and whether you need it yet
If a customer, contract or board is asking how your AI systems are secured under NIST CSF, the short answer is that NIST IR 8596 is still an initial preliminary draft, released on December 16, 2025, with comments due January 30, 2026. CSF 2.0 already applies to AI environments today, so you do not need to wait for the Cyber AI Profile to start mapping your AI systems to the Functions, Categories and Subcategories you already use. The draft will inform a later initial public draft, and the CSRC page lists no newer version, so treat its wording as provisional and do not write it into a contract as a final requirement.
The Cyber AI Profile is organized around the CSF 2.0 Functions, Categories and Subcategories, with three focus areas: *Secure* (securing AI system components), *Defend* (AI-enabled cyber defense) and *Thwart* (defending against AI-enabled cyberattacks). Confirm with the draft on the CSRC page which of these your own program needs to cover now. The practical starting point is an inventory of the AI systems you run, their components and their data flows, which the Identify Function already expects you to maintain. Then check how your current CSF Current Profile addresses those systems, without waiting for a profile to label them.
Your organization owns its AI controls. An implementation partner can help prepare systems, configuration records and evidence, but only an independent assessor or auditor issues any report or attestation, and NIST does not certify or endorse implementations. Ask any partner or assessor to state in writing which framework version and draft status they are assessing against, and to say how they will handle changes if the final profile differs from the current draft.
How the Secure, Defend and Thwart focus areas differ
Secure treats the AI system as an asset that needs protection. The question is whether the components an organization builds or buys, including models, training and fine-tuning data, prompts, retrieval sources, plugins, APIs and hosting environments, are inventoried, access-controlled, monitored and recoverable. The draft is organized around CSF 2.0 Functions, Categories and Subcategories, so Secure work falls mostly under Govern, Identify and Protect, with Detect where AI components produce logs.
- Component inventory: Identify asset management (ID.AM) covers listing models, datasets, pipelines and third-party AI services with their owners.
- Access and identity: Protect identity and access control (PR.AA) covers service accounts, API keys and model endpoints.
- Data protection: Protect data security (PR.DS) covers training data, embeddings and prompts at rest, in transit and in backups.
- Platform configuration and change: Protect platform security (PR.PS) covers model version control, configuration baselines and secure development of AI-enabled applications.
- Supplier and model provenance: Govern supply chain risk management (GV.SC) covers due diligence and contract terms for hosted models and AI services.
Illustrative evidence includes a model and dataset inventory export, access review records for AI endpoints, data lineage records, change tickets for model promotion and supplier due diligence files. Confirm the draft's current Subcategory wording before building evidence against it, because the initial preliminary draft will be revised.
Defend covers using AI inside the organization's own cyber defense, such as triaging alerts, correlating events or summarizing incidents. The concern shifts from protecting AI to governing how AI-assisted decisions affect detection and response. This work most often touches Detect (DE.CM and DE.AE), Respond (RS.MA and RS.AN) and Recover (RC.RP), because AI tools support monitoring, triage and analysis during an incident.
- Detection tuning: Adverse event analysis (DE.AE) covers how AI-assisted correlation and impact estimates are scored, and what gets suppressed.
- Analyst decision records: Incident management (RS.MA) covers triage and escalation, including when an analyst accepted or overrode an AI recommendation.
- Investigation records: Incident analysis (RS.AN) covers preserving the prompts, outputs and source data used in AI-assisted investigations so findings can be reviewed.
- Monitoring of the defense tools: Continuous monitoring (DE.CM) covers the activity, access and changes of the AI tools themselves.
- Validation of AI outputs: Improvement (ID.IM) covers exercises that test whether AI tools miss or misclassify events.
Illustrative evidence includes a change log for alert tuning, triage logs that record overrides, incident records with preserved AI inputs and outputs, and exercise after-action reports. Ask legal and records owners which retention rules apply to AI-generated analysis, since those rules are set by the organization and its obligations, not by the profile.
Thwart covers attackers who use AI to scale phishing, social engineering, vulnerability discovery or automated intrusion. The organization does not control the attacker's tools, so the work is anticipating these techniques and blocking them with existing controls tuned for them. This focus area touches Identify (ID.RA, for threat intelligence and vulnerability tracking), Protect (PR.AA and PR.AT, for verification and awareness) and Detect (DE.CM and DE.AE, for recognizing automated activity).
- Threat intelligence: Risk assessment (ID.RA) covers tracking AI-enabled attack techniques that are relevant to the organization's sector and suppliers.
- Verification against impersonation: Access control (PR.AA) and awareness (PR.AT) cover out-of-band checks for payment changes and credential requests, plus staff training on synthetic voice and video.
- Detection of automated attacks: Continuous monitoring (DE.CM) and adverse event analysis (DE.AE) cover high-volume reconnaissance and credential attacks that adapt quickly.
- Exposure management: Risk assessment (ID.RA) covers vulnerability tracking, with priority given to internet-facing assets that automated tools scan first.
- Scenario exercises: Improvement (ID.IM) covers tabletop exercises that include AI-generated phishing or fake vendor calls.
Illustrative evidence includes threat intelligence briefs that note AI-enabled techniques, written verification procedures, awareness training records, exercise reports and detection rule change logs. Confirm the current draft's Subcategory references before mapping these items, because the focus area wording may change in later drafts.
How CSF 2.0 already applies to AI systems today
CSWP 29 already treats artificial intelligence as an emerging technology risk and says the Functions, Categories and Subcategories apply to cloud, mobile and AI environments. The cards below show where AI systems fall across the six Functions, so organizations can start securing them with the existing CSF 2.0 Core while NIST IR 8596 is still in draft.
AI as an emerging technology risk
CSWP 29 names artificial intelligence as a contemporary example of emerging technology risk and points to the NIST AI Risk Management Framework. For AI systems, this means the risk decision belongs in the same enterprise risk process as other technology risks, not in a separate AI track. Check whether your risk register already records AI models, AI-enabled features and the third-party AI services you consume, with an owner for each.
Govern: AI in risk strategy and policy
The Govern Function sets the context, risk strategy, roles and policy that decide how AI is allowed into the business. Ask whether the organization's cybersecurity policy names AI systems, who may approve a new model or AI tool, and how that approval links to the organization's risk appetite. Govern is also where oversight of AI risk reaches the leadership team, which needs to see AI exposure alongside other enterprise risks.
Identify: inventory AI assets and data flows
The Identify Function covers asset management and risk assessment. For AI, that means inventorying models, training and fine-tuning data, prompts, retrieval sources, AI APIs and the supplier services behind them, then mapping how data moves between them. Without this inventory, the Protect and Detect outcomes cannot be applied to the AI components that matter most.
Protect: access, data and platform controls
The Protect Function covers identity and access, data security, platform security and technology infrastructure resilience. Applied to AI, these outcomes ask who and what can call a model, which data a model can read or return, how model-serving platforms are configured and patched, and whether AI workloads are segmented from sensitive systems. Confirm these controls against each AI component in the inventory rather than assuming the platform team covers them.
Detect: monitor AI activity and behavior
The Detect Function covers continuous monitoring and adverse event analysis. For AI systems, monitoring should reach prompts, model outputs, tool calls made by agents, and access to model endpoints, not only network and host logs. Check that logs from AI platforms reach the same monitoring pipeline as other systems and that analysts know which AI events count as adverse.
Respond and Recover: plan for AI incidents
The Respond and Recover Functions cover incident management, analysis, mitigation, recovery and communication. Test whether the incident response plan names AI incidents, such as a compromised model, poisoned data or a misused agent, and whether recovery covers restoring model artifacts, training data and configuration. Confirm that backups of AI assets are tested, since rebuilding a model may not be a simple restore.
What the OWASP LLM mapping in the Reference Tool shows
The NIST CSF 2.0 Reference Tool export lists the OWASP Top 10 for LLM Applications as an informative reference. Its 10 entries are linked to 77 of the 106 CSF 2.0 Subcategories. For a team running a large language model application, that link is a practical starting point: it shows which CSF outcomes the OWASP risk entries touch, so you can check whether your existing controls answer them. It is a map of where to look, not a record of what your organization has done.
Treat the mapping as a reference, not a certification or a claim of compliance. NIST states that it does not certify or endorse products, implementations or services, and an informative reference does not tell an assessor that your LLM application is secure. Each mapped Subcategory still has to be tested against your own architecture, including prompt handling, retrieval sources, tool and plugin permissions, output handling and the data your application can reach. Plan that testing as a separate activity with a named owner, and keep the results as evidence under the relevant Subcategories.
Before you rely on any row in the mapping, confirm it directly in the Reference Tool. Filter for the OWASP LLM entries, open each linked Subcategory, and check the wording and the version of the OWASP list against the document your team has adopted, because the mapping is only as current as the export you are reading. Record the date you checked and who checked it. Where a Subcategory you expected to see is missing from the links, record that gap in your gap analysis rather than assuming the control is covered.
How to start securing AI systems under CSF 2.0 before the final profile
This sequence lets an organization secure its AI systems today using the CSF 2.0 Functions it already has, so that its own inventory, risk picture, controls and test results are ready to map onto the Cyber AI Profile when NIST finalizes it. Each step produces a record the organization owns and can keep regardless of how the draft changes.
Inventory AI systems, data and dependencies
Start under ID.AM by listing every AI system in use or in development, including models, training and inference pipelines, agents, AI features inside SaaS products and the datasets, prompts, plugins and third-party APIs each one touches. Record the owner, the hosting location and which business processes depend on it. The output is an AI system inventory that is kept as part of the hardware, software, data and supplier asset records. The step is complete when the inventory is reviewed by IT, security and the business owners and every AI component has a named owner.
Assess AI-specific risk and threats
Under ID.RA, review each inventoried system for threats and vulnerabilities that are specific to AI, such as prompt injection, training data poisoning, model supply chain tampering, sensitive data leakage through outputs and excessive agent permissions. Estimate likelihood and impact and record the risk response for each. The output is an AI risk register entry per system, linked to the enterprise risk register. The step is complete when each entry names a risk owner and an accepted or planned treatment.
Set access and platform controls for AI
Under PR.AA and PR.PS, apply the same identity and configuration discipline to AI components that applies to other production systems. Define which people, services and agents may call a model, change its configuration or read its data, use least-privilege credentials and separate development from production. Harden the hosting platform, control which models, libraries and plugins may be installed and track changes through configuration management. The output is an access matrix and a platform baseline for each AI environment. The step is complete when access reviews and baseline checks show no unapproved identities or software in those environments.
Monitor AI runtime environments
Under DE.CM, extend continuous monitoring to model endpoints, vector stores, agent tool calls and the infrastructure that runs inference. Collect logs of prompts, tool invocations, data access and administrative actions where privacy rules allow, and set alerts for unusual volumes, unexpected tool use or outputs that expose protected data. Confirm which logs your monitoring platform can ingest from each AI service. The output is a monitoring specification and a log retention record. The step is complete when alerts are tested against a known abnormal event and the results are documented.
Test incident response and recovery for AI
Under RS and RC, write AI-specific scenarios into the incident response plan, such as a compromised model, a poisoned training set, a leaked prompt history or a misbehaving autonomous agent. Define how to isolate the system, preserve its logs and model artifacts, roll back to a known-good model version and restore its data from verified backups. Run a tabletop exercise, then record what failed. The output is an AI incident playbook and an exercise report with improvement actions tracked under ID.IM. The step is complete when the recovery steps have been demonstrated, not only written down.
Map results to the draft Cyber AI Profile
Once the first five records exist, compare them against the draft Cyber AI Profile's Secure, Defend and Thwart focus areas and the CSF 2.0 Subcategories it builds on. Note where a Subcategory has evidence, where it has a gap and where the draft's wording is still changing. Confirm the current status of NIST IR 8596 on the CSRC page before relying on it. The output is a gap list that becomes the input for a Target Profile. The step is complete when each gap has an owner and a decision to close it, accept it or defer it.
What to have in place before you map AI systems to the profile
The draft Cyber AI Profile is organized around CSF 2.0 Functions, Categories and Subcategories, so a mapping is only as good as the records behind it. The six items below are the records an assessor or internal reviewer will ask for first, and each card says how to check whether it exists and is current.
Current AI system inventory
List every AI system in use, built, or bought, including models embedded in SaaS products, internal copilots, and agents that call tools. For each entry, record the business purpose, the environment it runs in, the data it touches, and whether it is in production. This inventory is the object the Secure, Defend and Thwart focus areas act on. Check it by sampling three systems from a procurement list and one from a developer repository, then confirming all four appear in the inventory.
Named owners for each AI system
Each AI system needs one accountable owner who can approve changes, accept residual risk, and answer for incidents. Owners are distinct from the engineers who maintain the system. Without a named owner, Govern-related decisions about AI risk have no one to bind them. Check it by asking who approved the last model or prompt change and whether that person is listed as owner.
Documented data sources and training data handling
Record where each model's training, fine-tuning, retrieval and evaluation data comes from, who authorized its use, how it is classified, and how long it is kept. Data security outcomes under PR.DS apply to these datasets as they do to any other data. Check it by tracing one production model back to its data sources and confirming a written approval exists for each source.
Vendor and model supplier records
Keep a record for every model provider, hosting platform, and AI component supplier, including the contract terms on data use, the supplier's security documentation, and the model versions in use. Supplier risk belongs to the GV.SC subcategories. Check it by confirming each model version in production maps to a supplier record and that the contract addresses data retention and incident notice.
Incident response coverage for AI systems
Confirm that the incident response plan names AI-specific scenarios such as prompt injection, data leakage through model output, model poisoning, and misuse of an agent's tool access. Responders need to know how to disable a model or roll back a version without taking down the whole service. Check it by reading the playbook and finding a documented step for disabling one AI component, with a named responder who has tested it.
Risk register entry for AI
Each AI system should appear in the enterprise cybersecurity risk register with its threats, likelihood and impact estimates, the controls relied on, and the accepted residual risk. This is the link between the inventory and the risk decisions that GV.RM and ID.RA describe. Check it by confirming every inventory entry has a register line and that the register's review date falls within your stated review cycle.
Who owns the controls, who prepares the evidence and who assesses
The organization owns its AI controls and every risk decision that comes out of the Cyber AI Profile. That includes deciding which AI systems are in scope, which Subcategories apply to each model, agent and data pipeline, what residual risk it accepts, and who is accountable for each outcome. NIST's draft is a set of outcomes to be prioritized and tailored, not a checklist that transfers responsibility to a vendor. A security or AI governance lead should own the target profile for the AI estate, and the business owner of each AI system should sign off on the risks it carries. Those decisions cannot be delegated to an implementation partner.
An implementation partner such as DeployOpen can prepare the systems, configurations and evidence that support those decisions. In practice that work covers hardening the infrastructure that hosts self-hosted AI components, setting up logging and monitoring for model endpoints and retrieval pipelines, documenting asset inventories and data flows, and producing the records an assessor will ask to see. Engagements of this kind are fixed-scope, so the organization should agree in writing which systems, deliverables and timelines are included before work starts. A partner's output is evidence prepared for the organization; it does not by itself show that controls operate as described.
Only an independent auditor, assessor or certification body issues reports or certificates. NIST is explicit that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim that an AI system is "certified to the Cyber AI Profile" should be treated with suspicion, because no such certificate exists today. If a customer or regulator asks for independent assurance, the organization should confirm with the assessor which standard or report type will be issued and what the assessor will test. Before engaging anyone, check the current status of the draft at the NIST IR 8596 initial preliminary draft page, since the document may change before it is finalized.
Questions buyers ask about the Cyber AI Profile
Is the NIST Cyber AI Profile final?
No. The Cyber AI Profile, published as NIST IR 8596, was released as an initial preliminary draft on December 16, 2025. Comments were due January 30, 2026, and NIST said those comments will inform an initial public draft. The CSRC page lists no newer version, so treat the document as a draft that may change. Before planning work around it, check the NIST IR 8596 draft page for the current status and any later release. Plan your AI security program on CSF 2.0 and your existing AI risk controls, then map the final profile into them once it is published.
Can we claim compliance with the Cyber AI Profile?
Not as a certification, and not against a draft. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary and describes outcomes, so an organization can say it uses or aligns to a profile, but no body issues a NIST certificate for it. Any statement of alignment should name the profile version, describe your own Current and Target Profiles, and be backed by evidence you can show a customer or regulator. Confirm with your legal or contracts team how a customer contract defines alignment before you use the phrase in a bid.
Does NIST CSF 2.0 already cover AI systems?
Yes, in principle. CSWP 29 names artificial intelligence as an example of emerging technology risk, points to the NIST AI Risk Management Framework, and says the Functions, Categories and Subcategories apply to all ICT an organization uses, including cloud, mobile and artificial intelligence environments. That means you can already assess AI systems against Govern, Identify, Protect, Detect, Respond and Recover without waiting for the profile. The Cyber AI Profile adds more specific focus areas on top of that baseline. Expect your first gap analysis to show gaps in asset inventory and data flow mapping for AI components, which the Identify Function covers.
What does the OWASP mapping in NIST's Reference Tool add?
It links the OWASP Top 10 for LLM Applications to the CSF 2.0 Core, so engineers can see which Subcategories address LLM application risks. According to NIST's Reference Tool export, the 10 OWASP entries map to 77 of the 106 CSF 2.0 Subcategories. The mapping is a starting point for control selection and evidence planning, not a verdict on your application. Use it to pick which Subcategories to test, then decide your own controls and evidence for each. Confirm the mapping version in the Reference Tool before you cite it, since NIST updates informative references separately from the framework document.
Do we need an external assessor for the profile?
Not for internal use, but an independent assessor is the only party that can issue a formal assessment report. Organizations may run a self-assessment against their chosen profile, and NIST does not require outside involvement. If a customer, insurer or regulator asks for independent evidence, that role belongs to an auditor or assessor the requesting party accepts. An implementation partner can prepare systems, configuration evidence and gap findings, but it does not issue reports or certificates. Ask your reviewer which independent evidence they will accept before you commission any work.
What should we ask a consultant before hiring one?
Start with scope, deliverables and who owns the result. Ask for a written scope that names which CSF Functions, Categories and AI systems are covered, and whether the work targets the draft profile or your own Target Profile built on CSF 2.0. Ask who issues any report, since only an independent auditor or assessor can. Ask how they treat the draft's changes, what evidence they will hand over, and whether they will support a later update. Request a quote built from that written scope, and compare proposals on the same deliverables rather than on day rates alone.
How DeployOpen works on this
DeployOpen helps organizations prepare the AI systems, controls and evidence that a Cyber AI Profile assessment would examine, using self-hosted open-source platforms inside the client's own infrastructure. We do not issue assessments, attestations or certifications, which remain the role of the organization and its independent reviewers.
How we scope
- We agree a written scope listing which AI systems, components and environments are in the review.
- The scope states which Secure, Defend and Thwart outcomes the engagement addresses and which it leaves to the organization.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work starts.
How we build
- We map the AI system inventory and its supporting infrastructure to CSF 2.0 Categories and Subcategories.
- We configure self-hosted platforms for logging, access control, data protection and monitoring of AI workloads.
- We test controls against the agreed scope, including AI application and API security testing where contracted.
How we hand over
- We deliver control documentation, configuration records and test results mapped to the agreed Subcategories.
- We document ownership of each control so the organization can answer assessor questions directly.
- We confirm with the organization and its reviewer which evidence formats and retention periods they require.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can keep AI system inventories and evidence current as the NIST IR 8596 draft moves toward a later version.
- Organizations should confirm with their own assessor which evidence they will accept before the scope is signed.
