Is It Safe to Give an Email Client Access to Your Gmail?

Is it safe to give an email client access to your Gmail account? For most vetted apps, yes — the connection uses OAuth, not your password, and the scope you approve caps exactly what the app is allowed to do. But 'most vetted apps' is doing real work in that sentence, and the gap between a client that can only read your mail and one that can send, delete, or manage your account settings is a single line on a consent screen you probably clicked through without reading.

This is written for the moment right before you click Allow: what a Gmail OAuth grant actually hands over, what it doesn't touch, and the specific things worth checking about any vendor before you connect a second inbox — let alone a work one you're evaluating as part of switching email clients entirely.

What actually moves and what doesn't#

Connecting an email client to Gmail isn't a migration in the way switching providers is. Your mail stays on Google's servers. Your password never leaves Google, either — the client never sees it. What actually happens is that Google issues the client an OAuth access token: a scoped, revocable credential that states exactly which parts of your account it can touch, and nothing else.

That token is the entire grant. It doesn't move your account, your recovery phone number, your two-factor settings, or your other Google services. Gmail access and Calendar access are separate scopes, requested and revoked independently — a client holding gmail.modify has no more visibility into your Drive files than a stranger walking past your desk. The access token itself is also short-lived; the client's real credential is a longer-lived refresh token it uses to quietly request new access tokens, which is exactly why revoking access in one place — rather than deleting an app or clearing cookies — is the only reliable way to cut it off.

The scope itself comes in three practical tiers most email clients request, and the difference between them is the whole risk conversation. A fourth, narrower scope exists too — gmail.metadata, which exposes headers and labels but never message bodies — though few consumer clients use it, since it can't power search or AI features that need to read what mail actually says.

• gmail.readonly — read messages, threads, and labels. Cannot send, delete, or change anything.
• gmail.modify — read, send, archive, label, and trash mail. Cannot permanently erase messages or manage account-level settings like filters and forwarding, which live under separate gmail.settings.* scopes.
• https://mail.google.com/ ("full mail") — everything modify allows, plus permanent deletion and account settings. Functionally, this is the same level of control you have logging in directly.

Before you connect: a five-minute vetting checklist#

Which of those three tiers a client is requesting is visible on the consent screen before you approve anything — Google sometimes collapses it under 'See details,' so click through rather than trusting the one-line summary. That scope, plus a few minutes checking the vendor, is most of the due diligence this decision actually needs.

• Minimum scope. If the app only reads and summarizes mail, a request for modify or full access is a red flag, not a convenience. If it drafts and sends on your behalf, modify is the expected floor — full mail access should still prompt a question.
• A published security page. A vendor should state, in writing, how mail is stored, whether message content trains any model, and how long data is kept after you disconnect. Vague language like 'industry-standard security' with no specifics is itself a data point.
• A verification or assessment signal. For apps requesting broader Gmail scopes, look for language about Google's OAuth verification and, separately, Google's CASA (Cloud Application Security Assessment) program — an annual third-party security review Google requires for apps handling sensitive mail data, not a badge a vendor invented itself.
• A one-click revoke path. Every OAuth grant can be pulled from myaccount.google.com/permissions regardless of what the vendor's own settings page offers. If a vendor says to email support to disconnect, that's a design choice, not a technical limit.
• No password field, anywhere. A client that asks you to type your Gmail password into its own form — instead of redirecting you to a google.com address — isn't using OAuth at all.
• A stated position on human approval. If the app can act autonomously — sending, replying, deleting — ask whether there's a mode that drafts for your review first. A vendor that can't answer that question hasn't thought about the failure case.

How to read a consent screen before you approve it#

The checklist above tells you what to look for. This is the five-minute routine for actually looking, the first time you connect a new client and every time after.

1. 1

   Open the expanded permissions view

   Google's consent screen often collapses scopes under 'See details' or an arrow. Expand it — the one-line summary hides which of the three access tiers you're granting.

2. 2

   Match the request to a scope tier

   Compare the description against the readonly / modify / full-mail breakdown above. A client asking for full mail access to power a feature that clearly only needs to read subject lines has over-scoped its request.

