NIST Risk Management Framework for AI Agents

The NIST AI Risk Management Framework wasn't built with autonomous agents in mind, and that gap shows up the moment you try to govern a system that acts on its own. I spent weeks trying to map GOVERN, MAP, MEASURE, and MANAGE onto agentic deployments before I understood why the fit felt off: the base framework gets you most of the way there, but not all the way.

Where the base RMF was not designed to go: the structural gaps agentic AI exposes

NIST published the AI RMF on January 26, 2023, after pulling together input from more than 240 organizations across government, industry, and academia. It's voluntary by design, and it doesn't tell you exactly what to build. That flexibility is the point: a hospital system and a bank and a logistics company can all use the same four functions, GOVERN, MAP, MEASURE, MANAGE, without NIST prescribing a single control.

But the framework assumes something that agentic AI breaks: a system with fixed boundaries, where a human is watching most of the time. Agents don't work that way. They call tools, they write to databases, they send messages, and they do it fast enough that a human might not know anything happened until it's already done.

I kept running into the same four gaps whenever I tried to map the base RMF onto an agent.

First, there's the speed problem. An agent can delete records, fire off an email, or push a config change before anyone notices something's wrong. That gap between action and observation is new. MEASURE and MANAGE, as written in 2023, don't have a mechanism for closing it.

Second, accountability gets thin in multi-agent chains. When one agent spawns three sub-agents to handle parts of a task, who owns the outcome if step four goes sideways? The base RMF doesn't have a category for that kind of distributed responsibility.

Third, the attack surface changed shape entirely. Prompt injection buried in a tool's output, memory that persists across sessions, a poisoned link in a chain of tool calls: MAP as originally written has no concept of a system that picks up new capabilities while it's running.

Fourth, and maybe most practical: tool-use authorization, memory security, cross-organization trust. None of it shows up in the original subcategories, because none of it existed as a design concern in 2023.

One practitioner assessment submitted to NIST put a number on this: the base framework covers something like 60 to 70% of what agentic governance actually needs. That's not a small gap. It's the difference between a framework that mostly works and one that leaves real risk unaddressed. NIST answered with AI 100-5, the Agentic AI Profile, its first document scoped specifically to this class of system. CSA Labs put it plainly in an April 2026 assessment: multi-agent delegation chains create accountability distributions that existing RMF categories don't capture.

None of this is a reason to skip the RMF. It's the reason to use it deliberately, with agent behavior, autonomy, and data access built into every function instead of assumed away.

GOVERN applied to AI agents: making autonomy a deliberate organizational decision

GOVERN in the base framework is about structure: who's responsible, what's the risk tolerance, what are the policies. For agents, none of that can stay generic. You need answers that are specific to what an autonomous system is allowed to do without asking first.

Start with authorization boundaries. Which actions can an agent take with zero human confirmation? Which ones need a checkpoint? Which ones are off-limits no matter what the agent thinks it's optimizing for? If you haven't written that down, your agent's behavior is being decided by whoever wrote its prompt, not by your organization.

Identity matters just as much. Every MCP server, every agent in your stack, should have an entry in a registry somewhere. An identity nobody's tracking is the one that gets exploited first, because nobody's watching it.

Access control needs the same rigor. Role-based permissions for agents should reflect a decision your team made on purpose, not whatever permissions got inherited from the user session the agent happened to spin up under. And when agents delegate to sub-agents, governance has to specify who's on the hook for the whole chain, not just whoever kicked it off.

Here's the part that took me longest to accept: governance speeds things up. Teams that build a governed path to their tools ship agents into production faster than teams that plan to "secure it later," because the guardrails are what get a deployment approved in the first place. Blocking tool access without offering a sanctioned alternative doesn't stop adoption, it just pushes it underground. Shadow AI is what happens when governance shows up as a wall instead of a path.

There's real regulatory weight behind this now, too. OMB Memoranda M-25-21 and M-25-22, both from April 2025, lay out federal governance and procurement rules that already apply to a lot of agentic deployments under the "High-Impact AI" label. That's not theory anymore. It's a compliance deadline for a growing number of organizations.

