Skip to content
GovernanceUpdated 13 min read

NIST AI RMF for AI agents

Definition

The NIST AI Risk Management Framework is a voluntary framework that organises AI risk work into four functions: Govern, Map, Measure and Manage.

Applied to AI agents, it supplies the structure for inventorying what an agent can reach, tiering its risk, measuring its behaviour in production and responding when it acts outside its scope.

The framework is not agent-specific, and that is part of its value. It gives a common vocabulary that security, legal and product teams already recognise, which is more useful than a bespoke checklist nobody outside the programme has read.

Why does the NIST AI RMF matter for agents now?

Agents have made one of the framework's assumptions false. MAP asks an organisation to describe each AI system, its context and its dependencies. Agents are installed by individuals, connect to servers discovered at runtime, and hold credentials in config files. The inventory the framework assumes is the thing most organisations cannot produce.

Adoption makes that gap expensive. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily and 31% of daily users spent four or more hours a day with them (Stack Overflow Developer Survey 2026). A population that size cannot be governed by submissions alone.

The risk data explains why measurement has to be continuous. The largest public agent red-teaming competition recorded 1.8 million attacks and more than 60,000 successful policy violations across 22 frontier agents, and found little correlation between robustness and model size or capability (arXiv:2507.20526). A framework whose MEASURE function runs once before launch has nothing to say about a number produced after it.

Regulation is converging on the same shape, which is why the framework is worth the effort. The EU AI Act's obligations for high-risk systems cover risk management, documentation, logging and human oversight, and an organisation that has implemented Govern, Map, Measure and Manage has most of the artefacts already.

How exposed is your setup? Compass gives you a starting read that maps to the framework's functions: compass.alyria.ai.

How does the AI RMF apply to agents differently?

The four functions do not change. What changes is the evidence each one needs, because an agent's risk is in its runtime behaviour rather than in its documentation.

FunctionStandard AI systemAI agent
GovernPolicies, roles and risk appetite for AIAdds per-agent ownership, delegation rules and approval authority
MapSystem purpose, data, dependencies, affected partiesAdds tools, MCP servers, credentials, destinations and runtime capability set
MeasureAccuracy, bias, robustness, driftAdds attack success against the real tool set, denial and approval metrics, capability drift
ManageIncident response, monitoring, retirementAdds containment, credential revocation, agent suspension and scope rollback

In practice: The functions are identical on paper. The Map and Manage functions acquire a runtime dimension that a model-only programme never needed.

What does each function require for agents?

Govern

Govern establishes the culture, roles and accountability. For agents it needs three things that model governance did not: a named owner per agent, a tier that determines the control set, and a written rule for which actions require human approval.

Govern also covers third-party risk. An MCP server from a public registry is a supplier, and the framework expects supplier risk to be treated as part of the system's risk rather than as a procurement afterthought.

In practice: Governance is complete when a new agent cannot reach production without an owner, a tier and a policy file.

Map

Map is where most agent programmes discover how much they did not know. The framework asks for the system's context, its dependencies and the people affected. For an agent that means the tool list, the servers behind it, the credentials it can use, the data it can read and the destinations it can reach.

The dependency map is the part that changes fastest. Tool lists are negotiated at connection time, servers update without review, and new integrations appear between assessments. A map produced once is a historical document.

In practice: Map the capability set from observation, and date every map entry. An undated inventory is a guess with a table around it.

Measure

Measure is where agents are hardest and most rewarding. The framework expects testing, monitoring and metrics. For agents, model benchmarks are close to irrelevant: what matters is whether the agent, with its real tools and real credentials, can be made to act against its purpose.

Useful measures include attack success against the deployed configuration, denials per thousand calls, the approval queue's refusal rate, the gap between approved and observed capability, and the share of actions with a complete decision record. Each is measurable on a weekly cadence, which is what makes Measure a control rather than an audit.

In practice: If a metric cannot change a decision, it is reporting. Keep the five that can.

Manage

Manage covers response, recovery and residual risk. For agents it needs specifics that the general framework leaves to the organisation: who can suspend an agent, how fast credentials are revoked, how a scope rollback is executed and what evidence the response produces.

Residual risk is where honest programmes differ from optimistic ones. Some agents will hold two legs of a dangerous combination for business reasons. Manage is where that acceptance is written down with an owner, a compensating control and a review date.

In practice: A containment runbook that has never been exercised is a document. Exercise it once per tier per year.

