AI Agent Email Access Security: Scopes and Send Limits

An AI agent that can read an inbox and send mail combines the three things an attacker wants in one identity: untrusted input arriving from anyone, access to sensitive data, and an outbound channel that looks legitimate. Inbox assistants, triage bots, sales agents and support agents are being connected to Microsoft 365 and Google Workspace mailboxes through OAuth grants that were designed for human-driven apps. This guide covers how to choose mail scopes, how to limit which mailboxes and which recipients an agent can touch, how to filter and isolate inbound content against prompt injection, and what to log so misuse can be detected and investigated. It is for identity, messaging and AI platform teams approving or building email agents. Platforms are listed alphabetically (Google Workspace, then Microsoft 365); order is not a ranking.

Key takeaways

Every inbound email is untrusted input to the agent. OWASP LLM01 classes instructions hidden in external content as indirect prompt injection, and an email agent ingests external content by design.
Read and send should be separate identities. OWASP LLM06 uses the mailbox summariser as its example of excessive agency: a reading agent should not hold send capability, and drafted mail should need a human to press send.
Application permissions mean every mailbox unless you scope them. Microsoft's application mail roles cover all mailboxes until restricted with RBAC for Applications, and Google domain-wide delegation reaches all users' data for the granted scopes.
Prefer metadata and basic scopes where they work. Microsoft Graph lists Mail.ReadBasic as the least privileged permission for listing messages, and Gmail offers gmail.metadata for headers and labels without bodies.
Log the agent as its own identity. Exchange MailItemsAccessed records each message an identity binds to, and Google OAuth log events record client ID, scopes and whether an AI agent performed the action.

Why email agents are a distinct risk

Most agent integrations pull data from systems an attacker cannot easily write to. Email is the opposite: anyone on the internet can place text in front of the agent by sending a message. That changes three assumptions.

Input is attacker-controlled: a message body, a hidden HTML element, an attachment, a calendar invite or a quoted reply chain can carry instructions. The EchoLeak vulnerability (CVE-2025-32711) showed a crafted business email steering Microsoft 365 Copilot into placing sensitive context in a URL, without the user clicking anything.
The data is dense: inboxes hold password resets, MFA codes sent by email, invoices, contracts and personal data. Read access to a finance or HR mailbox is often more sensitive than access to most databases.
The exit is trusted: mail sent from your own domain passes your SPF, DKIM and DMARC alignment and lands in partners' inboxes. An agent that can send is an exfiltration and phishing channel that your gateway is built to trust.

OWASP's LLM06 Excessive Agency scenario describes exactly this chain: a summarising assistant with a plugin that can also send, receiving a malicious email that tells it to search the inbox and forward results to the attacker. The broader agent identity model is covered in the Agent Identity and Access Guide; this page focuses on the mailbox.

Choosing mail scopes on each platform

Pick the narrowest scope that does the job, and decide first whether the agent acts on behalf of a signed-in user (delegated) or as itself across many mailboxes (application or domain-wide delegation).

Google Workspace (Gmail API)

Scope	What it allows	Google classification	Agent use
gmail.metadata	Labels and headers, not message bodies	Restricted	Triage and routing agents that need sender, subject and labels only
gmail.readonly	Read messages and settings	Restricted	Summarisers and search agents
gmail.labels	View and modify labels	Non-sensitive	Sorting agents, combined with metadata
gmail.compose	Create drafts and send	Restricted	Drafting agents; note it includes send
gmail.send	Send on the user's behalf	Sensitive	A dedicated send identity only
gmail.modify	Read, compose and send, no permanent deletion	Restricted	Avoid for agents unless all three are needed
https://mail.google.com/	Full access including permanent deletion bypassing Trash	Restricted	Do not grant to agents
gmail.settings.sharing	Manage sensitive settings such as mailbox delegation	Restricted	Never for agents

