Least Privilege for AI Agents: A Practical Guide

Least privilege for AI agents means giving each agent only the tools, data, and actions it needs to do its job, and denying everything else. It is the single highest-leverage control in agent security, because it caps the damage of every other failure. Even if an agent is prompt-injected, buggy, or hallucinating, least privilege ensures it can only reach what you explicitly granted.

The problem: excessive agency

The OWASP Top 10 for LLM Applications names excessive agency as a top risk. It happens when an agent has more capability, permissions, or autonomy than its task requires. A support agent with database export rights, a research agent that can send email anywhere, a coding agent with production deploy access: each is an oversized blast radius waiting for a trigger.

Why it is the best return on effort

Prompt-injection detection is an arms race; least privilege is a wall. You do not have to predict every attack to benefit from it. If the agent cannot call a tool, no injection can make it call that tool. Scoping permissions tightly turns a potential breach into a denied action and a log line.

How to apply least privilege to an agent

1. Enumerate the agent's real job. List the specific tools and data it genuinely needs. Be strict; most agents need far less than they are given.
2. Allowlist tools, not deny-list. Grant the named tools the agent may call and deny the rest by default. A deny-list always misses something.
3. Scope to the resource. Go beyond the tool to the resource: this agent may read these tables, send to these recipients, write to this bucket, nothing more.
4. Separate read and write. Many agents only need to read. Granting write or delete should be a deliberate, justified decision.
5. Gate the dangerous remainder. For the few high-risk actions an agent legitimately needs, require human approval rather than free rein.

Enforce it where it cannot be bypassed

Least privilege only works if it is enforced at the action boundary, not in the agent's own code, which an injection can influence. Agentshield enforces tool and data permissions in the request path, so the agent physically cannot escalate its own access. Every denied attempt is recorded in the audit trail.

What does least privilege look like in practice?

The abstract principle is easy to agree with and hard to apply, because nobody tells you where to draw the line. This table is the version we hand teams: take each agent, and write down the four columns before it ships.

Two patterns repeat. First, the read and write split does most of the work: the majority of agents deliver their value on read access alone, and every write is where the risk lives. Second, the resource column matters more than the tool column. An agent granted a CRM read tool with no resource scope can read the whole CRM, which is a very different exposure from reading the one account it was asked about.

Why do AI agents end up with too many permissions?

Agents accumulate privilege because it is the path of least resistance during development. Broad access makes the demo work, permissions are inherited from a human service account that already existed, nobody wants to be the reason the agent fails mid-task, and the scope is never revisited once the feature ships. Over-permissioning is almost always an artifact of speed, not a decision anyone made deliberately.

The other driver is that agents are usually built by application teams and permissions are usually owned by platform or security teams, so scoping falls in the gap. The practical fix is to make the permission set a required artifact of shipping the agent, in the same way a service needs an owner and an on-call rotation, and to enforce it somewhere the app team does not have to remember.

What is the difference between least privilege and zero trust for AI agents?

Least privilege limits how much authority an agent holds. Zero trust removes the assumption that holding a credential is sufficient, so every request is verified in context rather than trusted because it came from inside the network. They are complementary: least privilege shrinks what a compromised agent can reach, and zero trust makes sure each individual call is still checked. The full architecture, and how the NIST SP 800-207 tenets translate to non-human actors, is laid out in zero trust for AI agents.

For agents, the zero trust part matters more than it does for ordinary services, because an agent request is generated by a model that may have been influenced by attacker-controlled text. The request looks legitimate and comes from a legitimate identity. Only a per-call policy check catches it. This is also why AI agent access control has to run at the action boundary rather than inside the agent.

How do you apply least privilege when agents delegate to each other?

Scope each agent independently, then enforce that a delegated task carries the intersection of what the requesting agent held and what the task needs, never the union. Without that rule, a low-privilege agent can ask a high-privilege peer to run the call it could not make itself, which is the confused deputy problem and a common route to agent privilege escalation.

This gets harder fast as fleets grow, because the number of delegation edges grows faster than the number of agents, and securing agent-to-agent communication becomes its own problem. Per-agent policy alone stops being sufficient somewhere around the third or fourth agent in a chain, and you need policy on the handoffs themselves. We cover that architecture in multi-agent system security.

AI agent least privilege access: what a real scope looks like

Least privilege stops being an abstraction the moment you write the scope down. The exercise that works is to take one agent and fill in four columns: what it may read, what it may write, which tools it may call, and which actions require a human. Most teams discover during this exercise that they cannot answer column three without reading the code, which is itself the finding.

These are realistic starting scopes for the four agent types we see most often. Treat them as a first draft to argue with, not a template to copy.

Two patterns show up every time. The read column is where over-permissioning hides, because read access feels harmless and is how data leaves. And the human-gated column is almost always the same short list regardless of agent: money, deletion, outbound communication, and permission changes. If you only get one column right, make it that one.

Worth noting that some runtimes now ship a usable default here. Claude Code, for example, starts read-only and confines writes to its launch directory, which is genuine least privilege out of the box, though it is configured per repository rather than centrally. The controls and their limits are covered on Claude agent security.

The payoff

With least privilege in place, your worst case shrinks dramatically. A hijacked agent is limited to the narrow scope you allowed, the attempt to go further is denied and logged, and a human is still required for the few genuinely risky actions. It is the foundation every other agent control builds on.

Read next: AI agent governance, or get started.