MAP applied to AI agents: accounting for tool access, data flows, and attack surface before deployment

MAP is supposed to catalog your system: its context, its data, its dependencies. Agents blow up the scope of that catalog because they pick up access and capability while they're running, not just at build time.

The first thing to inventory is every tool, API, and MCP server an agent can reach, including the ones it can only get to indirectly, through another agent it happens to be talking to. Miss one, and you've missed a door into your system that nobody's guarding.

Data flow mapping gets harder too. Agents move a lot more data than a person clicking through a UI ever would, and you need to track what crosses which boundary during a single session, not just what the model sees at inference time.

Then there's the access gap. Agents routinely get granted far more permission than their actual job requires, because it's easier to overprovision than to scope things precisely. MAP should be finding that gap, the space between what an agent can touch and what it actually needs to touch, before deployment, not after an incident.

Prompt injection deserves its own line item. NIST AI 600-1, published in July 2024, classifies both direct and indirect prompt injection as information security risks under section 2.9. For agents, MAP means tracing every path where untrusted content, a scraped web page, a tool's return value, a document pulled from a shared drive, could land in the agent's context window.

Supply chain sits in the same category. AI 600-1 treats it as a value chain and component integration risk under section 2.12, and for agents that means every MCP server, every third-party tool, every external API the agent touches is part of what it can actually do. NIST AI 100-2 E2025, from March 2025, went further and named agents explicitly as a threat surface for the first time, covering indirect injection, tool supply chain attacks, poisoning of retrieval knowledge bases, and prompt worms that spread across multiple agents.

If you find one of these attack paths after you've already deployed, that's not a security surprise. It's a governance failure. The vulnerability was sitting there the moment that server went live ungoverned.

MEASURE applied to AI agents: why real-time observability replaces periodic evaluation

MEASURE in the base RMF is about tracking performance and outcomes over time. For agents, the word that changes everything is "time." Evaluation cycles built for a static model version don't work when the system in front of you is taking actions right now.

Think about why the tempo matters. An agent can trigger a cascade, deleting records, sending messages, changing settings, faster than a human review cycle can catch up. A measurement system that surfaces results hours later isn't a safety net anymore. It's a postmortem.

Drift is harder to spot in agents than in models, too. The exact same model can produce wildly different chains of action depending on what tool state it walks into, what's sitting in its memory, or what got slipped into its context by something it read.

So what does agentic MEASURE actually need? A full session-level audit trail: every tool call, every read and write, in sequence, not just the final output the model spit out. Real-time anomaly detection that flags an unexpected tool call or an access attempt outside the agent's scope as it happens, not the next morning. And in multi-agent setups, measurement has to follow the whole delegation chain across orchestrator and sub-agents together, because looking at each one in isolation misses the interaction between them.

NIST's own research, from January 2025, found that novel attack strategies against agents succeeded 81% of the time in red-team testing, against just 11% for baseline defenses. That gap alone tells you a measurement approach built for last decade's threat model will miss most of what agents actually face today. OWASP ranks prompt injection as LLM01 in its 2025 top-ten list for large language models, and because an agent acts directly on what's in its context, an injection that slips past MEASURE doesn't just produce a bad answer. It produces an action nobody approved.

An audit log is only useful in real time. Read after the fact, it tells you what happened. It doesn't stop it from happening.

MANAGE applied to AI agents: operationalizing mitigation when the system acts autonomously

MANAGE is where you prioritize and mitigate risk, including risk from third parties. For agents, the mitigation has to run at the same speed the agent does, or it's not really mitigation.

Gateway enforcement is the core piece: a layer that sits between the agent and its tools, watching every call in real time, able to block it, slow it down, or require a human sign-off before it executes rather than after. Pair that with automated circuit-breakers, policy triggers that cut off a session the moment behavior crosses a line you've defined, without waiting on someone to read a dashboard.

