PrymeIntelligence

Agent governance·Article

Boards should govern agent authority, not agent technology

Boards should govern agent authority, not agent technology: what each AI agent may do, who answers for it, and the evidence that it stays in bounds.

Directors do not need to understand how a model predicts the next word. They need to know what each AI agent is allowed to do, who answers for it, and what evidence shows it stays inside those limits. Board oversight of agents is oversight of delegated authority, the same thing boards already do for people and committees.

Why do boards drift towards governing the technology?

Agent papers usually arrive at the board from technology teams, so they are written in technology terms. Model choices, architecture diagrams, vendor comparisons, accuracy benchmarks. Directors read them, ask sensible questions about data security, and approve. Nobody asks what the agent may actually do on a Tuesday afternoon without asking a person.

The technology framing also feels safer for directors who are not specialists. It turns a governance question into a procurement question, which boards know how to handle. But the risk to the business does not sit in which model was chosen. It sits in what the agent can change, send, pay or promise, and that is a question of authority.

There is a practical problem too. Models change every few months. A board that governs the model will be revisiting the same paper constantly and learning nothing it can act on. A board that governs authority sets something stable: this agent may draft customer letters and send none; that agent may issue refunds up to a set amount and no more.

What should a board actually oversee about AI agents?

Boards already oversee delegated authority. They approve a schedule that says who may sign contracts of what size, who may approve credit, who may commit spend. Agent oversight fits the same pattern, and our explainer on what delegated authority is sets out the basic idea. For agents, the board needs four things.

  1. An inventory of agents and what each may do. Not a list of tools, but a list of capabilities: read customer files, draft refunds, issue refunds up to a limit, close accounts.
  2. The depth each capability runs at. Whether the agent only reads, drafts for a person to send, executes routine work within limits, or moves money and takes actions that are hard to undo.
  3. A named person accountable for each agent. Someone who owns the outcome, signs off widening, and answers when something goes wrong.
  4. Evidence that the bounds hold. How many actions were allowed, held, refused or withheld, and whether any agent tried to act beyond its limits.

None of these needs a director to understand a model. All of them let a director ask a sharp question.

How does a delegation schedule for agents differ from one for people?

The shape is the same. The content needs more granularity. A person's delegated authority is usually expressed by role and amount: a branch manager may approve loans up to a figure. An agent's authority must also say how far it may act on each capability, because the same agent may be trusted to read everything, draft some things and execute almost nothing.

That is why a delegation of authority matrix for AI agents lists capabilities in rows and sets depth in each cell, rather than giving the agent a single job title. The board approves the matrix, or at least the parts that touch money, customers and regulated activity, and reviews changes to it.

Agent authority should also carry an expiry. People hold their authority until someone removes it, which is a known weakness. For agents, authority should lapse unless fresh evidence renews it. A board can ask a simple question each cycle: which agents had their authority renewed, and on what evidence?

Does the choice of model or vendor matter at board level?

It matters, but less than it seems and in a different way. A board should know which agents run on a third party's platform, because that creates a dependency and a concentration risk, and in some sectors a regulatory duty to manage it. It should not try to judge whether one model is better than another. That is a management decision.

The important point is that the board's control should hold whichever model sits underneath. If the bounds on an agent are enforced at the moment it acts, swapping the model does not change what the agent is allowed to do. We make this argument at more length in govern the action, not the model. For agents supplied by a vendor, the same logic applies: the vendor's assurances cover its platform, and your authority schedule still has to be yours, as our piece on governing AI agents supplied by vendors explains.

What should the board pack contain each quarter?

A short, consistent page per material agent is enough. Directors should see the same fields every time, so changes stand out.

Item What it tells the board
Capabilities and depth What the agent may do now, and what changed since last quarter
Accountable person Who answers for it
Verdict counts Allowed, held, refused and withheld actions
Attempts beyond bounds Whether the agent tried to act outside its authority, and what happened
Widening and narrowing Depth increases and decreases, with the evidence behind each
Incidents Any harm or near miss, and the change made in response

The verdict counts are the part most boards have never seen. A rising share of held items may mean the agent is being given work above its depth. A cluster of refusals on one capability may mean the bounds are wrong, or the process is. Either is a governance signal, not a technical one.

What questions should directors ask management?

Good board questions about agents sound like questions about any delegated function. Who decided this agent could issue refunds? On what evidence? What stops it issuing a larger one? Who reviews the ones it cannot issue, and do they have time to do it properly? What happens if it stops working tomorrow?

Directors should also ask what an agent is not allowed to do, and how that is enforced. "The policy says it must not" is not an answer. A written instruction guides people; it does not stop software. The answer the board wants is that the limit is checked at the moment of action and the check is recorded.

What is the trade-off in governing authority rather than technology?

Governing authority asks more of management. They have to describe each agent's capabilities in business terms, set depth deliberately, name owners and produce evidence. Many organisations find they cannot do this at first, because their agents were deployed with broad access and no clear scope.

That discomfort is the point. If management cannot tell the board what an agent may do, the board has found a control gap, and it is better found in a board meeting than in an incident review. The longer guide to agent governance as a bound, not a model describes the structure that makes these answers possible. What should change for directors is simple: stop asking which model, and start asking which authority, held by whom, and proven how.

Questions people ask

Should the board approve every new AI agent?

Not every one. The board should approve the framework and any agent whose authority touches money, customer outcomes or regulated activity above a threshold it sets. Lower-risk agents can be approved by a committee under delegated powers, with the board seeing the inventory.

Which board committee should own agent oversight?

Usually the risk committee, because agent authority is an operational risk question. Audit committee has a role in checking that the evidence is reliable. Whatever the choice, one committee should own it so nothing falls between them.

Do directors need AI training to do this?

They need enough understanding to ask good questions about authority and evidence, which is less than most training courses assume. A short briefing on what agents can do, how depth works and what the verdict record shows is usually more useful than a course on how models work.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.