What does least privilege mean for an AI agent?

Least privilege is the principle that any identity should hold only the access it needs to do its job, and no more. It is one of the oldest ideas in security and it applies to AI agents. It also has to be extended, because for an agent the job is not a fixed set of operations, and "the access it needs" turns out to be the wrong unit.

Why the classic form is not enough

For a human or a service account, least privilege is expressed as a set of entitlements sized to a known task. The clerk gets the invoice system and not the payroll system. The backup job gets read access to the database and write access to the archive bucket.

An agent is given a goal and chooses the actions to reach it. A refund agent needs the refund endpoint. That is its minimum access, and it is also enough to move an unbounded amount of money one permitted call at a time. The classic form of least privilege is satisfied and the risk is untouched.

The problem is that entitlements describe which operations are possible. For a chooser, the risk lives in how often, how much, on what, and in what sequence. None of those are entitlements.

Least authority, not just least access

Our position is that least privilege for agents has to be stated as least authority: the narrowest set of decision rights, bounded by the tightest constraints that still let the task complete, with everything outside that envelope going to a person.

That gives least privilege four dimensions instead of one.

Which decisions. The agent may decide refunds. It may not decide account closures, even if the API that does both is the same one.

Within what per-action limits. Refunds up to a per-case ceiling.

Within what cumulative limits. A daily total across every refund the agent issues, tracked as a ledgered ceiling so the fortieth refund is judged against the thirty-nine before it.

Under what conditions and with what escalation. Not on flagged accounts. Above the ceiling, the case goes to a named person before it executes.

The first dimension can partly be handled by access scopes. The other three cannot, because permission systems are stateless and binary. They need an authority layer with runtime evaluation and cumulative state.

The delegation problem

Least privilege for agents has a second complication. Agents spawn agents. If a spawned agent inherits the full authority of its parent, then nothing narrows as work moves further from the human who started it, and the tenth agent in a chain doing a small subtask holds everything the first one held.

Least authority requires attenuation: each delegation may narrow authority and may never widen it. The subtask agent gets the slice of its parent's authority the subtask needs. This is possible in principle in most systems. It is not what happens by default, and it is not what inherited-permission models deliver.

Getting there in practice

Start with the access layer and size scopes as tightly as the platform allows. Then write the authority for each class of decision as policy a human owns: decision rights, per-action constraints, cumulative ceilings, conditions, escalation. Run the enforcement point in event-only mode first to see where agents already exceed the intended envelope. Then enforce.

The order matters. Organizations that try to get least privilege from scopes alone end up with either scopes so tight the agent cannot work, or scopes wide enough to work and no control over what happens inside them.

Where BotAris fits

BotAris enforces least authority. Constraints in the Authority Model include per-action thresholds and cumulative ceilings, the enforcement point evaluates each action against them and against the delegation chain, and outcomes include constrain, which lets an action proceed with limits applied rather than forcing a choice between allow and deny.