Secure an AI agent connected to Gmail or Outlook

Why is a mailbox agent high risk?

Because a mailbox brings together the three ingredients of a prompt injection attack: private data, content written by third parties, and a way to communicate outward. Developer Simon Willison calls this combination the "lethal trifecta": an agent that accesses private data, reads untrusted content and can communicate externally can be manipulated into leaking that data.

Anyone can email you. If your agent reads the message and has a send, forward or mailbox-search tool, a booby-trapped message can give it instructions. This is indirect prompt injection (OWASP LLM01:2025), covered on our prompt injection page.

Examples of what a malicious email may attempt:

• ask the agent to forward the latest messages containing "invoice" or "password" to an external address;
• make it reply to a thread with a trapped link, from the user's legitimate address;
• make it create a forwarding rule or delete messages;
• make it summarize an attachment that carries hidden instructions.

Which OAuth scopes should the agent get?

Give the narrowest scope that allows the task, and nothing else. An agent that sorts or summarizes does not need to send; an agent that drafts replies does not need to delete.

On the Google side, the Gmail API documentation sorts scopes into sensitivity categories:

Two takeaways. First, mail.google.com gives full access and should be avoided for an agent. Second, a read-only scope is enough for most triage, summary or suggested-reply agents, as long as sending goes through a separate path.

On the Microsoft side, the equivalent Graph permissions are Mail.ReadBasic (read without body, preview or attachments), Mail.Read, Mail.ReadWrite (no sending) and Mail.Send. The critical point: in application mode (no signed-in user), Mail.Read opens reading of all mailboxes in the organization and Mail.Send allows sending as any user.

How do you limit the agent to certain mailboxes in Microsoft 365?

Use RBAC for Applications in Exchange Online, which pairs a permission with a scope of mailboxes (a management scope or an administrative unit). Microsoft states that this feature replaces Application Access Policies.

Microsoft documents a trap worth testing: permissions granted in Microsoft Entra ID and those from RBAC for Applications add up. If the app keeps an unrestricted Mail.Read in Entra ID, your RBAC scope does nothing. You must remove the organization-wide grant in Entra ID. The Test-ServicePrincipalAuthorization cmdlet lets you check, mailbox by mailbox, what the application can really do.

For an agent acting on behalf of one user, prefer delegated permissions: the agent then only reaches the mailbox of the person who gave consent.

How should email content be handled?

Treat every email, subject, body and attachment as untrusted input, never as an instruction. The model cannot reliably tell a legitimate instruction from text that looks like one; the separation has to come from the architecture.

Concrete measures:

1. Fence the content. Pass the message in a block explicitly marked as data, and tell the model never to execute orders found inside. This helps but is never enough on its own.
2. Reduce what the agent reads. If subject and sender are enough to sort, do not send the body.
3. Handle attachments separately. A document converted to text can contain instructions invisible on screen (white text, metadata, comments).
4. Ignore external senders for sensitive actions. Instructions from an outside domain carry no authority.
5. Split reading from acting. A first component reads and produces structured output (category, summary, draft). A second, with no access to the raw text, decides on the action.

How do you control sending and write actions?

Require human approval for every send, forward and delete, and enforce these limits in code, outside the model. OWASP phrases it this way for Excessive Agency (LLM06:2025): enforce authorization in downstream systems and ask for human approval on high-impact actions.

Useful controls:

• Drafts only. The agent creates a draft; the user reviews and clicks send.
• Recipient or domain allowlist, checked by the code that calls the API.
• No external links or images generated by the agent in outgoing messages without review.
• Send cap per hour and per day, to limit the damage of a hijack.
• Ban forwarding rules and mailbox settings changes.
• Full log: every read, draft and send, with the ID of the message that triggered it.

Which tests should you run before go-live?

Send yourself booby-trapped emails from an external account and watch what the agent does, in the API logs rather than in its reply. The list below covers the most rewarding cases.

Use test accounts and mailboxes you control only. Our method describes how we structure these scenarios.

How do you monitor and revoke access?

Monitor the agent's actions separately from the user's, and plan a way to cut access within minutes. Use a dedicated account or application so the logs clearly separate what the agent does.

• Store OAuth tokens in a secrets manager, never in the prompt or in the model's context.
• Alert on abnormal volumes: number of reads, sends, new recipients.
• Document the revocation procedure: where to withdraw consent, who can do it, how fast.
• Review consents whenever the agent gains a feature.

What should you remember?

Start with the narrowest configuration and widen it only when a concrete use case demands it, with a written reason for each new permission. The risk of a mailbox agent depends on what it is allowed to do rather than on the quality of the model. Reduce scopes, bound the reachable mailboxes, isolate email content and keep a human in front of sending. For the full picture, see our guide to AI agent security.

If you want a third party to attack your mailbox agent before your users do, the Agent Red Team Express maps its access and tests these scenarios over 5 days for 1,900 EUR.