How do you apply least privilege to AI agents?

Apply least privilege to an AI agent by giving it its own identity and only the tools, data and permissions its task needs, with short lived credentials and approval gates on irreversible actions. Assume the agent can be tricked by text it reads, and design so a trick cannot do much.

What does least privilege mean for an agent?

NIST's glossary defines least privilege as restricting access privileges of users, or processes acting on their behalf, to the minimum necessary to accomplish assigned tasks. An agent is such a process. The difference is that its behavior is chosen at runtime by a model reading untrusted input, so the permissions are your only fixed guarantee.

Where do teams go wrong?

The common pattern is convenience. One service account with broad access is shared by every agent. An API key with admin scope is pasted into a tool config. A coding agent gets a personal token with access to every repository. When something goes wrong, nobody can say which agent acted.

A constructed example

A release agent summarizes merged pull requests and posts to chat. Its token also allows pushing to main and deleting branches, because that was the quickest scope to configure. A malicious comment in a pull request tells the agent to delete a branch, and it might comply. Narrowing the token to read access on pull requests and write access to one chat channel makes the instruction harmless.

Checklist

1. One identity per agent. No shared accounts. Logs should point to one actor.
2. Tool allowlist. List exactly which tools each agent may call. Deny the rest by default.
3. Scope each tool. Read only where reading is enough. Limit repositories, tables, folders and channels by name.
4. Short lived credentials. Issue tokens that expire in minutes or hours and are fetched at run time, not stored in prompts or config files.
5. Separate read and write. Use different identities, or approval, for actions that change state.
6. Human approval for irreversible actions. Deletions, payments, external emails, production changes.
7. Limit data exposure. Give the agent only the context it needs. Anything in its context can be echoed back.
8. Treat inputs as untrusted. Web pages, tickets, documents and tool outputs can carry instructions.
9. Rate and budget limits. Cap calls, spend and run time so a loop is cheap.
10. Log every tool call with identity, arguments and result, and review samples.
11. Revoke fast. Know how to disable one agent without breaking others.
12. Review quarterly. Permissions grow; remove what is unused.

Does a good system prompt count as a control?

It helps, but it is advice to the model and not enforcement. Put enforcement in the tool layer, gateway or policy engine, where a model cannot argue its way past it. OWASP's work on large language model risks is a good place to read about how agents get manipulated.

Where tooling helps

Safeguard's MCP Guardrail and agent identity capabilities, along with policies and gates, are designed to sit between agents and the tools they call so limits are enforced outside the model. Check what is enabled on your account.

How do you test that it works?

Try to break your own agent. Feed it a document that contains instructions and see which tools it reaches for. Ask it to read something outside its scope and confirm the tool layer refuses. Revoke its token mid run and check it fails safely. Review logs for calls you did not expect. Repeat after every new tool or scope change, because permissions tend to grow quietly. If you cannot explain in one sentence why an agent has a given permission, remove it and see whether anything breaks. Most of the time nothing does.

Quick check

Sources

• NIST glossary: least privilege
• OWASP Top 10 for Large Language Model Applications
• OWASP Secrets Management Cheat Sheet

Last reviewed: 18 October 2026.