NIST AI RMF’s four functions: Govern, Map, Measure, Manage

Key takeaways

• Govern, Map, Measure, and Manage turn AI risk management into an ongoing process rather than a checklist. Govern provides accountability throughout; the other functions establish context, evaluate risks, and guide responses.
• Reliable AI inventories are essential to putting the framework into practice. Shadow AI and unknown agents leave gaps in risk mapping, policy enforcement, and oversight.
• WitnessAI helps enterprises operationalize AI governance through AI discovery, intent-based policies, pre-deployment security testing, and runtime protection. Capabilities support employee AI usage, enterprise AI applications, and agentic workflows through their respective deployment and integration paths.
• Governance needs operational evidence, not policy documents alone. Maintained inventories, production monitoring, and audit trails help teams show boards and regulators how AI risks are controlled while supporting deployment.
• AI RMF 1.0 remains the published version while NIST revises it, and it works alongside ISO/IEC 42001 and the EU AI Act without replacing their requirements. Its categories also accommodate agents and connected tools while final agent-specific NIST guidance is pending.

The NIST AI Risk Management Framework divides AI risk management into four functions: Govern, Map, Measure, and Manage. Many enterprise leaders can name the NIST AI RMF functions. Fewer can show a board or regulator how each one operates across employee AI use, customer-facing applications, and autonomous AI agents.

The distance between framework and operations appears in predictable places. Shadow AI tends to stay out of the inventory. Chatbots pass a pre-launch review and then meet inputs no test anticipated, and agents can inherit permissions no one mapped. In each case, documented governance requirements may lack the visibility, monitoring, or technical controls needed to manage risk during AI operations.

This article defines each function in NIST’s own terms and identifies where enterprises tend to stall. It then explains how visibility, intent-based controls, and runtime defense turn the framework into operating evidence.

What is the NIST AI RMF?

The NIST AI RMF (NIST AI 100-1) is a voluntary framework for incorporating trustworthiness into the design, development, use, and evaluation of AI systems. NIST published it on January 26, 2023, after 18 months of work with more than 240 contributing organizations. Part 1 frames AI risks and audiences, and Part 2 contains the Core and Profiles.

The Core “is composed of four functions: GOVERN, MAP, MEASURE, and MANAGE,” each broken into categories and subcategories. Govern “cultivates and implements a culture of risk management,” and Map “establishes the context to frame risks related to an AI system.” Measure uses quantitative, qualitative, or mixed methods to analyze and monitor risk, while Manage allocates resources to the risks that have been mapped and measured.

Govern works differently from the other three. NIST calls it “a cross-cutting function that is infused throughout AI risk management”, while Map, Measure, and Manage apply to specific systems and lifecycle stages. NIST also says the actions “do not constitute a checklist,” and most users start with Map once Govern outcomes are in place, then iterate.

Two companion resources sit beside the Core. The Playbook suggests voluntary actions for each outcome. Profiles tailor the functions to a setting, and NIST’s generative AI profile (NIST AI 600-1) tags its actions GV, MP, MS, and MG and centers on 12 risks and just over 200 actions.

Where the NIST AI RMF functions break down in enterprise practice

The framework defines outcomes and leaves the operating layer to each enterprise. The AI RMF defines risk-management outcomes rather than prescribing a universal set of technical thresholds or enforcement mechanisms. Organizations must select controls appropriate to their AI systems, including emerging agentic workflows and connected tools.

Few organizations have built that layer yet. In a 2024 survey of more than 200 financial services firms by ACA Group and the National Society of Compliance Professionals, only 12% of firms using AI had adopted an AI risk management framework, and only 32% had an AI committee or governance group.

GOVERN 1.6 calls for mechanisms to inventory AI systems, and the Cloud Security Alliance’s shadow AI whitepaper explains why that subcategory comes first. Teams can’t map AI systems they haven’t inventoried, and they can’t measure or manage what they haven’t mapped. Survey data shows how wide that gap runs for both employee AI and agents.

• Employee AI use is running ahead of policy. Gartner reports that 69% of cybersecurity leaders suspect or have evidence that employees use prohibited public GenAI, and IBM’s 2025 Cost of a Data Breach Report found that 63% of breached organizations lacked an AI governance policy or were still developing one. Among those with policies, only 34% audited regularly for unsanctioned AI.
• Agents add identities that most inventories never captured. In one Cloud Security Alliance survey, 82% of organizations have unknown AI agents in their environments, and a separate CSA survey found that 68% could not distinguish agent actions from human activity.

The gap carries a price. The same IBM report found that organizations with high levels of shadow AI paid an average of $670,000 more per breach than those with little or none. Each of these gaps sits inside a function that already exists on paper, so closing it means attaching each function to a control that runs where AI traffic actually flows.

How each NIST AI RMF function becomes an operating control

Each function can be supported by a combination of organizational processes, technical controls, monitoring, and evidence. Runtime controls are one important part of translating the framework into practice. Govern sets who may do what, Map and Measure supply the facts, and Manage acts on them. WitnessAI is a unified AI security and governance platform, the confidence layer for enterprise AI, that lets Global 2000 organizations observe, control, and protect AI activity routed through the platform across human employees and AI agents.

Govern: assign accountability and make policy enforceable

Govern outcomes depend on named owners and policies the organization can actually apply. GOVERN 2.3 states that “executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment,” and GOVERN 6 extends policy to third-party software, data, and other supply chain issues. NIST names senior leadership and the board as Govern actors.

An AI governance committee typically draws on legal, compliance, risk, information security, privacy, and IT. HR needs rules for employee AI use and training, and Marketing and Brand need limits on what customer-facing chatbots can say.

