Who has the authority to authorize an AI agent?

Authority is not the same as approval.

An approval record can identify a person, a date, and a decision. That is useful evidence of an event. It is not, by itself, evidence that the person had the institutional authority to grant the power being requested.

The distinction matters when an AI agent can act across systems, communicate externally, change records, or continue operating after the context of its original approval has changed. A technically valid grant may still rest on an unresolved organizational question: who was entitled to make that grant, and how far did that entitlement extend?

The issue is not whether an approval exists. It is whether the approval establishes a defensible mandate for the authority that follows.

What has to be established?

A mandate review starts with four questions. They are related, but they are not interchangeable.

1. Who was entitled to grant the authority?Identify the grantor and the source of their authority: typically a delegation-of-authority matrix, an approval policy or a committee mandate. A name in a workflow is not the same as evidence that the person could authorize this class of action.
2. What was the agent authorized to do?Define the actions, systems, data, counterparties, and consequences within scope. Broad language such as “assist operations” does not necessarily establish a meaningful boundary.
3. Why was the grant valid in this context?Establish the business purpose, decision basis, applicable limits, and any conditions attached to the grant. A technically enforceable permission cannot supply a missing rationale for granting it.
4. What reopens the decision when scope changes?Identify the changes that require renewed authorization, who can approve them, and what happens while that decision is unresolved. A boundary written once can become detached from the work it was meant to govern.

This is proportionate, not a review of every agent action. The questions are asked where a grant is created or widened, against records the organization already holds: its delegation-of-authority policy, approval records, and committee or board mandates.

Why logs, boundaries, and reviews do not settle the question

These controls can be important. They can restrict actions, record events, and help detect deviations. But they answer different questions from the one a mandate review asks.

Three questions are easily run together. Is there a grant: the approval record. Does the agent comply with it: technical controls and monitoring. Was the grantor entitled to give it: institutional basis, scope and continuity. The first two matter. They do not settle the third.

Technical enforcement can operate exactly as configured while the authority behind the configuration remains unresolved. An audit trail may accurately describe what the agent did without establishing that the original grantor was entitled to authorize it—or that the grant still covered the work being performed.

This is not an argument against logs, policy-as-code, sandboxing, or continuous monitoring. It is a limit on what those controls can prove on their own.

The critical moment may be the change in scope

An agent is approved to draft a reply. Weeks later, it sends the reply without a new approval. The system may have followed its configured workflow. The record may be complete. Yet the organization still needs to establish whether the original delegation covered sending, whether the context had changed, and who had authority to widen the mandate.

A change in scope can quietly become a change in authority. The critical moment is not always initial deployment or the incident that follows. It may be the point at which the work expands and nobody is asked to reconsider the grant.

That is why a scope-change process needs more than a technical threshold. It needs an identified decision-maker, an explicit trigger for renewed authorization, and a defined response when authority has not been re-established.

Why this is not just a compliance check

A compliance check commonly tests a system or process against a defined requirement. A mandate review examines the decision that made the authority possible in the first place.

These activities can complement each other. A system may meet its technical requirements and still leave unanswered whether the grant was valid, whether its scope was justified, or whether a later expansion required a new decision.

The question comes before the controls are treated as conclusive: what decision authorized this system to hold this authority, and can that decision still be defended?

The signal is worth examining

In an April 2026 survey, the Cloud Security Alliance reported that 53% of the organizations surveyed had seen AI agents exceed their intended permissions.

The percentage points to a control problem worth taking seriously. But “intended” raises a prior question: intended by whom, under what authority, and with what process for revisiting that decision as the agent’s work changes?

Source: Cloud Security Alliance, Enterprise AI Security Starts with AI Agents (April 2026). Commissioned by Zenity; 445 IT and security professionals; self-reported responses.

When is a mandate review warranted?

Consider a review before the first approval is treated as settled when an AI agent is expected to exercise meaningful authority, particularly when it can:

• take actions with external, financial, operational, or customer consequences;
• act across systems or on behalf of people or teams;
• continue operating after the original task, context, or accountable owner changes;
• gain additional permissions or move from recommendation to execution; or
• rely on a delegation whose grantor, scope, or renewal conditions are unclear.

It is not needed for low-consequence, easily reversed uses where the grant is narrow and plainly within the grantor’s remit.

The review is not a substitute for security engineering, legal advice, risk management, or ongoing governance. It examines a different layer: whether the authority being operationalized has a defensible mandate.