ExplainerUpdated October 26, 2026
Scopes for email agents: which permissions an agent really needs
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.
Contents
- What a scope is
- Five rights cover almost every job
- Gmail: fine-grained, but drafting includes sending
- IMAP and SMTP: full access on Gmail as a rule
- Microsoft 365 and Outlook: sending is its own right
- Mailbox boundaries are a separate question
- How to keep permissions tight
- How Command Mail splits the rights
- Review status
- Frequently asked questions
- Sources
01What 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.
02Five 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.
03Gmail: 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].
04IMAP 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.
05Microsoft 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].
06Mailbox 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.
07How 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.
08How 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 covers every right and level in detail, and human in the loop explains why an approval must be tied to the exact version that was checked.
09Review 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 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.