NIST AI Risk Management Framework Applied to Enterprise AI Rollouts

AI agents are already running inside enterprise systems, and most governance teams are still writing the policy that was supposed to arrive first. Okta's February 2026 citation of the Gravitee State of AI Agent Security Report puts the number at 91% of organizations with AI agents in active use, against just 10% with a formal strategy for managing the non-human identities those agents represent. That gap isn't a rounding error. It's the difference between an enterprise that knows what its AI touches and one that finds out during an incident review, after the damage is already logged somewhere nobody checked.

The cost of that gap shows up in numbers a CFO actually reads. Industry breach reporting has increasingly flagged unsanctioned AI tools as a contributing factor, and poor data quality and weak risk controls have been widely cited as reasons AI projects stall or get scrapped before they deliver value. Money isn't the constraint. Diligent put U.S. private-sector AI investment north of $100 billion in 2024 alone. What's missing is the governance work needed to know what all that money bought, where it's running, and what it can reach.

That leaves a lot of security and platform teams flying blind: no audit logs worth the name, no policy enforcement at the point of use, no real-time view into what an AI tool did five minutes ago. So how do security and platform teams build AI risk management without grinding deployment to a halt? NIST wrote an answer to that question, and most of the industry hasn't bothered to read past the executive summary.

What the NIST AI RMF actually is and why it suits enterprise deployment cycles

NIST published AI RMF 1.0 in early 2023. It's grown into one of the most widely cited voluntary AI governance frameworks around, backed by a steady run of companion playbooks, profiles, and evaluation tools through 2024 and 2025. The framework rests on four functions: Govern, Map, Measure, and Manage. Most people read those as four steps in a project plan, check each box once, and move on. That's the wrong read. NIST built them as interconnected, ongoing processes meant to run across the full life of an AI system, and treating the RMF as a checklist you clear once and file away defeats the entire point of the design.

The voluntary structure matters more than it sounds like it should. Enterprises adopt the framework at their own pace and fit it onto governance structures they already run, instead of ripping out existing compliance work to start fresh. NIST has published official crosswalks connecting the RMF to ISO/IEC 42001, to EU AI Act conformity workflows, and to SOC 2 AI controls, so a team already living inside one of those regimes isn't stuck duplicating paperwork.

The framework has also kept pace with how AI actually gets built and shipped, which sets it apart from a document written once and forgotten in a shared drive. NIST AI 600-1, the Generative AI Profile released in July 2024, covers twelve risk categories including prompt injection, data leakage, and supply chain risk. NIST IR 8596, a preliminary Cybersecurity Framework Profile for AI released in December 2025, tackles the three-sided problem of securing AI systems, using AI for defense, and defending against AI-enabled attacks. The Cloud Security Alliance went further, proposing an Agentic AI extension to the RMF that covers agent autonomy, tool-use risk, runtime behavior, and who's accountable when one agent hands a task to another; it lines up with the CSA AI Controls Matrix published in July 2025.

None of that is academic housekeeping. Enterprises don't deploy AI in one shot; they roll it out in phases, expanding scope as trust builds and use cases multiply, and the RMF's four functions map onto that same rhythm. Each function lands as an actual milestone in a deployment, not a document written to satisfy an auditor and then never opened again.

Govern: building the policy and accountability layer before the first model goes live

Govern is the organizational layer underneath everything else: leadership buy-in, a risk culture that doesn't treat AI as some special exception to how the business already manages risk, and clear accountability so every deployment decision survives being questioned six months later. Skip this step and the rest of the framework has nothing to stand on.

In practice, Govern means naming names. Who owns AI risk decisions? Who signs off before a new tool goes live? Who's on the hook when something breaks? It means writing down which AI tools are sanctioned, what categories of data they can touch, and under what conditions, then putting a cross-functional group in the room, security, legal, IT, and the business units, because none of them can govern this alone.

Shadow AI is what happens when Govern doesn't exist, or exists only on paper. A substantial share of the SaaS applications running inside the average enterprise are unauthorized to begin with, and AI tool sprawl just stacks another layer on a problem that was already out of control. Enterprises have had to learn to treat shadow IT as an enforcement problem rather than a curiosity. Shadow AI needs the same treatment, and the infrastructure to back it up.

Non-human identity is the piece almost nobody has built, and it's the one worth losing sleep over. Only 10% of organizations, per that same Okta citation, have a formal strategy for managing agents, service accounts, and automated workflows as identities in their own right. An agent that can read a mailbox or call an internal API needs to be provisioned and deprovisioned through the same identity systems, Okta, Entra ID, SAML, OIDC, that already govern human employees. Treat it as a special case instead, and it disappears from the picture entirely; that's how an agent ends up with standing access nobody remembers granting, sitting there until someone finds it the hard way.

