Least privilege for AI agents

TL;DR:

• Least privilege means an agent holds only the permissions its current task needs, for the shortest time.
• Use scoped, short-lived tokens and explicit tool allow-lists instead of one broad credential.
• Default to read-only and gate destructive actions behind explicit approval.
• The goal is blast-radius reduction: when an agent is manipulated, the damage stays tiny.

What is least privilege for an AI agent?

Least privilege for an AI agent is granting it the minimum permissions required to complete its task, and nothing more. A traditional script runs a fixed path, but an autonomous agent decides its own actions and can be steered by the data it reads, which makes broad permissions far more dangerous. The unit of control is the token, the tool allow-list, and the action approval gate. If an agent only needs to read a calendar, it should hold a read-only calendar token and no write access, no file-system access, and no shell. Anything beyond the task is a standing liability waiting to be abused.

This article sits in the DevSecOps guides for AI workloads hub and complements the emergency secret remediation guide: least privilege limits the damage of a leak, and fast rotation cleans it up.

Why do AI agents make over-permissioning so dangerous?

Agents combine autonomy with susceptibility to prompt injection, so a broad token becomes a remote-control panel for an attacker. When an agent reads untrusted content, a hostile instruction hidden in that content can redirect its behaviour. If the agent holds wide permissions, the attacker inherits all of them the instant the agent is manipulated. This is why excessive agency and over-reliance feature prominently in the OWASP LLM Top 10 and the broader OWASP GenAI security project. The defensive answer is structural, not behavioural: you cannot rely on the model refusing a malicious instruction, so you make sure the credential cannot do much harm even if it complies.

How do I scope tokens for an autonomous agent?

Issue one narrow, short-lived token per capability, never a single broad credential. Splitting credentials means abuse of one does not cascade into the others. The table contrasts the broad-token anti-pattern with the scoped approach.

Dimension	Over-permissioned (anti-pattern)	Least privilege (target)
Token scope	One key with full account access	One scoped key per capability
Lifetime	Long-lived or non-expiring	Short-lived, auto-rotating
Default action	Read and write everywhere	Read-only by default
Destructive actions	Allowed silently	Require explicit approval
Tool access	All tools available	Explicit allow-list only

What permission boundaries should every agent have?

Set hard boundaries that hold even when the model is fully compromised. These boundaries are the load-bearing controls.

1. Scope each token to a single capability. A token for reading email should not also send email or touch storage.
2. Set short token lifetimes and auto-rotation. A credential that expires in minutes is worthless to an attacker who exfiltrates it hours later.
3. Default to read-only. Grant write or delete only for the specific task that needs it, and revoke it after.
4. Gate destructive and high-value actions behind human approval. Spending money, deleting data, and changing access should require an explicit confirm.
5. Use an explicit tool allow-list. Deny every tool by default and enable only the ones the task requires, so an injected instruction cannot reach an unlisted capability.
6. Isolate the execution environment. Run the agent in a sandbox with no ambient credentials, so it cannot harvest secrets from the host.

How do I measure the blast radius of an agent?

Blast radius is the full set of systems and data an agent could reach if it were fully hijacked right now. Enumerate every token it holds, every tool on its allow-list, and every system those reach. The smaller and more read-only that set, the smaller the blast radius. In an illustrative internal exercise on 2026-06-20, mapping a sample agent’s tokens before and after scoping reduced its reachable write surface from several systems to a single read-only endpoint. Treat that figure as a worked example of the method, not a measured benchmark of your own agent: run the same enumeration against your real configuration to get a true number.

Methodology note: we map blast radius by listing each credential, resolving what it authorises at the provider, and marking read versus write. This mirrors the verification habit in the secret remediation guide and aligns with the defence-in-depth posture in NSA and CISA hardening guidance.

Where do I go from here?

Turn these principles into a repeatable audit. Work through the AI agent hardening checklist to confirm each boundary is in place, choose enforcement and scanning tooling from the security tooling directory, and map your agent’s risks against the OWASP LLM Top 10. For the wider control set, return to the DevSecOps guides hub and pick your next hardening pass.