AI agent permissions. Least privilege for something that decides.
An agent does not use the permissions its task needs. It uses the permissions it has, chosen at runtime from whatever its context suggests. That one difference is what makes scoping an agent a different job from scoping a pipeline.
- An agent uses every permission it holds, not the subset its task needs, because it picks its next call at runtime.
- Scoping the role is not enough. An agent can usually read whatever else sits in its job, so a broad token in the same environment undoes a narrow role.
- You cannot prevent prompt injection. You can limit what obeying it achieves by keeping destructive permissions off the identity that reads untrusted input.
- Start from ninety days of calls the identity actually made. That set, plus the cases you can name, is the honest scope.
Published Last reviewed
Permissions describe intent. Agents reveal what you granted.
Agent permissions are the actions an agent may take and the data it may read, expressed through the identity it runs as. On paper this is the same problem as permissions for any workload. In practice it differs in one way that matters: a workload uses the permissions its code calls for, and an agent uses the permissions it has.
That turns every unused permission into a live one and makes the gap between granted and needed the thing to measure. The four properties below are why.
A script uses what it was written to use. An agent uses what it was given.
Why agents are different. Four properties.
None of these is a flaw in the agent. All four are consequences of letting software decide its own next call.
A deploy pipeline runs the same three calls every time. An agent decides what to call based on what it reads, so the set of permissions it uses is the set it has, not the set the task needs. Permissions you granted for a rare case become part of normal operation.
A script does what it was written to do. An agent does what its context tells it to do, and that context can include a repository, a ticket, a web page or an email. Prompt injection is not a new permission, it is someone else choosing which of the existing ones to use.
An agent holds its own credentials and can usually read whatever else is in its shell, container or CI job. A grant you made to the job is a grant you made to the agent, which is how a coding agent ends up with a deploy token nobody handed it.
A human with too much access is slowed by having to decide. An agent walks several steps in seconds, so the gap between having a permission and using it in production closes before anyone sees it.
Four ways to scope an agent.
Each one holds up somewhere and fails somewhere. The failure column is the part worth reading first.
| Model | How it works | Holds up when | Breaks when |
|---|---|---|---|
| Static role | The agent runs as one identity with a fixed role. | The agent does one narrow job and nothing reads its secrets. | The job grows, or another workload shares the identity. |
| Scoped per task | A separate identity per task, each with only that task’s permissions. | Tasks are distinct and few, for example read and deploy. | Tasks multiply faster than anyone maintains the mapping. |
| Short-lived credentials | The platform issues a credential valid for minutes. | The platform supports it end to end. | One system in the chain only accepts a static key. |
| Approval on the step that matters | Broad read, explicit approval for writes and production. | The risky actions are a small, nameable set. | Everything is marked risky, so approval becomes a reflex. |
How to scope one. Four steps.
In this order, because step three usually undoes the work of step one if you skip it.
Take ninety days of real calls for the identity the agent runs as. That set, plus the cases you can name, is the honest starting scope.
Most agent work is reading. Split the identity so reading never carries the credential that can write to production.
A scoped permission is undone by a broad secret sitting in the same environment. Look at the whole job, not only the agent.
Name the actions that are hard to undo, require a human decision on those, and leave the rest alone so the approval keeps meaning something.
What it looks like in Elmoz
The same agent before and after the change, drawn the way the Elmoz security graph shows it.
Questions, answered.
Short answers on scoping what an AI agent may do.
What does least privilege mean for an AI agent?
The same thing as anywhere else, applied to a wider surface. An agent needs the permissions its task requires, and it also needs to be unable to reach credentials, roles and grants that belong to other tasks. Scoping the role and leaving a broad token readable in the same job is not least privilege.
Should every agent have its own identity?
Where you can, yes, and the reason is as much operational as it is security. A shared identity cannot be rotated without breaking the other consumers, and its log lines cannot be attributed to any single agent, so you lose both the fix and the evidence.
How do I stop prompt injection from using an agent’s permissions?
You cannot prevent the instruction, so you limit what obeying it achieves. Keep the destructive and data-reaching permissions off the identity that processes untrusted input, and require a human decision on the actions that are hard to undo.
Keep reading.
The pages that belong to the same picture.
Coding agentsWhat Cursor, Claude Code and Codex can reach.See the use case →See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.