Is It Safe to Give an AI Agent Access to Your Inbox?

It depends entirely on what "access" means, and most people never check. The OAuth prompt that connects an AI tool to Gmail or Outlook almost always requests read, send, and delete in one grant, because that's the permission tier the provider's app marketplace requires for full functionality, not because your actual task needs all three. The real question isn't whether to connect an agent to your inbox. It's which of those permissions it actually needs, and whether you looked before clicking allow.

What "inbox access" grants by default

Connect almost any AI email assistant and, unless you go out of your way to restrict it, you've handed over:

• Read access to every message, not just the ones relevant to the task, including anything already in the inbox: old contracts, password reset links, other people's forwarded threads.

• Send access under your identity. A message the agent sends looks, to the recipient, identical to one you sent yourself. There is no visual distinction on the other end.

• Delete or archive access, which most tasks never require and which turns a misfire from an annoyance into data loss.

• Standing access that outlives the task. A one-time "summarize my unread emails" request often leaves a token that keeps working indefinitely, until you manually revoke it.

The permission-scoping checklist

Before connecting anything, work down this list and grant only what the task in front of you actually needs:

1. Read-only for anything that summarizes or triages. Summarization, priority-flagging, and drafting suggestions for your review all work fine on read-only access. Send is a separate grant; don't bundle it in by default.

2. Draft mode instead of send mode. Route agent-composed replies to the Drafts folder. You click send. This one change removes the entire class of failure where the agent sends something wrong.

3. Scope by folder or label, not the whole mailbox. Most providers support this. An agent handling support triage needs the support label, not your legal correspondence.

4. No delete or purge permission, ever, with one narrow exception: a dedicated spam-cleanup tool that logs every action it takes and that you reviewed specifically for that purpose.

5. A separate alias or shared inbox for anything agentic and high-frequency, rather than your personal or primary business address. This bounds the blast radius and makes the audit trail obvious.

6. A token you actually revisit. Check your account's connected-apps page every few months. Tokens outlive the task that created them far more often than people expect.

A common shape of failure

Here's the pattern that shows up most often when send access is granted too early. An agent is given full inbox access to "help with client email." A client thread has pricing mentioned twice: an early message with an outdated number, and a later one with the corrected figure. Asked to draft a reply, the agent pulls from whichever message ranks as more relevant to the immediate question, not necessarily the most recent one, and sends the outdated price directly to the client. Nobody reviewed it first, because the whole point of granting send access was to skip that step.

The fix isn't a smarter agent. It's not skipping the step: draft mode catches this exact failure before it reaches a client, at the cost of one click per message.

The bundled permissions nobody checks

Inbox OAuth grants rarely stop at the inbox. The same consent screen that connects an agent to your email often bundles calendar access, contacts, and sometimes Drive or file storage, because the provider's permission tiers are coarse and the app developer took the broadest one available rather than requesting each scope individually. Read the actual scope list on the consent screen, not just the tool's marketing description of what it does. A tool that says "reads your email to summarize your day" may also be requesting write access to your calendar and your full contact list, neither of which a summarization task needs.

This matters more than it sounds like it should, because contacts and calendar access compound the inbox risk rather than sitting next to it. An agent that can read your contacts can address a message convincingly to someone you actually correspond with; one that can write to your calendar can plant a meeting invite that looks native to your workflow. Treat the bundle as a whole when deciding what to approve, not as one email permission plus some harmless extras. If calendar access is part of the bundle, the same staged-trust approach applies there too; see our breakdown of letting an AI agent manage your calendar.

If you're a solo founder who just wants help with email

Add capability in stages rather than granting everything on day one. Start with read-only summarization and triage, which is genuinely useful and close to zero-risk. Add draft-mode composition once you've seen enough drafts to trust its judgment on tone and facts. Hold send permission until you have a real track record, and even then, scope it to a specific folder or a specific kind of message rather than the whole inbox. This is the same staged-trust pattern worth applying anywhere you connect an agent to something that acts on your behalf; see our take on connecting AI to your bank account for the financial-access version of the same argument.

The same permission-scoping questions apply to social platforms as to your inbox — read-only access and posting access carry very different risk, a distinction is it safe to let an AI agent manage your social media accounts works through in detail.

Frequently asked questions

Is a "read-only" OAuth scope always actually read-only?

Check the exact scope name, not the marketing description. Gmail's read-only scope (gmail.readonly) is genuinely read-only. Some third-party tools request the broader gmail.modify or full mail scope and describe it in their UI as "read your emails," which is technically true but omits that the same grant allows writing and deleting too.

What about AI features already built into my email client?

The same logic applies, just with less visibility into what was granted, since you didn't go through a separate OAuth flow. Check your provider's AI settings for what the built-in assistant can do (draft, send, categorize, delete) and turn off anything beyond what you actually use.

Does two-factor authentication on my email protect against this?

No. Two-factor authentication protects against someone logging into your account without permission. An AI agent with a valid OAuth token isn't logging in, it's using a grant you already approved, and 2FA has nothing to check at that point.

Can I see what an AI agent has actually done in my inbox after the fact?

Only if the tool provides its own activity log, since most email providers don't distinguish agent actions from your own in the native activity log. Before granting send access to anything, check whether the tool has an audit trail you can review. If it doesn't, that's a reason to stay in draft mode regardless of how much you trust it. For the wider set of practices on what to let an agent touch versus review, see our guide to sandboxing an AI agent.

For more on the boundaries worth drawing before you connect an agent to anything, see our AI safety and risk coverage.

The same scoping logic applies to any other account-level system you connect an agent to. See our take on letting an AI agent manage your DNS settings for a different high-stakes example of the same permission problem.

For the specific 2FA-hijack angle of mailbox access, where reading alone is enough to reset other accounts, see our companion piece on whether it is safe to let AI read your email.

For the exact scope names behind these permission tiers, see Google's Gmail API OAuth 2.0 scopes reference.