The short answer
AI agent permissions are the set of rules that precisely define which systems an agent can read from, which it can write to or act on, and which class of actions must pass through human approval before execution. This is a topic bounded by access itself: what the agent can see, what it can do, and where its authority ends. It is narrower than full agent governance, which covers an entire risk and control architecture (see the AI agent security and governance article), and it is a different topic from designing the human-oversight experience itself (see the human-in-the-loop article).
Read vs write access
The simplest way to classify agent permissions is the distinction between read and write access. Read access lets an agent view a system's data — a customer record, an account balance, a support ticket's status — without modifying it. Write access lets it change that data: updating a record, sending a message, creating or deleting an item. An agent that only needs to answer questions or summarise information usually needs no write permission at all, and restricting it to read-only removes an entire class of potential risk without affecting its ability to do its job.
The least-privilege principle
Least privilege means granting an agent the minimum access needed for its specific task, not broad access "just in case it needs it later." In practice that means: only granting access to systems it actually needs, scoping access within each system (a single team's records, not all records), and reviewing permissions periodically as the agent's task changes. Expanding permissions later is far easier than discovering, after something has already gone wrong, that an agent had access it never needed in the first place.
Connector and integration scopes
Every connector or integration linking an agent to an external system — email, calendar, a CRM, a database — should be configured with a specific permission scope, not full access to the entire user account. Most modern integration systems support fine-grained scopes (such as "read messages only" vs "send messages"), and choosing the narrowest scope that gets the job done is the first step in scoping any agent's permissions. When reviewing the available integrations guide, it's worth checking which permission scopes each integration requests before connecting it to an agent handling sensitive data.
Environment boundaries: test vs production
Separating a test environment from production isn't just good development practice — it's a core part of an agent's permissions. An agent under test should run with credentials and an environment fully separate from production — not the same account with "slightly narrower" limits — so that a bug in the agent's logic or an exploit attempt during testing can never reach real data or systems. This separation also includes sandboxing: running an agent in an isolated environment while its behaviour is still unproven, so any actions stay within bounds that are reversible or fully observable.
Actions that require approval
Some classes of action call for human approval before execution regardless of how much you trust the agent's performance. The most notable: moving money or any financial action, external communication with parties outside the organisation on its behalf, deleting data, and any change to sensitive customer records. What these classes share is difficulty of reversal or direct impact on an external party — not technical complexity of the action itself. For more detail on designing the approval checkpoint as an experience, see the human-in-the-loop article.
Action classes and recommended posture
| Action class | Recommended permission posture | Approval gate? |
|---|---|---|
| Read-only lookup | Read access scoped to the data actually needed | Usually unnecessary |
| Internal draft (email, note, draft report) | Write within a closed scope, no automatic publish or send | Optional, depending on content sensitivity |
| External message on the organisation's behalf | Send permission limited to a clear channel and scope | Advisable before actual sending |
| Data write inside a system (record update) | Write access restricted to a narrow scope and specific record type | Depends on record sensitivity and reversibility |
| Irreversible or financial action | No direct execution permission without human involvement | Mandatory |
Credential revocation and rotation
The credentials an agent uses — API keys, access tokens, service accounts — should be instantly revocable without disrupting other systems, and rotated periodically like any other sensitive credential. Giving a single agent its own dedicated key instead of a key shared with other systems makes revoking its access, when needed, a simple, isolated action that doesn't affect the rest of operations.
Auditability and action logs
Any serious permission system needs a log that precisely shows which agent took which action, on what data, and when. This log isn't just a forensic tool for after something goes wrong — it's a baseline requirement for assessing whether the permissions currently granted actually match what the agent does in practice. Without a traceable audit log, any review of an agent's permissions rests on assumptions rather than evidence.
Who can change an agent's scope
Expanding or narrowing an agent's permissions should be a decision restricted to specific roles within a team, not available to every user who interacts with the agent day to day. Separating who uses an agent from who can change its access scope prevents unreviewed permission creep over time, and makes any scope change accountable and traceable within a clear log.