NIST AI RMF monitoring and drift for AI agents

Monitor what the agent does, not only what it says. The NIST AI RMF expects risks to be tracked after deployment and systems to be stopped when behaviour departs from intent. For AI agents, that means replaying fixed test cases on a schedule, watching overrides and escalations, and cutting authority automatically when a signal crosses its line.

What does the NIST AI RMF say about monitoring?

The framework spreads monitoring across two functions. Measure asks for mechanisms to track identified risks over time and to gather feedback on whether measurement still works. Manage asks for post-deployment monitoring plans, ways to capture input from users and affected people, change management, incident response and recovery, and mechanisms to supersede, disengage or deactivate a system whose outcomes drift from its intended use.

The framework is voluntary and does not set monitoring frequencies or thresholds. It describes the outcome: you know when your system has changed, and you act before the change causes harm. For how the four functions connect, see how the NIST AI RMF applies to AI agents.

Who does it apply to?

Organisations that adopt the framework. Monitoring belongs to the agent's owner and operators, with risk reviewing the results. Where the agent was supplied by a vendor, the deploying firm still owns monitoring of its own use, because only the deploying firm sees its own customers and outcomes.

How does an agent drift?

Drift in a classic model usually means its inputs or the world have moved away from the training data. Our glossary pieces on model drift and data drift cover those. An agent drifts in more ways, because it has more moving parts.

The model changes under it. Model providers update their models. The agent's brief is unchanged, yet its behaviour on edge cases can shift overnight.

Its inputs change. A new product launches, a fee changes, customers start describing a problem in new words. The agent meets cases it was never tested on.

Its sources change. Someone updates the policy library or the product terms. The agent now answers from different facts, sometimes correctly, sometimes from a half-edited page.

The people around it change. This is the drift most firms miss. Reviewers who once read every held item begin approving in batches. A capability that was meant to be supervised becomes, in practice, unsupervised. Nothing in the agent changed; its real authority grew.

Its tool use changes. An agent that once asked for a document before updating a record starts updating first. Answer quality can look stable while the sequence of actions has moved.

What signals should trigger action?

Watch signals that track each kind of drift, and decide in advance what each one does when it crosses its line.

• Sentinel replay. Re-run a fixed set of known cases every week. A fall on any metric is the clearest early warning of model or source drift.
• Override rate. How often reviewers change what the agent drafted. A rise suggests the agent is getting worse; a fall towards zero can mean reviewers have stopped checking.
• Escalation and refusal rates. Sudden drops mean the agent is taking on cases it used to hand over.
• Grounding failures. Claims that cannot be traced to a source.
• Complaints and contact repeats. Customers who come back about the same issue.
• Tool-call pattern. Changes in which tools are called, how often and in what order.

Take an illustrative case. A card issuer's disputes agent drafts chargeback responses. After its model provider ships an update, the weekly sentinel replay shows the agent citing the cardholder's account history less often. Answers still read well. The rule set in advance drops the agent from drafting to read-only for disputes until it is re-tested. The owner gets an alert, and the change is filed with its reason.

How do you meet the framework's monitoring outcomes?

Where monitoring reveals new effects on people, revisit the agent's impact assessment; our piece on NIST AI RMF impact assessment for agents covers it.

What will a supervisor, auditor or customer ask?

• How would you know if your model provider changed the model?
• What happened the last time a monitoring signal crossed its threshold?
• Who reviews override rates, and what rate worries them?
• How do you detect reviewers rubber-stamping held items?
• Can an agent's authority fall without a person deciding it should?

What does the framework not settle?

It does not tell you how often to monitor, what thresholds to set, or whether authority should fall automatically. It does not require you to report drift to anyone. Binding rules can: the EU AI Act places monitoring and record-keeping duties on providers and deployers of high-risk systems, and our comparison of the EU AI Act and the NIST AI RMF for agents sets out where they overlap. For the full set of 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

Attest includes a stable gate, which checks that an agent gives the same answer to the same question across runs, and certificates lapse after 90 days, so an agent's authority cannot outlive its evidence. A run that clears no depth drops the agent to depth 1 the same day. Because Pryme never updates model weights for a customer, a change in behaviour points to the model provider, the sources or the brief, each of which is versioned.