Least Privilege for AI Agents: Keys, Sandboxes, Approvals

Least privilege for AI agents means giving an agent only the access it needs for the current task, and nothing it might need someday. In practice: a dedicated API key with narrow scopes, a single working directory instead of your home folder, an outbound network allowlist, a sandbox for local code, and human approval before anything that sends, deletes, pays or publishes.

It matters because you cannot fully control what an agent does. A bug, a malicious dependency or a prompt injection can make it misuse whatever it holds. Least privilege does not stop those things happening. It decides how bad they are when they do. This article is part of our guide on how to vet an AI agent before you install it.

Why agents need tighter limits than people

OWASP's 2025 Top 10 for LLM applications calls the problem Excessive Agency (LLM06) and splits it into three parts: too much functionality, too many permissions, and too much autonomy. Each one is a setting you control.

An MCP server or agent runs with whatever keys and file access you give it, and it decides at run time which tools to call. A human with an admin token is also risky, but a human does not follow instructions hidden in a web page. An agent might. In the GitHub MCP demonstration by Invariant Labs, an agent with a token that covered both public and private repositories was steered by a malicious issue into leaking private data. A token scoped to the one repository being triaged would have left nothing private to leak. Our article on prompt injection in tool-using agents explains the attack.

How agent least privilege differs from traditional access control

Okta's guide to least privilege for AI agents compares the two. A shortened version:

Dimension	Traditional access control	Least privilege for AI agents
Identity	Shared human and service accounts	A unique identity per agent
Scope	Broad, persistent, role-based	Task-specific and short-lived
Credentials	Long-lived, rotated by hand	Short-lived, expire automatically
Granularity	App or database level	Resource or tool level
Timing	Granted at provisioning	Granted at task start, revoked at the end
High-risk actions	Automated by default	Require human approval

The steps below put each row into practice.

1. Give each agent its own identity

Do not run an agent under your own account or share one key between several agents. Okta recommends a unique identity per agent, separate from human users, so every action can be traced to the agent and the person who delegated the task. Keep a simple registry: each agent's owner, purpose, the data it can reach and when it was created. Register an agent before it goes live, not after something goes wrong.

2. Scope API keys and tokens

Never hand an agent your personal, all-purpose key. Create one per agent, per purpose.

GitHub

Use a fine-grained personal access token or a GitHub App instead of a classic token.

• Repository access: "Only select repositories", and pick just the ones the agent works on.
• Permissions: grant read-only where possible. An issue triage agent needs Issues read and write, not Contents write or Administration.
• Expiry: set a short expiration date so a forgotten token stops working on its own. GitHub explains the options in its docs on managing personal access tokens.

Cloud providers

