NIST AI RMF for AI Agents: Applying the Framework to Autonomous Agents

The NIST AI Risk Management Framework was built to manage risk across the AI lifecycle in general, but agentic AI is the case that stresses it hardest. Applying NIST AI RMF to autonomous agents means confronting a simple fact the base framework was never written with in mind: agents plan, decide, and act using tools, and every tool call expands the attack surface a chatbot never had. This guide walks through applying NIST AI RMF to AI agents function by function, covers where NIST's own 2026 initiatives are extending the framework, and flags the gaps you still need to close with other standards. If your team is scoping a NIST AI RMF autonomous agents program from scratch, the section on implementation timelines near the end is the fastest place to start.

Why Agentic AI Stresses the Base NIST AI RMF

NIST AI RMF 1.0, published in January 2023, organizes risk work around four functions: Govern, Map, Measure, and Manage. It was designed for AI systems broadly, including classifiers and generative models that produce an output and stop. Autonomous agents do not stop. They call tools, chain decisions across multiple steps, and sometimes hand off tasks to other agents without a human reviewing each move. NIST AI RMF Govern Map Measure Manage agents work looks different from function to function because agent risk compounds across a session rather than showing up in a single inference.

What Changes When a System Acts, Not Just Responds

A generative model that drafts a paragraph carries content risk. An agent that reads that paragraph, decides it means "send the invoice," and calls a payment API carries execution risk on top of it. The base AI RMF treats "output" as the end of the risk surface. For agents, output is a midpoint. Every tool call is a new decision point where a manipulated instruction, a poisoned document, or a misread context can turn into a real-world action: a file deleted, a transaction sent, a record changed. That shift from responding to acting is the single biggest reason organizations cannot apply AI RMF to agents the same way they applied it to a standalone model.

The Generative AI Profile (NIST AI 600-1) as the Bridge Document

NIST published NIST AI 600-1, the Generative AI Profile, in July 2024 in response to Executive Order 14110. It maps the same four RMF functions to twelve risk categories specific to generative AI, including confabulation, data privacy, information integrity, and information security, with more than 200 suggested actions organized by function. AI 600-1 is a useful bridge because it already extends RMF beyond the 2023 baseline. But it was written for content generation, not tool-calling autonomy. It does not address delegation chains, multi-agent coordination, or runtime permission boundaries, which is exactly the terrain agentic deployments now live in.

Applying Govern to Autonomous Agents

Govern is the function that sets accountability and culture before anything gets built. For agents, that means defining ownership at a level of granularity most organizations have not needed before.

Assigning Accountable Owners Per Agent, Not Per Model

A traditional AI governance structure assigns an owner to a model. That breaks down once one model powers a dozen different agents, each with different tool access, different data scopes, and different blast radii if something goes wrong. A customer support agent with read-only access to a knowledge base carries a different risk profile than a DevOps agent with write access to production. Under Govern, each deployed agent needs its own named accountable owner, its own documented purpose, and its own risk tier, even if several agents share the same underlying model. Without that granularity, incident response has no clear owner to call when a specific agent misbehaves.

Governance Structures for Multi-Agent Systems

Multi-agent systems raise a second governance question: who is accountable when Agent A delegates a task to Agent B, and Agent B's action causes harm? Govern needs to define delegation policy before deployment, not after an incident. That includes which agents are allowed to invoke which other agents, whether an orchestrating agent can grant permissions it does not itself hold, and how audit trails capture the full chain rather than just the final action. Organizations running multi-agent pipelines should treat the orchestration layer itself as a governed system, with its own owner, rather than assuming governance of the individual agents is enough.

Applying Map to Autonomous Agents

Map is where an organization establishes context: what the system does, who it affects, and what could go wrong. For agents, mapping starts with a question most security teams cannot yet answer confidently.

Agent and Tool Inventory as a Prerequisite

