The board’s questions about AI agents should begin with authority

When an AI agent can read records, call tools and change the state of a business process, the board’s first question should not be “Which model are we using?” It should be “What authority has this system been given, on whose behalf, and with what consequences?”

That starting point keeps oversight at the board’s proper altitude. Directors do not need to inspect every prompt. They do need enough information to see whether management has matched an agent’s mandate with evidence, controls and accountable ownership. The G20/OECD Principles of Corporate Governance place risk oversight and the integrity of reporting systems within board responsibility while leaving execution to management. Agent oversight should follow the same logic.

Ask what the agent can cause, not what it can say

An agent’s authority is the set of states it can alter: sending a message, changing a customer record, initiating a payment, merging code, ordering inventory or recommending a regulated decision. A fluent answer may be harmless; a plausible but incorrect action may not be.

Management should present an authority map for each material workflow. It should identify the agent’s data access, tools, action limits, financial or operational thresholds, required confirmations and prohibited actions. It should also show where authority originates. Is the agent exercising a standing organisational mandate, acting on a user’s delegated instruction or merely preparing a proposal for human approval?

The distinction changes the board conversation. A drafting assistant can be governed mainly through information handling and quality review. A system that creates binding external commitments needs stronger identity, authorisation, transaction evidence and recovery controls.

Connect authority to consequence

Authority without context is difficult to govern. The same action can have different consequences depending on the users, data, scale and reversibility involved. Ask management to describe plausible harm in operational terms rather than broad labels such as “high risk.”

A compact board view can use four questions:

Dimension	Board question
Reach	How many people, records, systems or transactions can one run affect?
Reversibility	Can an erroneous action be stopped or restored, and how quickly?
Detectability	Would the organisation know that the action was wrong?
Accountability	Which executive owns the workflow outcome and residual risk?

This is consistent with the NIST AI Risk Management Framework, which connects governance to context, measurement and management throughout the system lifecycle. The board does not need a universal autonomy scale. It needs evidence that greater consequence attracts tighter review.

Require one named owner and several clear contributors

Agentic systems cross product, technology, security, data, legal, risk and operations. Shared work must not become shared ambiguity. Every material agent should have one executive owner for the workflow outcome, even though several functions provide controls or assurance.

Ask who can approve initial release, who can change permissions, who accepts unresolved findings, who monitors production, who can suspend operation and who leads recovery. Then ask whether those people have both authority and information. A RACI chart is useful only if its “accountable” cell names a real decision-maker.

The GAO AI Accountability Framework groups accountability practices around governance, data, performance and monitoring. That combination matters: ownership without performance evidence is ceremonial, while measurement without an owner produces reports that no one must act upon.

Ask for evidence tied to a decision

Boards should resist both extremes: accepting a demonstration as proof and requesting an indiscriminate mass of technical results. The useful middle is a decision record that connects intended use, tested configuration, representative cases, findings, operating controls and residual uncertainty.

Ask management:

• Which release or expansion decision did the evaluation inform?
• Were actions and final system state checked, or only model responses?
• What important conditions were not represented?
• Which findings blocked release, constrained scope or became monitored risk?
• What change would make the evidence stale?

A score without this context cannot support oversight. Nor should external assurance language be accepted without a precise scope, method and limitation. A benchmark result can describe behaviour under its conditions; it cannot transfer accountability away from the organisation deploying the agent.

Test the intervention path before relying on it

“Human oversight” is not an adequate answer unless someone can intervene at the speed and level the workflow requires. Ask what signals trigger review, what an operator can actually stop, whether partial actions can be reversed, and when customers or affected teams are informed.

The board should see evidence from drills or controlled tests, not only a policy statement. A kill switch that has not been exercised, an escalation inbox that is not staffed and a rollback plan that cannot restore external state are aspirations rather than controls.

This is where cybersecurity, operational resilience and AI governance meet. The control objective is not to prevent every failure. It is to bound authority, detect loss of control and restore a known operating state before consequences compound.

Request reporting that reveals change

Quarterly reporting should show how the authority profile and evidence have changed, not merely how many AI projects exist. Useful indicators include new tools or data access, material permission changes, exceptions, failed or inconclusive evaluations, incidents and near misses, intervention performance, unresolved high-consequence findings and upcoming review triggers.

The IIA AI Auditing Framework separates governance, management and internal-audit perspectives. That separation helps boards ask whether first-line owners operate controls, second-line functions challenge them and internal audit provides appropriately scoped assurance—without pretending these roles are interchangeable.

The result should be a short, repeatable conversation: what may the agent do, what changed, what evidence supports continued operation, where uncertainty remains and who is accountable for the next decision. Starting with authority makes every later question sharper.

Use one worked authority review

Consider an agent proposed for supplier onboarding. It can collect documents, compare them with policy, create a supplier record and invite an authorised employee to approve payment details. A model-capability briefing might emphasize extraction accuracy. An authority review exposes a more useful set of board-level facts.

The agent can read identity and bank information, create a record that other systems trust and send an external message. It must not approve a supplier, change bank details after approval or bypass separation of duties. Its action is reversible inside the supplier system, but a fraudulent invitation could cause an external disclosure before detection. That combination makes authentication, provenance, confirmation and timely suspension more important than a small improvement in document classification.

Management could therefore propose a staged mandate: the agent extracts and drafts; deterministic checks validate required fields; a named employee approves record creation; any bank-detail mismatch routes to a separate team; and the agent’s invitation tool accepts only approved domains. The evidence pack would include boundary cases, hostile documents, cross-supplier isolation, duplicate prevention and a drill showing that credentials and queued invitations can be stopped.

The board or its committee does not decide the regex, model or queue design. It asks whether the staged authority matches consequence, whether management tested the controls it relies upon and when broader authority would return for review. That is a governance conversation directors can have without pretending to engineer the system.

The same review should include the negative option. Management should explain what value is lost if authority stays narrower and what evidence would justify expansion later. This keeps restraint from being treated as technical failure and makes progressive delegation an explicit business choice.