NIST AI RMF for AI Agents: What Govern, Map, Measure and Manage Should Leave Behind

The framework says "AI system". Your architecture diagram says planner, tool router, memory store and three MCP servers. Somewhere between those two vocabularies sits the question every security lead eventually hears: how do our agents line up with the NIST AI RMF?

This page offers a working translation. It is one practitioner reading, not NIST guidance and not a compliance opinion. The framework is voluntary and technology-neutral, so the job is to decide what evidence each of its four functions should leave behind when the system in question is an agent.

The four functions in NIST's words

NIST's AI RMF core treats Govern as the thread running through every other activity, Map as the step that sets context for framing risk, Measure as the use of quantitative, qualitative or mixed methods to analyse and track it, and Manage as allocating resources to risks that were mapped and measured. NIST also published a Generative AI Profile, NIST-AI-600-1, on 26 July 2024, which catalogues risks particular to generative models (NIST AI RMF overview). That profile covers the technology class and leaves the agent-level mapping to you.

Newer work targets agents directly. NIST's COSAiS project is building SP 800-53 control overlays for securing AI systems, and its list of planned use cases includes single-agent and multi-agent systems. The project page, last updated in January 2026, lists those overlays as use cases under development, with a public discussion draft available only for predictive AI at that date (NIST COSAiS project). Check the page for anything published since, and treat the overlays as a future crosswalk target and not a finished standard.

Where agents stretch the assumptions

The RMF presumes a describable system with a stated purpose and a stable setting. Agents bend all three. The purpose is wide, the setting shifts whenever a connector is added, and the edge of the system takes in servers written by strangers. Three traits cause most of the friction:

• A moving boundary. A new connector alters the risk profile with no release.
• Chained decisions. Each output feeds the following call, so grading one reply overlooks the chain.
• Delegated authority. The agent works on behalf of someone, and answerability must travel along that hand-off.

The mapping below therefore anchors on things you can control: an inventory, authority limits, logs and stop paths.

Govern: name the owner and write the exit

Govern is where agent programmes quietly go wrong. Start here:

• Maintain a register that gives every agent an owner, a purpose and an approved toolset. The Playbook's GOVERN 2.1 asks that roles, responsibilities and lines of communication be documented and clear (NIST Playbook, Govern).
• Treat the addition of any tool or data source as a change request, because it alters the risk profile.
• Define retirement. GOVERN 1.7 calls for procedures to decommission AI systems safely, and agents left running with working credentials are the usual gap.

GOVERN 6.1 deserves its own line. It covers policies for risks tied to third parties, and for an agent that is the entire plugin and server ecosystem it loads (NIST Playbook, Govern).

Map: list the agent's real reach

Mapping is a census. Per agent, capture the tool list, readable data, account identities, irreversible operations, and every party able to instruct it, web pages and files included. After that, note the harm each capability could cause if abused. A layout for this record appears in inventory before controls. To avoid blind spots, lean on a published taxonomy, and see our OWASP, ATLAS and NIST crosswalk.

Measure: gather three kinds of evidence

MEASURE 2.7 asks that security and resilience, as identified during Map, be evaluated and documented (NIST Playbook, Measure). For an agent, split that evidence in three:

1. Before release: adversarial exercises against the assembled agent, tools attached, together with regression checks for earlier bugs. See prompt injection testing in CI.
2. At runtime: counts of tool calls, refusals, unusual destinations and spend per task. See agent monitoring.
3. On a schedule: a person reads sampled traces and compares them with intended use.

Choose a handful of measures and attach a threshold that triggers action to each. A metric without a trigger is decoration.

Manage: act on what the numbers show

The best agent controls are unglamorous: least privilege, short-lived scoped credentials, approval for consequential actions, and a stop path. MANAGE 2.4 in the Playbook wants working mechanisms plus an assigned owner for overriding or switching off a system that drifts from its intended use (NIST Playbook, Manage). The design side is in our kill switch article.

Plan for incidents as well. That section also expects incidents to be reported to the right parties and the recovery steps documented afterwards (NIST Playbook, Manage).

One table of evidence per function

Function	Artefact an assessor can open
Govern	Agent register with owner, approval rule, retirement date
Map	Capability and authority map, list of irreversible actions
Measure	Test reports, monitoring thresholds, sampled trace reviews
Manage	Stop-path drill results, incident log, credential revocation timings

When logs cannot replay an agent's actions, a tidy mapping will not save the review. Capture who acted, with which tool, on what, and the result.

A sample register row

Take a support triage agent. Owner: the head of support operations. Purpose: label and route inbound tickets. Tools: ticket read, ticket update, a knowledge-base search server. Identity: one service account scoped to the support queue. Irreversible actions: none, because replies stay as drafts until a person sends them. Approval point: a human sends every customer-facing message. Last stop-path drill: the date, with the revocation time noted. Retirement: tied to the vendor contract end. Each field feeds one function, and an empty field marks where the programme is thin.

Begin with Map and Manage, not a governance committee

The framework lists Govern first, so many programmes start with a committee, a policy and a charter. For agents that order tends to stall. Policy written before anyone knows what the agents can reach describes an imagined system, and the committee has nothing concrete to approve.

The stronger sequence is to build the register and the capability map for the three most powerful agents, prove you can stop each one, and let the policy grow from what those exercises expose. Govern then documents decisions that already exist. The Playbook itself calls the functions parts of one cycle and describes Govern as cross-cutting, so doing the concrete work first does not break the framework.

The committee comes first when a client agreement or a supervisory body demands a named governance structure before launch. There the committee comes first because the paperwork is the deliverable, and the register still follows closely. Your compliance and legal colleagues can say which frameworks bind you.

Scope the first pass small

Resist mapping dozens of agents at once. Pick the three with the greatest reach, take them through every function, close the gaps that surface, and then widen. A brief, fresh register beats a sprawling, outdated one. Store it under version control, so each edit has an author and a date, and revisit it monthly.

What this page does not do

Securing an agent is outside the RMF's remit; it lists the questions a programme needs to answer. Which evidence an assessor accepts is for the assessor to say. Use the framework as an index into your controls. Put the engineering effort into inventory, authority limits and logging.

Questions about the NIST AI RMF and agents