NIST AI RMF Map function for AI agents

The Map function asks you to understand an AI agent before you let it act. For an agent, that means recording its purpose, every capability and tool it can call, the data it relies on, the systems it changes, and everyone affected, including people who never speak to it. Everything Measure tests and Manage treats comes from this record.

What does the Map function require?

The NIST AI Risk Management Framework 1.0 organises risk work into Govern, Map, Measure and Manage. Map establishes the context in which risks can be identified. In substance, it asks an organisation to:

• understand and document the intended purpose, the setting of use, the applicable laws and norms, and the people involved;
• categorise the system, including the tasks it performs and the methods it uses;
• understand its capabilities, intended use, goals, and the expected benefits and costs;
• map risks and benefits for every component, including third-party software, data and models;
• characterise the likely impacts on individuals, groups, communities, organisations and society.

The framework is voluntary and does not say how to document any of this. For the full sequence of functions, see how the NIST AI RMF applies to AI agents.

Who does Map apply to?

Any organisation that adopts the framework. Map is usually owned by the business owner of the agent, with input from risk, compliance, data protection and the team that operates the systems the agent touches. Map should be done before the agent acts and repeated when its capabilities change, not once at project start.

What must be mapped when the system is an agent?

A traditional model has one output. An agent has a list of things it can do, and each one has its own risk. Mapping an agent as a single system hides that. The useful unit is the capability: one action the agent can take in one system, such as "read a customer's transaction history", "draft a collections letter" or "update a delivery address".

For each capability, record six things.

The system it touches. Which ledger, case management tool or messaging channel changes when the agent acts, and with whose credentials.

Whether the action can be undone. A drafted email can be deleted. A sent one cannot. A changed address can be reverted; a payment to the wrong account may not be recoverable. Reversibility is the single most useful input to later prioritisation.

The data it relies on, and where that data came from. An agent answering from the firm's policy library is in a different position from one reading an invoice that arrived by email. Map the provenance of each source, because untrusted inputs are where manipulation enters.

Who is affected. The customer, obviously. Also staff whose queue the agent fills, third parties such as payees, and groups who may be treated differently because of how the agent reads their data.

The human process it replaces or supports. What did a person do before, what checks did they apply, and which of those checks the agent will now skip or perform.

The rules that apply. A capability that declines a credit application sits under different law from one that answers a balance query. Map at this level and you can see which obligations attach to which action. Our guide on mapping agent controls to several regulations at once shows how to let one record serve several rulebooks.

How do you meet Map for agents?

Take an illustrative case. A payments firm plans an agent to handle merchant onboarding queries. The first map lists one system. A capability-level map finds five: reading the application, requesting documents, updating the merchant's contact details, changing the settlement account, and approving low-risk applications. Two of those, the settlement account change and the approval, are hard to undo and affect people beyond the merchant. They are flagged for testing before the agent may do either, and the settlement account change is marked as an action the agent should only ever draft.

What will a supervisor, auditor or customer ask?

• List every action this agent can take, in every system.
• Which of those actions cannot be undone, and who decided the agent may take them?
• Where does each piece of information the agent relies on come from?
• Who, other than the customer, is affected when the agent acts?
• Which regulations apply to each capability?
• When was the map last updated, and what triggered the update?

What does Map not cover?

Map identifies and records; it does not test. Whether the agent handles exclusions correctly, refuses what it should, or escalates when unsure is a question for the Measure function. Deciding what to do about each mapped risk is the Manage function. Map also does not satisfy any law on its own, though a good map makes impact assessments under data protection law or the EU AI Act much faster. The framework gives you the questions; it does not give you the control set, a point we argue in the NIST AI RMF is a useful map, not a control set. For the binding rules, see our guide to AI agent regulation mapped to controls.

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

Where Pryme fits

In Pryme, Agent Studio turns a plain-language description of the job into the agent's brief: role, sources and connections. Each connection is a capability with its own depth, and every source arrives through the Pryme Context Protocol labelled as sealed, signed, declared or external. That brief is the map, kept current because the agent cannot act outside it.