What the framework leaves to you

The framework names the functions and does not choose your thresholds. It will not tell you which actions need approval, how long a credential may live, or what a high-impact agent is in your business. Those are decisions, and they have to be made once, written down, and reviewed rather than renegotiated per project.

The useful way to fill that gap is to tie each threshold to something observable. An approval threshold tied to a currency amount, a credential lifetime tied to a task, and a tier tied to whether an action can be undone are all defensible in a review because they can be tested. A threshold with no test behind it becomes a paragraph in a policy nobody reads.

How to implement the NIST AI RMF for AI agents

The sequence below turns the four functions into artefacts a small team can produce.

1. Build the register from observation

Combine submissions with endpoint discovery. Record the agent, the owner, the tools, the data, the identity, the destinations and the tier.

Tip: Include the config path that enabled each tool. It converts an abstract inventory row into a fixable item with a name attached.

2. Assign a tier per agent and per action

Tier by reversibility and blast radius, and attach the control set to the tier. One agent can span several tiers, which is normal and makes policy easier to defend.

3. Write the capability policy as an artefact

Govern expects documented decisions. Map expects described scope. One policy file per agent satisfies both and becomes the object that REVIEW and audit can inspect.

Tip: Store the policy in version control with the agent's code. Policy in a wiki drifts from reality within a quarter.

4. Define the measures before deployment

Choose the five metrics, the collection method and the review cadence before the agent ships. Deciding afterwards produces dashboards that flatter.

5. Test against the real configuration

Attack the deployed tool set, credentials and egress path, not a mock. Record the attack success rate and the denial behaviour, and repeat the test when the model or the tool list changes.

6. Instrument the decision record

Every tool call, hold and denial produces a signed record naming the agent, the arguments, the policy version and the outcome. This is the artefact that makes Measure and Manage possible.

7. Assign the response roles

Name who can suspend an agent, who can revoke credentials, who approves a scope change and who signs off residual risk. Write the runbook and exercise it.

Tip: Measure time to revocation, not time to detection. Detection without a fast stop is a long incident.

8. Review on a cadence tied to the tier

Tier one agents monthly, tier two quarterly, tier three annually. The review asks whether the scope still matches the register, whether the metrics moved and whether the residual risk is still accepted.

Where the NIST AI RMF applies in the agent lifecycle

Design

Govern and Map dominate. Ownership, tier, data scope and approval requirements are decided here, and every later artefact depends on them.

Note: A design that cannot name its owner will not produce a policy file, and a policy file that does not exist cannot be measured.

Development

Map refines into a capability list; Govern becomes a review process for tool additions. Dependencies are pinned and recorded as part of the system description.

Pre-deployment testing

Measure in its first form. Test the configuration, record the results and set the baseline against which drift will be judged.

Note: A test without a recorded baseline cannot detect drift later. Store the result, not only the conclusion.

Deployment

Manage prepares. Roles are assigned, the runbook is published, and the audit path is confirmed to receive events before the agent takes a real action.

Runtime

Measure runs continuously and Manage responds. Decisions, denials and holds are recorded and alerting is live on the patterns that matter.

Continuous monitoring

Review drift across the register, the capability set and the metrics. New tools, servers and destinations are changes to the system description, which means they are changes to the risk assessment.

Note: An agent whose description has not changed in a year is more likely to be unobserved than stable.

Decommissioning

Manage includes retirement. Disable the identity, remove the tools, retain the record and close the register entry so the next inventory starts accurate.

The takeaway: The framework is not a document set. It is four questions asked continuously, and agents make the answers a runtime property.

Worked example: applying the framework to 25 agents

A manufacturer has 25 agents in use, four of them touching production systems. Its AI policy references the NIST AI RMF and, until now, that reference has been aspirational.

Govern. Ownership is assigned for all 25, with four tiered as high impact because they can change production schedules or supplier records. A delegation rule is written: agents may not act on financial records without an approval, and no agent may hold a credential to the ERP without an owner sign-off.

Map. Endpoint discovery adds 9 agents that were not in the submitted list, plus 41 MCP servers, of which 6 are approved. The four high-impact agents are mapped in detail: tools, data, identity and destinations. The map is dated and stored with the agents' code.

Measure. A baseline test is run against the deployed configuration of each high-impact agent. One scheduling agent accepts an instruction embedded in a supplier email and writes a changed delivery date. The finding is recorded with the test, the payload and the tool call, which is the artefact that justifies the next quarter's work.

