NIST AI RMF Applied to Agentic Systems
Most practitioners who've worked with the RMF can summarize the four functions in about thirty seconds. GOVERN establishes the organizational conditions for risk management: accountability structures, policies, roles, culture. MAP identifies the system's context, intended use, and risks before deployment. MEASURE creates ongoing assessment of those risks through defined metrics and testing. MANAGE acts on what measurement surfaces, through mitigation, monitoring, incident response, and documentation. Together they form a cycle, not a checklist.
That cycle was built around a comprehensible unit of analysis: a model that takes input and returns output. GOVERN defined who was responsible. MAP catalogued what could go wrong before it went live. MEASURE evaluated whether it was going wrong during operation. MANAGE fixed it when it did. Clean boundaries. Manageable scope.
Agentic systems dissolve that unit of analysis entirely.
Where each function hits the wall
GOVERN breaks first, and it breaks on the delegation chain. When an orchestrating agent spawns a sub-agent, which calls an external MCP server, which executes against a production database, the standard role definitions — model owner, system operator, end user — do not tell you who owns the database action. Authority has passed between systems, not people. Nobody wrote a policy for that handoff because nobody imagined it would happen without a human in the middle.
MAP breaks on runtime surface expansion. An agent authorized to connect to MCP servers operates in an ecosystem with hundreds of millions of package downloads and thousands of community-built servers, a large fraction of which have received no security review. The risk register you build at deployment captures the threat surface that existed the day the system went live. By the time the agent is running in production for six months, that surface looks substantially different, because the tools it can reach have changed.
MEASURE breaks on the unit of assessment. Standard red-teaming and benchmark evaluation were built for single-turn outputs: you put something in, you evaluate what comes out. Agentic risk materializes across a chain of actions. The harmful outcome does not appear until several steps after the initial compromise, which means a testing program that evaluates only final outputs will miss the entire attack class that operates in the middle of a task.
MANAGE breaks on containment scope. Incident response for a static model has a clean boundary: take the model offline, investigate, redeploy. An agent mid-task has open sessions with multiple external services, queued downstream actions that will execute even after you stop the orchestrating agent, and credentials that remain valid long after the session ends. Stopping the agent does not stop the consequences.
The control family gaps that mirror these problems
The SP 800-53 control families practitioners normally map to AI governance carry corresponding blind spots. The AC family has no provisions for task-scoped, just-in-time agent permissions. The IA family has no framework for non-human agent identity or credential lifecycle. The AU family specifies nothing about logging agent tool calls or intermediate reasoning steps. The SR family does not treat agents that invoke third-party tools or other agents as supply chain risk, which is exactly what they are.
NIST's COSAiS project, announced in August 2025, is building SP 800-53 overlays to close these gaps. Those overlays are incomplete as of this writing. In the interim, practitioners must work with the existing framework and construct the missing controls themselves. The four sections that follow explain what that construction actually looks like, function by function.
Reinterpreting GOVERN for Agentic Systems: Accountability Across Delegation Chains
The base GOVERN requirement is straightforward: assign roles, define policies, establish accountability. It works cleanly when a human triggers a model and a human reviews the output. The accountability chain is short, visible, and populated entirely by people.
Agentic delegation chains are longer, partially invisible, and populated by systems that can themselves make consequential decisions. An orchestrating agent spawns a sub-agent. The sub-agent calls an external MCP server. The server executes against a production database. Each handoff transfers a portion of the authority the original operator granted. Nowhere in a standard GOVERN policy does it specify who owns the consequences at the end of that chain, because nobody anticipated that the chain would be that long.
What reinterpreted GOVERN looks like in practice
Start with autonomy tier classification. Not every agent operates at the same level of independence, and governance policy needs to reflect that distinction explicitly. An agent that requires human confirmation before any external action sits in a fundamentally different risk category than one that plans and executes multi-step workflows without interruption. The CSA's NIST AI RMF Agentic Profile, published in 2026, recommends formal tier assignment as a foundational GOVERN extension, and it is right to do so: without it, every downstream governance decision collapses into ambiguity, because you do not actually know what you are governing.
Delegation policy follows directly from tier classification. These are explicit rules specifying which agents may delegate to which other agents, and crucially, what permissions may be passed downstream. Permissions should not amplify at each delegation step. If the orchestrating agent has read access to a database, a sub-agent it spawns should be unable to acquire write access simply because it inherited a task. That constraint needs to be written into policy before it becomes an enforcement problem at runtime.
Non-human identity governance is where most organizations currently have nothing. Every agent needs a managed identity with a defined lifecycle: provisioning, rotation, suspension, deprovisioning. A shared service account is not identity governance; it is identity avoidance dressed up as convenience. The NCCoE concept paper published in February 2026 proposes treating agents as distinct non-human identities under OAuth 2.0, OpenID Connect, and SPIFFE/SPIRE. That infrastructure is what makes GOVERN decisions enforceable at the moment an agent attempts to act, rather than discoverable only in the post-incident review.
Shadow AI deserves explicit attention here because it is the GOVERN failure mode practitioners most reliably underestimate. When employees connect unauthorized MCP servers or build unofficial agent workflows, the governance structure has zero visibility into what those agents are doing or on whose behalf. No accountability chain exists for their actions. GOVERN's practical job is to make that scenario detectable and addressable, not just prohibited in a policy document nobody reads.
The concrete deliverable that makes all of this operational is an agent registry: a maintained inventory of every deployed agent, its autonomy tier, its managed identity, its permitted tool scope, and the human owner accountable for its behavior. Not a compliance artifact produced once and filed away; an active system that MAP, MEASURE, and MANAGE all depend on to function.
Reinterpreting MAP for Agentic Systems: Threat Surfaces That Expand at Runtime
Base RMF MAP is a design-time exercise. You identify the system's context, intended use, stakeholders, and risks before deployment. That approach is defensible for a static model, because the system you ship is the system you govern, and its risk surface is knowable before anyone uses it.
An agentic system's risk surface is not fully knowable at design time. Each new tool connection is a new trust boundary the deploying organization has implicitly accepted, and that boundary does not exist when the original risk assessment was conducted. This is not a theoretical concern about hypothetical future states. The threat categories below have documented real-world instances.
Threat categories MAP must cover
Tool poisoning embeds malicious instructions inside tool descriptions, directing agent behavior without the user's knowledge. Invariant Labs demonstrated this in April 2025 against a WhatsApp MCP server, where content in a tool's description was used to redirect agent actions entirely. The agent did exactly what it was told; it just wasn't told by the person who thought they were in charge.
Supply chain poisoning operates at the package level. The postmark-mcp incident in September 2025 illustrates the pattern cleanly: a trusted MCP package silently added malicious behavior in a later version, BCC'ing agent-sent emails to an attacker-controlled address across all downstream consumers. Nothing about the original package assessment would have surfaced it, because the vulnerability was introduced after that assessment was complete.
Privilege amplification occurs when an agent operating with elevated credentials processes user-supplied content that redirects those credentials toward unauthorized actions. The Supabase-Cursor incident in July 2025 illustrated this, with user-supplied database content manipulating an agent into executing operations well outside its intended scope.
Indirect prompt injection embeds malicious instructions in documents or emails that execute when an agent processes them. CVE-2025-32711, the EchoLeak vulnerability against Microsoft 365 Copilot, required zero user interaction: instructions embedded in content the agent processed caused it to exfiltrate data automatically. The user did nothing wrong. The architecture did.
Session hijacking and authentication gaps reflect a structural problem at the protocol level. MCP does not define how a session maps to a verifiable identity; authentication is optional in the protocol; role-based access control is not part of the spec. NSA guidance published in May 2026 flags this explicitly as a structural risk in MCP-based deployments.
The OWASP Top 10 for Agentic AI Applications, announced in the ASI taxonomy in December 2025, provides a structured checklist of threat categories, ASI01 through ASI10, that MAP practitioners can use to ensure no major attack class is overlooked during risk identification.
What MAP must produce for agentic systems
The output of MAP for an agentic deployment cannot be a static risk register. It needs to be a live threat model that updates as the agent's tool scope changes and feeds directly back into the agent registry established under GOVERN. The threat surface on day one of production is not the threat surface on day ninety. Treating MAP as a pre-launch gate rather than an ongoing process is precisely how organizations accumulate risk they did not know they accepted.
Reinterpreting MEASURE for Agentic Systems: Testing Behavior That Unfolds Across Steps and Agents
Most enterprises operationalize MEASURE as periodic model evaluation and bias testing. That is defensible for static deployments. For agentic ones it is structurally insufficient, and the numbers that have emerged from agentic security research make the gap concrete.
Multi-turn prompt injection attacks achieved success rates as high as 92% in testing across open-weight models in 2025. These attacks unfold gradually across extended conversations; single-turn benchmarks will never surface them. NIST's own red-team research, published in January 2025, found that novel attack strategies against AI agents achieved an 81% success rate, compared to 11% against baseline defenses. That 70-point gap is not a rounding error. It is the difference between a testing program that finds problems and one that produces reassuring paperwork.
What MEASURE must add
Multi-turn red-teaming means designing test scenarios that span multiple agent steps and involve tool calls, not just model outputs. The objective is to find attacks the agent is vulnerable to only because of what it has done in previous steps: the accumulated context, the tools it has already called, the credentials it currently holds. If your red-team scenarios do not look like that, they are not testing the thing that will actually fail.
Cross-agent trust boundary testing asks what happens when one agent's output is passed to another without re-verification. The NSA's May 2026 guidance explicitly flags trust relationship risks where one agent's output is assumed valid by a downstream agent without explicit verification. That assumption is a testable condition. MEASURE should test it on a defined schedule.
Tool call behavioral testing checks whether the agent calls only the tools it should, with only the permissions it needs, and only when the task actually requires them. Anomalous tool-call patterns, calls outside the expected scope, credential usage inconsistent with the task, are measurable signals of compromise or drift. They should have defined thresholds and defined response triggers.
Intent drift measurement asks whether an agent's behavior over a long session remains consistent with its original task. Context accumulated through injected content can gradually shift what an agent is effectively trying to accomplish. Measuring that drift requires comparing the agent's late-session actions against the objectives it was given at the start, which is a comparison that requires adequate logging of both.
None of this is possible without visibility into what the agent is actually doing. You cannot measure what you cannot see. Agent tool calls, intermediate reasoning steps, and credential usage must be captured at tool-call depth to support any meaningful measurement program. This is the AU family gap. Until the COSAiS overlays close it, practitioners need to build logging requirements into their own MEASURE program specifications, because no external standard currently requires them.
The practical output of MEASURE for an agentic system is a defined set of metrics: tool-call anomaly rates, credential scope violation frequency, intent drift detection signals. Those metrics are what MANAGE monitors. Without them, MANAGE is operating on intuition.
Reinterpreting MANAGE for Agentic Systems: Containing and Responding to Autonomous Actions in Progress
Base RMF MANAGE is well-established: act on measurement outputs, mitigate risks, monitor systems, respond to incidents, document decisions. For static systems the scope of any intervention is clear. Take the model offline, investigate, remediate, redeploy. The artifact sits still while you work on it.
An agent mid-task is not a static artifact. It has open sessions. It has already queued downstream actions that will execute whether or not the orchestrating agent is still running. It holds credentials that remain valid after the session ends. Stopping the agent stops the agent. It does not stop the consequences. That distinction is the entire problem.
What reinterpreted MANAGE requires
Just-in-time credential issuance is the foundational change. Credentials should be provisioned per task, scoped exactly to the tools and permissions that task requires, and revoked automatically when the task ends. Long-lived tokens that persist across sessions create a cleanup problem that MANAGE is left to solve under pressure, usually after something has already gone wrong. The AC family in SP 800-53 does not currently fill this requirement. Practitioners need to establish it explicitly, in their own policies, before they need it in an incident.
Runtime kill switches must be part of the system's design from the beginning. The ability to halt an agent's execution mid-task, revoke its active credentials immediately, and prevent queued downstream actions from completing requires that the system was architected with those intervention points built in. You cannot retrofit a kill switch onto a system that was designed without one. This is an architectural decision that MANAGE cannot make after deployment; it has to be a condition of deployment.
Containment playbooks need to be specific to agentic threat categories. A tool poisoning incident requires a different response sequence than an indirect prompt injection incident, which requires a different response than a privilege amplification event. Generic AI incident response procedures are not precise enough to be useful at speed. MAP identified the threat categories; MANAGE must have a playbook written for each one before it needs to use it.
Real-time behavioral monitoring means detecting tool-call anomalies, unexpected credential usage, and intent drift as they happen, not in a quarterly review cycle. The metrics MEASURE defined are the signals MANAGE monitors. The connection between those two functions, in agentic governance, needs to be effectively continuous.
The multi-agency breach that unfolded between December 2025 and January 2026, in which a single attacker used an AI agent to compromise multiple Mexican government agencies, illustrates what MANAGE failure looks like at scale: no runtime detection, no mid-task containment, consequences that propagated across organizational boundaries before any response was possible. That is the failure mode the reinterpreted MANAGE function exists to prevent.
Tamper-proof audit logs and full tracing of agent actions are the forensic record that makes post-incident response and regulatory accountability possible. Without them, MANAGE has no evidentiary basis for any conclusion it reaches about what happened or why. This is not compliance theater; it is the difference between learning from an incident and speculating about it.
There is an organizational dimension here that matters as much as the technical one. Security teams need tooling and visibility that positions them as the people who enable agentic AI adoption, not the teams that block every deployment that cannot be audited. MANAGE, implemented well, is what makes that posture credible.
Putting All Four Functions Together: What an Operational Agentic Governance Program Looks Like
The four functions are not a sequence you complete once. They form a continuous cycle, and for agentic systems that cycle runs at a faster cadence than it does for static deployments, because the ecosystem those systems operate in changes faster.
GOVERN establishes the agent registry, the autonomy tier definitions, the delegation policies, and the non-human identity infrastructure. Everything else depends on this foundation. Without a maintained registry, MAP has no authoritative list of systems to model. Without delegation policy, MEASURE has no baseline for what tool-call behavior should look like. Without managed identities, MANAGE has no credential lifecycle to control when something goes wrong.
MAP maintains the live threat model, updated as the agent's tool scope changes, cross-referenced against the agent registry. Each new tool connection is a MAP event, not just a deployment detail. The OWASP ASI taxonomy gives practitioners a structured checklist to apply every time that threat model updates, so additions to the tool scope don't slide through without a corresponding risk assessment.
MEASURE runs on the metrics defined during MAP, against the behavioral baselines established under GOVERN. Multi-turn red-teaming happens on a cadence that reflects how quickly the agentic ecosystem changes, not on an annual schedule designed for static model deployments. The audit logs MANAGE depends on are specified and validated under MEASURE before they are needed in an incident, because discovering that your logging is inadequate during a breach is an expensive way to learn that lesson.
MANAGE acts on what MEASURE surfaces, using playbooks specific to the threat categories MAP identified. Credentials are task-scoped and revoked automatically. Kill switches are tested before they are needed. Post-incident forensics run against logs that were specified to support exactly that analysis.
The cycle then feeds back. Every incident MANAGE responds to generates information that should update MAP's threat model. Every new attack category MAP identifies should generate new test cases for MEASURE. Every autonomy tier reclassification under GOVERN should trigger a review of the containment playbooks under MANAGE.
What makes this operationally real rather than aspirational is specificity: an agent registry that is actually maintained, autonomy tiers that actually constrain what an agent can do without confirmation, tool-call logs that are actually reviewed, credentials that are actually task-scoped, playbooks that are actually written for agentic threat categories. The RMF's four functions provide the structure. The reinterpretations described here specify what goes inside that structure for agentic deployments. Practitioners who build against both will have a governance program that can keep pace with what agentic systems are actually capable of doing.
