The NIST AI Risk Management Framework: Mapping the Core Suite to Security Practice

1. Introduction

Practitioners, vendors, and policymakers increasingly treat “the NIST AI security framework” as if it named a single control baseline. It does not. NIST has published a family of voluntary AI documents since 2023, and the phrase is used for at least three different things: the Artificial Intelligence Risk Management Framework (AI RMF) itself (NIST AI 100-1); the later Cybersecurity Framework Profile for Artificial Intelligence (NIST IR 8596); and, more loosely, the union of those documents with adversarial-machine-learning guidance (NIST AI 100-2) and ordinary cybersecurity controls (CSF 2.0, SP 800-53). Conflating them produces two failure modes. Teams that wanted a security program implement only governance workshops. Teams that wanted trustworthy AI implement only model-hardening checklists.

The AI RMF was released on 26 January 2023 as NIST AI 100-1, under a mandate in the National Artificial Intelligence Initiative Act of 2020. It is voluntary, rights-preserving, non-sector-specific, and use-case-agnostic. Its object is not an information system in the SP 800-37 sense. Its object is a socio-technical AI system, and its success criterion is trustworthiness rather than confidentiality, integrity, and availability alone. NIST did not ship the framework as an isolated PDF. It shipped a companion Playbook, a Roadmap of follow-on work, a detailed account of trustworthy-AI characteristics inside the core document, and a community catalog of implementations and crosswalks via the Trustworthy and Responsible AI Resource Center. Those five resources are the original AI RMF program. Everything else in the NIST AI stack — the Generative AI Profile (AI 600-1), the draft Cyber AI Profile (IR 8596), the adversarial taxonomy (AI 100-2), and profiles for critical infrastructure — is a specialization that attaches to that program.

This paper is a map, not an evaluation of models and not a claim of empirical discovery. We read the public NIST corpus as of August 2026 and the standards it is designed to sit beside. Three observations structure the rest of the paper.

The suite is the framework. AI RMF 1.0 is Part I (how to frame AI risk and what “trustworthy” means) plus Part II (four functions with categories and subcategories). The Playbook, Roadmap, characteristics discussion, and community catalog are how NIST expected organizations to operationalize, extend, and share that core. Treating AI 100-1 as the entire program understates what NIST published in the first quarter of 2023.

Security is a characteristic, not the frame. NIST lists seven trustworthy-AI characteristics: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed. Secure and resilient is one row in that list. The four functions — Govern, Map, Measure, Manage — are how an organization pursues all seven, including the tensions among them.

Cybersecurity instruments plug in; they do not replace. NIST’s own commentary on the Cyber AI Profile is that CSF 2.0, the AI RMF, and the Profile are meant to be used together. AI 100-2 supplies attack vocabulary for Measure and Manage. SP 800-53 remains the control catalog for systems that need one. ISO/IEC 42001 and the EU AI Act are adjacent regimes, not NIST documents, and should be crosswalked rather than merged.

Contributions. This paper makes four contributions:

1. We reconstruct the original AI RMF resource suite and show how the Playbook, Roadmap, trustworthiness characteristics, and community catalog relate to AI 100-1.
2. We locate cybersecurity inside the seven-characteristic model and spell out what “secure and resilient” does and does not cover.
3. We map later NIST AI-security instruments onto the four functions, including CSF 2.0, IR 8596, AI 100-2, AI 600-1, and the critical-infrastructure profile concept note.
4. We give a usage procedure and a worked example for an agentic language-model system, with failure modes that follow from treating any one document as the whole program.

2. Background: AI risk is not information-system risk

The classical NIST Risk Management Framework (SP 800-37) authorizes an information system. It categorizes the system, selects SP 800-53 controls, assesses them, authorizes operation, and monitors. That loop remains necessary whenever an AI system runs on federal or otherwise controlled infrastructure. It is not sufficient for AI, and NIST says so: AI risks differ from traditional software risks in kind, not only in degree.

Three differences matter for security teams.

The unit of risk is socio-technical. An AI system’s behavior depends on training data, evaluation data, prompts, tools, users, and downstream decision processes. A model that is confidential and available can still be unfair, unsafe, or strategically non-compliant. The AI RMF therefore treats impacts on individuals, groups, communities, organizations, and society as in-scope, not as externalities to be handled by a separate ethics office.

