Least privilege for non-human users: what permissions should an agent get?
Give an AI agent its own identity and only the limited, temporary permissions its task requires. Separate reading, writing and high-risk actions, with approval and logging where appropriate.
An agent should receive only the permissions it needs to perform its task, and no more. Give it its own identity and a dedicated account with limited access. Use temporary access where possible, and distinguish clearly between reading, writing and irreversible actions such as deleting or sending. That limits the potential damage if the agent makes a mistake or is misled.
Least privilege means giving an agent access only to the data and functions required for its work. Apply that rule at every step: which files it can view, which systems it can change and which actions require approval. For a practical introduction to safeguards for agents, see guardrails for AI agents.
Give the agent its own identity
An agent is a non-human user: a software process that retrieves information or performs actions on an organization’s behalf. Give it a distinct identity in the systems it uses. Do not use a shared administrator account or reuse an employee’s credentials. Otherwise, it can be difficult to tell who performed an action, and the agent may have more access than its task requires.
Associate the identity with a defined purpose, such as reading documents in a particular folder or preparing draft replies. Record who owns the account and who can change its permissions. If different agents or tasks need different levels of access, use separate identities. An agent that only summarizes documents does not need the same access as one that updates records in a business application.
A separate identity also lets you revoke access independently. When an agent is no longer needed, you can disable its account without changing human accounts. This helps prevent old automation from quietly retaining access.
Separate reading, writing and irreversible actions
Reading is not the same as editing. An agent that needs to look up information usually does not need permission to change it. Start with read-only access, then add write permissions only when the task requires them. Limit those permissions to the right environment, folder, records or fields. For more on setting boundaries around files, see agent access to files.
Also distinguish writing from actions that have effects outside the system. Saving a draft is different from sending an email to a customer. Suggesting a change is different from deleting a case, initiating a payment or confirming an appointment. For high-risk actions, let the agent prepare a proposal and have a person approve the final step. Which actions need approval depends on their consequences, context and your organization’s policies.
If an agent is allowed to write on its own, decide in advance where it can write and how mistakes can be reversed. Where possible, use drafts, proposed changes or a recycle bin instead of immediate, irreversible changes. This reduces the impact of a misunderstanding.
Limit tokens, secrets and tasks
Access is often controlled through tokens, keys or other secrets. Give each token only the permissions needed, and make it expire automatically or available only for a single task where possible. A token with broad, long-lived access can be misused if it leaks or if the agent follows a harmful instruction.
Do not put secrets in a prompt or hard-code them. Prompts may be stored, displayed or influenced by text in documents and emails; code can end up in logs or source control. Have a secure service provide the required secrets to the process that needs them, without exposing them to the agent. The right setup varies by environment, so check how credentials are issued, renewed and revoked.
Where possible, keep tasks and agents separate. A short-lived task that summarizes a folder does not need to inherit access from another task that updates customer records. Limit the duration and scope of sessions too. This makes it less likely that an error in one task will affect other processes.
Account for manipulation and mistakes
An agent may misunderstand a request, make a wrong assumption or treat text in a file as a valid instruction. In a prompt-injection attempt, a document or email might try to persuade the agent to share data or take other actions. If the agent has broad permissions, that deception can have greater consequences.
Limiting permissions cannot prevent every mistake, but it does reduce what the agent can do. Give it access only to sources relevant to its task, and do not let content in those sources change its access rules. Require the agent to stop and request approval before sensitive or irreversible actions. Decide in advance which actions need human confirmation; when should a person approve? can help define that boundary.
Also decide what happens when the agent lacks a permission it needs. A well-bounded setup should let the task stop safely or request help. The agent should not be able to switch identities, obtain a broader token or find another route on its own.
Log actions and review permissions
An audit log helps you see which identity used access, what data it consulted and which actions it performed. Record enough to investigate incidents and check changes, while avoiding the unnecessary collection of sensitive content. Decide who can view the logs and how long they should be retained.
Observability can also help you spot when an agent gets stuck, takes unexpected actions or repeatedly tries to access something. See agent observability for more. Logs do not replace access controls: they help you understand what happened afterwards, while least privilege limits what the agent can do in the first place.
Review permissions regularly, and whenever the task, systems or owner change. Remove access that is no longer needed, revoke old tokens and verify that temporary accounts really expire. Permissions can accumulate as new requests arise; without review, an agent may eventually have more access than its purpose justifies.
Quick checklist
Review these points before deployment and whenever the setup changes:
- Does the agent have its own identity and an accountable owner?
- Are shared administrator accounts and employee credentials excluded?
- Can it read only the required sources and change only the data it needs to change?
- Are deletion, sending and other high-risk actions separately restricted or subject to approval?
- Are tokens limited and temporary where possible, with secrets kept out of prompts and code?
- Are tasks or agents with different permissions kept separate?
- Can you check what the agent did in logs, and do you periodically remove unused permissions?
The right permissions depend on the task and the potential consequences of mistakes. Start with the least access possible, add only justified permissions and review the setup when the agent’s work changes.