You cannot map risk for an agent you do not know exists. Most of NIST AI RMF's Map-function work, and frankly most of Measure and Manage, assumes a current, accurate inventory of every deployed agent and every tool each one can call. Shadow agents, spun up by individual teams without central review, and undocumented MCP server connections are the most common gaps. Before any meaningful Map-function work can happen, an organization needs a living inventory that captures each agent's purpose, its tool and data access, its owner, and its risk tier. Teams that skip this step and jump straight to controls end up governing only the agents they already knew about.

Mapping Delegation Chains and Trust Boundaries

Once the inventory exists, Map extends into tracing how trust flows between systems. If Agent A can call Agent B, and Agent B holds credentials to a finance system, then Agent A effectively has indirect access to finance, whether anyone documented that or not. Mapping delegation chains means diagramming these indirect paths explicitly rather than assuming each agent's documented permissions represent its true reach. This is also where trust boundaries get defined: which systems an agent's outputs should never be allowed to cross without a human checkpoint, and which tool calls should require step-up authorization regardless of how routine the request looks.

Applying Measure to Autonomous Agents

Measure is where NIST AI RMF asks you to test the system against defined risk. Static benchmarking, the kind that works for a single-turn model, does not capture agent behavior well, because agent risk shows up across sequences of actions rather than in one output.

Red Teaming for Prompt Injection and Excessive Agency (OWASP LLM01/LLM06)

The OWASP Top 10 for LLM Applications gives Measure-function work a concrete target. Prompt Injection (LLM01) remains the top-ranked risk in the 2025 edition, and it is the most direct way an attacker steers an agent's behavior without touching its code. Excessive Agency (LLM06) is the closer match for agent-specific risk: OWASP breaks it into excessive functionality, where an agent can reach tools beyond its assigned task, excessive permissions, where those tools carry broader privileges than the task needs, and excessive autonomy, where high-impact actions proceed without any human checkpoint. Red teaming under Measure should test both directly, including indirect prompt injection through documents or web content the agent reads mid-task, not just direct chat-style attacks.

Measuring Non-Deterministic, Multi-Step Behavior

An agent can pass the same test ten times and fail it on the eleventh, because the same prompt does not always produce the same tool-call sequence. That non-determinism means Measure-function work needs repeated trials across a range of scenarios, not a single pass or fail run, plus monitoring for behavioral drift as memory or context accumulates across sessions. Useful metrics include the rate of unauthorized tool calls per session, the frequency of actions taken without required approval, and how often an agent's stated reasoning diverges from the action it actually took. A single clean test run says almost nothing about risk in production.

Applying Manage to Autonomous Agents

Manage is where identified risks get resourced and treated. For agents, that increasingly means controls that operate in real time, not just policy written in advance.

Runtime Guardrails as a Manage-Function Control

Static, pre-deployment reviews cannot catch an agent that behaves correctly in testing and then encounters a manipulated input in production. Runtime guardrails, meaning controls that inspect and can block a tool call at the moment it happens, are a Manage-function control suited specifically to agent autonomy. These include permission checks that confirm a requested action falls within an agent's documented scope, content filters on both inputs and outputs, and rate limits that catch an agent looping or escalating unexpectedly. Runtime guardrails do not replace the governance and mapping work upstream. They catch the cases that upstream review could not have anticipated.

Incident Response for Autonomous Actions

Incident response for a traditional AI system usually means reviewing a bad output after the fact. For an agent, an incident can mean a real action already taken: a file deleted, funds transferred, an email sent to the wrong recipient. Manage-function incident response for agents needs a faster path to containment, meaning the ability to suspend a specific agent's credentials immediately, plus a forensic trail detailed enough to reconstruct exactly which tool calls happened in what order and why. Organizations should treat agent incidents with the same urgency as a compromised service account, because functionally, an agent that has been manipulated often behaves exactly like one.

NIST's Broader 2026 Agent Initiative