Google requires restricted-scope verification for public apps using restricted scopes and a security assessment where restricted-scope data is stored or transmitted on servers. For internal agents the control point is the admin: domain-wide delegation, configured by a super admin under Security, Access and data control, API controls, Manage Domain Wide Delegation, lets a service account act for every user in the domain for the listed scopes. Google advises keeping those scopes as narrow as possible, reviewing service accounts regularly and removing unused scopes; multi-party approval can require a second super admin. See the Google Workspace Domain-Wide Delegation Security Guide.

Availability (Google): scope classifications and verification rules apply to all OAuth clients; multi-party approval and some audit features depend on Workspace edition.

Microsoft 365 (Microsoft Graph and Exchange Online)

Permission or role	What it allows	Agent use
Mail.ReadBasic (delegated), Mail.ReadBasic.All (application)	Least privileged permission Graph lists for listing messages	Triage agents that need message properties rather than full content
Mail.Read	Read mail; as an application role, mail in all mailboxes	Summarisers and search agents, scoped
Mail.ReadWrite	Create, read, update and delete mail, but not send	Drafting agents that leave drafts for a human to send
Mail.Send	Send mail; as an application role, send as any user	A dedicated send identity, tightly scoped
Application Mail Full Access, Application Exchange Full Access	Mail read/write plus send; Exchange Full Access adds calendars, contacts and mailbox settings	Avoid for agents
Application EWS.AccessAsApp	Full EWS access to all mailboxes	Avoid; prefer Graph roles

The Graph sendMail method needs only Mail.Send and, by default, saves the message to Sent Items (saveToSentItems defaults to true); an agent that sets it to false leaves no copy in the mailbox, so check for that parameter in agent code reviews. Delegated permissions let the agent act as the signed-in user within that user's own access. Application permissions are where scoping matters: Microsoft's RBAC for Applications in Exchange Online, which replaces Application Access Policies, assigns roles such as Application Mail.Read to a service principal over a management scope or an administrative unit. See the guide to finding high-privilege Graph application permissions and the Entra ID Applications and Consent Guide.

Availability (Microsoft): RBAC for Applications applies to Microsoft Graph and EWS access only; MailItemsAccessed auditing is on by default for Office 365 and Microsoft 365 E3/E5 users.

Limiting which mailboxes an agent can reach

Microsoft: scope, then remove the tenant-wide grant. RBAC for Applications grants are additive with Entra consented permissions. Microsoft's documentation is explicit that an unscoped Mail.Read granted in Entra still gives access to all mailboxes even after you add a scoped RBAC assignment, so remove the Entra permission once the scoped role is in place.
Microsoft: build the scope correctly. Use New-ServicePrincipal to create the Exchange pointer to the Entra enterprise application, then New-ManagementRoleAssignment with -CustomResourceScope or -RecipientAdministrativeUnitScope. Only direct group members fall in a MemberOfGroup scope, exclusive management scopes do not restrict apps, and changes take 30 minutes to 2 hours to apply.
Microsoft: test before go-live. Test-ServicePrincipalAuthorization with -Resource shows InScope True or False for a named mailbox and bypasses the cache. It ignores Entra grants, so check Entra separately.
Google: avoid domain-wide delegation for user-facing agents. Where an agent serves individual users, let each user grant consent to a narrowly scoped OAuth client so the agent reaches only that user's mailbox. Reserve domain-wide delegation for automation that truly needs many mailboxes, and limit it to the fewest scopes.
Google: control which apps can request scopes. API controls let admins decide which third-party apps may access Gmail data; combine this with periodic review of domain-wide delegation clients and deletion of unused ones.
Both: one mailbox set per agent. A sales agent needs the shared sales mailbox, not executive inboxes. Group target mailboxes explicitly and treat any request to widen the set as a change requiring approval. The Least Privilege Techniques Guide covers the general approach.

Send-as limits and outbound controls

Sending is the high-impact action. Treat it as a separate capability with its own identity and guard rails.

