NIST AI Security Framework: Practical Guide for LLM Apps

Every security team building or buying AI systems eventually runs into the same document: the NIST AI Risk Management Framework. It shows up in vendor questionnaires, board presentations, and increasingly in state law references, yet most teams have only skimmed the summary slide rather than worked through what it actually asks an organization to do. This guide walks through the NIST AI security framework in practical terms: what it is, how its core functions apply to agentic and LLM applications, where it falls short technically, and how to operationalize it with real controls rather than a binder that sits on a shelf.

What is the NIST AI Security Framework?

The NIST AI RMF, formally titled the Artificial Intelligence Risk Management Framework, is voluntary guidance from the U.S. National Institute of Standards and Technology that helps organizations design, develop, deploy, and use AI systems that are valid, reliable, safe, secure, resilient, accountable, transparent, explainable, privacy-enhanced, and fair. It's become the default reference point for AI governance in the United States, not because it's mandatory, but because almost nothing else fills the gap it addresses.

Origins and Purpose of the AI RMF

NIST published AI RMF 1.0 on January 26, 2023, following an open, multidisciplinary process that drew input from more than 240 contributing organizations across industry, academia, civil society, and government over roughly 18 months. It was developed under the National AI Initiative Act of 2020, and its stated purpose is straightforward: give organizations a structured, repeatable way to identify, assess, measure, and manage AI-related risk across a system's entire lifecycle, rather than leaving each team to invent its own approach. NIST has signaled that AI RMF 1.0 is being revised as generative AI and agentic systems have matured well beyond what the original document anticipated.

Core Principles and Structure

The framework is organized into two parts. Part 1 lays out foundational concepts, the intended audience, and the characteristics of trustworthy AI. Part 2 contains the Core, which is where most of the practical AI risk management work actually happens, structured around four functions that this guide covers in detail below. Governance sits above the other three functions as a cross-cutting concern meant to inform and be infused throughout Map, Measure, and Manage, rather than existing as a separate, siloed activity, and risk management is meant to run continuously across the full AI system lifecycle rather than as a single pre-launch gate.

Key Concepts: Trustworthiness, Risk, and Governance in AI

Before applying the framework to any specific system, it helps to understand the vocabulary NIST built it around, since trustworthy AI and AI governance are the two ideas the entire Core is designed to operationalize, and AI trustworthiness in particular is the outcome every other function is ultimately working toward.

Defining Trustworthiness in AI Systems

NIST defines trustworthy AI through seven characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. These aren't abstract values. Each one maps to concrete engineering and governance questions: does the system perform as intended under expected conditions, can it withstand adversarial manipulation, can a human trace why it produced a given output, and does it avoid systematically disadvantaging any group of users. Every subsequent function in the AI RMF Core exists to help an organization answer these questions for a specific system rather than in the abstract, and together they form the basis of AI assurance, the ongoing evidence an organization can point to when asked to prove a system is trustworthy rather than simply asserting it.

AI Risk Types and Threat Surfaces

AI risk types span far more than model accuracy. They include security risks like adversarial manipulation and data poisoning, privacy risks from training data or memorized outputs, fairness and bias risks in system decisions, and increasingly, for generative and agentic systems, risks tied to autonomous action, tool use, and multi-step reasoning. Effective AI threat modeling has to account for all of these categories together rather than treating security as a separate concern from fairness or privacy. NIST's Generative AI Profile, published as NIST AI 600-1 on July 26, 2024, extends AI RMF 1.0 specifically for generative AI systems, including LLMs, AI agents, and multimodal models, and identifies 12 risk categories unique to or amplified by generative AI. That companion document is the clearest signal that NIST itself recognized the base framework needed a more specific technical layer for exactly the systems most enterprises are deploying today.

Applying the NIST AI RMF to Agentic AI and LLM Applications

The real test of any AI risk management program isn't whether it looks good in a policy document. It's whether the four core functions actually produce useful outcomes when applied to a live LLM application or an autonomous agent making tool calls in production.

Framework Functions: Govern, Map, Measure, Manage

The framework is organized around four core functions. Govern establishes organizational accountability, policies, and oversight for AI risk, and it's the only function that spans the organization as a whole rather than applying to a single system. Map establishes context and identifies risks for a specific AI system, translating the general categories from the Govern function into the concrete details of what a particular application does, what data it touches, and who it affects. Measure analyzes and tracks risks using both quantitative and qualitative methods, and for LLM applications specifically, this includes red team testing for prompt injection, output validation testing for data leakage, and tool-calling behavior analysis for excessive agency. Manage allocates resources to treat identified risks, documents residual risk that wasn't fully mitigated, and defines how the organization responds to incidents when something goes wrong anyway.