NIST's 2025 guidance also pushes enterprises toward an AI Bill of Materials: a full inventory of every model, data source, and third-party vendor involved. Govern is where that inventory lives and where somebody's name gets attached to it. Done right, this stage produces a governed catalog of every AI system in production, a named owner for each one, and a policy that covers sanctioned tools while giving someone the means to spot the unsanctioned ones.

Map: understanding what each AI system actually touches before it causes harm

Map asks a deceptively simple question: what does this thing actually reach? For every AI system, that means understanding the environment it runs in, who it affects, what data it can access, and which downstream systems it's allowed to call.

Start with the basics. What is the system supposed to do, and who does it touch? What data types flow through it, flagged explicitly for anything personally identifiable, financial, medical, or a credential? What third-party pieces is it built on: pre-trained models, open-source libraries, vendor APIs, MCP servers? NIST's 2025 AI-BOM guidance applies here too: map the model itself, where its training data came from, and every external tool it can invoke.

Agentic systems make this exercise a lot harder than it used to be. An agent that reads email, queries internal APIs, browses the web, and calls out to external tools through MCP doesn't have a fixed attack surface the way a static model does; what it can reach expands the longer it runs. The CSA's proposed Agentic AI extension specifically adds runtime behavioral governance and delegation chain accountability to cover exactly this gap. Map has to account for what an agent can touch while it's operating, not just what it was designed to touch on day one.

Prompt injection belongs squarely in this stage, and it's the risk most teams still underrate. OWASP's 2025 Top 10 for LLMs lists it as the primary threat category, covering both direct attacks and indirect injection buried inside content the model reads from somewhere else. The EchoLeak incident from mid-2025, where Microsoft 365 Copilot exfiltrated data through nothing more exotic than a background email read, is the textbook case. There was no clever exploit; the attack surface was an ordinary inbox. Catching exactly that class of risk before deployment, rather than after, is what Map exists for. A completed Map stage produces a risk context document per system: data flows, dependencies, affected stakeholders, threat vectors, signed off by a named owner from the Govern layer.

Measure: turning identified risks into signals the organization can actually act on

Measure is where risk stops being a story people tell in a meeting and becomes a number somebody can check on a screen. It means setting metrics, running assessments, and building the telemetry that tells someone whether the controls in place actually work.

That requires defining, concretely, what "acceptable risk" means for each system: thresholds for data exposure, how fast a violation gets caught, an acceptable rate of policy violations before someone gets paged. It means audit logging every AI interaction: who called the model, what prompt went in, what data got touched, what came out. And it means tracking usage and cost per team, per agent, per tool call, because that number is both an operational signal and a piece of governance evidence.

Without real-time visibility into how AI tools actually get used, Measure turns into paperwork nobody reads, and closing that gap is what AI governance and observability platforms are built around. Gartner, cited by Witness.ai in 2026, projects that 40% of enterprise applications will include AI agents by 2026, up from a small minority in 2025. That's a scale problem, and most teams' instrumentation isn't growing fast enough to keep up with it.

MCP gateways solve a real chunk of this. A gateway sitting between agents and the tools they call gives Measure something concrete to work with: every tool invocation logged, every policy check recorded, cost and usage broken out by key or by team. Done this way, the audit trail SOC 2, GDPR, or HIPAA requires becomes a byproduct of how the system already runs, instead of a separate exercise someone does by hand every quarter.

MITRE ATLAS is worth building detection rules against, because it gives Measure a documented taxonomy of adversarial techniques specific to AI and ML systems, rather than leaving detection to generic anomaly scoring with no named threat behind it. A finished Measure stage looks like a live dashboard: policy violations, prompt injection attempts, PII exposure events, cost per agent, usage by team, all tied back to the thresholds Govern set and the threats Map identified.

Manage: turning measurement into enforcement and keeping governance current as AI evolves

Manage is where the organization does something with what it measured: prioritize the real risks, apply controls, fix what broke, and update policy, repeatedly, as an ongoing exercise rather than a one-off.

That means having an actual incident response playbook for AI-specific events: prompt injection caught in the act, an attempted PII exfiltration, a shadow AI tool somebody finds running unsanctioned, an agent acting outside the scope it was authorized for. It means enforcing role-based access at the AI layer itself, not just gating who can log into a tool but which data and which downstream tools each role can reach, tied into the identity providers the organization already runs rather than bolted on separately. And it means blocking in real time, not just logging after the fact, when something crosses a line: a secret typed into a prompt, PII showing up in an output, a call to an MCP server nobody approved.

