What is AI agent authorization?

AI agent authorization is the decision, made at the time an agent attempts an action, about whether that action may proceed. In conventional systems, authorization means checking a request against roles, scopes, or policies attached to the caller's identity. For agents, that check is necessary but does not answer the question that matters: was this particular decision, in this context, with this cumulative history, one the organization delegated to this agent?

Two kinds of authorization

It helps to separate them.

Access authorization asks whether the identity may reach the resource. Can this token call the refund endpoint? Can this service account read the customer table? The answer is a property of the grant and does not change from one request to the next.

Decision authorization asks whether this action, with its specific parameters and in light of everything the agent has already done, falls inside the authority a human delegated. Is a refund of this amount, on this account, as the eleventh refund today, within the refund policy the support director owns? The answer depends on the action, the context, and the running state, not just the identity.

The existing stack does the first well. It was never built to do the second, and no amount of refining scopes gets there, because a scope has no field for a daily total or a fraud flag.

Why roles and scopes fall short for agents

Roles and scopes were designed for callers whose behavior was known in advance. A human in the accounts payable role does a predictable set of things, and the role is sized to it. An agent is a chooser. It is given a goal and selects actions to reach it. The scope describes the ceiling of what is technically possible, not the boundary of what was intended.

Three specific gaps follow. Scopes are binary, so they cannot express thresholds. Scopes are stateless, so they cannot express cumulative limits. Scopes attach to the identity, so they say nothing about the delegation chain that put this agent in motion.

What a decision-level check evaluates

Our position is that an authorization check fit for agents evaluates each consequential action against four things.

The decision rights delegated to the agent: which class of decision this is, and whether the agent holds a mandate for it.

The constraints on those rights: per-action thresholds, and cumulative ceilings carried across the run.

The delegation chain: who granted the authority, through which intermediate agents, and whether it narrowed or widened on the way.

The escalation rule: what happens at the boundary, and which accountable human the decision belongs to.

The outcome is one of four. Allow: inside authority, proceed and record. Constrain: proceed with limits applied, such as a reduced amount or narrower scope, and record the constraint. Escalate to a human: route to the named person with context attached, and record their answer. Deny: outside authority, do not proceed, record the reason.

Where the check runs

Authorization for agents has to happen in the action path, before execution. That can be an in-process API call the agent's framework makes before acting, an inline gateway that terminates the agent's outbound traffic, a required check at the API tier, a sidecar beside the workload, or a tool broker in front of every tool call. The pattern varies. The requirement that the check sits between the decision and its effect does not.

Where BotAris fits

BotAris performs decision authorization for AI agents. The Decision Authority Enforcement Point evaluates each proposed action against the Authority Model, in the agent's action path, and resolves it to allow, constrain, escalate, or deny. It works alongside the access authorization your identity provider and API gateways already perform.