Start from the task, not the role.
Enumerate the calls this task requires. Role-based grants imported from human job descriptions are far broader than any single task needs.
Whose rights
is it using?
Every agent permission question starts with identity. An agent acting as itself is a new privilege; an agent acting as its user is a new interface.
READ THE DEFINITION ↓IDENTITY · SCOPE · EXPIRY
01 / DEFINITION
The short answer first.What are AI agent permissions?
AI agent permissions are the rights an agent holds when it calls tools and reads data: which identity it acts as, which resources that identity may reach, which operations it may perform, and for how long. Permission design sets the ceiling on everything an agent can do, correctly or otherwise.
Permissions and access control are often discussed as one thing and are better separated. Permissions are the design: what rights should exist and who holds them. Access control is the enforcement: how each request is checked. A clean permission model badly enforced is a document, and strong enforcement of an over-broad model is a well-guarded mistake.
02 / THREE IDENTITY MODELS
The decision everything else depends on.| Model | How it works | Use when | Risk |
|---|---|---|---|
| Agent as itself | A dedicated service account with its own rights | Background work with no requesting user | Aggregates privilege; attribution is lost |
| Agent as the user | The requesting user's identity is propagated to every call | Anything triggered by a person | Requires identity propagation through every tool |
| Agent with delegated scope | A short-lived token carrying a subset of the user's rights | Long-running or asynchronous tasks | Token lifetime and scope must both be bounded |
The default should be the second, with the third for work that outlives the session. The first is common because it is easy, and it is how an agent becomes the most privileged actor in an organisation: a service account accumulates the union of every capability any user ever needed, and then a system that follows instructions from documents holds all of it.
Identity propagation has a real engineering cost. Every tool has to accept and honour a caller identity, which for internal services is straightforward and for third-party APIs is frequently impossible. Where it cannot be propagated, the compensating control is a narrow, purpose-specific credential per tool rather than one broad account shared across them.
03 / SCOPING TO THE TASK
Permissions that end when the work does.Bind the grant to the request.
A token issued for this run, this user and this objective, expiring when the run ends rather than on a calendar.
Separate read from write from send.
Three different risk profiles. Combining them into one grant removes the ability to allow the safe part of a task.
Cap the volume.
A limit on records touched per run. Legitimate access to one matter is not legitimate access to the whole corpus.
Volume caps are underrated. Most permission models are binary — an identity may read a collection or it may not — which makes a compromised agent's access identical to a legitimate one's right up to the point where it has read everything. A per-run cap converts a silent bulk read into a visible boundary event, and the cap rarely inconveniences real work because real tasks touch few records.
04 / WHAT GOES WRONG
Three failure patterns worth designing against.Permission creep.
Capabilities added during development to unblock a demo are never removed. Expiring grants by default is the only reliable countermeasure.
The union problem.
Several narrow tools combine into a capability nobody approved. Review the set, not the items — see privilege escalation.
Retrieval as a side door.
An index built without document-level permissions hands the agent everything, whatever its API rights say. See RAG access control.
The third pattern is the one that most often defeats an otherwise careful design. Permissions are enforced at the API and then quietly bypassed by a vector index built from the whole corpus with no per-document access metadata. Retrieval is an access path and has to be permissioned as one. Privilege AI treats permissions and retrieval boundaries as the same problem: what information a model can access, and which actions it can propose.
05 / QUESTIONS
Asked when designing an agent's rights.Should an AI agent have its own account?
+
Only for work with no requesting user, and then with a narrow, purpose-specific grant. For anything a person initiates, propagating that person's identity keeps existing access controls meaningful and preserves attribution in the audit trail.
How do you scope permissions for an agent that explores?
+
Scope the resources rather than the sequence. An agent that may need any of a hundred records within one matter should be permitted that matter and capped on volume, not granted the whole store because its path is unpredictable.
What about agents that call other agents?
+
Delegation must narrow, never widen. A sub-agent inherits at most the caller's scope, with its own shorter lifetime, and the chain is recorded so the original requester remains identifiable. Chains that re-broaden scope are a common escalation path.
How long should an agent credential live?
+
As long as the task, which is usually minutes. Long-lived credentials exist for operational convenience and are the main reason a compromise persists beyond the run that caused it.
Do permissions need to cover retrieval as well as tools?
+
Yes, and it is the most frequently missed half. A retrieval index built without per-document permissions gives an agent access it was never granted through any API. See RAG access control.
Give it
only the task.
Privilege AI designs permission and retrieval boundaries that define what a model can access and which actions it can propose.