Trustworthiness characteristics conflict. A system that is easier to explain may leak more about training data. A system that refuses dual-use queries may be less “helpful” on a developer-specified objective. NIST lists this tradeoff problem as a Roadmap priority rather than pretending the characteristics form a free lunch. A security program that optimizes only adversarial robustness can move risk into fairness, privacy, or safety without reducing total harm.

The framework is voluntary and outcome-based. AI 100-1 does not contain a numbered control catalog. It contains functions, categories, and subcategories that describe outcomes (“AI risks are identified and documented”) rather than mechanisms (“deploy input filtering X”). The Playbook suggests actions; it is explicitly not a checklist to complete in order. Organizations that need an auditable management system are expected to look to ISO/IEC 42001 or to bind the AI RMF to an existing RMF authorization boundary — not to invent a certification out of AI 100-1 itself.

These facts explain the naming confusion. Security engineers hear “framework” and reach for CSF or SP 800-53. AI governance teams hear “framework” and reach for AI 100-1. Both instincts are half right. The rest of this paper is about keeping them attached to the same system rather than substituting for each other.

3. The original AI RMF resource suite

NIST’s January 2023 launch was a package, not a single file. The table below lists the five resources that, in practice, people mean by “the AI RMF.” Later profiles and taxonomies are complements, not members of this table.

3.1 AI RMF 1.0 (NIST AI 100-1)

AI 100-1 has two parts. Part I frames AI risk: who the AI actors are, how AI harm differs from software harm, and what “trustworthy” means. Part II is the Core: four functions, each decomposed into categories and subcategories.

Govern is cross-cutting. It is organizational policy, accountability, culture, third-party governance, and engagement with affected parties. Map, Measure, and Manage then run as a loop on a given AI system or use case. Map establishes context and inventories impacts. Measure selects methods, evaluates trustworthy characteristics, and tracks risk over time. Manage prioritizes treatments, including residual risk, incident response, and third-party exposure. NIST presents these as concurrent and iterative, not as a waterfall.

Two structural choices are easy to miss.

First, profiles are first-class. A profile is an implementation of the functions for a specific setting, risk tolerance, and resource envelope. The Generative AI Profile (AI 600-1) and the forthcoming critical-infrastructure profile are profile instances, not competing frameworks.

Second, the Core describes outcomes, not tools. “MEASURE 2: AI systems are evaluated for trustworthy characteristics” does not name a red-team vendor, a bias benchmark, or an adversarial-robustness metric. Those choices belong in the Playbook, in an organizational profile, or in a complement such as AI 100-2.

3.2 The Playbook

The Playbook is the implementation companion. For each subcategory it offers suggested actions, informative references, and notes on documentation. NIST is explicit on three constraints: the Playbook is voluntary; organizations may use as many or as few suggestions as apply; and it is not a sequence that must be completed in full. The first complete web version was announced on 30 March 2023, with the Resource Center launch. NIST has stated that the Playbook will be updated after AI RMF 1.0 is revised.

For a security reader, the Playbook is where “secure and resilient” becomes tactical — logging, evaluation, incident processes, supply-chain questions — without becoming SP 800-53. If a team needs a control ID they can audit, they have left the Playbook and should say so.

3.3 The Roadmap

The Roadmap is NIST’s list of gaps at the time of 1.0, not a schedule with delivery dates. Published priorities include alignment with international standards and crosswalks; expanded test, evaluation, verification, and validation (TEVV); AI RMF profiles; guidance on tradeoffs among trustworthiness characteristics; methods for measuring the effectiveness of the AI RMF itself; case studies; human factors; explainability connected to risk management; methods for setting reasonable risk tolerances; and educational material.

Several of these have since grown into documents of their own (profiles, TEVV-adjacent taxonomies). Others remain open, especially tradeoff guidance and effectiveness measurement. A team that treats 1.0 as finished doctrine will be surprised by the revision process.

3.4 Trustworthy AI characteristics

The characteristics are not a fifth PDF. They are Part I of AI 100-1, and they are the object of MEASURE 2. The important suite-level point is that NIST defined “good AI” before it defined the four functions. The functions exist to pursue those characteristics, including when they pull in opposite directions.

