NIST AI RMF Manage function for AI agents

Manage is the NIST AI RMF function that acts on what Map and Measure found. For AI agents, it means ranking each risk, choosing a treatment, and responding when something goes wrong. The most useful treatment is rarely a new policy. It is narrowing what the agent may do, capability by capability, on the same day.

What does the Manage function require?

The NIST AI Risk Management Framework 1.0 has four functions: Govern, Map, Measure and Manage. Manage takes the risks identified in Map and the evidence gathered in Measure and turns them into decisions. In substance, it asks an organisation to:

• prioritise risks based on their assessed impact and likelihood, and decide whether the system should proceed at all;
• plan and document treatments that reduce negative impacts and keep the benefits;
• manage risks from third-party models, data and software;
• have mechanisms to supersede, disengage or deactivate a system whose performance or outcomes depart from its intended use;
• monitor after deployment, respond to and recover from incidents, and communicate them to the people who need to know.

The framework is voluntary and outcome-based. It tells you what Manage should achieve, not how. Our overview of how the NIST AI RMF applies to agents shows how the four functions connect.

Who is responsible for Manage?

Any organisation that adopts the framework. Inside it, Manage belongs to the people who own the agent's outcomes: the business owner, risk, and the operators who can change the agent's authority. It should not sit only with the engineers who built the agent, because the treatment decisions are business decisions about what the firm will let software do.

What changes when the system acts rather than advises?

A model that advises can be managed by telling people to treat its output with care. An agent that acts needs treatments that work before the action, not after. The reason is mechanical: an agent acts by calling tools, and each tool call changes something in another system. Our explainer on function calling covers how that works. If a risk is found, the treatment must reach the tool call.

That gives agent risk treatment a specific shape. You have four levers, and they are more precise than the classic "accept, mitigate, transfer, avoid":

Reduce depth. Move a capability from executing to drafting, so a person sends what the agent prepares. The agent stays useful; the risky step returns to a human.

Remove a capability. Take the tool away entirely. If an agent that handles address changes has also been given the ability to update bank details, and Map flagged that as a fraud route, remove it.

Tighten bounds. Keep the capability but lower the amount, narrow the account types, or restrict the sources the agent may rely on.

Stop the agent. Disengage it while you investigate. The framework expects this to be possible; for agents it must be possible without a release cycle.

Prioritisation decides which lever. Rank risks by what the action does if wrong: reading data is less severe than drafting a letter, which is less severe than changing a record, which is less severe than moving money. Then weight by how often Measure saw the failure on your own cases.

How do you prioritise and respond in practice?

Take an illustrative case. A mid-sized insurer runs an agent that pays small claims under a fixed amount. Measure shows it handles routine claims well but sometimes pays where a policy exclusion should have applied. Under Manage, the team ranks this as high impact, because a wrong payment is hard to recover. They keep the agent drafting all claims, remove its authority to pay where an exclusion clause is present in the policy, and route those cases to a named handler. They record the decision, the reason and the evidence. After the agent passes re-testing on exclusion cases, the payment authority returns for those claims, and the record shows why.

Measure supplies the evidence for each ranking; see the Measure function for agents. Map supplies the list of capabilities and affected people; see the Map function for agents.

What will a supervisor, auditor or customer ask?

• How do you decide which agent risks to treat first?
• Show us a capability you narrowed or removed, and the evidence that drove the decision.
• How quickly can you stop an agent, and who may do it?
• What happens to an agent's authority when the model provider changes the model?
• How are customers told if an agent acted wrongly on their account?
• What residual risk have you accepted, and who accepted it?

What does Manage not cover?

It does not identify risks; Map does. It does not test them; Measure does. It does not set the organisation's risk appetite; Govern does. And it does not specify controls. The framework says deactivation must be possible but not how fast, or which person decides. That is why we describe it as a useful map, not a control set. You still need to meet binding rules such as model risk guidance, data protection law or the EU AI Act; our guide to AI agent regulation mapped to controls sets those out.

This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

Where Pryme fits

Pryme makes the four treatment levers operational. Depth is set per agent and can be lowered the same day; a capability can be removed from the agent's brief; customer limits tighten bounds; and an Attest run that falls short cuts the agent to the highest depth it cleared, or to depth 1 if it cleared none, automatically. Each verdict names the bound that decided and is filed in an append-only record, which is the evidence Manage needs.