Create a dedicated role or service account. A policy that lets an agent read one S3 prefix and nothing else looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::reports-bucket/agent-input/*"
  }]
}

No s3:*, no "Resource": "*".

Databases

Give the agent its own database user with read-only access to the tables it needs:

CREATE ROLE agent_reader LOGIN PASSWORD '...';
GRANT SELECT ON orders, products TO agent_reader;

Point it at a replica if you can, so a heavy or runaway query cannot slow production.

OAuth-based MCP servers

Remote MCP servers often ask you to sign in with OAuth. Read the consent screen and decline if the scopes are broader than the tools need. The MCP project's security best practices for the 2026-07-28 revision recommend that servers start with a minimal scope set and request more only when a privileged operation is first attempted, and they list wildcard or "full-access" scopes as a common mistake.

Short-lived, task-scoped tokens

Where the provider supports it, issue a token when a task starts and let it expire when the task ends, instead of leaving a standing key in a config file. Okta's guide recommends time-bound credentials that expire automatically, with a way to revoke an active session early. If your provider only offers long-lived keys, set the shortest expiry it allows and rotate on a schedule.

Scope tools inside one MCP server

One server can expose many tools with very different risk. Airia's guide to least privilege for MCP tools gives the example of an agent that only needs to read pull requests: connecting it to a server that also has a merge tool gives it merge access too. Turn off the tools the task does not need, if your client lets you choose tools per server, and scope the token so the dangerous tools would fail even if called.

3. Limit filesystem access

Local agents and MCP servers run as your user, so by default they can read everything you can: SSH keys, cloud credential files, browser profiles, and every project on your disk.

• Pass an explicit directory. Many filesystem tools accept allowed paths as arguments. Give them one project folder, not ~ or /.
• Mount read-only where you can. If the agent only needs to read code, it does not need to write it.
• Keep secrets out of the working directory. Move .env files and credentials outside the folder the agent can see, or add them to the tool's ignore list if it has one.

4. Limit network access

An agent that cannot reach a domain cannot send your data there.

• Default deny. Start with no network and add only the hosts the tool needs.
• Use an egress proxy or firewall rule that allows specific domains, and log everything else it tries.
• Watch for side channels. Rendering a markdown image from an arbitrary URL is an outbound request. So is a DNS lookup.

Before you write an allowlist, find out what the tool actually contacts. Run it once with traffic recorded and compare against its documentation. On AgenticMart, any listing can get a free automated scan; each listing page shows its scan status. Where a listing has been scanned, its scan report shows the outbound traffic seen during a sandboxed run, compared with the domains the manifest declares, with undeclared domains and hard-coded IPs flagged. That gives you a starting allowlist. You should still confirm it in your own environment, since behaviour can depend on configuration.

5. Run local code in a sandbox

A container is the most practical sandbox for most developers. The flags below remove most of what a malicious process would want:

docker run --rm -i \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --user 1000:1000 \
  --read-only --tmpfs /tmp \
  --network none \
  -v "$PWD/project":/work:ro \
  -e GITHUB_TOKEN="$AGENT_SCOPED_TOKEN" \
  my-mcp-server:1.4.2

What each part does:

• --cap-drop=ALL removes Linux capabilities the process does not need.
• --user 1000:1000 runs as a non-root user.
• --read-only and --tmpfs /tmp stop it writing anywhere but a scratch area.
• --network none blocks all network access. Replace with a restricted network when the tool needs to reach an API.
• -v ...:ro exposes one folder, read-only.
• -e passes only the one scoped token, not your whole environment.

This is close to the setup AgenticMart uses for its own scans: the repository runs in a Docker container with all capabilities dropped, as a non-root user, on a fresh virtual machine that is destroyed afterwards. For stronger isolation, use a separate VM or a cloud sandbox for agents that execute arbitrary code. Our article on local vs remote MCP servers discusses where each option fits.

6. Require human approval for risky actions

Some actions are hard or impossible to undo. Make the agent ask first.

Action	Approval?
Read files in the project folder	No
Search the web	No, but treat results as untrusted
Write or edit files in the project	Optional, review the diff
Run shell commands	Yes, or allowlist specific commands
Send email or messages	Yes, show recipient and full text
Push, merge, deploy	Yes
Delete data, change permissions, spend money	Always

Good approval prompts show the exact action and arguments, not the agent's own summary. If the prompt only says "Send report?", you cannot tell that the recipient was changed.

Approval also limits damage from tool poisoning, where hidden instructions in a tool description try to make the agent act on its own.

Watch for approval fatigue. If you approve fifty prompts an hour, you stop reading them. Reduce prompts by narrowing what the agent can do, so the ones left are worth reading.

7. Treat budgets as privilege

Spending and call volume are permissions too. A looping or hijacked agent with an uncapped key can run up a large bill or hammer an API. Set per-key rate limits, model token budgets and spending caps wherever your providers support them. OWASP lists rate limiting and quotas as mitigations for Unbounded Consumption (LLM10), and its Excessive Agency entry notes that rate limiting reduces how many unwanted actions can happen in a given time.

8. Review, re-review on update, and revoke

• Keep a list of every agent, the keys it holds and where they are stored.
• Set expiry dates on tokens and rotate them on a schedule.
• Revoke immediately if a package you use is reported as compromised, as with the Shai-Hulud npm incident.
• Re-review on every update. A new version can add tools, request new scopes or contact new domains. Pin versions, read the changelog and diff, and re-check tool descriptions and network behaviour before you upgrade.
• Remove unused agents and their keys. Idle access is still access.

FAQ

What is the principle of least privilege for AI agents?

It means an AI agent gets only the permissions, data and tools required for its current task. For example, a read-only token for one repository instead of an admin token for your whole organisation. It limits the damage if the agent is buggy, malicious or hijacked by prompt injection.

Should I run MCP servers in Docker?

Running local MCP servers in a container with dropped capabilities, a non-root user and restricted network is a strong default, especially for servers you have not reviewed closely. It keeps them away from your SSH keys, cloud credentials and other projects. See our MCP server install guide for setup details.

How do I give an AI agent access to GitHub safely?

Use a fine-grained personal access token or a GitHub App limited to the specific repositories the agent needs, with the minimum permissions and a short expiry. Avoid classic tokens with the broad repo scope.

Should each AI agent have its own API key?

Yes. A separate key per agent lets you see which agent did what, set scopes for its task alone, and revoke it without breaking anything else. Sharing your personal key, or one key across agents, makes every agent as powerful as the broadest one.

How do I limit what tools an MCP server exposes?

Some clients let you enable or disable individual tools per server. Use that to switch off tools the task does not need, and scope the server's token so that the tools you leave on cannot do more than the task requires.

Which agent actions should need human approval?

Anything that is hard to undo or reaches outside your machine: sending messages, publishing, pushing or deploying code, deleting data, changing permissions and spending money. Reading files in a scoped project folder usually does not need approval.

How often should I review an AI agent's permissions?

On every update, whenever its task changes, and on a fixed schedule such as when its tokens expire. Remove keys and agents you no longer use.