What is authority governance?

Authority governance is the practice of defining what an AI agent is allowed to decide on behalf of an organization, enforcing that definition at the moment the agent acts, and keeping a record that ties every decision back to the human who granted the authority.

It is a different discipline from access management. Access answers whether an identity may reach a system. Authority answers whether the decision that identity is about to make was ever delegated to it, within what limits, and on whose accountability.

The definition we work from

We define authority as three things together. Decision rights: what an agent is delegated to decide, by whom, and in what scope. Constraints: the limits, conditions, and thresholds that bound each decision. Accountability: an attributable, reviewable record of every decision made under that delegation.

Take away any one of the three and you do not have authority. Decision rights without constraints is a blank check. Constraints without accountability is a rule nobody answers for. Accountability without decision rights is a log of things that were never authorized in the first place.

Why access controls do not cover this

Consider an agent that handles customer refunds. Its credential carries a refund scope on the payments API. Every access control in the stack is satisfied: the agent authenticated, the token is valid, the scope permits refunds.

What the business actually intended was narrower. Refunds up to a per-case ceiling. A daily total the agent may not exceed. No refunds on accounts flagged for fraud review. Anything outside those bounds goes to a named person before it executes. None of that lives in the scope. A scope is binary. The agent either has refund permission or it does not.

So the agent issues a refund just under the per-transaction check, then another, then another. By the end of the run it has moved a sum no single employee could have approved alone. Every individual call was permitted. The gap between what the credential allowed and what the organization meant to allow is the authority gap, and it is invisible to any control whose unit of analysis is the identity rather than the decision.

What authority governance requires

Our position is that closing the gap takes four things, and that they have to work together.

First, decision rights have to come from policies that humans own. Not an owner label on the agent, but a person attached to a written policy that says which class of decisions may be made under it and on what terms. Ten agents or ten thousand can operate under one refund policy, and the person who owns that policy is accountable for all of them.

Second, constraints have to carry state across a run. A per-action check is necessary and not sufficient. The daily total and the cumulative exposure have to be tracked as ledgered ceilings, so the tenth refund is evaluated against the nine before it.

Third, escalation has to be defined before execution and go to an accountable human, not to a queue. When the agent reaches the edge of its authority, the system already knows whose decision it is.

Fourth, every decision needs a record of its own: what was decided, under which policy, against which ceiling, with what outcome. Not a log line saying an API was called.

Where enforcement has to sit

If authority is checked only for agents that have been registered, then registration has become the perimeter, and the perimeter has holes in it by definition. Agents spawn other agents. They are created and destroyed inside a single workflow.

The check therefore has to sit in the action path: at the tool call, the API tier, a gateway in front of the system of record, or a sidecar beside the workload. An action from an agent nobody registered is evaluated because of where the check sits, not because anyone knew the agent existed.

Where BotAris fits

BotAris is the authority governance control plane for AI agents. Humans define authority in the Authority Model. The Decision Authority Enforcement Point evaluates every consequential action against it at runtime, resolving to allow, constrain, escalate to a human, or deny. The Accountability Ledger records each decision as evidence. It sits above identity and access and works with the IAM investments you already have.