Map the NIST AI RMF 1.0 functions (Govern, Map, Measure, Manage) to concrete controls and audit evidence for AI agents in a regulated US enterprise.
The NIST AI Risk Management Framework was written before most companies had an AI agent in production, and it says nothing specific about agents. It does not need to. Its four functions and 72 subcategories describe outcomes, and an agent that reads documents, calls systems and takes actions is a good test of whether you can reach those outcomes with real controls.
This post maps the framework to controls a US bank, insurer or other regulated enterprise can run for AI agents, and to the evidence an examiner or auditor can sample. It is a mapping, not a certification path: NIST AI RMF is voluntary, and the control choices below are our reading of how its subcategories apply. If you want the checklist version, see the 12 controls for governing AI agents. For the definition, see AI agent governance and the NIST AI RMF glossary entry.
NIST's own text says the functions are not a checklist or a strict sequence. For agents, MAP and MEASURE repeat every time an agent gets a new tool, a new data source or a new instruction set.
The table pairs subcategory examples (quoted from NIST AI 100-1) with an agent control and the evidence you would keep. Subcategory text is abridged.
Function | Subcategory examples | Agent control | Evidence |
|---|---|---|---|
GOVERN | GOVERN 1.6: mechanisms to inventory AI systems. GOVERN 2.1: roles and responsibilities documented | Agent register with a named business owner, technical owner, purpose, systems touched and risk tier | The register, quarterly reconciliation to platform and identity data, owner attestations |
GOVERN | GOVERN 3.2: roles for human-AI configurations and oversight. GOVERN 6.1: policies for third-party AI risk | Written autonomy policy by action type, plus vendor due diligence for model and platform providers | Approved policy, vendor risk files, contract clauses on logging and incident notice |
MAP | MAP 1.1: intended purposes and context documented. MAP 3.3: targeted application scope specified | One-page agent charter: job, allowed systems, allowed actions, out-of-scope actions | Signed charter per agent, version history |
MAP | MAP 2.2: knowledge limits and human oversight documented. MAP 3.5: processes for human oversight | Approval gates and confidence thresholds that route uncertain or high-value cases to a person | Gate policy, approver lists, escalation rates by action type |
MEASURE | MEASURE 2.3: performance measured for deployment-like conditions. MEASURE 2.7: security and resilience evaluated | Pre-release evaluation suite on real task samples, plus adversarial testing including prompt injection | Test sets and results, red-team reports, remediation tickets |
MEASURE | MEASURE 2.4: behavior monitored in production. MEASURE 3.1: track existing and emergent risks | Production monitoring of error rates, override rates, tool-call anomalies and drift after instruction changes | Dashboards, alert logs, monthly review minutes |
MANAGE | MANAGE 2.4: mechanisms to supersede, disengage or deactivate. MANAGE 4.1: post-deployment monitoring, override, incident response, change management | Kill switch, rollback of agent instructions, change tickets with approval and incident runbooks | Disable drills, change records, incident tickets and post-incident reviews |
MANAGE | MANAGE 1.3: responses to high-priority risks documented. MANAGE 3.1: third-party risks monitored | Risk register with treatment decisions, and ongoing monitoring of the model and tool vendors | Register entries with owner and date, vendor monitoring reports |
GOVERN is where most agent programs are thinnest, because it is the least technical. Three subcategories carry most of the weight.
GOVERN 1.6 asks for mechanisms to inventory AI systems, resourced according to risk priorities. For agents, that means every pilot and production agent is on a register, including ones a business team set up without IT. Shadow agents are the fastest route to an examination finding.
GOVERN 2.3 puts responsibility for AI risk decisions with executive leadership. In practice, someone at the level of a chief risk officer or head of operations signs the autonomy policy, so "the agent approved it" is never the accountable answer.
GOVERN 6.1 and 6.2 cover third parties and contingency plans for failures in third-party AI. If an agent depends on a model provider, a vendor outage or a silent model change is your risk. Decide in advance what the agent does when the provider is down, which is usually to stop and queue work for people.
Identity belongs here too. An agent needs its own credential, not a borrowed human login, so every action can be attributed. We cover this in depth in AI agent identity management. For the broader organizational layer above agents, see the AI governance framework guide.
MAP is the discipline of writing down what the agent is for before it runs. MAP 1.1 asks for intended purposes and context, MAP 3.3 for a documented application scope, and MAP 2.2 for the system's knowledge limits and how humans oversee its output.
An agent charter satisfies all three. It lists the job in one sentence, the systems the agent may read and write, the actions it may take alone, the actions that need a person, and what it must never do. If the agent cannot send a payment, say so in the charter and enforce it in permissions.
MAP 3.5 is the subcategory that justifies human-in-the-loop approval gates. Define them by action: releasing a payment, filing a report, changing master data or contacting a customer. Our post on where human judgment still belongs covers how to set the thresholds. Access scoping sits here as well, and AI agent access control goes into the design.
MEASURE is where you produce numbers. MEASURE 2.3 expects performance measured under conditions like the deployment setting, so test on your own documents and edge cases, not a vendor demo set. MEASURE 2.4 expects monitoring in production, and MEASURE 3.1 expects a way to track unanticipated and emergent risks.
For agents, useful metrics are task accuracy against a sampled human-reviewed set, the share of cases escalated to people, the rate at which approvers override the agent, tool-call failures, and any change in those numbers after an instruction or model update.
MEASURE 2.7 covers security and resilience, which is where AI red teaming fits. Test whether a malicious instruction hidden in an invoice, email or web page can steer the agent into an action outside its charter. MEASURE 1.3 adds a useful rule: assessors should include people who did not build the system. Have a security or internal audit team run the adversarial tests, not the team that wrote the agent.
MANAGE turns findings into decisions and gives you a way to stop. MANAGE 1.3 asks for documented responses to high-priority risks, and the options NIST lists are mitigating, transferring, avoiding or accepting. A risk register entry with an owner and a date is the usual evidence.
MANAGE 2.4 is the most agent-specific line in the framework: mechanisms to supersede, disengage or deactivate AI systems that perform outside their intended use, with assigned responsibilities. Build a kill switch and run a drill. Test it the way you test a disaster recovery plan, with a named person and a timestamp.
MANAGE 4.1 bundles post-deployment monitoring, appeal and override, decommissioning, incident response, recovery and change management. For agents, a change to the prompt, tools or model version is a change to the control environment. Route it through a ticket with review and approval, and keep an audit trail that shows which version acted on which case.
NIST does not tell you which object to hang the controls on. We use the AOP, because each AI employee has exactly one and it holds the rules the framework asks you to document.
Function | What we run |
|---|---|
GOVERN | Each agent has its own identity with least-privilege access, and a named process owner who writes and changes its AOP. |
MAP | The AOP is the charter: objectives, policies, sources of truth, approval limits, escalation paths and scoped precedents from real cases. Anything outside it is not the agent's job. |
MEASURE | The PEV loop validates each case's output against what the agent expected before it closes. Changes run against evals, including a golden set of behavior the agent must keep. |
MANAGE | Changes go through a branch, evals, review and merge. Only the AOP changes, never model weights, so every behavior change traces to a reviewed correction and can be reversed by editing the AOP. |
In a biopharma procurement deployment, the agent sent 64% of purchase requests to manual review in week one and recommended a decision on 36%. We read that as the MAP 3.5 oversight design doing its job, since unfamiliar cases went to a person instead of being approved. As the team fed back every case where the agent and the reviewer disagreed, the decision rate rose to 85% and manual review fell to 15%. Those two rates are the override and escalation measures MEASURE 2.4 asks you to monitor, and the trend matters more than any single week. The agent also wrote its reasoning into SAP Ariba, the team's own purchasing system. See the case study.
When a case breaches a tolerance or lacks data, the agent sets Needs Attention and hands a person the context. Why keeping learning inside the procedure matters for auditability is covered in how the self-learning system works, and what an AOP holds is in the AOP explained.
NIST AI 600-1, the Generative AI Profile, was published in July 2024 as a companion to the AI RMF. It lists twelve risks that are unique to or made worse by generative AI, including confabulation, information security, human-AI configuration and value chain and component integration, and it attaches suggested actions to RMF subcategories.
The profile is not specific to agents, and it does not use the word as a category. It is still useful for agents built on large language models. Two examples: MS-2.7-007 suggests AI red-teaming to assess resilience against abuse to facilitate attacks on other systems, and MP-5.1-005 suggests adversarial role-playing, red-teaming or chaos testing to find anomalous failure modes. Treat these as starting points for your test plans.
Banks cannot assume the old model risk playbook covers agents. On April 17, 2026, the OCC, the Federal Reserve and the FDIC issued revised model risk management guidance (OCC Bulletin 2026-13, Federal Reserve SR 26-2). It supersedes SR 11-7 and rescinds OCC Bulletin 2011-12. SR 26-2 also replaces SR 21-8, the 2021 interagency statement on BSA/AML model risk.
The new guidance states that "generative AI and agentic AI models are novel and rapidly evolving" and are "not within the scope of this guidance." The agencies also said they plan to issue a request for information on banks' use of AI, including generative and agentic AI. Read the bulletin on the OCC site and the Federal Reserve letter.
Out of scope does not mean unexamined. Examiners can still ask how you govern an agent under safety and soundness, third-party risk and internal control expectations. The NIST mapping above gives you a documented standard to point to. Many teams will also keep applying model risk management disciplines such as independent validation and ongoing monitoring by analogy. That is an internal policy choice, not a regulatory requirement, so confirm the approach with your model risk and legal teams.
The mapping above applies to any agent platform you evaluate, ours included.
