AI Agent Governance: A Practical Framework and Checklist

AI agent governance is the set of rules, owners and records that decide which agents may run, what they may touch, who approves them and what happens when one goes wrong. Start with an inventory, an owner and a risk tier for each agent. Then map the work to a framework such as the NIST AI RMF and check the EU AI Act dates.

Why agents need more than a usage policy

A chat policy tells people what not to paste. An agent policy has to cover something harder: software that takes actions. A coding agent edits files and runs commands. A support agent can send a message or issue a refund if you connect it to the right tool. An automation agent can touch many systems in one run. The risk is not only what data leaves, but what the agent does while it is there.

That is why governance is a separate layer from security. The controls on enterprise AI coding agent security decide what an agent can do. Governance decides what it should be allowed to do, who said so, and how you would know if it went wrong. The buying questions are on enterprise AI agents.

The two sources we anchor to

We use two public sources, and we name them so you can read them yourself.

NIST also published a concept note on 7 April 2026 for an AI RMF profile on trustworthy AI in critical infrastructure, which matters if you run such systems. The NIST site describes the framework's core as outcomes and actions that enable dialogue, understanding and activities to manage AI risks, organized under four functions: govern, map, measure and manage. ISO/IEC 42001 is another reference. Cursor lists an ISO/IEC 42001:2023 certification among its own, and the standard is an AI management system standard, but we did not read the standard text for this page.

This page is editorial guidance, not legal advice. Our mapping of agent practices to the NIST functions is our own reading, and NIST does not publish an agent-specific profile that we could cite.

The four NIST functions, applied to agents

We find the order useful in practice. Most companies jump to Measure with an evaluation project before they have done Map, so they test an agent no one has described. Start at Govern and Map.

Step 1: Build an inventory

An inventory is a table with one row per agent. It is the single most useful governance artifact, and many companies do not have one. Include every agent, from the developer who installed a coding agent last month to the support tool a vendor added to your helpdesk.

Shadow agents are the usual gap. Developers install tools on their own, so the inventory needs a way to find them: expense reviews, package manager and extension audits, and a clear route for registering a tool without a fight.

Step 2: Assign risk tiers

A risk tier decides how much review an agent gets. Three tiers are enough for most companies. The thresholds are your choice, and the table is an example.

Two questions sort most agents. Can it change anything outside a sandbox? And does it see data you could not publish? A yes to the first or the second moves it up a tier. A yes to both puts it in High.

An example register, three rows

The rows below are invented illustrations of the format, not real systems, so you can see how the fields read in practice.

Row C shows how one attribute, running unattended, lifts an agent a tier even though its actions are small. That is the point of tiers: they reflect how much a person watches, not only what the agent can do.

Step 3: Decide autonomy on purpose

The central governance decision is how much an agent may do without asking. Claude Code documents permission modes from Manual, where it starts read-only and asks before edits and commands, through to modes where it acts with fewer prompts. Cursor documents run modes that range from an allowlist to an Auto-review classifier, and calls them best-effort guardrails. The vendors give you the dial. Your policy sets it.

Write down who may raise an agent's autonomy, and make that person different from the person who benefits from the speed. Lock the setting centrally where the tool allows, as Claude Code does with managed settings.

Step 4: Records and logs

Governance without records is opinion. Keep four kinds.

1. The register from step 1, reviewed on a schedule.
2. Decision records: who approved each agent, on what date, against which risks.
3. Activity logs: what each agent did. Vendors differ here, and Cursor's audit log, for example, covers admin events and does not record prompts or generated code. Claude Code can export usage and tool events through OpenTelemetry, and Anthropic's Compliance API describes an Activity Feed with six-year retention. Decide what you need, because zero retention and full logging pull against each other.
4. Incident records: what happened, what was done, what changed afterwards.

Set a retention period for each, and an owner who can produce them in a week.

Step 5: Data rules per tier

Tie agent tiers to the data rules in the vendor terms. Retention and training positions differ by vendor and by model. As of 2026-10-31, Anthropic's Fable 5.1 requires 30-day retention, OpenAI keeps abuse logs for up to 30 days unless you have approved controls, and Cursor says some models need provider retention that conflicts with Privacy Mode. A policy that says "no vendor retention for High-tier data" can be checked against those documents. Our vendor pages cover Anthropic, OpenAI and others in the same format.

Step 6: Incidents

An agent incident is any case where an agent did something outside its remit, exposed data, or acted on hostile input. Plan for it before it happens.

The inventory makes the assess step fast, because it already says what the agent could reach. The kill switch is a design requirement for buying: ask each vendor how you revoke a key, remove a user and disable an agent across the company in minutes.

The EU AI Act dates to know

The EU AI Act is a legal text, and we reproduce dates from the implementation timeline on artificialintelligenceact.eu, last updated 31 August 2026, so check the current text and your own legal advice.

Two practical points for agent buyers. AI literacy duties have applied since February 2025, so staff using agents need training that you can evidence. And whether any of your agents is a high-risk system under the Act depends on its use, not on the vendor. A coding agent used by engineers is usually a different case from an agent that screens job applicants or scores customers. Ask counsel to classify each High-tier agent.

A one-page agent policy outline

Keep it to a page. A long policy is not read, and a short one can be enforced.

Checklist

1. Name an executive owner for agent risk.
2. Build the inventory, and find the shadow agents.
3. Assign a tier to every agent.
4. Set the autonomy ceiling per tier, and lock it centrally.
5. Tie data classes to vendor retention terms, model by model.
6. Decide what to log, for how long, and who reads it.
7. Build a kill switch and test it.
8. Train staff, and keep the evidence.
9. Ask counsel to classify High-tier agents under the EU AI Act where relevant.
10. Review the register and vendor terms every quarter.

Our take

Governance fails in two ways. One is no register, so no one knows what is running. The other is a policy so heavy that developers route around it. The cure for both is the same: a short register, three tiers, an owner for each agent, and controls that the tools enforce rather than the handbook. The frameworks help with vocabulary, not with the work. The NIST functions are a good checklist for whether you have covered the ground, and the EU dates tell you when the legal clock starts. The vendor documents tell you what you can enforce today.

We have not run tests for this page. It reflects NIST and EU sources as read on 2026-10-31, and it is not legal advice. For help building a register, a policy and the controls behind them, get quotes from AI service providers.

Related pages

Enterprise AI agents, Enterprise AI coding agent security, build vs buy AI agents, AI agents vs agentic AI, private AI for teams.