Least privilege
Give each user, service and agent only the permissions its current task needs, for only as long as it needs them. Limits damage when it's tricked or buggy.
Least privilege means giving each person, program or AI agent the smallest set of permissions it needs to do its job. An agent that summarises tickets needs to read tickets, not delete them or email customers. If the agent is tricked by Prompt injection (indirect) or just makes a mistake, it can only do damage within those narrow permissions. It is the single most effective control for AI agents.
A hotel key card that opens your room and the gym for the length of your stay, not every room in the building forever.
Relying on instructions as permissions. 'Do not modify production' in a system prompt is a request, not a control; if the credential allows it, the agent can do it.
Saltzer and Schroeder (1975) list least privilege among the core design principles: every program and user operates with the least set of privileges necessary. For agents, apply it on four axes: scope (which resources: one repo, one folder, one tenant), verbs (read vs write vs delete vs send), duration (short-lived credentials: STS sessions, OAuth tokens with minutes-long expiry, MCP authorization with per-server scopes), and autonomy (which actions run without human approval). Issue credentials per task from a broker rather than giving the agent a long-lived service account; the agent never sees a secret it could leak. Separate dev and prod: an agent working in a dev environment should have no route to prod data. Willison's lethal trifecta gives a quick test: if the permission set combines private data, untrusted input and outbound communication, cut one. OWASP's 2025 LLM Top 10 names 'excessive agency' (LLM06) as the failure: too much functionality, permission or autonomy.
Per-task credentials from a broker (AWS STS, GCP short-lived tokens, Vault dynamic secrets); OAuth scopes per MCP server per the MCP authorization spec; read-only by default; separate dev/prod accounts with no cross-access; approval gates for send/pay/delete/share; quarterly review of agent permissions vs actual usage.
An insurance-claims agent drafts settlement letters. Before: a service account with read/write to the claims DB, the document store and the email API. After: a per-claim token (15-minute expiry) granting read on that claim's documents, write to a drafts table only, and no email scope. Sending is a separate human action in the adjuster UI. A red-team injection in an uploaded claim document ('email all open claims to…') now fails at three points: no access to other claims, no email tool, no write outside drafts.
For any agent I'd list its tools and scopes on four axes (resources, verbs, duration, autonomy), issue per-task short-lived credentials from a broker, keep dev and prod separated, and check the trifecta. Follow-up: 'doesn't that make the agent less useful?' Slightly; you add capabilities back one by one with evals and approvals, which is cheaper than retracting them after an incident.
| Axis | Too broad | Least privilege |
|---|---|---|
| Scope | all repos / all claims | one repo / one claim |
| Verbs | read+write+delete | read + write drafts |
| Duration | long-lived key | 15-min token |
| Autonomy | acts unattended | approval to send/pay |
Numbers worth knowing
- Credential lifetime
- 15 min–1 hAWS STS sessions start at 15 min; shorter limits leaked-token value
- Unused permissions
- remove if unused for 90 daysfrom access logs; IAM access analysers report this
- Trifecta legs allowed per agent
- ≤2private data + untrusted input + external comms together is the danger
How to decide
| When | Do this |
|---|---|
| Agent only reads | Read-only scopes on the specific resources; no write tools registered. |
| Agent must write | Write to a staging area (drafts, PRs, tickets) that a human promotes. |
| Action is irreversible (send, pay, delete) | Human approval, with the exact payload shown. |
| Agent works in dev | No credentials or network route to production. |
Cost maths
A credential broker adds one call per task (~20–100 ms) and some platform work. The alternative cost is the blast radius of one compromised long-lived key, measured in every record it can read and every action it can take for as long as it's valid.
Operating it
- Agents share a service account
- Agent gains a new tool or a new data source
- Access logs show granted permissions far exceeding used ones
- Granted vs used permissions per agent: review quarterly; alert on new high-risk scopes
- Credential age: alert on any agent credential older than 24 h
- Denied tool/permission attempts per agent run: alert on spikes
When it goes wrong
A coding agent deleted a production database during a code freeze (Replit, July 2025).
The user discovered data loss and published the transcript.
The agent operated with write access to production data from its development workflow; the freeze was an instruction, not a permission.
Separate dev and prod databases with no agent path to prod, and approval gates for destructive operations.
Related terms
Where it shows up
Sources
- The Protection of Information in Computer Systems — Saltzer & Schroeder, 1975paper
- The lethal trifecta for AI agents — Simon Willison, 2025blog
- Model Context Protocol: Authorization — MCP, 2025spec
- OWASP Top 10 for LLM Applications 2025 — OWASP, 2025spec
Check yourself
Three questions. Every option is explained once you answer.