Least-Privilege Permissions for AI Agents: Scopes That Hold

Least-privilege permissions for an AI agent mean that each tool the agent can call receives only the read and write rights its specific job requires, and nothing adjacent to that job. Set the scope per tool and per action, not once for the whole agent, so that a more capable model does not inherit wider reach simply because it reasons better. The steps below show how to define those scopes, test them, and keep them narrow as the agent and the business change.

Key takeaways

• Scope each tool by the job it performs, not by what the vendor's credential happens to allow.
• Split every system into separate read, draft and write tools, and grant only the tiers the job needs.
• Enforce limits in the tool layer and the credential, outside the model's reasoning, where a clever plan cannot override them.
• Test the boundary with requests the agent should fail, and treat every unexpected success as a defect.
• Review permissions on a schedule and whenever the agent's role, the systems it touches or its approval rules change.

Why a more capable agent needs narrower scopes

A more capable agent does not become more trustworthy by default. It becomes better at finding a path to its goal, including paths you did not design. A model that plans across several steps may read a record in one system, copy a value into a second system and write it into a third, even though no single step looked risky. The broader the access at each step, the more ways a plan can succeed in ways you never approved.

Instructions in a system prompt are guidance. A scope is enforcement. The model can be told not to issue refunds, and it may comply most of the time, but the refund tool should refuse the call if the agent's role does not include refunds. Input from emails, web pages or documents can also try to redirect the agent, which is why the prompt injection risks for business agents matter for permission design. A narrow scope limits what a redirected agent can actually do.

The practical rule is simple: the question is not whether the agent is smart enough to be trusted with a capability, but whether the capability is needed for the job at all. If it is not needed, remove it. If it is needed sometimes, put it behind an approval step rather than leaving it open.

Start from the job and list the actions it truly needs

Before you open any access, write down what the agent must do, in plain verbs, for the one role you are defining. A useful list is short. For a scheduling assistant, it might be: look up free slots, propose a time, create a tentative hold, and send a confirmation after a person approves. Anything not on that list is outside the role until someone adds it on purpose.

Use this checklist to turn the list into scopes:

• Name the role in one sentence and the single outcome that proves it works.
• For each action, write the system it touches, the object it acts on and the direction of data flow.
• Mark each action as read, draft, or write, and note whether a person must approve it before it takes effect.
• Remove any action that exists only because the vendor's default permission included it.
• Write down what the agent must never do, even when asked, and confirm that no tool provides that capability.
• Record who owns each scope, so that a change request has a named decision maker.

This list is also the input for an acceptance review. If an action cannot be traced to a sentence in the role definition, it does not belong in the tool set.

Split each tool into read, draft and write

Most systems expose one broad connection that can do everything. Replace it with separate tools that match the three tiers. A read tool returns information and changes nothing. A draft tool prepares an output, such as a reply, a record or a document, and stores it for review. A write tool commits a change to the system of record. Keeping these apart means you can grant the agent reading and drafting without granting it the power to publish or delete.

The distinction matters more as capability rises, because a stronger agent will use every tool it is offered. The article on read, draft and send permissions walks through why these three tiers behave differently in practice, and why the send or commit step deserves its own approval rule.

When you design the write tool, make its inputs narrow and typed. A tool that accepts a free-form instruction such as "update the customer record as needed" is not a scope at all. A tool that accepts a specific record identifier, a limited set of fields and a stated new value is one you can audit and reason about.

Each tool should answer one question: what is this agent allowed to change, and in which system?

Narrow the object, the field and the time window

A read permission on a whole system is rarely what the job needs. Narrow it along three axes. The first is the object: which records, folders, mailboxes, calendars or tables the tool can see. The second is the field: which columns or attributes are returned or writable. The third is the time window or context: for example, only the next thirty days of appointments, or only tickets assigned to one queue.

Some systems support these limits natively, and others need a filter in front of the tool that the model cannot change. The calendar write access guide covers how to limit which calendars and event types an agent can modify. For databases, a read-only connection with a restricted view is usually safer than a general query tool. See connecting an AI agent to your database with read-only access for the specific steps.