WitnessAI supports intent-based policies that organizations can configure around user context and business requirements. Its agentic security capabilities can provide visibility into agent identities and activity within supported integrations, helping security teams investigate agent behavior and establish accountability.

Map: build the inventory from observed activity

Map produces enough context for a go/no-go decision, and NIST expects users to keep applying it as context changes. MAP 4 requires risks to be mapped “for all components of the AI system including third-party software and data,” and MAP 1.1 asks teams to document each system’s intended purpose.

Self-reported inventories tend to miss Shadow AI because employees and developers rarely register what they adopt informally. WitnessAI’s Observe module provides network-level visibility without endpoint clients or browser extensions, drawing on a discovery catalog of 4,000+ AI applications. WitnessAI’s agentic observability capabilities can provide visibility into supported MCP server connections, tool usage, and agent activity through configured agentic security integrations.

Intent-based classification then records why each tool is used, which lets teams test MAP 1.1’s documented purposes against real behavior. With that inventory in hand, teams can approve new tools faster instead of defaulting to blanket bans.

Measure: test before launch and monitor in production

Measure asks for evidence both before and after deployment. MEASURE 2.4 requires functionality and behavior to be monitored in production, and the Playbook notes that systems “may encounter new issues and risks while in production.” MEASURE 3.1 tracks emergent risks in deployed contexts, and the GenAI profile’s MS-2.7-007 calls for AI red-teaming to assess resilience against prompt injection and other adversarial prompts.

Prompt injection belongs in both pre-launch testing and production monitoring. Keyword- and regex-based filters match strings without accounting for the context and purpose of a conversation, so they tend to miss prompt injection.

Witness Attack, WitnessAI’s automated red-teaming capability, runs those tests before deployment. In production, WitnessAI provides runtime guardrails for supported AI applications and models, with detection capabilities designed to address prompt injection and other AI-specific threats. Its published materials describe high-fidelity guardrail performance and support for more than 100 LLM types. Specific performance metrics should be accompanied by the relevant test methodology and deployment scope.

Manage: treat risk at the moment AI acts

Manage turns measurement into response. MANAGE 1.3 lists response options as “mitigating, transferring, avoiding, or accepting,” and MANAGE 2.4 requires mechanisms to “supersede, disengage, or deactivate” systems that perform inconsistently with intended use. The GenAI profile’s MG-3.1-001 adds “filtering GAI input and outputs” for third-party resources.

Binary allow/block controls give security teams only two responses to an AI request. WitnessAI supports policy actions including allow, warn, block, and routing eligible requests to configured AI models, so a request that breaks policy doesn’t have to end in a hard block. Those actions work alongside bidirectional defense for AI traffic routed through the platform.

• Data tokenization protects sensitive data before it leaves the enterprise. WitnessAI supports real-time detection and tokenization of sensitive information in supported AI workflows, helping reduce exposure before data is sent to an AI model. Available tokenization and restoration behavior depends on the configured protection workflow.
• Response protection keeps customer-facing chatbots on policy. In the Air Canada case, a tribunal held the airline responsible for what its chatbot told a customer, and response guardrails in WitnessAI’s Protect module filter off-policy answers before they reach customers.
• Pre-execution protection governs what agents do. WitnessAI’s agentic security capabilities support governance of connected tools and MCP servers, including policy controls over supported tool interactions. Where pre-execution enforcement is configured at the relevant tool boundary, organizations can restrict unauthorized tool calls and apply controls to agent actions.

Pre-execution controls can help organizations intervene before certain unauthorized agent actions occur. These controls support risk response under Manage, but they are not equivalent to the ability to disengage or deactivate an entire AI system.

CONTROL

Can You Prove How Your Organization Governs AI?

WitnessAI generates granular audit trails, enforces policies across every role and region, and redacts sensitive data before it ever leaves your network. Compliance-ready from day one.

See How Control Works →

Producing evidence that the functions are working

NIST points to maintained inventories and monitoring plans as signs that the functions are operating. The Playbook asks for an AI inventory with defined attributes and a named maintainer and suggests documenting how production metrics differ from pre-deployment testing. MANAGE 4.1 expects post-deployment monitoring plans that cover incident response, recovery, and change management.

Regulators expect the same kind of record. The EU AI Act’s high-risk obligations include “logging of activity to ensure traceability of results”, and Article 12 requires automatic recording of events over a system’s lifetime. The AI Omnibus moved the deadline for stand-alone Annex III high-risk systems to December 2, 2027. In the US, the SEC’s FY2026 examination priorities cover the training and security controls firms use to identify and mitigate new AI risks.

WitnessAI provides audit records for supported AI interactions, including prompt and response visibility where configured. Agentic observability can add records of supported agent and tool activity, helping compliance teams correlate evidence across enterprise AI use cases. WitnessAI supports enterprise AI security deployments across more than 40 countries, and InComm Payments’ CISO summed up the result: “We’re reducing risk while maximizing our productivity because of WitnessAI.”

Building the confidence layer under the AI RMF

The four functions give AI risk management a shared structure. They become defensible when inventory comes from observed activity, intelligent policies act on intent, runtime defenses help detect and mitigate prompt injection, off-policy responses, and unauthorized agent activity at supported enforcement points, and audit trails capture what happened. WitnessAI helps CISOs and compliance leaders document AI usage, policy enforcement, and security activity for internal governance and compliance reviews. Its capabilities can support secure AI adoption across employees and agentic workflows, with controls tailored to each environment. Schedule a demo to see how WitnessAI maps the AI activity routed through its platform to Govern, Map, Measure, and Manage evidence.