Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Least Privilege

Pattern

A reusable solution you can apply to your work.

“Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” — Jerome Saltzer and Michael Schroeder

Also known as: Principle of Minimal Authority, PoLA

Context

This is a tactical pattern. Once you have authentication and authorization in place, the question becomes: how much permission should each actor get? Least privilege says the answer is always “as little as possible.”

In agentic coding, this pattern matters a lot. AI agents often request broad access (shell access, file system access, API tokens) because it’s convenient. But an agent with more power than it needs is a liability. If the agent is compromised through prompt injection or a bug, every excess permission becomes a weapon.

Problem

Granting broad permissions is easy. It avoids the friction of figuring out exactly what’s needed, and it prevents the annoying “permission denied” errors that interrupt work. But every excess permission is dormant risk. If a component is compromised, its permissions become the attacker’s permissions. How do you grant enough access for legitimate work without creating unnecessary exposure?

Forces

  • Generous permissions reduce friction during development but increase risk in production.
  • Determining the minimum required permissions takes analysis and testing.
  • Permissions that are too restrictive break functionality and frustrate users.
  • Requirements change over time, and permissions must evolve with them. But permissions granted are rarely revoked.

Solution

Grant each component, user, service, or agent only the permissions it needs to perform its current task, and no more. This applies at every level:

  • User accounts: Don’t use admin accounts for daily work. Create separate accounts or roles for administrative tasks.
  • Service accounts: A service that only reads from a database shouldn’t have write permissions.
  • API tokens: Scope tokens to specific actions and resources. A token for reading repository data shouldn’t grant delete access.
  • AI agents: Give the agent access to the tools and files it needs for the current task. Don’t grant persistent, broad access “just in case.”
  • Processes: Run applications with the minimum OS-level permissions needed. Don’t run web servers as root.

When in doubt, start with no permissions and add them as needed, rather than starting with full access and trying to remove excess later. The first approach converges on the minimum; the second rarely does.

How It Plays Out

A cloud-deployed application uses a database service account with full admin privileges because it was easier to set up during development. One day, a SQL injection vulnerability in a search feature lets an attacker execute arbitrary queries. Because the service account is an admin, the attacker can not only read data but drop tables and create new users. If the account had been limited to SELECT on specific tables, the injection would still be a serious bug, but the damage would be contained.

A developer configures an AI agent for a code review task. Instead of giving the agent a personal access token with full repository access, they create a fine-grained token that can read code and comment on pull requests but can’t push commits, merge branches, or access other repositories. The agent works perfectly within these constraints. If the agent were compromised, the attacker could leave comments but couldn’t alter code. A nuisance, not a catastrophe.

Tip

When setting up AI agents with tool access, start with the minimum and add permissions only when the agent actually needs them. If the agent says it needs broader access, evaluate whether the task genuinely requires it or whether there’s a narrower path.

Example Prompt

“Create a fine-grained GitHub token for this agent. It needs read access to code and write access to pull request comments. No push access, no branch deletion, no access to other repositories.”

Consequences

Least privilege reduces the blast radius of any security failure. A compromised component with minimal permissions can do minimal damage. It also makes systems easier to audit: when permissions are explicit and minimal, it’s clear what each component can and can’t do.

The costs are real. Configuring fine-grained permissions takes more time than granting broad access. Developers hit permission errors that slow their work. Permission models need maintenance as the system evolves. But these costs are investments in resilience. They pay off the moment something goes wrong, which in any long-lived system, it eventually will.

  • Depends on: Authorization. Least privilege is implemented through the authorization system.
  • Depends on: Authentication. You must know who an actor is to limit their permissions.
  • Enables: Blast Radius. Minimal permissions limit how far damage spreads.
  • Enables: Sandbox. Sandboxing is an enforcement mechanism for least privilege.
  • Uses: Secret. Credentials should be scoped to minimum required access.
  • Enables: Prompt Injection. Reducing agent permissions reduces injection impact.
  • Related: Tool Poisoning – restricting tool access shrinks the exfiltration surface.