Agentic AI is the case that stresses this structure the most. An agent is an LLM that plans, decides, and executes multi-step tasks using external tools, and every tool an agent can call becomes part of the attack surface the Map function needs to account for. A chatbot that only generates text has a fairly bounded risk surface. An agent connected to a customer database, a payment system, and an email client has a Map function that needs to be redone every time a new tool gets added, which is a very different operational rhythm than most organizations are used to.

Challenges in Operationalizing the Framework

The most common implementation failure looks the same across organizations of very different sizes: teams complete Govern and Map on paper, publish a policy, produce an AI inventory, and then quietly drop Measure because they lack the data infrastructure to benchmark risk consistently. Manage becomes whatever ad hoc process happens when an incident actually occurs, rather than a planned response built ahead of time. The result is a framework that exists on the intranet while the operational reality of how AI systems are actually built and deployed stays unchanged. Fixing this requires treating the four functions as a continuous process with real inputs, outputs, and handoffs, not a one-time documentation exercise completed before launch and never revisited.

Technical Gaps: Where the NIST AI RMF Falls Short for Modern AI Security

NIST AI RMF limitations become obvious fairly quickly once a security team tries to use the framework as a direct source of technical controls rather than a governance structure.

Lack of Prescriptive Controls for Agentic Workflows

The AI RMF is deliberately non-prescriptive. It tells organizations what outcomes to achieve, not which specific technical control to implement, and that flexibility is a strength for a framework meant to apply across industries and risk levels. It's also a real limitation for security teams trying to protect agentic workflows specifically, since the Core offers no equivalent to a concrete checklist for securing tool permissions, validating MCP server connections, or detecting memory poisoning across a session. Those gaps are exactly why security teams pair the AI RMF with more technical, prescriptive frameworks rather than treating it as sufficient on its own.

Real-World Attack Scenarios Not Explicitly Covered

The base framework doesn't explicitly walk through prompt injection or excessive agency as named, prescriptive attack scenarios. That gap gets filled by external taxonomies. The OWASP Top 10 for LLM Applications 2025 ranks prompt injection (LLM01) as the top risk for the second consecutive edition, and lists excessive agency (LLM06) as a system granted more tools, permissions, or autonomy than the task actually requires. These risks are typically layered in under the AI RMF's Measure function using OWASP's taxonomy and similar external references, since the base NIST document simply wasn't written with today's tool-calling, multi-step agent architectures fully in view.

Integrating Automated Security Controls with the NIST AI Security Framework

Closing the gap between the AI RMF's governance structure and the technical reality of modern AI systems means bringing automated security controls into the Measure and Manage functions specifically, since those are where the framework's own language is most abstract. This is also where AI security best practices earn their keep, translating the framework's outcomes into controls a security team can actually run.

Continuous Red Teaming and Runtime Protection

Structured, continuous red teaming is one of the clearest ways to operationalize the Measure function for LLM and agentic applications. Rather than a single pre-launch assessment, ongoing adversarial testing for prompt injection, tool misuse, and memory manipulation gives an organization the kind of quantitative risk data the AI RMF calls for but doesn't specify how to produce. Runtime protection extends that coverage into production, since testing alone doesn't stop an exploit from happening to a live system, and the Manage function explicitly expects organizations to have a real AI incident response capability rather than a reactive one built after the first breach.

Automated Discovery and Guardrails for AI Agents

The Map function assumes an organization actually knows what AI systems exist to assess in the first place, which is a much harder problem than it sounds once agent adoption becomes decentralized across teams. Automated discovery of AI agents, models, and MCP server connections gives the Map function something concrete to work from, rather than relying on teams to self-report every new integration. Guardrails that enforce policy at runtime, blocking or flagging risky tool calls as they happen, turn the abstract idea of AI security controls into something that actually intervenes rather than something that only appears in a report after the fact.

Case Study: Operationalizing NIST AI RMF with Akto

Seeing how the four functions map onto real tooling makes the framework concrete in a way that reading the NIST document alone doesn't.

Mapping Akto Capabilities to Framework Functions

Akto supports the Map function by continuously discovering AI agents, LLM applications, and MCP server connections across an organization's environment, building the AI system inventory that Map assumes already exists. It supports Measure through large-scale, continuously updated red teaming probe libraries that test for prompt injection, tool misuse, memory poisoning, and the other risk categories NIST's Generative AI Profile calls out, giving security teams the quantitative and qualitative risk data the framework asks for without requiring a bespoke measurement program built from scratch. And it supports Manage by feeding findings from that testing directly into runtime guardrails, so a vulnerability identified during assessment gets addressed in production rather than sitting in a report that never gets acted on.

Lessons Learned and Measurable Outcomes