Split identities: run reading and sending under different service principals or OAuth clients, so a prompt-injected reader cannot send. OWASP LLM06 recommends removing send functionality from a summarising extension altogether.
Draft, do not send: where a human is in the loop, grant Mail.ReadWrite or gmail.compose usage only to create drafts, and require the user to send. If you must grant gmail.compose, remember it also allows sending; enforce draft-only behaviour in the tool layer. See the Human-in-the-Loop for AI Agents Guide.
Restrict recipients in the tool, not the prompt: the send tool should accept only allow-listed domains or recipients already in the thread, reject BCC unless explicitly needed, and cap attachments. A system prompt telling the model "only reply to customers" is not a control.
Rate-limit sends: OWASP LLM06 suggests rate limiting on the mail-sending interface to reduce damage. Set a per-agent daily cap and alert when it is approached.
Block external auto-forwarding: in Microsoft 365, set the outbound spam policy's automatic forwarding to Off (blocked forwards return NDR 5.7.520), or On with remote domains restricting destinations. This stops an injected agent creating a forwarding rule as a persistent exfiltration path, the ATT&CK technique T1114.003 Email Forwarding Rule.
Never grant settings scopes: mailbox settings and delegation scopes (MailboxSettings.ReadWrite, gmail.settings.basic, gmail.settings.sharing) let an agent create rules, filters or delegates that survive the session.

Filtering and isolating inbound content

No filter reliably removes prompt injection; EchoLeak bypassed a classifier, link redaction and a content security policy. Defence relies on limiting what injected instructions can achieve, with filtering as one layer.

Layer	Control	What it stops
Pre-processing	Strip hidden HTML (zero-size text, white-on-white, comments), convert to plain text, drop remote images	Instructions invisible to the human reader
Provenance	Mark content from external senders as untrusted data in the prompt and never concatenate it into system instructions	The model treating email text as operator instructions
Capability	Agent that reads external mail has no send, forward, delete or settings tool	Injection turning into action
Output	Block or rewrite URLs and Markdown images in agent output; do not auto-render links	Data exfiltration through fetched URLs, as in EchoLeak
Data scope	Restrict what the agent can retrieve alongside the email (no access to unrelated mailboxes or document stores)	An injected email pulling in other sensitive data
Approval	Human confirmation for any send, forward or external share	Silent exfiltration

MITRE ATLAS catalogues this as AML.T0051.001 LLM Prompt Injection: Indirect. For the broader defences see the Prompt Injection Guide and the OWASP LLM Top 10 LLM01 Prompt Injection Guide; lessons from real incidents are collected in the Prompt injection data theft guide.

Logging and detection

Google OAuth log events: found under Reporting, Audit and investigation, OAuth log events. They record app authorisations and revocations with OAuth client ID, scopes and product, and API calls with method name, plus user, IP address, client type, response size and whether an AI agent performed the action. API call events are limited to Enterprise Plus, Education Plus, Enterprise Standard, Education Standard and Cloud Identity Premium.
Microsoft MailItemsAccessed: part of Audit (Standard), covering POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST. Bind events record each message by InternetMessageId, aggregated into two-minute records; sync events mark a whole folder. Use it to establish what an agent identity actually read, and to scope impact after an incident.
Agent-side logs: record every tool call (search queries, message IDs read, recipients, attachment names) with the agent identity and the user it acted for. Platform logs show access; only the agent log shows why.
Forwarding visibility: review the Microsoft 365 Auto forwarded messages report and alert on new inbox rules or forwarding settings created by an application identity.

Signal	Why it matters
Agent reads mailboxes outside its expected set	Scoping failure or token misuse (T1528, T1550.001)
Spike in messages bound by the agent identity	Bulk collection after an injection (T1114.002 Remote Email Collection)
Agent sends to a first-time external domain or adds BCC	Exfiltration, as in the postmark-mcp case
Inbox rule or forwarding created by an app	Persistence (T1114.003)
New OAuth grant adding send or full-access scopes	Permission drift

