NIST AI RMF for AI Agents: Govern, Map, Measure, and Manage (2026)

The NIST AI Risk Management Framework (AI RMF 1.0), published as NIST AI 100-1 on January 26, 2023, is the document most U.S. enterprises now reach for when a board or auditor asks how they govern AI. It was directed by the National AI Initiative Act of 2020 and developed by NIST through an open, multi-stakeholder process. It is voluntary, sector-agnostic, and use-case-agnostic, and its stated purpose is to help organizations manage risk to individuals, organizations, and society across the full AI lifecycle while promoting *trustworthy AI*.

The framework was written for the AI most teams had in 2023: models that classify, predict, and generate. It was not written for software that acts - autonomous agents that call tools, chain steps, delegate to other agents, and reach into your file systems and APIs through MCP servers. The good news is that the AI RMF's structure holds up well for agents; the hard part is that agents break the one assumption the framework quietly depends on - that you know which AI systems you have. This guide walks the framework as it actually is, then maps it to the agentic reality without inventing precision the standard does not provide.

What the NIST AI RMF actually is

The AI RMF is outcome-based and descriptive, not prescriptive. This is the single most important thing to understand before you try to use it. Unlike a control catalog such as NIST SP 800-53, it does not give you numbered controls, maturity scores, or pass/fail tests. It describes outcomes you should be able to demonstrate and leaves the *how* to you. A companion document, the AI RMF Playbook, offers suggested actions, documentation, and references for each outcome - but those are suggestions, not requirements.

The framework comes in two parts. Part 1 frames AI risk and defines the seven characteristics of trustworthy AI. Part 2 is the Core - the four functions, categories, and subcategories that organize the work. The whole thing is explicitly iterative, not a linear checklist you complete once.

The seven trustworthy-AI characteristics

Part 1 names seven properties that, together, define trustworthy AI. They are not abstract: the MEASURE function maps subcategories directly onto them, so they become the things you actually evaluate.

• Valid and reliable - the foundational characteristic the others build on
• Safe - does not, under defined conditions, endanger life, health, property, or environment
• Secure and resilient - withstands and recovers from adversarial events
• Accountable and transparent - actions are attributable and visible
• Explainable and interpretable - outputs and mechanisms can be understood
• Privacy-enhanced - respects norms and values around autonomy and data
• Fair, with harmful bias managed - equity considerations are addressed

The Core: Govern, Map, Measure, Manage

The Core organizes work into four functions → 19 categories → 72 subcategories. GOVERN is cross-cutting and is meant to inform the other three; MAP, MEASURE, and MANAGE are roughly lifecycle-ordered - establish context, then measure, then respond - but you cycle through them continuously rather than once.

Two profiles extend the Core. The Generative AI Profile (NIST AI 600-1), published July 26, 2024 under Executive Order 14110, identifies 12 GenAI risk areas - including confabulation, data privacy, information security, information integrity, value chain and component integration, harmful bias, and human-AI configuration - and maps 200+ suggested actions to the four functions. It is the closest official extension to agent-relevant risk today. Notably, a formal NIST 'Agentic Profile' does not yet exist; the Cloud Security Alliance published a draft community 'Agentic AI Profile' in late 2025 to fill the autonomy gap, but it is not a NIST standard.

Why agents and MCP servers stress the framework

AI RMF assumes a known system you are deploying deliberately. Agentic AI violates that assumption in three ways. First, agents arrive bottom-up: a developer installs a coding agent, an analyst wires up an MCP server, and neither shows up in any inventory. Second, agents act - they hold credentials, call tools, and chain multi-step operations whose blast radius is hard to predict. Third, agents delegate, diffusing accountability across human and machine identities. We have written about this dynamic at length in Why AI Agents and MCP Servers Are the New Shadow IT and in MCP Server Security: The Complete Guide.

None of this requires a new framework. It requires reading the existing one honestly: every function below has an agentic interpretation, and most of them quietly assume a capability - visibility into the agent fleet - that few organizations actually have.

Mapping the functions to agentic risk

Operationalizing it for a security team

Treat the four functions as a continuous loop you run against the fleet, not a binder you fill out once. Here is a pragmatic sequence that respects the framework's intent while staying grounded in what agents actually do.