Organizations that have gone through this kind of mapping exercise tend to arrive at the same conclusion: the AI RMF is genuinely useful as an organizing structure, but it only produces real risk reduction once every function has a technical system behind it, not just a policy document. Govern without Measure produces a false sense of assurance. Measure without Manage produces a pile of findings nobody fixes. The organizations getting real value out of the framework are the ones treating each function as a place where automated tooling does the actual work, with the framework providing the shared vocabulary and structure that keeps security, legal, and engineering teams talking about risk the same way.

Final Thoughts: Moving from Framework to Continuous AI Security Practice

The NIST AI security framework is a strong starting point precisely because it isn't trying to be a technical standard. It gives organizations a common language for AI governance, AI risk management, and AI trustworthiness that legal, security, and engineering teams can all use without translating between three different vocabularies. But a framework alone doesn't stop a prompt injection attack or catch a misconfigured agent before it reaches production. Getting real value out of the AI RMF means pairing its Govern, Map, Measure, and Manage structure with actual AI security best practices: continuous discovery, ongoing red teaming, runtime guardrails, and an incident response process that was built before it was needed rather than improvised during the first real incident. A mature AI RMF implementation also tends to make AI compliance conversations with auditors and regulators far more straightforward, since the evidence already exists rather than needing to be assembled after the fact. Treat the framework as the operating model, and build the technical practice underneath it that turns AI risk assessment from an annual exercise into a continuous one.

Frequently Asked Questions: NIST AI Security Framework

1. What is the NIST AI Risk Management Framework (AI RMF)?

The NIST AI Risk Management Framework (NIST AI RMF 1.0) is voluntary guidance published by the U.S. National Institute of Standards and Technology in January 2023, helping organizations design, develop, deploy, and use AI systems that are valid, reliable, safe, secure, resilient, accountable, transparent, explainable, privacy-enhanced, and fair.

2. What are the four core functions of the AI RMF?

The framework is organized around four core functions: Govern (establish organizational accountability, policies, and oversight for AI risk), Map (establish context and identify risks for a specific AI system), Measure (analyze and track risks with quantitative and qualitative methods), and Manage (allocate resources to treat risks, document residual risk, and respond to incidents).

3. Is the NIST AI RMF mandatory?

No. NIST AI RMF 1.0 does not offer formal certification and is voluntary guidance rather than a mandatory regulation.

4. What is NIST AI 600-1, and how does it relate to the base framework?

NIST AI 600-1 is a companion profile published July 26, 2024, that extends AI RMF 1.0 specifically for generative AI systems, including LLMs, AI agents, and multimodal models, identifying 12 risk categories unique to or amplified by generative AI.

5. How does NIST AI RMF apply to agentic AI specifically?

Agentic AI is the case that stresses the framework the most, since an agent is an LLM that plans, decides, and executes multi-step tasks using external tools. Every tool an agent can call becomes part of the attack surface.

6. How does NIST AI RMF relate to ISO 42001?

NIST AI RMF 1.0 centers on four risk functions and trustworthy AI characteristics, while ISO/IEC 42001:2023 is an international management system standard with a certifiable audit path. Many organizations use NIST AI RMF as their risk-management operating model inside an ISO/IEC 42001 AI Management System.

7. What does the Measure function look like in practice for LLM applications?

For LLM applications, this includes red team testing for prompt injection, output validation testing for data leakage, and tool-calling behavior analysis for excessive agency.

8. Why do organizations struggle to operationalize the framework?

The most common implementation failure is completing Govern and Map on paper, then dropping Measure because organizations lack the data infrastructure to benchmark risk consistently.

9. How long does it take to implement the NIST AI RMF for a single AI system?

A functional implementation covering all four functions for a single high-risk AI system takes approximately 8 to 14 weeks for an organization with an existing enterprise risk management structure, while full program maturity across an AI portfolio typically takes 12 to 18 months.

10. Does the NIST AI RMF explicitly cover prompt injection and excessive agency?

Not prescriptively on its own. The OWASP Top 10 for LLM Applications 2025 ranks prompt injection (LLM01) as the top risk for the second consecutive edition and lists excessive agency (LLM06) as granting an agent more tools, permissions, or autonomy than the task requires. These risks are typically layered in under the Measure function using external taxonomies like OWASP.

11. What tools help automate NIST AI RMF compliance?

Governance platforms like Credo AI and Holistic AI map to AI RMF subcategories for compliance tracking, while adversarial testing tools like Garak and PyRIT support the Measure function by enabling structured red teaming of LLMs.

12. What is an AI RMF "Profile," and why does it matter?

A Profile documents how organizations apply the Core functions to specific systems, business units, or risk environments. It helps identify gaps and shape a roadmap using a Current Profile compared against a Target Profile.