What Is NIST IR 8596?

NIST released the preliminary draft of their Cyber AI Profile (IR 8596) in December 2025. If AI is anywhere in your environment (and at this point it probably is) it’s worth understanding what it says.

The Cyber AI Profile is not a new framework. It’s a CSF 2.0 overlay that applies what most security teams are already working with to three specific problems: securing AI systems, using AI to enhance your defences, and defending against adversaries who are using AI to attack you. It sits alongside the CSF, AI RMF, and ISO 27001 rather than replacing them.

The challenge is that the document is dense and not easy to navigate. I’ve been working through it and built an Excel workbook to help make the recommendations more accessible. More on that at the end of this post.

Breaking Down the Numbers

The Profile maps recommendations across all six CSF 2.0 functions, each tagged as either General, High, Moderate, or Foundational priority.

PROTECT has the most High-priority recommendations (22), followed by IDENTIFY (17) and GOVERN (15).

If you’re trying to work out where to focus first, PROTECT is the answer.

The General Themes

A few things come up repeatedly across the document regardless of which function or focus area you’re looking at.

AI accelerates the impact of gaps that already exist. Configuration drift, incomplete logging, weak change management. None of this is new, however, the use of AI means the consequences of ignoring these things move faster and at greater scale than before.

The fundamentals still matter most. Most of the High-priority recommendations aren’t exotic AI-specific controls. They’re established security practices that need to be deliberately extended to cover AI assets and AI-enabled threats.

Human-in-the-loop is a consistent requirement. The Profile doesn’t position AI as a replacement for human judgement. AI handles volume and speed; humans retain accountability for decisions and escalation.

Risk tolerance needs more frequent revisiting. The AI threat landscape is changing faster than most organisations update their risk appetite statements. The Profile treats risk reassessment as an ongoing activity rather than an annual one.

General Recommendations

These apply across all three focus areas:

• Update your risk appetite and tolerance statements to explicitly include AI-related risks, and review them more frequently than your standard cycle
• Assign clear human accountability for every AI system in your environment, including automated and agentic systems
• Establish AI-specific incident categories because adversarial inputs, data poisoning, and model exploitation don’t map cleanly to existing incident taxonomies
• Communicate the capabilities and limitations of AI systems to the people using them, including how to identify when the system is wrong and what to do about it
• Actively track AI legal and regulatory obligations as the compliance landscape is moving quickly

Secure: Protecting AI System Components

Secure is about treating your AI stack as an asset class with its own attack surfaces, not just an add-on to your existing environment.

• Expand your asset inventory to include models, training data, prompts, hyperparameters, and inference configurations
• Version and track all AI configurations because model settings, prompts, thresholds, and guardrail rules need configuration management just like source code
• Extend vulnerability management to explicitly cover AI frameworks, libraries, and hardware
• Enforce strict code execution controls as unvetted third-party libraries and AI dependencies are a primary entry point for supply chain attacks
• Implement data integrity controls for training data, since poisoned data is one of the most difficult AI attacks to detect after the fact

Defend: Using AI to Enhance Your Defences

Defend is about incoroporating AI to mature or enhance an organisation’s existing defences and controls. This is where the opportunities are, but only if the implementation is done carefully.

• Use AI to analyse logs at scale with human confirmation before acting on findings
• Extend your SIEM and logs to capture AI-specific fields including model version, confidence score, inference time, and whether responses matched policy. Without these, incident investigations will have blind spots
• Apply AI to vulnerability prioritisation so early warnings surface before incidents occur
• Use AI to accelerate compliance activities such as summarising requirements, mapping controls, and monitoring for policy violations
• Guard against your own defensive AI tools being manipulated by building in confidence thresholds and HITL checks to protect against model drift and hallucination

Thwart: Defending Against AI-Enabled Attacks

Thwart talks to the actions that organisations should take to account for the rising use of AI by threat actors. This is the least mature area for most organisations and arguably where the most risk sits right now.