1. GOVERN - establish ownership and discover the fleet

GOVERN 1, 2, and 6 are unsatisfiable on paper alone. Before you can write a policy for AI agents, name an owner, or assess a third-party MCP server, you have to know they exist. Start with discovery: enumerate every agent runtime, CLI, IDE extension, and MCP server on endpoints and in CI. Our walkthrough of what surfaces when you scan AI configs shows how much of this is invisible by default. Assign each discovered agent an owner and a record - that record is the spine everything else hangs from.

2. MAP - classify tools, permissions, and blast radius

For each agent, satisfy MAP 2–4 by classifying its tasks, its tool and MCP permissions, and the data it can touch. The practical question is excessive agency: does this agent hold more authority than its job requires, and how reversible are its actions? Coding agents and CLIs are the sharpest case because they execute code and hold tokens - see Securing AI Coding Agents and CLIs. Third-party MCP servers belong here too, under MAP 4 and GOVERN 6, because an acquired tool provider can carry supply-chain risk you inherit; AI Supply-Chain Attacks: A Defender's Guide covers that threat model.

3. MEASURE - monitor behavior and emergent risk

MEASURE 2 and 3 ask you to evaluate trustworthiness and track *unanticipated and emergent* risk over time. For agents this means runtime behavioral telemetry - action velocity, permission escalation, delegation depth - and watching tool inputs and outputs for the agentic flavor of prompt injection, where adversarial instructions arrive through a tool result rather than the user prompt. That class of attack is documented in our coverage of MCP tool poisoning. MEASURE is where a static inventory becomes a living one.

4. MANAGE - respond, contain, and decommission

MANAGE 1, 2, and 4 turn measurements into action: prioritize risks, keep an override or deactivation path (MANAGE 2's kill-switch outcome), correct behavioral drift, and decommission agents cleanly. For a runaway or compromised agent - the scenario in multi-agent prompt injection and credential theft - you need to know which identity is affected, what it can reach, and how to revoke it fast. None of that works without the visibility you built in GOVERN and MEASURE.

Where continuous agent and MCP visibility fits

Read across the four functions and a pattern emerges. GOVERN needs an inventory. MAP needs permission and data-reach classification. MEASURE needs runtime behavioral telemetry. MANAGE needs an identity-aware response path and a record to act on. And across all of them, NIST asks for documentation, monitoring, and incident tracking that you can produce on demand. For traditional software you get most of that from existing asset, IAM, and SIEM tooling. For autonomous agents and MCP servers, those tools largely do not see the layer at all.

That gap - continuous discovery, permission monitoring, behavioral anomaly detection, and a queryable audit trail for every agent and MCP server - is the category Anomity works in, and the reason we describe our discovery approach in Inside Anomity Discovery. The framing matters more than any product: the AI RMF is evidence-able only when the agent layer is visible. If you are governing coding assistants specifically, Governing AI Coding Assistants Across Your Fleet maps these same functions to that narrower problem.

Common mistakes

• Treating it as a control checklist. There are no numbered controls or scores in the AI RMF - do not invent them or cite control numbers that do not exist.
• Skipping GOVERN discovery. Writing AI policy before you have an agent inventory produces a document that describes systems you cannot see.
• Ignoring third-party MCP servers. GOVERN 6 and MAP 4 explicitly cover acquired components; unvetted MCP servers are exactly the supply-chain risk they target.
• Running it once. The framework is iterative. Agents change behavior, permissions, and tooling continuously, so MEASURE has to be continuous too.
• Confusing the GenAI Profile with an agent profile. NIST AI 600-1 helps, but no official NIST agentic profile exists yet; do not cite one as a NIST standard.

Bottom line

The NIST AI RMF is a strong, durable scaffold - voluntary, outcome-based, and broad enough to absorb agentic AI without amendment. Its four functions map cleanly onto the work of governing an agent fleet: discover and own (GOVERN), classify permissions and blast radius (MAP), monitor behavior and drift (MEASURE), and respond and decommission (MANAGE). The framework's only blind spot is the one it inherited from a pre-agentic world: it assumes you can already see your AI. For autonomous agents and MCP servers, earning that visibility is the first and load-bearing step. You can't govern what you can't see - and with agents, you usually can't see it yet.