NIST itself has acknowledged that AI RMF and AI 600-1 were not written with autonomous agents in mind, and it has launched dedicated work to close that gap.

The NIST AI Agent Standards Initiative (CAISI)

NIST's Center for AI Standards and Innovation, known as CAISI, launched the AI Agent Standards Initiative on February 17, 2026. It is the first US government program dedicated specifically to interoperability and security standards for autonomous agents, organized around three pillars: industry-led standards development, community-led open-source protocol development, and research into agent security and identity. CAISI has been explicit that this is not a single publication. The initiative runs through requests for information, listening sessions, and concept papers before any finalized guidance ships, with sector-specific listening sessions for healthcare, finance, and education held in April 2026.

The NCCoE Concept Paper: OAuth 2.0, Zero Trust, and Agent Identity

The National Cybersecurity Center of Excellence (NCCoE), working alongside CAISI, published a concept paper on February 5, 2026, titled "Accelerating the Adoption of Software and AI Agent Identity and Authorization." It proposes applying existing identity standards, including OAuth 2.0, OpenID Connect, SPIFFE/SPIRE, and Zero Trust architecture under SP 800-207, to agents as a distinct non-human identity class that requires proper lifecycle management, rather than shared service accounts or static API keys. Its comment period closed on April 2, 2026. One unresolved problem: current OAuth handles single-hop delegation well through on-behalf-of tokens, but multi-hop delegation, where Agent A delegates to Agent B, which delegates to Agent C, still lacks a clean standard, directly relevant to the delegation-chain mapping discussed under Map above.

Where NIST AI RMF Still Falls Short for Agents

Even with AI 600-1 and the CAISI initiative, gaps remain that organizations need to close themselves.

What the Framework Doesn't Prescribe

NIST AI RMF is deliberately non-prescriptive. It tells you what outcomes to pursue, not which specific control to deploy. For agents, that means the framework does not specify concrete permission models, does not define what "least privilege" looks like for a tool-calling agent in practice, and does not prescribe runtime enforcement mechanisms. It also predates the standardized identity and authorization patterns the NCCoE concept paper is still working out. Organizations that treat AI RMF as a complete control checklist for agents will find real gaps in exactly the areas agentic risk concentrates: tool permissioning, delegation accountability, and runtime behavioral enforcement.

Pairing NIST AI RMF with OWASP Agentic Top 10 and MITRE ATLAS

Closing those gaps means pairing AI RMF with frameworks built specifically for agent-level and threat-level detail. The OWASP Top 10 for Agentic Applications, a companion to the LLM Top 10 released in December 2025, names risks specific to autonomous systems, including agent goal hijacking and tool misuse, that the base LLM list only partially covers. MITRE ATLAS complements both by cataloging documented adversary techniques against AI and agentic systems, including agent-specific patterns such as tool credential harvesting and context poisoning, thereby giving Measure-function red teaming a concrete, real-world-grounded target rather than a theoretical one. None of these three frameworks replaces the others. AI RMF supplies the governance structure, OWASP supplies application-level risk categories, and MITRE ATLAS supplies the adversary playbook.

A Practical Implementation Timeline

Applying AI RMF to agents does not need to happen all at once, and trying to reach full maturity across an entire portfolio in one pass usually stalls. For a single high-risk agentic system, a realistic timeline runs four to eight weeks: about two weeks for Govern and Map, including assigning an owner and documenting the agent's tool and data access, two to three weeks for initial Measure-function red teaming against prompt injection and excessive agency, and two to three weeks to stand up baseline runtime guardrails and an incident response path under Manage. For full portfolio maturity across every deployed agent, expect six to twelve months, since it requires building the agent inventory first, then repeating the cycle system by system. Prioritize agents with write access to financial, health, or production systems before working down the list.

How Akto Operationalizes NIST AI RMF for Agents