Illustrative scenario: a support agent for a small online shop can read order status and draft replies to customers. It should not issue refunds or change addresses after dispatch. The team gives it a read tool limited to orders from the last ninety days, a draft tool for replies, and no write tool for money or shipping. When a customer asks for a refund, the agent creates a request in a queue that a staff member approves. The agent never holds the refund capability, so a persuasive customer message cannot unlock it.

Scope the credential behind each tool

A tool's permissions are only as narrow as the credential it uses. If the tool authenticates with an administrator token, the tool's own filters are a convention, not a boundary. Use a dedicated account or token for each agent role, and grant that identity only the permissions named in the scope list. Where the platform supports scopes, request the smallest set that covers the actions you wrote down.

OAuth-style authorization makes this explicit. Each scope names a permission the user or administrator approves, and the token carries only those grants. The [Google OAuth 2.0 documentation](https://developers.google.com/identity/protocols/oauth2) describes how authorization scopes limit what an application can access on a user's behalf. The choice between a service account and a user-delegated token depends on whether the agent acts for the organization or for a person, which is why service accounts or OAuth tokens deserves its own decision before you grant anything.

Keep credentials out of prompts and out of shared notes. Store them in the platform's secret store, rotate them, and revoke them when a role ends. A permission that cannot be revoked quickly is a permission that will eventually be forgotten.

Test the boundary and review it on a schedule

A scope that has not been tested is a hypothesis. Write a short set of negative tests, which are requests the agent should fail. Ask it to read a record outside its window, to write a field it should only read, to act on a system outside its role, and to take an action that requires approval without approval. Each attempt should be refused by the tool or routed to the approval step. Any success is a defect to fix before the agent goes into regular use.

Run these tests again after every change to the model, the prompt, the tool definitions or the underlying system. A model upgrade can change how the agent chains actions, even when the scope file is unchanged. Recurring evaluations are the practical way to catch this, and the [OpenAI evals guide](https://platform.openai.com/docs/guides/evals) describes the general pattern of running fixed test cases against a system and comparing results over time. Log every tool call with the identity, the object and the outcome, so that an unexpected pattern can be traced later.

Review permissions at fixed intervals and at every role change. Remove scopes that were added for a one-off task. Confirm that owners still exist for each scope. Check that the vendor has not added new default permissions during an update.

Be Human designs and operates this kind of scope structure as part of its managed approach. A first engagement defines one useful role, the memory and tools that role needs, the approval boundaries around each action, and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, permission review, integration maintenance and incident response, so the scopes agreed at the start are still checked after a vendor changes an API or the team adds a new process. The goal is not a perfect permission file on day one, but a boundary that stays visible and tested as the agent gets more capable.

If you are not yet sure which task should go to an agent first, the free Be Human AI diagnostic can help you find the first task worth handing over.

Frequently asked questions

Is least privilege enough to make an AI agent safe? It is one of the most important controls, but it does not replace monitoring, approval steps for sensitive actions and protection against manipulated input. Least privilege limits the damage an agent can do when something goes wrong, which is why it should be the foundation. Combine it with logs, tests and a clear owner for each role.

Should one agent have one set of permissions for all of its tools? No. Permissions should follow the tool and the action, not the agent as a whole. A single agent may need read access to a calendar, draft access to email and no access to payments. Granting one broad identity to every tool makes it harder to see which action caused a problem and harder to revoke only the risky part.

How do I know a scope is too narrow? The agent will fail the job in a visible way, such as repeatedly asking for information it should be able to read or escalating routine cases to people. When that happens, add the smallest specific permission that the job requires, record why it was added, and test it. Avoid widening a scope because it is inconvenient without tracing the need back to the role definition.

Can I give an agent write access and rely on approval prompts instead? Approval prompts are useful for actions that are rare and consequential, but they are weak protection when the agent can write freely and people approve quickly without reviewing each change. Prefer a draft or queue step for anything that changes records or sends messages, and reserve direct write access for low-risk, reversible actions with clear limits.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.