NIST AI RMF mapping for agentic systems

NIST AI RMF 1.0 is a risk-management framework, not a product checklist. Its value comes from assigning outcomes to real owners, connecting them to technical and organizational controls, and retaining evidence that the controls operate through change.

For agentic systems, the mapping must extend beyond model accuracy. Agents select tools, handle delegated authority, cross data boundaries, and create external effects. Those behaviors make authorization, approval, audit integrity, containment, and incident reconstruction first-class parts of the profile.

How should an organization use this mapping?

Start with one system and one intended use. Name the affected people, business process, decision authority, data, model endpoints, tools, deployment boundary, and potential harms. Then select the relevant RMF outcomes and bind each to an owner, control, artifact, test, and review cadence.

This page is a practitioner mapping, not an exhaustive transcription of NIST subcategories. The official NIST publication and Playbook remain authoritative.

How does GOVERN become operating practice?

GOVERN establishes the policies, accountability, culture, and lifecycle processes that make the other functions repeatable.

Governance need	Agentic-system implementation	Evidence artifact	Review question
Accountable ownership	Named system owner, risk owner, data owner and decision authority	Responsibility matrix and approval policy	Who can accept which risk?
Risk tolerance	Consequence classes and prohibited actions	Risk taxonomy and action catalog	Which actions may never be delegated?
Lifecycle control	Release gates for model, policy, tool and data changes	Versioned release evidence	What change forces reevaluation?
Workforce competence	Role-specific training for reviewers and operators	Training scope and exercise records	Can reviewers recognize material risk?
External accountability	Contract, provider and downstream responsibility boundaries	Shared-responsibility matrix	Which party owns a failed control?
Documentation	Current system card, data map, policy set and incident process	Controlled document set	Can a new reviewer reconstruct the system?

Assign decision authority, not only responsibility

A RACI table that names an owner but does not define what they can approve leaves the most important question unanswered. Specify risk-acceptance limits, approval tiers, escalation, emergency authority, expiry, and separation of duties.

Make changes visible to governance

Models, prompts, tools, integrations, policies, and data sources can all change system behavior. Record the change class, required tests, approver, rollout plan, rollback or recovery path, and monitoring period.

Define the boundary of public claims

Marketing statements, model cards, security pages, and procurement responses should resolve to release evidence. "Aligned with" should name the control family or outcome and the evidence boundary rather than implying a certification the framework does not grant.

How does MAP define the real system context?

MAP establishes context, intended use, actors, impacts, dependencies, and risk sources.

Map the workflow, not just the model

Document the complete path from request to side effect: identity, input, retrieval, model endpoint, planning, policy, approval, tool adapter, target system, receipt, and audit store. A model-only diagram misses most agentic risk.

Map affected parties

Identify the people who request work, review it, are described by the data, receive outputs, or are affected by actions. Include people who cannot directly interact with the system but may bear consequences.

Map data and provenance

For each source, record owner, collection basis, classification, freshness, permitted purpose, retention, quality limitations, and retrieval boundary. Distinguish data used for inference from data written by tools.

Map deployment and provider dependencies

List model endpoints, identity systems, policy services, storage, queues, tools, observability, update channels, and administrators. For air-gapped systems, identify which dependencies must exist locally and how updates cross the boundary.

Map foreseeable misuse and failure

Include prompt injection, goal manipulation, tool misuse, excessive privilege, data exfiltration, stale context, memory poisoning, cascading actions, reviewer fatigue, unavailable controls, and irrecoverable external commitments.

How does MEASURE produce decision-quality evidence?

MEASURE selects methods and metrics for evaluating trustworthiness characteristics and risk.

Measurement area	Agentic evidence	Weak substitute to avoid
Task quality	Scenario evaluation with grounded acceptance criteria	General benchmark score
Authorization	Positive and negative policy tests at tool boundaries	Prompt saying "do not"
Human review	Parameter mismatch, expiry and duplicate-use tests	Screenshot of an approval dialog
Audit coverage	State-change boundary inventory and mutation tests	Count of log lines
Privacy	Data-flow tests, minimization review, access negatives	Policy statement alone
Robustness	Fault injection across model, policy, tool and queue	One successful demo
Security	Threat-model tests and incident exercises	Vendor questionnaire only
Monitoring	Defined signals, owners, thresholds and response	Dashboard with no reader

Measure the exact release

Evaluation results should identify source, model, policy, tool adapters, configuration, hardware or provider, dataset version, and test date. A score from a prior model or different environment does not establish current behavior.

Include negative and counterfactual tests

Test denied actions, missing attributes, cross-tenant requests, changed approval parameters, stale data, poisoned retrieval, unavailable audit storage, tool timeouts, duplicate delivery, and recovery. The absence of a bad event in ordinary use is not evidence that the detector works.

Separate model uncertainty from control certainty

Model output can be probabilistic. Authorization and approval decisions should still be deterministic and inspectable. Measure both layers without using a model confidence number as a substitute for policy assurance.

How does MANAGE turn findings into decisions?

MANAGE prioritizes risk, selects responses, allocates resources, communicates status, and monitors residual risk.

Choose a treatment

For each material risk, select avoid, reduce, transfer, accept, or monitor. Name the decision owner and evidence. "Add guardrails" is not a treatment until the control, boundary, test, and failure behavior are explicit.

Gate release on unresolved risk

Release criteria should include critical evaluation results, high-consequence action coverage, known limitations, incident readiness, reviewer staffing, and recovery. A waiver needs scope, owner, rationale, compensating controls, expiry, and review.

Monitor leading and lagging signals

Leading signals include denied unknown actions, approval mismatches, stale attributes, queue growth, drift and evaluation regressions. Lagging signals include incidents, reversals, complaints, unauthorized disclosure, or downstream harm.

Prepare containment and recovery

Define how to revoke an agent, policy, tool, grant, model endpoint, or deployment release. Test whether operators can stop side effects without losing evidence needed for investigation.

What does a complete control record look like?

Each mapped outcome should have a record like this:

RMF outcome: GOVERN 2.3
System interpretation: executive responsibility for agentic-system risk
Owner: system risk owner
Control: consequence taxonomy and approval authority matrix
Implementation: policy bundle + approval service + release gate
Evidence: versioned policy, negative tests, reviewer roster, audit samples
Cadence: each material change and quarterly review
Known limitation: customer-specific authority mapping required
Residual-risk decision: accepted by named owner through stated date

This is more useful than a binary crosswalk because it shows how the organization interpreted the outcome and what proof it expects.

Which artifacts should diligence request?

Request the system description, intended-use statement, actor and data map, risk taxonomy, action catalog, policy and approval model, evaluation plan, release evidence, model and tool inventory, incident runbook, audit verifier, monitoring ownership, provider responsibility matrix, open risks, and dated review record.

These artifacts should agree. If the architecture claims human approval but the action catalog contains unreviewed external effects, the mapping is not operating as a system.

How should the mapping handle framework change?

NIST states that AI RMF 1.0 is being revised. Version the mapping against the source publication and record the date reviewed. When NIST publishes a revision, perform a controlled delta review rather than silently relabeling the old mapping.

The same practice applies to OWASP, provider terms, regulations, customer requirements, and internal policy. A crosswalk is a maintained product, not a one-time spreadsheet.

What does Trunnion's position mean?

Trunnion designs for explicit authority, contextual access control, human approval, release-specific evaluation, and reviewable execution evidence. Those design objectives can support AI RMF outcomes, but the public site does not establish customer compliance, certification, or authorization. The applicable mapping and evidence are scoped to the release, configuration, environment, and written engagement.