How to govern AI agents, not just chatbots

There is a quiet gap in most AI governance programs right now. The policy on file was written for generative AI, the kind that drafts an email or summarizes a document. Then the same vendors started shipping agents, and the policy never caught up.

The difference matters more than it sounds. A chatbot produces text and waits for a human to decide what to do with it. An agent decides for itself. It can plan a sequence of steps, call other tools, move data between systems, and complete a task without anyone approving each move. Your old policy assumed a person was always the one taking the action. An agent removes that person from the loop, and everything downstream of that assumption needs to be rethought.

This is not a reason to panic or to ban agents. It is a reason to govern them on the dimensions that actually describe what they do. Here is how to think about it.

Why "risk tier" alone stops working

Most governance programs score an AI system on business impact. Higher impact, more scrutiny. That logic is sound, and you should keep it. The problem is that impact alone cannot tell the difference between a system that suggests and a system that acts.

Picture two tools with the same data and the same business impact. One drafts a customer email for a human to send. The other sends the email itself, and can issue a refund while it is at it. Same tier on paper. Completely different risk in practice. The second one can cause harm before anyone notices, because no human sits between the decision and the action.

If your classification only measures impact, you will govern both of those the same way. That is how the riskier one slips through.

The dimensions that actually describe an agent

To govern agents properly, you need to classify a few things your old policy probably never asked about. These are the questions that matter.

Autonomy: how independently does it act?

This is the core question. Does the system only make suggestions a human acts on, or can it execute steps on its own? Somewhere in the middle sit the systems that act within narrow limits and escalate when they hit an edge. Score this on a scale, from fully supervised up to fully autonomous, and be honest about where each system really sits. Teams tend to describe their agents as more supervised than they actually are.

Authority: what is it allowed to affect?

Autonomy is about whether it acts. Authority is about what it can touch when it does. An agent that can only read information is a different animal from one that can move money, change records, or send messages to customers on your behalf. Define the blast radius. The wider it is, the more governance the system needs, regardless of how "smart" it looks.

Human oversight: who is watching, and when?

"Human in the loop" gets used as if it means one thing. It does not. There are a few distinct patterns, and the difference between them is the difference between catching a problem and reading about it later.

• A human approves each action before it happens.
• A human monitors in real time and can step in.
• A human reviews after the fact, on a sample or a schedule.
• Nobody is watching at all.

Every one of those is a legitimate choice for the right system. The failure is not choosing. It is deploying an agent without deciding which pattern applies, and finding out the answer was "nobody" after something goes wrong.

The most common agent governance failure is not a bad decision. It is an unmade one. Nobody decided how much oversight the system needed, so it shipped with none.

Let the classification drive the controls

Once you can describe a system by autonomy, authority, and oversight alongside the usual impact and data sensitivity, the governance almost writes itself. High autonomy, broad authority, or no human oversight should push a system into your strictest tier automatically. No debate in a meeting, no exception talked through in a hallway. The classification decides.

What "strictest tier" should require is not exotic. It is the same discipline you already apply to your riskiest systems, pointed at the right targets:

• A named owner and a committee sign-off before it goes live.
• A written decision record capturing why the autonomy and authority were granted.
• A way to stop it fast. Call it a kill switch, a circuit breaker, whatever fits your environment. The point is that someone can pull it without a change request.
• Monitoring that runs continuously, not a review once a year.
• A shorter review clock, because a system that acts on its own earns re-checking more often than one that only suggests.

Do not forget the agents you did not build

The hardest agents to govern are the ones nobody decided to adopt. A SaaS tool your team already uses ships an update, and a feature that used to draft text can now execute a workflow. No procurement review, no security check, because the tool was already approved last year. It changed under you.

This is why an agent governance program has to start with visibility. You cannot classify what you have not found. Before you write another policy line, run an honest inventory of where AI already lives in the business, including the capabilities buried inside tools you already pay for. Add one question to your vendor reviews from now on: can this product plan, call tools, or take actions without a human approving each one? If the answer is yes, it is an agent, and it belongs in the same governance as the ones you built yourself.

Where to start

You do not need a perfect framework to begin. You need three things in motion:

1. An inventory that surfaces the agents already running, including the ones embedded in existing tools.
2. A classification that scores autonomy, authority, and oversight, not just impact.
3. A rule that the classification, not a negotiation, decides the controls.

Get those three working and you have closed the gap that most programs still have open. Everything after that is refinement.