The Govern function of the NIST AI RMF sets the policies, roles, culture and processes the other three functions depend on. For AI agents, Govern has one job above all: decide who may grant an agent authority to act, on what evidence, within what limits, and how that authority is reviewed and withdrawn.
What does the Govern function ask for?
The NIST AI Risk Management Framework 1.0 has four functions: Govern, Map, Measure and Manage. Govern is cross-cutting; it informs and runs through the other three. In substance, it asks organisations to:
- have policies, processes and practices for mapping, measuring and managing AI risk, aligned with legal and regulatory requirements;
- set out accountability structures, with roles and responsibilities documented and people trained;
- prioritise workforce diversity, equity, inclusion and accessibility in AI risk work;
- foster a culture that considers and communicates AI risk, including the ability to raise concerns;
- engage with relevant AI actors and people affected;
- address risks from third-party software, data and AI, including systems and models supplied by others.
Our pieces on the Map function and the Measure function cover what Govern's policies feed into, and our overview of how the NIST AI RMF applies to agents puts all four together.
Who does it apply to?
Any organisation that adopts the framework, which is voluntary. Govern is typically owned by senior leadership and risk functions, with input from legal, compliance, technology and the business lines that use AI.
What should Govern decide for agents that act?
Most AI policies were written for models that produce outputs. Agents call tools: each action is a function call that changes something in a system. Our explainer on function calling covers the mechanism. Policy has to reach that point, which means Govern must decide five things.
A policy on authority. How does an agent come to be allowed to take an action? Our answer: per capability, earned on evidence from the organisation's own cases, enforced at the moment of action, and expiring. Whatever your answer, write it down; without it, authority is whatever an engineer configured.
Risk tolerance by action type. Reading data, drafting messages, executing routine changes and moving money carry different risks. Govern should set what each class of action requires before an agent may take it unsupervised.
Roles and decision rights. Who owns each agent, who approves changes, who decides on held actions, who may stop an agent. Our piece on accountability roles under the framework sets them out.
Third-party models. Agents run on models from model providers that change over time. Govern should require re-testing after a provider's change and set what happens to an agent's authority meanwhile.
A culture of challenge. Staff working beside agents must be able to report a bad action without fear, and those reports must reach the agent's owner.
The principle under all five is that you govern the action, not the model. The model is a supplier's component; the action is what affects your customers.
Take an illustrative case. A regional bank's operations team wants an agent to waive late fees up to a small amount. Under a working Govern function, the request runs through the authority policy: the business owner proposes the capability, the agent is tested on past waiver requests from the bank's own records, risk sets the limit, and a named approver signs off. When the model provider later updates its model, the capability drops back to drafting until it is re-tested. Without that policy, the same capability arrives as a configuration change nobody approved.
How do you put Govern into practice for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Policies for AI risk | Agent authority policy: how authority is granted, limited, reviewed and withdrawn | Approved policy |
| Legal alignment | Policy maps agent capabilities to applicable regulatory requirements | Regulatory mapping |
| Accountability structures | Decision-rights register per agent | Register with named people |
| Risk tolerance | Approved tolerance per action class (read, draft, execute, move money) | Tolerance statement |
| Third-party risk | Model provider changes trigger re-testing; authority reduced until passed | Supplier change log and re-test records |
| Culture and reporting | Route for staff to report agent errors, reviewed by owners | Concern log and responses |
| Engagement with affected people | Customer feedback and complaints about agents fed to owners | Feedback summaries |
| Training | Role-based training on agent risk | Training records |
What will a supervisor, auditor or customer ask?
- What is your policy on how agents gain authority to act?
- What risk tolerance has leadership set for agents that move money or change customer records?
- Who owns each agent, and who may change it?
- What happens when your model provider changes the model?
- How do staff report an agent mistake, and what happened to the last report?
- How does your agent policy map to the regulations you are subject to?
What does Govern not cover?
Govern sets the frame; it does not identify specific risks (Map), test them (Measure) or treat them (Manage). The framework is voluntary and does not replace regulation such as the EU AI Act, model risk guidance such as SR 11-7, or sector conduct rules. For the argument that governance must be enforced at the moment of action rather than stated in policy, see our guide agent governance is a bound, not a model.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme turns an authority policy into enforcement. Depth is earned per agent from Attest evidence, capped by the customer's plan, and lapses after 90 days. Every action meets the minimum chain of five bounds, and the verdict records which bound decided, so policy and practice can be compared directly.
Questions people ask
Can existing AI policies cover agents without changes?
Rarely. Most were written for models that inform decisions. Agents need explicit policy on authority to act, risk tolerance by action type and what happens when the model provider changes.
Who should own the Govern function for agents?
A senior leader accountable for AI risk, supported by risk, compliance, technology and the business. Ownership should not sit only with the team that builds agents.
How detailed should an agent authority policy be?
Detailed enough that two people reading it would grant the same agent the same authority. Principles alone leave too much to whoever configures the agent.