NIST Cyber AI Profile: Three Focus Areas and Evidence

The NIST Cyber AI Profile gives a security program three different jobs. Secure the AI systems the organization adopts and use AI deliberately in cyber defense. Prepare for attackers who use AI. NIST introduced that structure in the preliminary draft of NISTIR 8596, published on December 16, 2025, as an application of the current Cybersecurity Framework.

A useful implementation should show the current state and the target outcome. It should also identify the owner and the evidence behind every claimed result. A list of CSF references alone will look tidy in a review and say very little about what production traffic can do.

TL;DR

• The preliminary NIST Cyber AI Profile organizes work into the Secure and Defend focus areas. Thwart is the third.
• It applies CSF outcomes to AI and sets strategic priorities across the organization. Product checks and technical control selection happen in supporting work.
• Build a current profile and choose target outcomes. Then assign owners and name the evidence that proves each outcome.
• Keep the AI RMF and COSAiS control overlays connected to the profile without collapsing their different jobs.

NIST Cyber AI Profile scope

NIST's December 16, 2025 release describes NISTIR 8596 as a preliminary draft. The publication applies CSF 2.0 to the intersection of cybersecurity and AI. NIST said the draft would move through further public development, so a control register should identify the version it uses rather than label the preliminary text as a final standard.

The three focus areas overlap inside ordinary production systems. An organization may deploy an AI assistant in its SOC, which creates a Defend use case and an AI system that needs protection under Secure. An attacker may poison the content the assistant retrieves, bringing Thwart into the same workflow. One row in an inventory can therefore connect to outcomes across all three areas.

I would reject any profile exercise that assigns the entire document to an "AI team." CSF outcomes need accountable owners in security operations and platform engineering. IAM and data governance also have duties, as do incident response and risk. A shared label hides the handoffs that fail during an incident.

Secure covers the AI system itself

Secure starts with the AI components and data flows the organization introduces. It also covers their identities and dependencies. For an HTTP-based LLM application, the architecture record should identify the authenticated caller and the application sending the request. It should also name the model route and retrieved data sources. The same record should cover tool endpoints and the policy decision point, plus systems that retain evidence.

The NIST AI RMF implementation guide helps teams organize broader AI risk work through GOVERN, MAP, MEASURE, and MANAGE. The Cyber AI Profile brings a cybersecurity lens through CSF 2.0. These artifacts should reference each other, while each retains its own purpose and owner.

At the request boundary, Secure evidence can include an approved route inventory and identity propagation specification. Add the active policy version and a sample allow decision. Include a sample blocked decision and the response when a dependency fails. Put one real request ID on the review-room screen. Ask the IAM team to find its identity record for that event. The gateway team should produce the policy decision and the application team should produce its request record. Missing joins become visible within minutes.

Defend governs AI used in security operations

Defend covers AI used to support cybersecurity work. The NIST profile announcement describes this area as identifying opportunities to enhance cybersecurity while understanding the challenges introduced when AI supports defensive operations. That wording calls for a controlled operating model, not a blanket instruction to add models to the SOC.

Start with one bounded task, such as summarizing an alert or proposing investigation steps. Record the approved inputs and prohibited data. Name the model destination and expected human review, then set the action boundary. A generated recommendation should retain links to the underlying alerts and telemetry. Analysts also need a clear signal when the model lacks enough context or returns material that conflicts with the system of record.

The AI governance framework can hold the use-case approval and review cadence. Cyber controls should then prove how that approval reaches production. Useful evidence includes route configuration and access policy. It should also include evaluation results and analyst sign-off rules, plus sampled decisions. A slide that says "human in the loop" fails this test unless it names the human and the decision they review. It must also identify the record created by that review.

Thwart addresses AI-enabled attacks

Thwart concerns resilience against attackers using AI. NIST separates this work because adoption risk and adversary capability create different planning questions. A target profile may prioritize faster analysis of malicious activity and protection against automated attack volume. Controls for adversarial inputs aimed at AI-enabled defenses may be another priority.

The evidence still needs a specific system boundary. For a routed LLM call, defenders can test prompt injection and prohibited data movement. They can also test identity misuse and disallowed model destinations. A separate test should verify fail-closed behavior. Endpoint compromise, credential theft, local model execution, and attacks that bypass the inspected HTTP path require controls elsewhere. The profile should show those owners rather than shade the entire architecture diagram green.

NIST's May 22, 2025 explanation says community profiles provide a shared taxonomy for priorities and outcomes. It also distinguishes profiles from use-case-focused, threat-informed SP 800-53 control overlays. That distinction keeps Thwart planning honest: the profile sets desired outcomes, while technical guidance and local design decide how systems meet them.

Build the profile as an evidence register

A practical current-state record should name the AI system and business purpose. It should identify the owner and deployment boundary, along with applicable outcomes from the three focus areas. For each outcome, record the present implementation and its evidence source. Mark gaps with an accountable owner and an acceptance date. Then create the target profile that security leadership has approved.

The evidence field deserves precision. "Gateway logs" is too broad. "Decision record for request 7f3a, containing the supplied user identity, model route, policy version, classification, action, and timestamp" gives an assessor something they can retrieve and test. Evidence for model evaluation and training data belongs in their respective systems. The same applies to incident response and human approval.

The existing COSAiS overlay mapping addresses a neighboring technical question. COSAiS tailors SP 800-53 controls for securing AI systems. The Cyber AI Profile uses CSF 2.0 to frame organizational cybersecurity outcomes across a wider scope. Use the profile to decide the destination, then use overlays and architecture standards to specify technical controls.

DeepInspect

DeepInspect supplies evidence for the HTTP AI request boundary inside the Secure focus area. It sits as a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. For deliberately routed traffic, it evaluates identity-aware policy before forwarding the request and writes a per-decision record with the supplied context, policy version, action, and timestamp.

That record can support current-state assessment and show that a target request-boundary outcome operates in production. DeepInspect leaves model evaluation and training-data governance to their respective control owners. The same applies to endpoint security and SOC decision quality, along with attacks outside the routed HTTP path.

Book a demo today.