Metrics: percentage of email agents with mailbox-scoped rather than tenant-wide grants (target 100%); number of agents holding both read and send on external mail (target zero); share of agent sends requiring human approval; mean time to revoke an agent grant during an incident; days since last review of domain-wide delegation clients and Graph application mail permissions.

Implementation steps

Inventory: list every OAuth client, service principal and domain-wide delegation client holding mail scopes, and tag those used by agents. Start from the Graph high-privilege permission review and the DWD client list.
Classify each agent: read-only, draft-only or send. Record the mailboxes and recipients it needs.
Re-grant narrowly: move Microsoft application grants to RBAC for Applications scopes and remove the Entra tenant-wide permission; replace Google full-access scopes with metadata, readonly or send as appropriate.
Pilot: run the re-scoped agent in a test group of mailboxes, verify with Test-ServicePrincipalAuthorization and a set of injection test emails (hidden text, instructions to forward, link-rendering bait).
Turn on detection: confirm MailItemsAccessed and OAuth log events are flowing to the SIEM and the five signals above have alerts.
Roll out by mailbox group, keeping the old grant disabled rather than deleted for one cycle so you can roll back quickly if workflows break.
Review quarterly: recertify each agent's scopes and mailbox set. See the Agent Permission Drift guide.

Common failure patterns

Trusting a third-party mail tool: the postmark-mcp malicious MCP server added one hidden BCC in version 1.0.16 and copied every email agents sent through it to an attacker, using the victim's own credentials. Pin and review mail tools; see the MCP Server Trust Assessment.
Scoping in RBAC but leaving the Entra grant: because permissions are additive, the agent keeps tenant-wide access and the scope is cosmetic.
Granting full access "to be safe": https://mail.google.com/ or Application Exchange Full Access for an agent that only summarises, giving deletion, send and settings rights that injection can use.
One identity for read and send: the OWASP LLM06 scenario in production: a malicious inbound email instructs the agent to search and forward.
Rendering agent output with live links: EchoLeak's exfiltration relied on images and links being fetched automatically from allowed domains.
No agent identity in logs: agents running under a human's token or a shared service account make MailItemsAccessed and OAuth logs unable to separate agent actions from user actions.

Framework mapping

Framework	Reference	Application to email agents
OWASP LLM Top 10 2025	LLM01 Prompt Injection; LLM06 Excessive Agency	Inbound email as indirect injection; read-only scopes, no send function, human approval
MITRE ATLAS	AML.T0051.001	Indirect prompt injection through email content
MITRE ATT&CK v20	T1114.002, T1114.003, T1528, T1550.001	Remote email collection, forwarding rules, application token theft and use
NIST SP 800-53 Rev. 5	AC-6, AC-4, SI-10, AU-12, CA-7	Least privilege, information flow limits on send, input validation, audit record generation, continuous monitoring
NIST CSF 2.0	PR.AA-05, DE.CM-09	Least privilege permissions reviewed; monitoring of software and data for adverse events

Practitioner checklist

Inventory every agent with mail scopes on both platforms and name an owner for each.
Separate read and send identities; no agent that reads external mail can send without human approval.
Use Mail.ReadBasic or gmail.metadata where bodies are not needed.
Scope Microsoft application grants with RBAC for Applications and remove the Entra tenant-wide permission; verify with Test-ServicePrincipalAuthorization.
Limit Google domain-wide delegation to the fewest clients and scopes, with multi-party approval where available.
Enforce recipient allow-lists, BCC blocking and send rate limits in the send tool.
Block external automatic forwarding and alert on app-created inbox rules.
Strip hidden content and disable automatic link and image rendering in agent output.
Stream MailItemsAccessed and OAuth log events to the SIEM with alerts on the five signals above.
Recertify agent scopes and mailbox sets every quarter.

AI Agent Email Access Security: Scopes, Send Limits and Injection Defences