The feedback loop here is explicit in how NIST wrote the framework. Manage feeds straight back into Govern. A new threat found in production updates the Map. New incidents reset the thresholds Measure is watching for. Gaps an incident reveals in policy go back to Govern for a rewrite. This runs as a continuous loop rather than an annual audit, which is exactly why NIST describes the four functions as interconnected rather than sequential.

Agentic systems push Manage into territory that didn't used to count as AI governance at all: runtime behavior. When an agent can pick up new tools on its own, spin off sub-agents, and act across a multi-step chain nobody scripted in advance, whatever controls got set at deployment time simply aren't enough anymore. The CSA's Agentic AI extension and the AAGATE reference architecture, published in December 2025, both address this directly, covering delegation chain accountability, approval workflows for tool use, and anomaly detection at the level of the individual agent. A finished Manage stage looks like response playbooks that have actually been run through a tabletop exercise, RBAC enforced through the identity provider rather than a spreadsheet, real-time blocking active at the gateway, and a set cadence for revisiting every other function's output as the deployment changes underneath it.

How the four functions work as a continuous loop rather than a linear checklist

NIST built the RMF to loop, full stop. Treating it as a straight line from Govern to Manage misses the point entirely, and any team that runs it that way will find out the hard way when an incident traces back to a step nobody revisited.

Here's what the loop looks like in motion. An agent picks up a new capability in production, Manage catches it, and that triggers a fresh Map assessment of the attack surface it just gained, which resets Measure's thresholds, which might send a policy change back up to Govern. A gateway flags a shadow AI tool nobody approved, that's Measure doing its job, and Govern has to decide fast whether to sanction it, block it outright, or quarantine it while somebody investigates. A prompt injection incident gets caught and handled by Manage, and the detection rules that catch the next one get written into Measure's baseline while Map's threat inventory gets updated to match.

Gartner's 40%-by-2026 projection for agent-equipped enterprise applications, up from a small minority in 2025, carries weight beyond a slide-deck statistic. At that rate of change, an annual review cycle is already months stale by the time anyone reads it.

There's real efficiency on offer here, too. Organizations already running ISO/IEC 42001 or EU AI Act conformity processes can map their existing review calendars onto the RMF's four functions instead of running two governance tracks side by side. Set the cadence on purpose: Govern reviewed quarterly at minimum, with extra reviews triggered by an incident or a major new agent capability; Map redone for every new system or any material change to what an existing one can touch; Measure running continuously, with thresholds checked weekly or monthly and deep dives triggered by incidents; Manage responding the moment something's detected, with playbooks reviewed after every event worth reviewing.

Where current RMF guidance leaves gaps that enterprise teams need to fill

The RMF gives enterprises structure. It does not hand them a finished system, and any team that treats it as complete is setting itself up to be surprised later, probably during an incident review rather than a planning meeting.

Agentic AI is the clearest gap, and it's not a small one. NIST's core framework was written before autonomous, tool-using agents became a mainstream deployment pattern, and the CSA's proposed extension, useful as it is, remains an outside addition rather than something baked into NIST's own text. Delegation chains, where one agent hands a task to another and that agent hands it to a third, raise accountability questions the base RMF was never built to answer: when an agent three hops down the chain does something wrong, whose Govern policy actually got violated?

Non-human identity management sits in a similar spot. The RMF talks about accountability and governance in the abstract, but it doesn't spell out how to provision, monitor, and retire an AI agent's identity the way federated identity standards already do for human users. Each enterprise is left to figure this out alone, and most haven't: recall that 10% figure on formal non-human identity strategy, worth repeating here because it's the single most damning number in the whole picture.

Runtime behavioral monitoring is thinner in the guidance than deployment-time risk assessment. Map and Measure, as NIST describes them, lean toward assessing a system before and during rollout. Watching what an autonomous agent does moment to moment, in production, over the full arc of a multi-step task, needs tooling and standards that are still being built, largely outside NIST's own publications, by groups like CSA and by the vendor ecosystem forming around MCP.

Finally, the framework has nothing to say about MCP-specific risk, which is a strange silence given how fast MCP became the default way agents reach tools and external systems. It introduces its own worries: how servers get authenticated, whether the tools an agent connects to actually are what they claim to be, how permissions get scoped. NIST hasn't caught up to the protocol yet, and enterprise teams that wait for a future update to cover it will be waiting through several more product cycles. The framework is a foundation still under construction. The teams getting real risk management out of it right now are the ones pouring the missing floors themselves, on their own schedule, because nobody's coming to do it for them.