Third-party risk has to extend past your own code. Every MCP server and outside API an agent touches is part of your risk surface now, whether or not your team built it. And incident response plans need to account for the fact that by the time you've confirmed something went wrong, the agent may have already finished a dozen downstream actions off the back of it.

There's real infrastructure coming to support this. The COSAiS project, announced in mid-2025, is building SP 800-53 control overlays for both single-agent and multi-agent deployments, giving enterprises a way to map existing NIST controls onto agentic systems before the final overlays land, which NIST expects sometime in late 2026 or 2027. In the meantime, AI 600-1 offers more than 200 suggested actions organized by RMF function, a solid starting reference for generative AI risk generally, even though the sharper, agent-specific controls will come from AI 100-5 and the COSAiS overlays once they're finished.

The friction people blame on security controls is almost never the control itself. It's the absence of a gateway. Done right, MANAGE is what lets a team move fast and stay safe at the same time, not a tradeoff between the two.

How the companion publications fill in what the base RMF left open for agents

NIST didn't leave the base framework to stand alone. A stack of companion documents fills in exactly where GOVERN, MAP, MEASURE, and MANAGE fall short for agents.

AI 600-1, the Generative AI Profile from July 2024, was first out the door, mapping RMF subcategories directly to generative AI risks like prompt injection and supply chain integrity. Federal agencies already use it as their reference under OMB M-24-10, and it's the sensible starting point for most enterprises while agent-specific profiles keep maturing.

AI 100-2 E2025, from March 2025, expanded NIST's adversarial machine learning taxonomy to name agents as a threat surface directly, covering indirect injection, tool supply chain attacks, knowledge base poisoning, and worm-like propagation across multiple agents. This is the threat model MEASURE and MANAGE teams should actually be building against.

AI 100-5, the Agentic AI Profile, is the first NIST document built for autonomous agents specifically. It takes on the risks of autonomy head-on and closes the conceptual hole the base framework left around multi-agent architecture and delegation accountability.

NIST IR 8596, a preliminary draft from December 2025, maps CSF 2.0 functions to three AI security objectives: securing AI components, using AI for cyber defense, and countering AI-enabled attacks. For any organization already running a CSF 2.0 program, it's the most direct bridge into AI-specific risk without rebuilding the whole security program from scratch.

The COSAiS overlays, once published, will give teams a structured way to operationalize MANAGE against SP 800-53. Nothing final has shipped as of April 2026; expect late 2026 or 2027.

CSA Labs put out its own Agentic NIST AI RMF Profile in May 2026, proposing extensions for agent autonomy, tool-use risk, runtime behavior governance, and delegation accountability, tied to its AI Controls Matrix of 243 controls across 18 domains. Until NIST's own agentic profile fully matures, it's the most developed outside supplement available.

And on the institutional side, NIST launched its AI Agent Standards Initiative, CAISI, on February 17, 2026, the first U.S. government program focused on agent interoperability, open protocol work including Model Context Protocol, and foundational research into agent identity and authorization. That's a signal worth sitting with: the gap between the base RMF and agentic deployment is closing at the institutional level, not just through scattered practitioner workarounds.

What a governed agentic deployment looks like when all four functions work together

Picture an agent that handles customer refunds. GOVERN has already decided it can approve refunds under $50 on its own, flag anything higher for a human, and never touch a customer's payment method directly. MAP has cataloged every tool it can call, the refund API, the CRM lookup, the email service, and flagged that its CRM access is broader than the job needs. MEASURE is watching every session in real time, logging each call in sequence, ready to flag the moment it tries something outside its lane. MANAGE has a gateway sitting in front of the refund API, ready to block or pause the moment a threshold gets crossed, and a playbook ready if it doesn't.

That's not four separate compliance exercises. It's one system, watched from four angles, each one covering what the others can't. Miss GOVERN, and MAP has nothing to check against. Skip MEASURE, and MANAGE is reacting blind. Run all four together, built for autonomy from the start instead of bolted on after a scare, and you get something rare in this industry: an agent that's fast because it's governed, not despite it.