3.5 The community catalog (AIRC)

On 30 March 2023 NIST launched the Trustworthy and Responsible AI Resource Center to host Playbook content, crosswalks, perspectives, and contributed use cases. This is the resource often described informally as an “AI risk management database”: a catalog of community implementations, not a vulnerability database and not a control library. Its function is social — shared profiles and mappings — rather than technical evaluation. It should not be confused with incident databases or with MITRE ATLAS.

4. Trustworthiness characteristics and the security row

NIST’s trustworthiness model is the part of the AI RMF most often skipped by security programs and most often treated as the whole program by responsible-AI programs. Both cuts lose the structure.

4.1 Seven characteristics

AI 100-1 states that trustworthy AI systems are, in combination:

1. Valid and reliable — they perform as intended under expected and reasonably unexpected conditions, with documented limitations.
2. Safe — they do not endanger human life, health, property, or the environment under defined conditions of use.
3. Secure and resilient — they withstand unexpected adverse events, including those from unauthorized access, use, or disruption, and they recover.
4. Accountable and transparent — actors can be identified, and information about the system is available to those who need it.
5. Explainable and interpretable — AI output and system behavior can be understood at a level matched to the audience and the decision.
6. Privacy-enhanced — they incorporate privacy values such as anonymity, confidentiality, and control.
7. Fair, with harmful bias managed — they manage harmful bias and related discrimination risks.

Validity is described as a prerequisite for the others: an invalid system cannot be fair or safe in any robust sense. Beyond that, NIST does not rank the remaining six. The Roadmap instead flags tradeoffs as an open research and guidance problem.

4.2 What “secure and resilient” covers

In RMF language, secure and resilient is the characteristic that overlaps the classical CIA triad and the CSF outcomes. It includes confidentiality of model weights, training data, and prompts; integrity of data, models, and tool outputs; availability of inference and of the surrounding pipeline; and resilience under attack, distribution shift, and operational failure.

It does not, by itself, include:

• whether the model’s stated objective matches the deployer’s values (accountability);
• whether refusals and dual-use policy are adequate (safety, often also fairness);
• whether explanations are faithful (explainability);
• whether training data or logs create privacy harm (privacy);
• whether evaluations are statistically valid (validity).

Adversarial machine learning sits on the boundary. Evasion, poisoning, privacy attacks, and generative misuse are security events, but they are also validity, privacy, and safety events. That is why NIST wrote a dedicated taxonomy rather than folding AML entirely into CSF Identify-Protect-Detect-Respond-Recover.

4.3 How the four functions apply to the security row

A security-only reading of the four functions still has content, and it is narrower than a full AI RMF program:

Govern. Who owns model risk versus application security versus safety policy? Are third-party models, RAG corpora, and tools in the vendor-risk process? Is there an acceptable-use policy that is not only an information-security policy?

Map. What is the AI system — model, prompts, tools, retrieval, evaluators, humans in the loop? Who is harmed if it fails closed, fails open, or is steered? Which environments are training, evaluation, and production, and can the model infer the difference?

Measure. What tests exist for jailbreaks, prompt injection, data exfiltration, poisoning, membership inference, and tool abuse — and what tests exist for the non-security characteristics that those attacks can induce? Are metrics tracked over time, or only at launch?

Manage. What is residual risk after mitigations? What is the incident path when a model action causes harm that is not a classical security incident? How are third-party model updates treated?

This is still not a control baseline. It is a way to notice that “we ran a red team once” is a Measure activity, not a Govern or Manage system.

5. Complements: cybersecurity and specialized profiles

If the suite is the trunk, the documents in this section are the branches that people most often mislabel as “the NIST AI security framework.” They are real, useful, and narrower.

5.1 CSF 2.0

The Cybersecurity Framework 2.0 organizes cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond, Recover. It is technology-neutral and already widely deployed. It does not know what a model weight, a prompt injection, or a chain-of-thought leak is. Using CSF alone on an LLM system typically captures the surrounding cloud account and application and misses the model-specific failure modes.

The lexical overlap of “Govern” with the AI RMF is coincidental in naming and aligned in spirit. CSF Govern is cybersecurity governance. AI RMF Govern is AI-trustworthiness governance, which includes security and a great deal else.

