AI agent permissions: what they cover and what they miss

AI agent permissions are the entitlements attached to an agent's identity: the API scopes on its tokens, the roles assigned to its service account, the resources it has been granted access to. They define the ceiling of what the agent is technically able to do.

They are necessary. An agent with no permissions can do nothing. But permission is not authority, and treating the two as the same is the most common mistake we see in agent deployments.

Permission is binary; intent is not

A permission either exists or it does not. The agent can call the refund endpoint or it cannot. The business intent behind granting that permission is almost never binary. It is a set of conditions: up to this amount, this many times, not on these accounts, and above this line a person decides.

Permission systems are written in terms of what is allowed. The intent of the business lives almost entirely on the other side: the ceiling it may not exceed, the accounts it may not touch, the decisions that always go to a person no matter what the agent concludes. The permission carries none of it.

Three ways permissions are assigned to agents, and what each misses

Direct grants. The agent gets its own service account with scopes sized to its task. This is the cleanest approach and still leaves the gap above: scopes cannot carry thresholds, cumulative limits, or conditions.

Inherited permissions. The agent acts as a user and inherits that person's entitlements, and every agent it spawns inherits the same. This sounds like a control and produces the opposite. It hands the agent the human's full accumulated reach, not the human's intent. Over-provisioned human access is the normal state of the enterprise, and the inheritance model hands that pile to software that will use whatever it is given. It also compounds down the chain: the tenth agent in a chain, doing a subtask the human never contemplated, holds exactly what the human holds. And when something goes wrong, the record says the human did it.

Shared credentials. Multiple agents use one credential. This makes attribution impossible and is a problem before any question of authority comes up.

What has to sit above permissions

Our position is that agent permissions should be sized as tightly as the access layer allows, and that a separate authority layer should then govern what the agent may decide within them. The authority layer holds what the permission cannot: decision rights delegated by a named human, constraints including cumulative ceilings, an escalation path, and a per-decision record.

The two layers answer different questions and both have to be satisfied. The access layer confirms the agent may call the endpoint. The authority layer confirms this call, with these parameters, at this point in the run, is one the organization delegated.

A worked example

An agent that manages cloud infrastructure has permission to resize compute instances. The intent: it may scale within a cost envelope per day, it may not touch instances tagged as production databases, and any change that would exceed the envelope goes to the platform lead.

The permission is one IAM policy statement. The intent is a decision right (resize compute), two constraints (a daily cost ceiling, a tag exclusion), and an escalation rule. The permission alone lets the agent resize the production database fleet at 3 a.m. because a metric spiked. The authority layer stops it, or routes it to the platform lead, and records why.

Where BotAris fits

BotAris does not manage agent permissions. Your identity provider, PAM, and cloud IAM do that. BotAris governs the decisions agents make within those permissions: the Authority Model holds the decision rights and constraints, the enforcement point checks each action against them at runtime, and the ledger records the outcome.