Least privilege for AI coding agents: a permissions checklist

Give a coding agent the smallest set of access that lets it finish the task: one repository, a branch it cannot merge, no production credentials, limited network egress, and approval for risky commands. Assume it can be misled and design so a misled agent can only do small harm.

Start from the assumption

OWASP's guidance on prompt injection tells builders to enforce least privilege and to treat the model as an untrusted user. An agent reads untrusted text all day, so that is the sensible default for a coding agent too.

The checklist

Files

• Limit to the project directory. No access to your home directory, SSH keys or cloud credential files.
• Mark sensitive paths such as environment files as off limits.

Shell

• Allow a short list of commands, such as the test runner and linter.
• Require approval for installs, deletes, network tools and anything with sudo.
• Prefer a container over your own shell.

Network

• Deny by default; allow the package registry and the host you actually need.
• Block outbound calls to unknown hosts so a hijacked agent cannot send files out.

Credentials

• Use short lived, narrowly scoped tokens, one per agent, so actions are attributable.
• Never give an agent deployment or production database credentials.
• Keep secrets out of the agent's context. Do not paste them into prompts.

Git

• Let it push to a feature branch only.
• Protect the main branch and require human review before merge.
• Keep the agent from changing CI workflow files or branch protection settings without review.

Tools and MCP servers

• Install only servers you have reviewed. Each tool is a capability the agent can be talked into using.
• Prefer read only tools when the task is read only.

Review the permissions like code

Write the allowed commands and paths into a config file that lives in version control, and review changes to it. A quiet widening of permissions is as important as a code change.

Why separate identities matter

If every agent shares one token, a log line tells you nothing about which agent acted. A distinct identity per agent supports revocation and audit. Safeguard's agent identity capability and MCP Guardrail address this, alongside policies and gates for enforcement.

Starting point for a small team

If this list feels long, begin with three items: run the agent in a container, give it a token that can only push to feature branches, and require approval for installs and deletes. Those three cover the most damaging cases. Add network restrictions and per agent identities as you go, and write each decision down so new teammates inherit it.

Quick check

Sources

• OWASP LLM01: Prompt Injection

Last reviewed: 19 October 2026.