3. 3

   Note whether Google flags the app as unverified

   An interstitial reading something like 'Google hasn't verified this app' means the vendor hasn't finished Google's review yet. It doesn't automatically mean the app is unsafe, but it does mean you're trusting the vendor's own word instead of Google's — check their security page first.

4. 4

   Approve, then confirm what actually registered

   Right after connecting, open myaccount.google.com/permissions and confirm the scope listed matches what you meant to approve. Mismatches are rare, but this is the one place to catch them.

5. 5

   Put a recurring check on your calendar

   Set a reminder every six months to review everything listed on that page. Access granted once tends to be forgotten, not out of malice — nothing ever prompts a second look.

What each Gmail scope actually lets a client do#

The three tiers aren't just consent-screen language — they map to concrete differences in what a compromised or careless client could do with your inbox.

This is why the requested scope matters more than almost anything else on this page. A note-taking or CRM integration that only needs to confirm which emails exist has no legitimate reason to ask for full mail access — and a client that does, for a feature that plainly doesn't need it, has either over-scoped out of laziness or is building toward something it hasn't told you about yet. gmail.metadata is worth knowing about specifically because it's the honest answer to 'what can an email client actually see in my inbox' for the narrow category of tools — mostly analytics and CRM sync — that never need to read what your mail actually says.

How to revoke access if you change your mind#

Unlike an app password, an OAuth grant has a single canonical off switch that works no matter what the vendor's own settings page offers you.

1. 1

   Go to myaccount.google.com/permissions

   This page lists every third-party app and service with any access to your Google account, independent of which app you're currently looking at.

2. 2

   Select the app and remove its access

   This invalidates the OAuth token immediately — the client's next API call fails, wherever it's running.

3. 3

   Check Gmail's own account activity

   In Settings, or the security panel for a Workspace account, confirm there's no other lingering grant from the same vendor under a different name.

4. 4

   Ask about data already synced

   Revoking the token stops future access; it doesn't reach back and delete copies the client already made for search, AI features, or caching. Ask for a data-deletion confirmation separately if that matters to you — a vendor's own privacy page should say how long that takes and what it covers.

5. 5

   On a work account, loop in IT

   A Workspace admin can also block the app domain-wide from the Admin console — worth doing if you connected it before a company policy existed, or if the account being disconnected is shared rather than personal.

Testing the connection without disrupting your inbox#

Nothing about approving an OAuth token disrupts your existing mail flow — Gmail keeps working exactly as it did the moment before you clicked Allow, so there's no real migration window to protect. Use that slack to test lightly before you commit fully:

• Connect a secondary or throwaway address first, if the client supports adding one later, and run a few days of low-stakes mail through it.
• Keep gmail.com open in another tab for the first week. Connecting a client doesn't disable the web interface — you always have a fallback.
• Start in a mode that drafts for your approval rather than one that acts on its own. Most AI email tools distinguish the two; approve by hand until you trust the pattern.
• Pilot on your own inbox before a shared or delegated one. A team mailbox multiplies the blast radius of a misconfigured scope.
• Watch how the client behaves the first time it hits an edge case — an ambiguous reply, an attachment it can't parse, a sender it doesn't recognize. How it fails tells you more than a week of routine mail does.

Where AI Emaily fits#

AI Emaily requests gmail.modify, not the broader full mail scope — enough to triage, label, draft, and send on your behalf, not enough to permanently erase mail or rewrite your account settings. Stored OAuth tokens are envelope-encrypted at rest, and message content isn't used to train any model. The same connection model applies whether the account is Gmail, Outlook, or a plain IMAP mailbox — the scope conversation above isn't Gmail-specific, it's what to ask any vendor.

Every send in Copilot mode, the default, waits for your explicit approval before it leaves your account, with an undo window and an audit trail on what the agent actually did — nothing goes out on its own unless you turn that off. We're pursuing Google's CASA Assessment Level 1 certification for the gmail.modify scope; it isn't complete yet, and we'd rather say that plainly than imply a badge we don't hold. We build AI Emaily.