NIST AI RMF, for agents: Govern / Map / Measure / Manage as a checklist for autonomous systems.
The NIST AI Risk Management Framework is a voluntary, non-regulatory framework organized around four functions — Govern, Map, Measure, Manage. Each was written for AI systems in general; each takes on extra teeth when the "system" is an autonomous agent that loops, calls tools, and produces consequences without a per-decision human. This essay walks the four functions from an agent team's perspective, naming the work each one actually demands and how it stacks with the EU AI Act's high-risk duties when both apply.
The framework in one paragraph, then why it bites harder for agents.
NIST AI RMF 1.0 organizes AI risk management around four functions — Govern, Map, Measure, Manage — designed to be iterative rather than one-shot. NIST also publishes a Generative AI Profile that walks the same functions through the failure modes specific to generative systems. The framework is voluntary, framework-not-regulation, and is the de-facto operationalization most US-based teams reach for; it crosswalks well onto the EU AI Act's high-risk duties from eu-ai-act-for-agents.
For an autonomous agent the framework reads slightly differently than for a model. Each function still applies, but the unit of analysis is the loop, not a single inference; the surface includes the tool registry; the "system" extends to every downstream effect the agent can produce; and the oversight question moves from "can a person catch a bad output" to "can a person stop a sequence of decisions that may already be acting." Walk the four functions with that lens, not the single-prompt lens.
Govern: it is somebody's job, with authority and resources.
Govern is the function that scaffolds the other three. For an agent program it asks:
- Named accountability for the agent. Not "the team"; a specific operator role with authority to halt, change, or retire the system. The accountability-and-roles material is the engineering shape of this.
- Policies, processes, and an organizational structure that say how risk decisions get made and by whom — tiered by risk, not uniform (see governance-in-practice).
- Roles, responsibilities, training — the people who can operate, oversee, and review the agent are identified, equipped, and trained for the specific failure modes autonomy adds.
- External-stakeholder engagement and disclosure posture — how impacted users, affected communities, regulators, and partners get information; what gets disclosed and when.
The agent-specific bite: Govern has to allocate authority for things the team cannot decide unilaterally — pulling the kill switch, halting a tenant, deciding when a regression is bad enough to roll back. If that authority is not named in advance, it falls onto whoever happens to be on-call, and the answer at 3am is "I don't think I'm allowed to do that."
Map: characterize the system, its context, and the tool surface.
Map captures what the system is and what could go wrong. For an agent the standard list — intended use, stakeholders, deployment context, risks — needs to be extended with the surface autonomy creates:
- Intended and reasonably-foreseeable uses, including failure modes specific to multi-step autonomy (loops, fan-out, runaway).
- Stakeholders and impacted parties — the user, the people they are acting on, third parties an agent's tool calls reach, regulators with jurisdiction.
- Trust boundaries and the tool surface — every tool the agent can call is a place harm can leave the system. Map this explicitly; it is the input to the safety material in agentic-threat-model.
- Risks across the lifecycle, including risks introduced by the loop (compounding errors), by retrieval (untrusted context), and by integration with other systems.
- Provenance for inputs and outputs — what data goes in, what artifacts come out, who is accountable for each.
Map is heavily front-loaded — most of the value comes from doing it carefully once and re-visiting it when something material changes (a new tool, a new model snapshot, a new use case).
Measure: quantify what Map identified, on a schedule.
Measure is the empirical layer. The framework names the broad properties an AI system should be measured against — validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, fairness with managed bias. For an autonomous agent the measurement program looks like:
- Validity and reliability — task-success rates on the eval suite from eval-driven-agent-development; reliability scored as a distribution, not a single pass@1.
- Safety and security — adversarial red-team evals, prompt-injection regression tests, data-exfiltration monitors; both offline and the online signal from online-vs-offline-evals.
- Accountability and transparency — coverage of the audit trail (are all decisions traceable?); rate of decisions where the trace is insufficient to reconstruct the action.
- Privacy — measurable: rate of PII leaks in outputs, rate of un-tagged personal data flowing through tools.
- Bias and fairness — slice-based metrics: do outcomes differ across user populations on dimensions that matter to your use case?
A measurement program that runs only at launch is the inverse of risk management. Schedule re-measurement against the same metrics on a rhythm — model snapshot bumps, tool registry changes, and quarterly drift checks. The point of NIST's "iterative" emphasis is exactly this: the system that was measured-safe last quarter is not measured-safe this quarter unless you re-measured.
Manage: act on what Measure found — and how it stacks with the EU AI Act.
Manage is the loop-closing function. It takes Measure's findings and Map's risk register and decides what to do: prioritize risks for treatment, document residual risk, plan and execute response and recovery, monitor in production, and feed lessons back into Govern and Map. For an agent that means:
- Risk treatment — for each material risk: mitigate, transfer, accept (with documented justification), or avoid (refuse to build that use case). Make the choice explicit and reviewable.
- Incident response and recovery — the incident-response-for-agents runbook is Manage's operational form for autonomous systems; the kill switches and recovery paths are the artifacts NIST asks for under this function.
- Change management with agents-in-the-loop — a model snapshot bump, a tool registry change, or a prompt revision is a change Manage owns; the discipline from rollout-and-versioning is what makes it auditable.
- Continuous monitoring and feedback into Govern/Map — production telemetry, customer reports, and incident postmortems all loop back; new failure modes update Map, and structural issues update Govern.
Where this stacks with the EU AI Act: a serious NIST AI RMF program — Govern with named accountability, Map with documented risk, Measure with scheduled metrics, Manage with a real incident path — covers most of the Act's high-risk technical and organizational duties. Pick one as the scaffolding; do not run two parallel programs. The Act tells you what is required by law in the EU; NIST gives you a structure to organize the work; the EU Act and NIST overlap heavily on what that work actually is. A team that satisfies the Act's high-risk duties is generally also covering NIST's territory, and vice versa.