What Is Least Privilege for AI Agents? Scoping Authority

Agents are granted permissions generously during development because restrictive scoping slows the build, and those permissions are never revisited because nothing triggers a review. The result is a population of automations holding standing access that nobody has examined, which is the most consistent finding in any agent security assessment. This explainer covers how to scope them properly. It complements what is an agent registry and what is a confused deputy attack, and reflects FISTA Solutions' approach in AI agents delivery.

Why not mirror the assisting role?

Because the person exercises judgement and the agent does not. A finance analyst holds broad system access and uses a narrow slice of it for any particular task, guided by professional understanding of what is appropriate.

An agent granted the same access has all of it available on every request, and a single crafted input can direct it anywhere within that scope. The role's permissions were sized for a human's judgement, which the agent does not have.

Scoping dimension	Question	Typical failure
Operations	Which actions specifically	Full CRUD by default
Data scope	Which records	Whole table or tenant
Value	Up to what amount	No ceiling
Volume	How many per period	No rate limit
Time	For how long	Permanent
Approval	What needs a human	Nothing

Why separate read from write?

Because the consequences differ completely and most agent work is reading. A read-only agent that is confused produces a wrong answer, which is recoverable. A write-capable agent that is confused changes records, sends messages, or moves money.

Splitting them means the dangerous permission exists only in the narrow component that genuinely needs it, and the large surface that handles retrieval and reasoning holds nothing consequential.

What limits beyond operations?

Value and volume. An agent permitted to issue refunds needs a per-transaction ceiling and a daily aggregate, because any operation permitted without bounds can be repeated until something stops it.

Rate limiting is an authorisation control in this context rather than a capacity one. An agent that may update ten records an hour cannot update ten thousand, whatever it is persuaded to attempt.

Why time-bound access?

Because permissions granted for a purpose outlive the purpose. An agent given write access during a data migration retains it for years, and nothing in any process prompts a review.

Expiry inverts the default: the agent loses access unless someone renews it, and renewal is a moment where the question gets asked. Most elevated grants expire unused, which is itself evidence they were not needed permanently. See what is an access request agent.

How are agent permissions reviewed?

Only if something is built to review them. Access review processes are keyed to employment events that agents never experience, so an agent's permissions are examined the first time during an incident or an audit.

A scheduled review driven by the agent registry, with each entry carrying an owner and a review date, is what closes this. It is not sophisticated and it is almost always absent.

What should you do first?

Take one production agent and list what it can actually do — every operation, on every system, with no limits applied. Compare that to what it needs for its stated purpose. The gap is your exposure, and it is usually wide enough to make the case on its own.

Does narrow scoping make agents less useful?

Sometimes, briefly, and it is usually a design prompt rather than a real constraint. An agent that appears to need broad access frequently needs several specific capabilities that were bundled together for convenience, and separating them produces a clearer system as well as a safer one.

Where genuinely broad access is required, the honest response is an approval gate on the consequential actions rather than an unbounded grant. That preserves usefulness while keeping a human in the path of anything expensive.

How does this interact with development?

Badly, unless planned. Engineers building an agent want permissive access to iterate quickly, and the permissions granted for development frequently become the permissions in production because nobody tightened them before launch.

The workable pattern gives development environments broad access to non-production data, and requires production scoping to be defined explicitly as a launch step. Making it a gate rather than a good intention is what stops development convenience becoming production exposure.

What does good look like?

Agents holding narrowly scoped permissions that map to their stated purpose, elevated access time-bounded and renewed deliberately, read and write separated into distinct components, and a scheduled review that actually removes permissions rather than confirming them.

How FISTA Solutions helps

FISTA Solutions scopes agent authority by task rather than by role, separates read from write into distinct components, bounds value and volume as authorisation controls, time-bounds elevated grants with forced renewal, and drives scheduled permission reviews from the agent registry, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To find out what your agents can actually do, message FISTA on WhatsApp, or read what is an agent registry.