5.2 Cyber AI Profile (NIST IR 8596)

The Cybersecurity Framework Profile for Artificial Intelligence, released as an initial preliminary draft in December 2025, is the closest NIST document to an “AI security framework” in the colloquial sense. It applies CSF 2.0 outcomes to AI and is organized around three focus areas:

1. Secure — cybersecurity of AI system components (models, data, pipelines, agents, infrastructure).
2. Defend — using AI to enhance defensive operations, including the new failure modes that introduces.
3. Thwart — resilience against AI-enabled attacks (automated phishing, malware, intrusion).

NIST’s stated intent is that CSF 2.0, the AI RMF, and this Profile be used together, not that the Profile supersede AI 100-1. The draft assigns priority levels to considerations as planning guidance; organizations are expected to adjust those priorities to their own risk tolerance. As of this writing the document remains a draft on the path to an initial public draft after the January 2026 comment period.

5.3 Adversarial machine learning taxonomy (NIST AI 100-2)

NIST AI 100-2 is a terminology and taxonomy report, updated in 2025. It classifies attacks by learning paradigm, lifecycle stage, attacker goals, capabilities, and knowledge. For predictive systems the headline classes are evasion, poisoning, and privacy attacks. For generative systems it adds misuse. It also discusses mitigations and their limits.

This is the document to cite when Measure needs a shared language for “what happened to the model.” It is not a governance framework and not a CSF profile. ATLAS is a related practitioner threat landscape; AI 100-2 is the NIST vocabulary intended to inform future standards and practice guides.

5.4 Generative AI Profile (NIST AI 600-1)

NIST AI 600-1 is an AI RMF profile, not a CSF profile. It applies Govern–Map–Measure–Manage to risks that are unique or amplified in generative systems: confabulation, data privacy, information security, harmful content, homogenization, human–AI configuration, and several others. A team deploying LLMs or agents that implements 1.0 without 600-1 is using the general frame without the GenAI-specific risk list NIST already wrote.

5.5 SP 800-53 and AI control overlays

SP 800-53 remains the control catalog for US federal systems and for many private programs that already use it. NIST has been developing AI-oriented control overlays: selections and interpretations of existing controls for AI system types, rather than a replacement catalog. Until overlays are final, the honest implementation path is: RMF authorize the platform; AI RMF govern the model; CSF / Cyber AI Profile prioritize cyber outcomes; SP 800-53 (or a private catalog) instantiate technical controls.

5.6 Critical infrastructure profile

In April 2026 NIST released a concept note for an AI RMF profile on trustworthy AI in critical infrastructure. The audience is CI operators in IT, OT, and ICS contexts who need to state trustworthiness requirements to vendors and internal teams. It is a sector profile of AI 100-1, not a replacement for sector-specific cyber regulation.

5.7 Revision of AI RMF 1.0

NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan, and that the Playbook will be updated after that revision. Any mapping paper, including this one, should be read as a map of the 1.0-era suite plus the complements published through mid-2026 — not as a freeze of the 2.0 text.

6. A usage map

The practical question is not which document is “the” framework. It is which document answers which question.

1. What outcomes do we owe? → AI RMF 1.0 + profile (600-1 or sector)
2. How might we pursue them? → Playbook + AIRC examples
3. What are the cyber outcomes? → CSF 2.0 + Cyber AI Profile
4. What can happen to the model? → AI 100-2 (+ ATLAS)
5. Which controls instantiate that? → SP 800-53 / overlay / ISO 27001

Skipping a row is common; claiming the skipped row was covered is the usual error.

6.1 Procedure

1. Name the system and the actors (Map). Write down the model(s), data stores, tools, evaluators, users, and affected parties. If this inventory does not exist, neither CSF nor the Playbook will save the program.

1. Select a profile. General systems use 1.0 as-is. Generative and agentic systems add AI 600-1. CI operators should watch the critical-infrastructure profile. A profile is a scoping decision, not extra paperwork for its own sake.

1. Stand up Govern before Measure theatre. Assign owners for model risk, application security, safety policy, and vendor AI. Decide risk tolerance explicitly — Roadmap item 9 exists because this step is usually faked.

