Can an Agent Safely Use Your Gmail or Outlook Mailbox?
An AI agent can safely use your Gmail or Outlook inbox to read and draft. What the OAuth grant covers, why inbound mail is the risk, and when it needs its own inbox.
- engineering
- security
- gmail
- outlook
- ai-agents
TL;DR
Connecting an AI agent to a person's Gmail or Outlook mailbox is safe for some jobs and risky for others. This article explains what the permission screen actually hands over, why mail from strangers is the part that goes wrong, and what happens to the account when the agent sends. By the end you will know which agent jobs belong in a person's mailbox and which need an inbox of their own.
Most email agents start life inside somebody's real mailbox. A developer wires up an assistant, clicks through an OAuth consent screen, and the agent can suddenly read years of mail. It works on the first try, so nobody looks at the grant again.
The consent screen says "read, compose, and send." It doesn't say who else gets to talk to the agent. Any stranger who knows the address can now put text in front of it. The agent reads that text with the owner's access. When the agent sends, it sends as that person, under that person's limits, on that person's domain.
The sections below cover what the grant allows and where the risk comes from. Then they cover what the account absorbs when the agent sends, and give a job-by-job rule for when a normal inbox is fine.
Is it safe to connect an AI agent to a person's mailbox?
It is safe when the agent reads and drafts for one person and a human approves every send. The grant should be the narrowest one that does the job. It stops being safe once the agent acts alone, sends at volume, or answers mail from people nobody vetted. At that point the grant covers the whole mailbox and the account's standing, and a mistake lands on a real person.
A normal inbox here means a mailbox a human already uses: a Gmail or Google Workspace account, or an Outlook or Microsoft 365 mailbox. Both APIs work. What matters is what the agent can reach when something goes wrong, and who pays for it.
What does an inbox grant actually let the agent do?
An inbox grant is an OAuth scope, the permission string your app asks for on the consent screen. Gmail's scopes come in three tiers, and almost everything an agent needs sits in the strictest one.
Google lists gmail.readonly, gmail.compose, gmail.modify and full mail access as restricted Gmail API scopes. Restricted means wide access to the user's data and a heavier verification review. If your servers store or transmit data from those scopes, Google requires a security assessment. Sending alone, gmail.send, is a sensitive scope. There is no Gmail scope that means "read only the mail about invoices."
Microsoft 365 adds a sharper edge. A Graph application permission, the kind a background agent uses with no signed-in user, is tenant wide. Microsoft describes Mail.ReadWrite as access to email "in all mailboxes without a signed-in user." Mail.Send sends "mail as any user." That includes the CEO.
An admin can narrow both with RBAC for Applications in Exchange Online. The catch is in Microsoft's own FAQ. Grants from Entra ID and Exchange add together. An unscoped Mail.Read left in Entra plus a scoped one in Exchange "results in no effective resource scoping."
In practice the grant is the mailbox. Whatever the agent is told to do, the token can do everything the scope allows, on every message the account holds.
Why is mail from strangers the real risk?
Email is untrusted input. Anyone who knows an address can put text in front of the agent, and the agent reads it as part of its context. Prompt injection, an email written to make the agent follow the sender's instructions instead of yours, needs nothing more than that.
Imagine a support assistant connected to a founder's Gmail. A message arrives that looks like a vendor notice and asks the agent to forward the last three invoices to an outside address. The agent holds gmail.modify, so it can read the invoices and send the forward. Nothing in the grant tells it the request is hostile.
In a dedicated agent inbox with an inbox-scoped key, the same message reaches an agent that can only see its own conversations. In a person's mailbox, it reaches an agent that can see that person's contracts, password resets and private threads. The injection is the same. What it can reach is not.
Models also handle suspicious mail differently. Our AI agent email security evals found most of them replied to mail flagged as spam, while Claude mostly held back. A model default is not a control you own, so the inbox setup has to limit the damage on its own.
What happens to the account when the agent sends as you?
Every message the agent sends counts against the person's account and carries their name. Google Workspace allows 2,000 messages per user per day on paid accounts and 500 on trial accounts, per Google's sending limits page. After hitting a limit, the user can't send new mail for up to 24 hours.
The worse outcome is on the same page. Google says a user who exceeds sending limits might have the account suspended, and accounts that send spam might be permanently restricted from sending. For an agent, that means one bad loop locks a person out of their own mail. The triggers and the recovery steps are in our guide on what to do if Gmail bans your AI agent.
Reputation is the slower cost. Mailbox providers track sender reputation per domain. An agent that sends badly from a work address drags down every human on that domain. The people who never touched the agent pay for it too.
Which agent jobs can safely use a normal inbox?
The job decides the setup. Read the row that matches what your agent does, not what it might do later.
| Agent job | Normal inbox? | Minimum safe setup |
|---|---|---|
| Summarize and triage one person's mail | Yes | Read-only scope, no send scope, owner reviews output |
| Draft replies a person sends | Yes, with care | Drafts only, a human presses send every time |
| Reply to customers on its own | No | Own inbox, sender allowlist, injection screening |
| Sign up for services or receive codes | No | Own inbox per agent, no human history inside |
| Many agents or many customers | No | Inbox per agent, scoped keys, separate domains |
The line falls where the agent starts acting without a person in between. Read and draft: a normal inbox works. Send alone or talk to strangers: give the agent its own address.
How do you give the agent its own inbox with tight limits?
An agent inbox is a mailbox that belongs to the agent instead of a person, so its blast radius is its own mail. On AgentMail you can also limit who reaches it. Lists are allow and block rules on an inbox. A receive allowlist marks mail from anyone else as blocked. A send allowlist refuses sends to anyone else.
Python
# agentmail==2.0.22: only accept mail from, and only send to, one trusted domainimport osfrom agentmail import AgentMailclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])inbox_id = os.environ["AGENTMAIL_INBOX_ID"]for direction in ("receive", "send"): entry = client.inboxes.lists.create(inbox_id, direction, "allow", entry="example.com") print(entry.direction, entry.list_type, entry.entry, entry.entry_type)# output: receive allow example.com domain# output: send allow example.com domainBlocked inbound mail is still stored, with a blocked label, but it fires message.received.blocked instead of message.received. An agent that reacts to message.received never sees it. A blocked send comes back as a 403 with message_rejected. No email goes out.
Approval is the second control. The agent writes the reply as a draft. A person sends it.
Python
# agentmail==2.0.22: the agent writes the reply as a draft and a person sends itimport osfrom agentmail import AgentMailclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])inbox_id = os.environ["AGENTMAIL_INBOX_ID"]draft = client.inboxes.drafts.create( inbox_id, to=["customer@example.com"], subject="Re: Refund for order 4417", text="Hi Dana, your refund is approved and is on its way back to your card.",)print(draft.labels, draft.subject)# output: ['draft'] Re: Refund for order 4417Approval should hold even if the agent misbehaves. Give the agent an inbox-scoped API key whose permissions include draft_create and message_read, and leave out draft_send and message_send. Once a key carries a permissions object, anything not set to true is denied. The reviewer's tool holds the key that can send. The human-in-the-loop email agent build walks through the review side in full.
When is a normal inbox the right call?
Use a person's mailbox when the agent's job is that person's existing mail. Summarizing a founder's inbox, finding last quarter's contract, drafting replies inside threads that already exist: none of that works from a fresh address. If that is the product, use the Gmail API or Microsoft Graph directly, or a unified API like Nylas across both. Keep the grant at the narrowest scope the job allows.
The Gmail route has its own setup costs and limits, which we cover in Gmail MCP server setup and limits. You can also run both: the assistant reads the person's mailbox, and anything the agent sends on its own goes out from an agent inbox. More posts on agent email design are on the AgentMail blog.
What AgentMail does not do
AgentMail cannot read or act on a person's existing Gmail or Outlook history, because an agent inbox starts empty. Agent Armor, our prompt-injection scanner in AgentMail Labs, marks suspicious mail for review, and its verdicts are advisory rather than a guarantee. Your app still owns the action policy. That means what the agent may do with a message, when a human must approve, and what happens when a verdict is unavailable.
