Map is the most under-rated of the RMF's four functions because it sounds clerical. It is not. The Map artefact is what every other function reads from. If it is wrong, vague, or absent, Measure has nothing to measure against and Manage has nothing to defend.
Context first, system second
The base NIST guidance for Map covers five categories: context, system categorisation, risks and benefits, impact, and oversight. For agentic systems, the order in which a team fills these in matters. Context first. Before anyone draws a box and labels it "agent", write a paragraph in plain language: who the agent serves, in what business process, replacing or augmenting which existing task, with what frequency, under what regulatory regime, with what tolerance for being wrong.
This paragraph is the answer to the first of the five honest questions from Chapter 4. If the team cannot write it without hedging, the agent is not ready to be built and no further mapping work will rescue it. We have seen teams attempt to skip this step in favour of architectural diagrams. The diagrams are always plausible. They are also always built on context that, when written down later, no one agrees with.
Action-consequence mapping
The base RMF assumes that risk is a property of the model. For agents, that assumption is incomplete. An agent's risk profile is determined by the interaction between model behaviour and tool capability. A perfectly aligned model with database-write access and a single ambiguous prompt can do enormous damage; a poorly aligned model with read-only retrieval can do almost none.
The Cloud Security Alliance's Agentic AI RMF Profile proposes Action-Consequence Mapping as the missing artefact. For every tool the agent can invoke, write down: what it does in the world, whether the action is reversible, what its blast radius is (one record? one customer? one tenant? the whole company?), what authority it requires, and what happens when it fails. This is not difficult work. It is just work that almost no one does.
The output is a directed consequence graph, but it does not have to start as one. A team's first version is usually a table with five columns. The graph emerges when you start drawing arrows from one tool's output to another tool's input — and that is also the moment when the worst surprises appear, because a sequence of three reversible tools can produce one irreversible outcome, and only the graph will tell you so.
Multi-agent topology
If your design has more than one agent — an orchestrator and sub-agents, or a "crew" — Map gets harder by exactly one dimension: the agents talk to each other. The CSA paper calls this AG-MP.3: Multi-Agent Topology Risk, and it is the gap in the base RMF that bites most often.
Three failure modes show up: compromise propagation (a poisoned input to one agent flows through the network to others); emergent behaviour (the system as a whole does something none of its agents would do alone); and adversarial exploitation of the inter-agent channel itself (a malicious sub-agent spoofs an authority it does not have). The first two are not security problems; they are design problems. The third is a security problem, and is the reason the inter-agent channel needs the same authentication, logging, and least-privilege as any external API.
The most expensive multi-agent failures we have seen are not malicious. They are an orchestrator that, after a tool error, fell back to a sub-agent's reasoning, which fell back to a tool retry, which compounded a small mistake into a large one. Topology must be drawn for the well-behaved case and the failure case. The latter is harder and more important.
The artefact a team can carry
If you finish a serious Map exercise for one agent, you should have one page. The page contains: a context paragraph; a system summary; the action-consequence table; the topology diagram (if multi-agent); the autonomy tier (0–4, per Chapter 3); the human principal who authorised the agent; the kill-switch procedure; and the date the next Map review is due. That is enough. Anything longer is usually a sign that the team is hiding from the work, not doing it.
The next chapter takes this artefact and asks: how would we know if any of it is still true? That is the Measure function, and it is where most enterprise agent programs visibly come apart.