1. Pull cybersecurity through CSF, not through metaphor. Map Secure / Defend / Thwart considerations from IR 8596 onto existing CSF categories. Do not rewrite the ISMS around AI 100-1 subcategories.

1. Give Measure an attack vocabulary. Use AI 100-2 classes (evasion, poisoning, privacy, misuse) as the minimum taxonomy for model-centric tests. Add non-security evaluations for validity, fairness, privacy, and safety or stop claiming those characteristics.

1. Instantiate controls in a real catalog. SP 800-53, a cloud provider’s control mapping, or ISO/IEC 27001 can hold the technical objects. Record residual risk in Manage, including harms that will never appear in a SIEM.

1. Document the negative space. If the organization implements only Secure-and-resilient + CSF, say “we run an AI cybersecurity program informed by the AI RMF,” not “we implement the AI RMF.”

6.2 Worked example: an agentic chat system

Consider a hosted assistant that retrieves private documents, calls tools, and acts over multiple turns — the shape of many production LLM agents.

Map. The system is not “the model.” It is the model, the system prompt, retrieved corpora, tool APIs, session memory, evaluators, and human operators. Affected parties include end users, bystanders whose data appear in retrieval, and whoever is on the other side of a tool call. AI 600-1’s GenAI risk list is in scope; a predictive-ML-only reading of 1.0 is not.

Govern. Separate owners for: application security (authn/z, tenant isolation); model and prompt change control; safety policy (refusals, dual-use); and vendor models. Third-party Govern (GOVERN 6 / MANAGE 3) applies to foundation-model APIs the same way it applies to SaaS.

Measure. AI 100-2 misuse and privacy classes cover jailbreaks, prompt injection via retrieved documents, and data exfiltration through tools. They do not cover confabulation that harms a user without an attacker, or systematic refusal failures on some languages. Those are validity, safety, and fairness measurements. A red-team report that only counts attack success rate is incomplete Measure relative to 600-1.

Manage. Incident types include classical breaches and harmful completed tool actions, secret leakage in logs, and discovered alignment-faking or deceptive reasoning if the model is evaluated for it. Recovery may mean rolling back a prompt or a model, not only rotating credentials.

CSF / IR 8596 overlay. Secure covers the serving stack and training or fine-tuning pipeline. Defend covers any use of models inside SOC workflows — and the prompt-injection risk that creates. Thwart covers attackers using other models against this system (credential stuffing with generated lures, automated vulnerability discovery).

None of this requires pretending IR 8596 is AI 100-1, or that AI 100-1 is SP 800-53.

6.3 Failure modes

We observe four recurring category errors in public claims (not a statistical sample; a typology):

• PDF compliance. Treating a completed Playbook spreadsheet as implementation of MEASURE 2.
• Security synecdoche. Equating AI RMF implementation with an adversarial robustness eval.
• Ethics synecdoche. Equating AI RMF implementation with a fairness dashboard and no incident path.
• Certification theatre. Advertising “NIST AI RMF certified” despite NIST offering no such certification for 1.0.

The last is the most misleading. ISO/IEC 42001 is the certifiable AI management system. The AI RMF is a voluntary outcomes framework that can be aligned with that system.

7. Related work

NIST’s own stack. This paper is a reading of that stack rather than a competitor to it. Primary sources are AI 100-1, the Playbook and Roadmap, AIRC, AI 600-1, AI 100-2, CSF 2.0, and IR 8596. SP 800-37 and SP 800-53 remain the authorization and control spine for federal information systems.

International management systems and law. ISO/IEC 42001 specifies an AI management system that can be audited. ISO/IEC 22989 provides vocabulary; ISO/IEC 42005 addresses impact assessment. The AI RMF Roadmap already listed crosswalks to this family as a top priority. The EU AI Act is binding risk-tiered regulation for systems in its scope. It is not a NIST profile. Crosswalks are appropriate; identity is not. The OECD AI Principles sit at a higher altitude still and informed much of the 2019–2023 trustworthy-AI vocabulary that NIST distilled.

Secure development guidelines. CISA and NCSC’s guidelines for secure AI system development are closer to IR 8596’s Secure focus area than to AI 100-1 as a whole. They are useful Measure/Manage input, not a substitute Govern model for fairness or accountability.

