What Is Least Privilege for AI Agents?

Quick answer
Least privilege for an agent means one task, one scope, one short-lived credential — not the developer’s personal token.
Agents are non-human identities: they should have their own credentials, their own audit trail, and a defined owner.
Start from the tools the task needs, not from the tools the server offers.
Prefer read-only, scoped, and time-limited credentials, and revoke them when the task ends.
The test is blast radius: if this agent went wrong now, what is the worst it could do?

Why is least privilege different for agents?

A human with broad access applies judgement about when to use it. An agent follows instructions, including instructions embedded in content it reads. Broad access plus a manipulable instruction source is the combination that produces incidents.

Agents are also numerous. A person has one identity; a fleet of runs can have hundreds, each with its own token and its own lifetime. Without a per-agent identity, every run borrows a human’s permissions and the audit trail ends at “a developer did this”.

How do you scope an agent’s access?

Work backwards from the task: which repositories, which tables, which API endpoints, which environment. Grant those, and nothing adjacent. A migration agent needs the staging database and the migration tool, not the production cluster and not the billing API.

Then scope in time. A token that expires at the end of the task is safer than one that lives for a year, and a credential issued per run is safer still. If the agent needs standing access, that is a design decision worth documenting.

# What can this credential actually do?
gh auth status
aws sts get-caller-identity
# Prefer a short-lived, scoped token per run over a personal login
export GITHUB_TOKEN="$(gh auth token --hostname github.com)"  # replace with a scoped token
unset GITHUB_TOKEN  # at the end of the run

What does least privilege look like in practice?

A separate identity per agent or per task class, with a name that says what it is for. Read-only where reading is enough. Write access limited to the specific resource, not the organisation. No ability to change permissions, create credentials, or disable logging.

Tool-level scoping matters as much as API scoping. An MCP server that offers a delete tool gives the agent the ability to delete even if the token could not. Expose only the tools the task needs, and treat the rest as unavailable.

How do you know it worked?

Ask what the agent could do if it were fully compromised right now. If the answer includes production data, other users’ records, or the ability to grant itself more access, the scope is too broad. That question is faster than a policy review.

Then check attribution. Every action should be traceable to a specific agent identity and run. If you cannot tell which run made a change, the credential is shared and the audit trail is decorative.

Where this bites vibecoders
The default setup is the developer’s own token in an environment variable, which gives the agent every repository and every permission the developer has. Replace it with a scoped token before the first real run, not after the first incident.

Where AI coding assistants get this wrong

Using a personal access token for agent runs.
Granting organisation-wide write access for a single-repository task.
Keeping a long-lived token because rotation is inconvenient.
Scoping the API token but exposing every MCP tool.
Sharing one identity across many agents so actions cannot be attributed.
Granting permission-management rights so the agent can “fix” access errors.

Checklist

Name the resources the task actually needs.
Create a dedicated identity for the agent.
Use read-only access unless writing is required.
Set an expiry and revoke at the end of the run.
Expose only the tools the task needs.
Confirm every action is attributable to one run.

FAQ

Is a service account enough?

It is better than a personal token, but a shared service account still collapses attribution. Prefer one identity per agent or per run, or at least per task class, so the logs distinguish them. Rotation is also easier when identities are not shared.

How do agents get credentials without storing secrets?

Through the platform: workload identity, short-lived tokens issued to the process, or a secrets manager the agent queries with its own identity. Each removes a long-lived secret from the environment the agent can read.

Does least privilege slow the agent down?

It produces more permission errors, which is the point: they reveal what the task actually needed. The alternative is an agent that succeeds at things you did not intend, which is harder to notice and much harder to undo.

What about production read access?

Read-only production access is often reasonable for diagnosis and dangerous for generation. Decide per task class, and prefer a replica or a redacted view. Read access to personal data is still sensitive even when nothing is modified.