AI Agent Permissions: A Least Privilege Setup Guide

An AI agent should receive only the permissions needed for its specific task: limited data access, narrowly scoped tools, and no authority to make consequential changes unless those actions are explicitly required and controlled. Start with read-only access where possible, then grant access to particular resources and actions, use human approval for sensitive operations, and review permissions regularly.

What least privilege means for an AI agent

Least privilege is a security principle: give an identity only the access it needs, for only as long as it needs it. An AI agent may have several identities and capabilities at once: an application account, access to files or databases, tools it can call, and credentials that let it act in other services. Treat each separately rather than assuming that a safe prompt makes broad access safe.

The goal is not to make an agent incapable of useful work. It is to limit the harm a mistake, compromised component, misleading instruction, or unexpected tool call can cause. An agent that summarizes a folder usually does not need permission to delete files, send email, or administer the organization’s accounts.

Choose permissions by task and resource

Write down what the agent must accomplish before selecting permissions. For each step, identify the data it needs, the actions it must perform, and the systems involved. Prefer permissions attached to a specific resource or action over broad roles such as “administrator” or “full access.”

Reading: Grant access only to the relevant documents, records, or database views. Avoid exposing unrelated personal, confidential, or operational data.
Writing: If the agent must create or update information, restrict it to the required fields, records, or workspace. Separate creating a draft from publishing or sending it.
External actions: Treat sending messages, changing account settings, making purchases, deleting data, and publishing content as higher-impact actions. Omit them unless they are part of the task.
Administration: Keep user management, security settings, access-policy changes, and credential management out of ordinary agent roles.
Tools and integrations: Enable only the tools the workflow needs. A connected tool can extend the agent’s reach beyond the model itself.

For example, a meeting-notes agent could read a designated transcript folder and create draft notes in a particular workspace. It does not automatically need access to every company file or permission to email attendees. If sending a summary is required, make that a separate, reviewable step.

Set up access in practical stages

Define the job. Describe the intended workflow and list every system and action it requires. Identify actions that should remain unavailable.
Create a separate identity. Use a dedicated service account or equivalent identity when the platform supports it, rather than sharing a person’s account. This makes access easier to attribute, limit, and revoke.
Start read-only and narrow. Give access to a small test set of resources. Add write permissions only when the task cannot be completed without them.
Separate preparation from execution. Have the agent prepare a draft or proposed change, then require an authorized person to approve consequential actions. Approval should show what will happen and to which resources.
Test denied actions. Confirm that the agent can complete the intended task, but cannot access unrelated resources or perform actions outside its role. Test with representative data and a non-production environment where available.
Document and review. Record the owner, purpose, granted permissions, expiration or review date, and revocation procedure. Recheck access when the workflow changes and remove permissions that are no longer needed.

Protect credentials, sessions, and data

Permissions are only one part of the setup. Credentials that carry those permissions must also be protected. Store secrets in an approved secrets manager or platform-provided credential store, restrict who and what can retrieve them, and avoid placing passwords, API keys, or access tokens in prompts, source code, logs, or ordinary documents.

Prefer short-lived credentials or scoped tokens when the system supports them. Set expiration and rotation practices appropriate to the service, and make sure there is a clear way to revoke access quickly. Do not reuse a broad personal access token for an agent: if it is exposed, the agent may inherit the account holder’s wider access.

Limit the data sent to the agent as well as the data it can retrieve. Remove fields that are irrelevant to the task, and establish how inputs, outputs, and tool activity are logged and retained. Logs help investigate errors, but they can themselves contain sensitive information; restrict access to them and avoid recording secrets unnecessarily.

Control high-impact actions and unexpected instructions

An agent may process documents, messages, web pages, or other content that contains instructions. Such content should not be treated as a reason to expand the agent’s permissions or override access controls. Enforce authorization in the tools and connected systems, not only through instructions in a prompt. A prompt can guide behavior, but it is not a substitute for a permission boundary.

Use additional safeguards where an action is difficult to undo or affects other people. Depending on the workflow, that may mean requiring a human to approve a deletion, external message, payment-related action, publication, or account change; limiting transaction size or destinations where the service supports it; and keeping an audit trail of requests, approvals, and results. If an action does not need to happen automatically, leave it out of the agent’s role.

Common permission mistakes

Granting a broad role for convenience: A role that can access an entire account or organization may expose much more than the task needs. Look for resource-level or action-level controls.
Confusing prompt rules with access control: Telling an agent not to delete files does not prevent deletion if its connected tool allows it. Remove the capability or enforce the restriction in the tool.
Leaving old access in place: Temporary experiments and retired workflows can leave unused accounts, tokens, or integrations active. Revoke them when they are no longer needed.
Giving write access when a draft is enough: A workflow can often produce a proposed change for review instead of directly changing a live system.
Ignoring inherited access: A service account may gain access through groups, shared folders, or default roles. Check effective permissions, not just the permissions shown on one agent setting.

Least privilege does not mean that read-only access is always harmless. Reading sensitive records can expose private information, and an agent can include that information in an output. Apply data minimization, access restrictions, and output review to read workflows too.

Frequently Asked Questions

Should an AI agent have administrator access?
Usually not. Administrator access can allow changes far beyond a normal task. Use a dedicated, narrowly scoped identity and reserve administrative actions for a separate, controlled workflow.

Is read-only access safe for an AI agent?
It reduces the risk of direct changes, but it does not eliminate risks from exposing sensitive data or producing inappropriate outputs. Limit what the agent can read and control where its results can go.

Can a prompt enforce least privilege?
No. Prompts can describe intended behavior, but technical permissions must limit what tools and accounts can actually do. Enforce boundaries in the connected service or integration.

When should a person approve an agent’s action?
Consider approval when an action is external, consequential, difficult to reverse, or affects sensitive data or other people. The approver should be able to inspect the proposed action before it runs.

How often should agent permissions be reviewed?
Review them whenever the task, connected systems, or responsible owner changes, and establish a recurring review schedule suited to the risk. Remove access that is no longer necessary.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →