# Scopes for email agents: which permissions an agent really needs

> Read, draft, send, delete: the OAuth permissions Gmail, Microsoft 365 and IMAP give AI agents, where they are too broad, and how to keep them tight.

Updated: 2026-10-26 · Fact-checked: 2026-10-26 · Canonical: https://commandmail.app/en/learn/email-agent-scopes · Deutsch: https://commandmail.app/de/wissen/scopes-fuer-e-mail-agenten.md

An email agent needs exactly the permissions its job calls for, and nothing beyond that. Summaries need read access, sorting adds the right to change labels or folders, drafts are a separate right, and you grant sending or deleting only if the agent really should do that on its own. These permissions are called scopes, and how finely you can grant them depends a lot on the provider.

## What a scope is

A scope is a named permission you give a program when you connect it through OAuth. The consent screen shows it as something like "Read your email" or "Send email on your behalf". The mail service checks on every call whether the access token carries the right scope and refuses the call if it does not.

For AI agents, this is the most important layer of protection because it works regardless of the model. An agent can be fooled by a crafted email, but it cannot do anything its access does not allow. OWASP describes this case directly: an assistant is meant to summarize incoming mail, but the extension it uses can also send. A malicious email makes it search the inbox for sensitive information and forward it to the attacker[^5]. One of the fixes OWASP lists is an OAuth session with a read-only scope.

## Five rights cover almost every job

Nearly every task of a mail agent breaks down into five rights. Reading covers search, summaries and briefings. Organizing covers labels, folders, flags and archiving. Drafting stores replies for a person to check. Sending and deleting are the rights with effects outside the mailbox or without an easy way back.

| Job | Read | Organize | Draft | Send | Delete |
|---|---|---|---|---|---|
| Summaries, morning brief | yes | no | no | no | no |
| Sorting and labeling | yes | yes | no | no | no |
| Preparing replies | yes | optional | yes | no | no |
| Sending approved replies | yes | optional | yes | after approval only | no |
| Replying on its own | yes | optional | optional | yes | no |
| Cleanup including deletion | yes | yes | no | no | yes |

Several of the jobs shown need neither sending nor deleting. Some providers bundle exactly these two rights into broader scopes, as the next sections show.

## Gmail: fine-grained, but drafting includes sending

The Gmail API offers many separate scopes, from `gmail.labels` for labels to `gmail.readonly` for reading and `gmail.send` for sending only[^1]. A read-only agent gets by with `gmail.readonly`. Sorting is coarser: `gmail.labels` manages the labels themselves, while moving messages around belongs to broader scopes. Google says `gmail.modify` allows reading, composing and sending, but not immediate permanent deletion that bypasses the trash.

There is no drafts-only scope. Google describes `gmail.compose` as "Manage drafts and send emails"[^1]. Allowing an agent to draft therefore also allows it to send. If a person should approve every email, that block has to live outside Gmail's permissions, for example in the software that sits between the agent and Gmail.

Google describes the widest scope, `https://mail.google.com/`, as read, compose, send and permanently delete all your email, and advises requesting it only if an app really needs immediate permanent deletion[^1]. Google classes reading and modifying scopes such as `gmail.readonly`, `gmail.compose` and `gmail.modify` as "restricted". Public apps need a dedicated verification for them, and apps that store or transmit that data on servers also need a security assessment[^1].

## IMAP and SMTP: full access on Gmail as a rule

Some MCP servers and local agents use IMAP and SMTP instead of the Gmail API. For connections on behalf of a user, Google issues the scope `https://mail.google.com/` for these protocols[^2]. The only exception Google names is IMAP through domain-wide delegation with service accounts in Google Workspace, which uses `gmail.imap_admin`. An agent that reads Gmail over IMAP with the regular scope `https://mail.google.com/` therefore formally holds the right to send and to delete permanently, even if all it should do is summarize. This does not apply to the `gmail.imap_admin` exception.

## Microsoft 365 and Outlook: sending is its own right

Microsoft Graph keeps sending apart from everything else. According to Microsoft, `Mail.ReadWrite` lets an app create, read, update and delete mail and explicitly does not include permission to send; that is `Mail.Send`[^3]. A drafting agent with `Mail.ReadWrite` can store drafts without being able to send them. It can still delete, though. `Mail.ReadBasic` reads metadata without body or attachments, and `Mail.Read` reads everything.

The second difference is reach. Delegated permissions act for the signed-in person: `Mail.Read` reads their own mailbox, and `Mail.Read.Shared` adds mail shared with them. Application permissions without a signed-in user cover all mailboxes, and `Mail.Send` then reads "Send mail as any user"[^3]. With RBAC for Applications in Exchange Online, an admin can restrict such application permissions to a set of mailboxes[^4]. This only works if the same permission is not also granted organization-wide in Microsoft Entra ID; Microsoft adds both grants together[^4].

## Mailbox boundaries are a separate question

Scopes describe what an agent may do, not always where. Read access to a Gmail account covers the whole account. An application permission in Microsoft 365 that has not been scoped covers every mailbox in the organization. If an agent should see only one mailbox, you need a separate boundary: its own account, a mailbox restriction set by an admin, or a layer in between that tells mailboxes apart.

## How to keep permissions tight

A short check before you connect pays off. Write down in one sentence what the agent should do, then map that sentence to the rights above. Look at which scopes the consent screen actually requests, and decline if a summarizing tool asks for sending or full access. Where a provider lets you switch off individual rights, switch off what the job does not need.

For sending without a person in the loop, OWASP also recommends limiting the damage, for example with rate limits on sending[^5]. Revoke access you no longer use in the provider's account settings.

## How Command Mail splits the rights

Command Mail is our product. We checked the following statements against the app code at commit `5a48c2b`.

Command Mail offers agents five public OAuth permissions to choose from: `mail:read`, `mail:draft`, `mail:send-approved`, `mail:send` and `mailboxes`[^6]. `mail:draft` saves drafts and never sends. `mail:send-approved` sends only the exact version a person approved in the app. `mail:send` sends without approval, and only from mailboxes on the autonomy level `auto`. Forwarding, direct trash calls and permanent deletion need `mail:read` and `mail:send` together; forwarding and permanent deletion also need the `auto` level. Check rules and running retention periods separately. On the consent screen you can switch off any requested right, and `mail:send` starts switched off.

We state two limits openly. `mail:read` is not a pure read right: it also allows sorting, flags, labels and rules within the autonomy level, so to keep an agent from changing existing messages, the mailboxes also need to be on the `read` level. That is not a write block for everything in the account; the agent can still create labels, for example. And `mail:read` reads every mailbox in your account. The autonomy level per mailbox limits changes and sending, not reading. Separate read access is only possible with separate accounts. The [permissions documentation](https://commandmail.app/en/docs/permissions-and-autonomy) covers every right and level in detail, and [human in the loop](https://commandmail.app/en/learn/human-in-the-loop-email) explains why an approval must be tied to the exact version that was checked.

## Review status

As of 2026-10-26. The Google, Microsoft and OWASP pages were retrieved that day. Statements about Command Mail rest on llms.txt and the app code at commit `5a48c2b` (scope checks on API routes, the delete route with its autonomy check, OAuth consent and its preselection). We did not run our own tests against Google or Microsoft services for this page.

You can [start for free](https://commandmail.app/login?signup=1) and connect your agent with `mail:read` only at first.

## Frequently asked questions

### What is a scope for an email agent?

A scope is a named permission you grant through OAuth when you connect a tool, such as reading mail or sending mail. The mail service checks it on every call. Whatever the agent was not granted, it cannot do, even after being tricked.

### Which permissions does an agent need if it only summarizes or sorts?

Summaries need read access. Sorting also needs permission to change labels or folders. Sending and deleting are not part of either job. OWASP uses this exact case: a summarizing agent that can also send can be tricked by a crafted email into forwarding data.

### Does Gmail have a drafts-only permission?

No. Google describes the gmail.compose scope as "Manage drafts and send emails", so it includes sending. If you want an agent to draft only, the block has to sit outside Google's permissions.

### Why do IMAP-based agents usually ask for full Gmail access?

For normal connections on behalf of a user, Google issues the scope https://mail.google.com/ for IMAP, POP and SMTP. It allows reading, composing, sending and permanent deletion. Finer Gmail permissions exist only through the Gmail API. The exception is IMAP through Google Workspace domain-wide delegation with gmail.imap_admin.

### Do Microsoft 365 permissions cover every mailbox in a company?

Delegated Mail.Read reads the signed-in person's own mailbox, and Mail.Read.Shared adds mail shared with them. Application permissions without a signed-in user cover all mailboxes, according to Microsoft. RBAC for Applications in Exchange Online can limit them to specific mailboxes, but only if the same permission is not also granted organization-wide in Microsoft Entra ID.

## Sources

1. [Google for Developers: Choose Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes), accessed 2026-10-26
2. [Google for Developers: OAuth 2.0 Mechanism (IMAP, POP, SMTP)](https://developers.google.com/workspace/gmail/imap/xoauth2-protocol), accessed 2026-10-26
3. [Microsoft Learn: Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference), accessed 2026-10-26
4. [Microsoft Learn: Role Based Access Control for Applications in Exchange Online](https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac), accessed 2026-10-26
5. [OWASP: LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), accessed 2026-10-26
6. [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-26

[^1]: [Google for Developers: Choose Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes), accessed 2026-10-26
[^2]: [Google for Developers: OAuth 2.0 Mechanism (IMAP, POP, SMTP)](https://developers.google.com/workspace/gmail/imap/xoauth2-protocol), accessed 2026-10-26
[^3]: [Microsoft Learn: Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference), accessed 2026-10-26
[^4]: [Microsoft Learn: Role Based Access Control for Applications in Exchange Online](https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac), accessed 2026-10-26
[^5]: [OWASP: LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), accessed 2026-10-26
[^6]: [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-26

---

Command Mail: one inbox for you and your AI agent. Start free: https://commandmail.app/login?signup=1 · Connect your agent: https://commandmail.app/en/agents · MCP: https://commandmail.app/mcp