Key Takeaways
- Treat the AI RMF as voluntary and non-certifiable; pursue ISO/IEC 42001 when a certificate is needed.
- Map every production LLM application and agent to the four functions.
- Read Measure 2.4 and Manage 4.1 as a demand for continuous production metrics and retained enforcement records, because single-attempt pre-deployment testing understates agent hijacking risk.
- Under Texas TRAIGA, substantial compliance with the NIST Generative AI Profile is a route to avoiding liability, which makes documented alignment a legal asset.
- Build the AI inventory and assign an accountable owner before instrumenting metrics; measurement without a registry produces evidence no auditor can attribute to a system.
An agent that passed a single-attempt red team in the spring can be hijacked in the autumn by an attacker who kept trying. The U.S. AI Safety Institute, now CAISI, reported that pattern in January 2025 using the AgentDojo benchmark. Five prompt-injection tasks succeeded against an agent 57% of the time on a single attempt and 80% of the time after 25 attempts per task [1]. Adaptive attacks developed against held-out tasks raised success from 11% to 81% [1]. NIST concluded that multi-attempt evaluation “can result in meaningfully different, and possibly more realistic, estimates of risk” [1].
The NIST AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1 in January 2023) is a voluntary framework for managing risks to individuals, organizations, and society from AI systems. It organizes AI risk management into four core functions, Govern, Map, Measure, and Manage, and describes seven characteristics of trustworthy AI that those functions are meant to produce [2]. NIST uses Measure and Manage to describe the production evidence a governance officer should be able to show, which is where the one-time red-team report falls short.
What the NIST AI Risk Management Framework Is
NIST published the AI RMF under a direction from Congress. The National Artificial Intelligence Initiative Act of 2020 directed NIST to develop a voluntary risk management framework for trustworthy AI systems, and AI 100-1 describes itself as “intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic” [2]. NIST’s FAQ answers the question of whether the framework is mandatory with one word, “No,” followed by the statement that NIST produced it as a voluntary framework [3].
The document has two parts. Part 1 defines AI risk and sets out the seven trustworthiness characteristics. Part 2 is the Core, which states outcomes under the four functions, each broken into categories and subcategories written as outcome statements rather than controls. The subcategories do not prescribe thresholds, tools, or testing frequencies, which leaves the governance officer to define those in a profile.
The July 2025 America’s AI Action Plan directed NIST to revise AI RMF 1.0 [4]; as of August 2026 no draft had been published, so the January 2023 text remains the one to cite.
The Four Core Functions of the AI RMF
AI 100-1 states that “while GOVERN applies to all stages of organizations' AI risk management processes and procedures, the MAP, MEASURE, and MANAGE functions can be applied in AI system-specific contexts and at specific stages of the AI lifecycle” [2]. Govern sets the organizational foundation, Map defines context, Measure tracks results, and Manage directs risk treatment.
Govern: Set the Policy Foundation
Under Govern, organizations establish the policies and accountability that support the inventory and the other three functions. Govern 1.6 asks that “mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities,” which is the AI registry requirement, covering retired systems as well as live ones [2]. Govern 1.1 requires that legal and regulatory requirements involving AI are “understood, managed, and documented.” Govern 2.3 places responsibility for decisions about AI deployment risk on executive leadership.
Map: Define the System’s Context
Map directs governance teams to establish the context in which a system operates before they measure it. Map 1.5 asks that organizational risk tolerances are “determined and documented” [2]. Map 2.2 asks that the system’s knowledge limits, and how humans will oversee its output, are documented well enough to support later decisions. Map 3.5 requires that processes for human oversight are “defined, assessed, and documented.” For an agent, the governance team records its permitted tools and data, along with the points where a human must intervene.
Measure: Track Risk Before and After Deployment
Measure directs teams to convert the risks identified in Map into metrics tracked over time, including after deployment. Measure 2.4 asks that the functionality and behavior identified in Map are “monitored when in production” [2]. Measure 2.6 asks that safety metrics reflect “real-time monitoring, and response times for AI system failures.” Measure 3.1 requires tracking of “existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts.” The section narrative states that AI systems “should be tested before their deployment and regularly while in operation” [2].
Manage: Enforce the Response and Keep the Record
Manage directs organizations to allocate resources to measured risks and document how they treat each one. Manage 1.3 requires that responses to high-priority risks are “developed, planned, and documented,” with options that include mitigating, transferring, avoiding, or accepting [2]. Manage 2.4 requires mechanisms “to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.” Manage 4.1 requires post-deployment monitoring plans covering “appeal and override, decommissioning, incident response, recovery, and change management.”
The Seven Characteristics of Trustworthy AI
NIST names seven characteristics in AI 100-1 Section 3 and notes that tradeoffs between them are usual [2]:
- Valid and reliable: the system meets intended-use requirements and performs without failure over a given interval.
- Safe: the system does not, under defined conditions, endanger human life, health, property, or the environment.
- Secure and resilient: the system maintains confidentiality, integrity, and availability and degrades gracefully.
- Accountable and transparent: information about the system and its outputs is available to relevant actors.
- Explainable and interpretable: the system can represent its mechanisms and the meaning of its output in context.
- Privacy-enhanced: the system safeguards human autonomy, identity, and dignity.
- Fair with harmful bias managed: systemic, computational and statistical, and human-cognitive biases are managed.
NIST adds that trustworthiness “is only as strong as its weakest characteristics” and that human judgment should set the metrics and threshold values for each one [2].
Is the AI RMF Mandatory, and Can You Be Certified Against It?
The AI RMF is voluntary, and no body certifies conformance to it. NIST’s FAQ states the voluntary status directly [3], and there is no NIST audit scheme and no conformity assessment program. Credentials marketed as NIST AI RMF certifications come from training vendors.
What organizations produce instead is alignment evidence. AI 100-1 describes Current and Target Profiles. The Current Profile records how AI risk is managed today. The Target Profile records the outcomes the organization needs, and organizations can identify the gaps to close by comparing the two [2]. In practice the governance officer assembles a self-attestation, an internal profile mapping each subcategory to a control and its evidence, and a readiness report for the board, customers, or procurement teams.
The Texas Responsible Artificial Intelligence Governance Act (TRAIGA, HB 149), signed June 22, 2025 and in effect since January 1, 2026, provides that a person “may not be found liable” under the Act if it substantially complies with “the most recent version of the ‘Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile’ published by the National Institute of Standards and Technology or another nationally or internationally recognized risk management framework for artificial intelligence systems” [5]. The Attorney General has exclusive enforcement, there is no private right of action, and violations carry a 60-day cure period. Civil penalties run from $10,000 to $12,000 for a curable violation and $80,000 to $200,000 for an uncurable one [5].
The Generative AI Profile (NIST AI 600-1)
NIST AI 600-1, published July 26, 2024, is the cross-sectoral profile that adapts AI RMF 1.0 to generative AI [6]. It identifies 12 risks, including confabulation, data privacy, information security, harmful bias and homogenization, and value chain and component integration, and it maps each risk to the trustworthiness characteristics it affects. Under each relevant AI RMF subcategory, the profile lists suggested actions tagged with the risks they address; action identifiers follow the pattern GV-1.1-001, and NIST counts more than 200 of them [6].
TRAIGA names this profile for its liability protection. The profile also states that AI RMF 1.0 and Playbook actions “are already applicable for managing GAI risks,” and it lists autonomous agents among the security threats to assess, with threat modeling and deactivation protocols recommended [6]. The PDF is available from NIST at nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf.
How the AI RMF Compares to ISO/IEC 42001 and the EU AI Act
The three instruments differ in legal force and in what evidence each demands.
Regulation (EU) 2026/1744, in force since 27 July 2026, moved application of Annex III high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028 [9].
One AI inventory can support Govern 1.6 and the ISO/IEC 42001 Annex A life-cycle controls, and one set of production metrics and enforcement records can support Measure 2.4 and Manage 4.1. Building that evidence once and mapping it to each framework can avoid duplicate work.
What Measure and Manage Require as Production Evidence
Read together, Measure 2.4, 2.6, and 3.1 support an implementation that scores a deployed LLM application or agent at inference time and retains the results. For a generative system the metrics are concrete: hallucination or faithfulness against retrieved context, toxicity, PII/PHI leakage in prompts and outputs, and jailbreak or prompt-injection attempts on the request.
A quarterly red-team report alone does not demonstrate the production monitoring described in Measure 2.4 because it records a point in time. The CAISI finding that success rates climb with repeated attempts also means the point-in-time number can understate live risk [1]. Sampled scoring has a related blind spot. A rare hijacking can succeed in unsampled traffic and leave no record.
Manage adds enforcement and the record of it through the disengage mechanism in Manage 2.4 and the post-deployment monitoring plans in Manage 4.1. To document each enforcement event, a governance team should retain four elements:
- Who: the user, session, or agent that triggered the event.
- What: the request or response content that matched the policy, and the action applied (allow, block, or redact).
- When: a timestamp that aligns with the trace of the surrounding agent session.
- Why: the policy, threshold, or evaluator score that caused the action.
The Fiddler AI Observability and Security platform produces that evidence for first-party agents, third-party agents, and coding agents, through four capabilities that map to the AI RMF’s functions:
Out-of-the-box and customizable Fiddler Centor Models run in-environment with zero data egress and power Evaluations, Continuous Monitoring, and Guardrails.
The platform supports compliance evidence for these frameworks; alignment and evidence generation are not a guarantee of legal compliance, and the governance officer still owns the legal determination for each jurisdiction.
A Starting Sequence for Adopting the AI RMF
The governance team should follow this order because the output of each step becomes the input for the next. Without a registry entry, the team cannot attribute a metric to a system; without an approved risk tolerance, it cannot defend a threshold.
- Build the AI inventory. Record every live, testing, and retired model, LLM application, and agent, with purpose, owner, and lifecycle status, to support Govern 1.6 and the decommissioning processes under Govern 1.7.
- Assign a governance owner for each entry. Govern 2.1 and 2.3 require documented roles and executive accountability for deployment risk decisions, so the registry entry should name an individual.
- Set risk tolerance per system. Map 1.5 requires documented tolerances; for an agent, state the acceptable rate of blocked injections, PII/PHI redactions, and faithfulness failures, and record who approved it.
- Instrument test, evaluation, verification, and validation (TEVV) and continuous measurement. Document test sets and tools per Measure 2.1, then carry the same thresholds into production scoring per Measure 2.4.
- Record enforcement evidence. Retain every allow, block, or redact decision with its session, policy, and score, and tie incident records to Manage 4.3 communication steps.
Request a demo to review how continuous production evidence for the AI RMF would fit the organization’s agent architecture and deployment environment.
References
[1] NIST, Technical Blog: Strengthening AI Agent Hijacking Evaluations (January 17, 2025). https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
[2] NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[3] NIST AI RMF FAQs. https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-faqs
[4] The White House, America’s AI Action Plan (July 2025). https://www.whitehouse.gov/wp-content/uploads/2025/07/Americas-AI-Action-Plan.pdf
[5] Texas Legislature, HB 149 Enrolled Text (Texas Responsible Artificial Intelligence Governance Act). https://capitol.texas.gov/tlodocs/89R/billtext/html/HB00149F.htm
[6] NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
[7] UKAS, UKAS Grants First AIMS Accreditation (January 15, 2026). https://www.ukas.com/resources/latest-news/ukas-grants-first-aims-accreditation/
[8] EUR-Lex, Regulation (EU) 2024/1689 (Artificial Intelligence Act), consolidated text of 27 July 2026. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng
[9] EUR-Lex, Regulation (EU) 2026/1744 (Digital Omnibus on AI). https://eur-lex.europa.eu/eli/reg/2026/1744/oj
[10] NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/37/r2/final
Frequently Asked Questions
Does NIST Define Four Types of AI Risk?
AI 100-1 does not enumerate four risk types. The four core functions are ways of addressing risk. Figure 1 of the framework groups potential harms into three sets: harm to people (individual, group or community, and societal), harm to an organization (operations, security breaches or monetary loss, and reputation), and harm to an ecosystem (interdependent systems such as the global financial system or supply chain, and natural resources) [2]. Lists of four risk types in vendor material reflect the vendor’s own taxonomy.
How Does the Older NIST RMF (SP 800-37) Differ From the AI RMF?
SP 800-37 Revision 2, published December 2018, is the Risk Management Framework for federal information systems, and it runs seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor [10]. It is technology-neutral and control-based, it ties to FISMA compliance, and OMB Circular A-130 requires federal agencies to apply it. The AI RMF is voluntary and outcome-based, and it addresses trustworthiness characteristics that security controls do not cover, such as explainability and harmful bias.
Who Should Use the AI RMF?
AI 100-1 defines AI actors as “those who play an active role in the AI system lifecycle, including organizations and individuals that deploy or operate AI” [2]. Appendix A lists their task categories: AI design, development, deployment, operation and monitoring, TEVV, human factors, domain expertise, AI impact assessment, procurement, and governance and oversight. The framework notes that the people verifying and validating a system should ideally be distinct from those who built and tested it, which is the separation-of-duties point a model risk function already applies to predictive models.
What Are the Playbook and Profiles For?
The Playbook is a companion resource of suggested actions aligned to each Core subcategory; NIST states it is neither a checklist nor an ordered list of steps. Profiles are implementations of the Core for a setting. Use-case profiles cover a domain such as hiring, temporal profiles compare Current and Target states, and cross-sectoral profiles such as AI 600-1 cover a technology used across sectors [2]. The governance officer typically writes an internal temporal profile and borrows actions from the Playbook and AI 600-1.
How Does the AI RMF Handle Agentic Systems?
NIST has not published a mapping of the four functions to agents, so any such mapping is interpretive; the nearest official statement is AI 600-1’s inclusion of autonomous agents among security threats to assess [6]. In practice, Map 3.5 directs organizations to define where a human must intervene in an agent’s tool use. Measure 2.4 can be read to call for monitoring tool calls and responses in production, and Manage 2.4 requires a mechanism to disengage the agent when it acts outside its intended use [2].
To make those records attributable, a governance team can retain context across the agentic hierarchy of application, session, agent, trace, and span. That context allows an auditor to connect an enforcement event to the session that caused it.