Threat landscapes. MITRE ATLAS catalogs adversary tactics against AI systems. Biggio and Roli survey the first decade of adversarial ML. Weidinger et al. taxonomy language-model risks beyond the adversarial setting. Amodei et al. framed accident risk that is not primarily an attacker problem. The AI RMF is deliberately broader than any one of these lists; AI 100-2 is the NIST document that most directly absorbs the adversarial subset.

Alignment as a trustworthiness problem. Work on helpful, honest, and harmless assistants and on constitutional training addresses safety, accountability, and validity more than classical cybersecurity. It still belongs under Map and Measure for agentic systems: a model that strategically complies under oversight is a Manage-relevant failure mode even when no SP 800-53 control has failed. The AI RMF does not use “alignment” as a primitive; organizations that care about it should treat it as a named risk in Map, not as a synonym for secure-and-resilient.

8. Discussion

8.1 What this mapping does not do

We did not measure whether organizations that claim AI RMF alignment differ in incident rates from those that do not. Roadmap item 5 (effectiveness of the framework) remains an open NIST workstream. We also did not produce a new control overlay or a complete crosswalk to ISO/IEC 42001 or the EU AI Act; those are documents-sized projects, some of which already live in AIRC.

The paper is therefore a cartographic contribution. Its failure mode is the usual one for maps: looking more authoritative than the terrain, especially while 1.0 is under revision.

8.2 Voluntary frameworks and procurement language

Because AI 100-1 is voluntary and outcome-based, it is a poor object of binary procurement clauses (“supplier must be AI RMF compliant”). A more precise clause names the profile (e.g. AI 600-1), the characteristics in scope, the evidence expected for Measure, and the control catalog used to instantiate Protect/Detect technical objects. Where a certifiable management system is required, ISO/IEC 42001 is the designed instrument. Where a certifiable security control set is required, SP 800-53 or an equivalent remains the designed instrument.

8.3 The measurement gap

Govern and Map can be done with workshops. Measure cannot. NIST’s TEVV Roadmap item exists because socio-technical evaluation of AI systems is still methodologically thin relative to the claims buyers want to hear. Security teams should not fill that gap by overloading red-team pass/fail rates to stand in for validity, fairness, and safety. That substitution is how “NIST AI security framework” becomes a marketing phrase.

8.4 Agents, tools, and the 2023 text

AI 100-1 predates the widespread deployment of tool-using agents. AI 600-1 and IR 8596 are the documents that begin to catch up. An agent that can send email, change infrastructure, or write code expands the Map inventory and the Manage incident taxonomy. It does not require a new marketing name for the AI RMF; it requires a profile that names tools, memory, and authorization as first-class system components.

8.5 Revision risk

Readers implementing from this paper should track the 1.0 revision. Function names may persist while subcategories, profile expectations, and Playbook actions change. The structural claim we care about — suite versus complements; characteristics versus controls — is likely to survive; table-level citations to 1.0 subcategories may not.

9. Conclusion

There is no single NIST document titled the AI Security Framework. There is a 2023 program — the AI RMF suite of AI 100-1, Playbook, Roadmap, trustworthiness characteristics, and community catalog — and a set of later instruments that deepen cybersecurity, generative-AI, and sector-specific practice.

Security is one of seven trustworthy-AI characteristics. The four functions operationalize all seven. CSF 2.0 and the draft Cyber AI Profile are the cybersecurity outcome layer. AI 100-2 is the attack vocabulary. SP 800-53 (and forthcoming overlays) are the control layer. ISO/IEC 42001 and the EU AI Act are adjacent regimes.

Used together, these documents are coherent. Used as synonyms, they produce programs that are either security with ethics vocabulary, or ethics with no incident path. The cheapest correction is linguistic: say which document answers which question, and stop claiming the rest.

Acknowledgments

This paper is a structured reading of publicly available NIST and related standards documents. It is not affiliated with NIST, does not constitute legal or compliance advice, and does not claim that any product implements the AI RMF.

@online{violet2026nistairmf,
  author = {Haigh, John},
  title = {The NIST AI Risk Management Framework: Mapping the Core Suite to Security Practice},
  date = {2026-09-12},
  year = {2026},
  url = {https://www.violetai.ca/en/research/nist-ai-rmf/paper},
}