Manage. The scheduling agent is suspended for two weeks while egress and write scope are narrowed. Time to suspension is measured at 40 minutes; time to credential revocation at 12 minutes. Both become the runbook's reference figures.

Second quarter. The measures stabilise: denials per thousand calls fall as configuration mistakes are fixed, approval refusals hold at 6%, and the observed-to-registered gap closes from 9 to 2. The map is refreshed when a server update adds a tool.

The audit. An external auditor asks how the organisation knows its high-impact agents behave as described. The answer is three artefacts per agent: a dated map, a policy file with a version, and a decision export for the period. The framework's value was that it named those artefacts before the auditor did.

How standards and regulations influence the NIST AI RMF for agents

FrameworkPrimary focusRelationship to the AI RMF
NIST AI RMFGovern, Map, Measure, Manage, plus trustworthy characteristicsThe organising framework described here
NIST Generative AI ProfileConfabulation, information integrity, information security, human oversightAdds guidance that maps closely to agent failure modes
ISO/IEC 42001AI management system with certificationProvides the management-system structure the RMF assumes informally
ISO/IEC 42005AI system impact assessmentSupplies a method for the design-stage risk assessment
ISO/IEC 23894AI risk management inside enterprise riskConnects the RMF's functions to the enterprise register
EU AI ActBinding obligations by risk classReuses the same artefacts for high-risk systems
OWASP Top 10 for Agentic Applications 2026ASI01 to ASI10 threatsSupplies the threat content the Measure function tests
SOC 2Security, availability, confidentiality over a periodSets the evidence standard for access and monitoring

Further reading: AI risk management frameworks for agentic systems for how the RMF sits beside the others, AI TRiSM for agents for the operating model around it, and Agentic AI governance for the ownership layer.

How Alyria handles it

Alyria supplies the runtime evidence the framework's Map, Measure and Manage functions need, and it does so without a questionnaire. Beacon, the signed daemon on every machine, inventories agents, MCP servers, tools, credentials and network destinations continuously, so the system description is observed rather than asserted.

Lyra provides the enforceable policy artefact: one capability-brokered, information-flow-aware policy per fleet, versioned, decided locally before the call executes. That gives Map a described scope and Measure a baseline to compare against.

Spectra exports signed, chained OpenTelemetry to Alyria Cloud or your own SIEM, which is the decision record the framework expects, and Observatory holds policy decisions, detections, CVE posture and agent health in one plane for the periodic review.

Start free at alyria.ai and produce your first dated agent inventory in an hour: app.alyria.ai/signup.

The free Agent Exposure Report covers the read-only version, and the platform overview explains the modules.

Frequently asked questions

Is the NIST AI RMF mandatory?
No. It is voluntary in the United States and widely used as a reference elsewhere. It becomes effectively mandatory through contract, through sector regulators who expect it, or through an organisation's own policy, which is how most adopters encounter it.
Does the AI RMF say anything specific about agents?
The core framework predates the agent wave and its language covers AI systems generally. The Generative AI Profile adds guidance on confabulation, information integrity, information security and human oversight, which map closely to agent failure modes. Applying it to agents is an interpretation exercise, not a lookup.
Where do agents break the MAP function?
Inventory. MAP assumes you can describe the system, its context and its dependencies. Agents are installed by individuals, connect to servers discovered at runtime and hold credentials nobody recorded, so the inventory has to come from observation as well as from submissions.
What does MEASURE look like for an agent?
Behavioural metrics rather than model benchmarks: denials per thousand calls, approval refusal rate, drift between approved and observed capability, incidents per thousand sessions, and the share of actions with a complete decision record. Those are measurable weekly.
How much documentation is enough?
Enough that a person who was not on the project can answer what the agent may do, who approved it, what it touched and what happened last month. That is a register entry, a policy file, and an exportable decision record.
Can a small team use the AI RMF without a formal programme?
Yes. Start with a register, a tier per agent and a decision log. Those three artefacts satisfy the intent of Govern and Map for a fleet of ten and give you something to measure against later.
How does the AI RMF relate to ISO/IEC 42001?
The RMF is a risk framework. ISO/IEC 42001 is a management-system standard with certification. Many organisations use the RMF to structure the work and 42001 to certify that the work is managed, since the control objectives overlap substantially.

See how this looks on your own fleet.

The free Agent Exposure Report inventories every AI agent, tool and MCP server on your endpoints in about 30 minutes.