On this page
Least privilege for AI agents means giving an agent only the access needed for its assigned task, and removing that access when the task ends. Apply it to the account the agent uses, the files it can reach, its tools, and the actions those tools can perform.
A useful starting question is: if this agent followed the wrong instruction, what could it change? A request to summarize support tickets should not also grant permission to refund customers, change account owners, or export every customer record.
This guide uses an illustrative support workflow to turn that question into a permission plan. It is a design exercise, not a report of a tested deployment.
Start with a task, not an administrator account
NIST defines least privilege around the minimum access a user or process needs to do its assigned work. For an agent, write down that work before connecting tools. “Help with support” is too broad to evaluate. “Read these ten tickets and save a draft summary in this project” gives an operator something concrete to authorize.
Our example agent needs ticket text, a place to write a summary, and permission to read the relevant product documentation. It does not need billing administration or a tool that sends replies. Removing those capabilities is more dependable than telling the model not to use them.
Separate four kinds of access
| Boundary | Question to answer | Example restriction |
|---|---|---|
| Identity | Which account performs the work? | A dedicated support-reading identity, not an administrator's session. |
| Resources | Which records and files can it reach? | The selected project and tickets, with no production secrets mounted. |
| Actions | What can it do to those resources? | Read tickets and write a draft, but no refunds, deletion, or outbound replies. |
| Duration | When should access end? | A task-scoped session or short-lived credential with a defined expiry. |
These restrictions belong in the systems that enforce access. A prompt can explain the task, but the underlying account, server, or execution environment must reject actions outside it. Google Cloud's agent-security guidance similarly recommends dedicated identities and the minimum IAM roles needed for the job.
Read-only still needs a boundary
A read-only account can expose information. If our summary agent can read all customer records and send arbitrary network requests, a mistaken action may disclose data without changing a single ticket.
Decide where the summary may go. Keep customer data out of unrelated tools, limit the accessible records, and inspect exports before sharing them. A tool's name is not enough: a tool called “search” may return sensitive fields, and a “preview” endpoint may still create a persistent object. Review the actual tool contract and provider permissions.
For MCP connections, evaluate each server separately. The MCP security guidance describes the risks of broadly scoped tokens and local servers running with the host user's privileges. Approving a server connection does not establish that every action it exposes belongs in this task.
Keep drafting separate from sending
Suppose the next task is to reply to a ticket. Give the drafting stage enough context to prepare the answer. A separate, explicitly authorized step can review the recipient and final text before delivery. The ticket-reading identity does not need to become a general-purpose mail sender.
Record the chosen ticket, intended recipient, proposed change, and result. If delivery times out, check whether the message was sent before trying again. Least privilege limits access; it does not solve duplicate actions or uncertain results.
Where HOL Guard fits
HOL Guard applies policy to supported agent action boundaries, with coverage that depends on the harness and event. It can provide an additional review or blocking point where that integration supports it. Keep account permissions and environment restrictions in place; a local policy tool does not grant fine-grained authorization inside every remote service.
Before adopting a configuration, check the current Guard product and integration information and test the specific action path you intend to use. A control that covers one shell or MCP path should not be assumed to cover another.
A permission plan you can review
Write a short record containing the task, identity, allowed resources, allowed changes, forbidden actions, access expiry, and person responsible for exceptions. Include one permitted action and one harmless action that should be refused. If you cannot say what a refusal should look like, the boundary is not ready to rely on.
Start with a narrow job that can finish successfully. Expand access only when a specific missing permission prevents that job, then test the revised boundary again. The goal is useful work with a smaller exposure, not a long permission list that nobody understands.
Put the permission plan into practice
Use the permission-testing worksheet to check a disposable configuration, then use the tool-call review checklist when an action needs an operator decision.
Sources checked November 2, 2026. Examples are illustrative. This guide does not claim a measured security outcome or universal Guard coverage.