Akto's continuous discovery of AI agents, LLM applications, and MCP server connections builds the agent and tool inventory that the Map function assumes exists, closing the exact prerequisite gap most organizations hit first when applying NIST AI RMF to autonomous agents. Ongoing red teaming targets the risks named directly under Measure, including prompt injection, excessive agency, and credential harvesting through agent tool access, chaining techniques the way a real adversary would rather than testing each one in isolation. Runtime guardrails then supply the Manage-function control the base framework describes as an outcome but does not prescribe as a mechanism, flagging anomalous tool calls as they happen. Together, discovery, red teaming, and runtime enforcement turn AI RMF's four functions into something a security team can run day-to-day.

Frequently Asked Questions: NIST AI RMF for Autonomous Agents

1. How do you apply NIST AI RMF's four functions specifically to autonomous agents?

Govern assigns accountable owners per agent and defines delegation policy for multi-agent systems. Map builds an agent and tool inventory and traces delegation chains. Measure red teams for prompt injection and excessive agency across multi-step behavior. Manage enforces runtime guardrails and defines incident response for autonomous actions.

2. Why does agentic AI stress the base NIST AI RMF more than traditional AI systems?

The base framework treats a model's output as the end of the risk surface. Agents use that output to call tools and take real actions, so every tool call becomes a new decision point the original framework was not written to address.

3. What is NIST AI 600-1, and how does it relate to agent security?

NIST AI 600-1 is the Generative AI Profile, published in July 2024, mapping AI RMF's four functions to twelve generative-AI-specific risks. It extends RMF beyond the 2023 baseline but was written for content generation, not tool-calling autonomy, so it does not cover delegation chains or runtime permissioning.

4. What does the Map function look like when applied to a multi-agent system?

It means building a full agent and tool inventory first, then diagramming delegation chains so indirect access through another agent's credentials is visible, not assumed absent just because it was never documented.

5. How should red teaming under the Measure function address excessive agency and prompt injection?

Test both direct and indirect prompt injection, including manipulated content the agent reads mid-task, and run repeated trials rather than a single pass or fail test, since agent behavior is non-deterministic across sessions.

6. What is the NIST AI Agent Standards Initiative (CAISI)?

Launched February 17, 2026, by NIST's Center for AI Standards and Innovation, it is the first US government program dedicated to interoperability and security standards for autonomous agents, built around industry standards, open-source protocols, and security and identity research.

7. What does NIST's NCCoE concept paper recommend for agent identity and authorization?

Published February 5, 2026, it proposes applying existing identity standards, including OAuth 2.0, OpenID Connect, SPIFFE/SPIRE, and Zero Trust under SP 800-207, treating agents as a distinct non-human identity class rather than relying on shared service accounts or static API keys.

8. What does NIST AI RMF not tell you about securing autonomous agents?

It does not prescribe specific permission models, define least privilege for tool-calling agents, or specify runtime enforcement mechanisms. It sets outcomes, not controls, leaving the concrete implementation to the organization.

9. How does NIST AI RMF pair with OWASP's Agentic Top 10 and MITRE ATLAS?

AI RMF supplies a governance structure, OWASP's Top 10 for Agentic Applications supplies application-level risk categories specific to autonomous systems, and MITRE ATLAS supplies a catalog of documented adversary techniques to test against. Used together, they cover governance, application risk, and threat modeling.

10. How long does it typically take to apply NIST AI RMF to a single high-risk agentic system?

Roughly four to eight weeks: about two weeks for Govern and Map, two to three weeks for initial Measure-function red teaming, and two to three weeks to stand up baseline Manage-function guardrails and incident response.

11. How does Akto help operationalize NIST AI RMF's Measure and Manage functions for agents?

Akto's continuous agent and MCP discovery supplies the inventory Map assumes exists; its red-teaming targets named Measure-function risks like prompt injection and excessive agency directly; and its runtime guardrails deliver the Manage-function enforcement the framework describes but does not prescribe.