• Update your threat model to include AI-specific techniques such as prompt injection, model evasion, adversarial inputs, jailbreaking, and deepfake-enabled social engineering
• Move to continuous monitoring because AI-enabled attacks can generate millions of probes in seconds, designed to blend in or overwhelm detection rules built for human-speed threats
• Subscribe to AI-specific threat intelligence as MITRE ATLAS and OWASP LLM Top 10 are the primary references and traditional CTI feeds won’t surface AI attack techniques reliably
• Revisit your risk tolerance for AI-enabled threat scenarios, since the speed and scale of these attacks may require different response thresholds
• Plan for AI-generated content attacks as phishing and social engineering are becoming harder to detect at the human layer

Three Recommendations Worth Examining More Closely

Recommendation #1: Revisiting Your Risk Tolerance for AI-Enabled Threats

This recommendation sounds straightforward: review your risk appetite and update it to account for AI-enabled threats. In practice it surfaces a contradiction most organisations haven’t resolved.

Security programmes typically operate with a low tolerance for cybersecurity incidents. But those same organisations have given their business units a high tolerance for AI experimentation i.e. deploying tools quickly, often ahead of any security review. Those two positions are in direct conflict, and most organisations have simply let both coexist without acknowledging the gap.

Reconciling them practically means three things:

• Define a separate risk appetite for AI adoption: what data AI tools can access, what approval is needed before deployment, what monitoring is required from day one to control the risk and speed of AI adoption
• Assume AI tools are already in your environment whether approved or not, and build your posture around that reality. This might mean putting in place initial detection and monitoring and DLP use cases to alert on accidental or malicious leakage of known sensitive information
• Include AI tool usage in your acceptable use policy with clear guidance on what is and isn’t permitted that gives your security team a basis for enforcement
• Set explicit escalation criteria for AI-related incidents that reflect where your organisation actually is, rather than applying a blanket low-tolerance position your business units are already operating outside of

The point isn’t that experimentation is wrong. It’s that your risk tolerance statement needs to reflect what the organisation is actually doing.

Recommendation #2: Closing the Logging Gap for AI Systems

Most teams won’t have a purpose-built AI monitoring pipeline in place yet. Good news is you don’t need one to start closing the gap. Here’s what you can do with what you likely already have:

• If you’re using Microsoft Copilot or similar enterprise AI tools, the unified audit log is already capturing interaction data. Most teams haven’t turned this on or aren’t ingesting it into their SIEM.
• If AI tools are calling external APIs, your proxy or firewall logs will show outbound requests. Flag large or frequent outbound payloads to known AI endpoints as a detection rule. It won’t capture response content but it will surface unusual usage patterns.
• At the application layer, most AI integrations will have their own logging. Work with whoever owns the application to confirm what’s being captured and whether it’s being retained anywhere. In most cases it exists but nobody is monitoring it.
• For DLP, review whether your existing rules would catch an employee pasting a sensitive document into an AI prompt. Most were written for email and file transfer and they likely won’t trigger on an API call. That’s a rule update, not a new tool.

None of this is a complete solution. But it moves you from having no visibility into AI interactions to having some, which is where most organisations need to start.

Limitations of the Draft Recommendations So Far

One thing worth calling out is that not all the recommendations carry the same weight. In the Thwart focus area especially, some entries read more like observations than actionable guidance.

Statements like “new risk tolerance recommendations may be needed with emerging AI-enabled threats” and “the scale and speed of AI-enabled attacks may challenge cybersecurity detection and monitoring systems” are directionally correct but don’t tell you what good looks like or how you’d know if you’d done enough.

While the document openly acknowledges it is a preliminary draft and invites the community to help fill the gaps, it is worth acknowledging that even prominent cyber security authorities and bodies like NIST do not have all the answers yet. The Secure and Defend focus areas are considerably more developed than Thwart, and if you’re using this document to build a programme, that’s where you’ll get the most traction right now.

The final version will be worth revisiting when it drops. In the meantime, we’re already working with customers to think through AI risks and build practical approaches to get ahead of them.

Work Through It Yourself

The document has over 200 recommendations across six functions and three focus areas.

I built an Excel workbook that maps all of the recommendations by function, priority, and focus area so you can filter down to what matters for your context and use it as a starting point for a gap assessment against your existing controls.

Download the workbook here.

If you work through it and want to talk about what you find, feel free to reach out.

Contact Us