What an App Can Actually Do With Gmail Access
The short answer
Granting Gmail access hands an app a scope, not a blanket permission — from read-only, to modify (read, compose, send, label, trash, but not permanent delete), to full mail.google.com access with IMAP. The scope named on the consent screen is the ceiling on what the app can ever do, enforced by Google rather than by the app's own promises.
What an app can do once you grant Gmail access — read, modify and send scopes explained, and how to read the consent screen before approving one.
On this page
What does an app get when you grant Gmail access? Never your password, and never full access unless the scope you approve is the one that has it. Every Gmail integration runs on a scope — a defined slice of your account that Google enforces on the app's behalf, from read-only to full read, send and delete.
The consent screen names that scope for you, in Google's own wording, but the wording is easy to skim past. This guide breaks down what the common Gmail scopes actually permit, how to read a permission request before you click Allow, and what changes if your account sits inside a Google Workspace domain instead of a personal one.
None of this is theoretical. A scheduling tool, a CRM sync, and a browser extension you installed for one unrelated reason can all end up holding a grant on the same mailbox, at different tiers, and most people never look at the list until something goes wrong. Reading the scope once, at the moment you approve it, is the cheapest version of that check.
The short answer#
Gmail OAuth access comes in a few practical tiers, and the phrase Google shows you tells you which one an app is asking for.
- Read-only (gmail.readonly): the app can see your messages, labels and attachments. It cannot send, delete or change anything.
- Modify (gmail.modify): the app can read, compose, send, label and move messages to trash. It cannot permanently delete mail or access your account the way a signed-in browser session can.
- Send-only (gmail.compose / gmail.send): the app can send or draft email as you but cannot read your inbox at all — the profile for a service that only fires transactional messages.
- Full account access (mail.google.com/): the broadest scope. It grants everything above, plus IMAP/SMTP-level access and permanent deletion. Very few consumer apps should ever need to request this one.
Before you start: how Gmail scopes actually work#
Google groups every scope into one of three sensitivity tiers, and the tier determines how hard it was for the developer to get your consent screen approved. Non-sensitive scopes — your name, your email address — need no review. Sensitive scopes, which cover most Gmail read access, require Google to verify the developer's identity and stated use.
Restricted scopes — gmail.modify, gmail.send and mail.google.com among them — need that verification plus an independent security assessment of the app itself before Google will let it request them from the public. None of this involves your password at any point.
OAuth's entire design point is that the app never sees your Gmail credentials. It receives a token scoped to specific actions, and that token can be revoked from your Google Account at any time without touching your password. If an app asks you to type your Gmail password directly into its own form instead of redirecting you to a google.com sign-in page, that is not OAuth, and it is not how a legitimate integration works.
The consent screen's plain-language line — something like 'Read, compose, send, and permanently delete all your email from Gmail' — is Google's own summary of the scope, not marketing copy from the developer. It is worth reading literally. It is the actual ceiling on what the app can do to your account, not an approximation of it.
The password test
Steps: how to read a Gmail permission request before you approve it#
- 1
Check who's actually asking
Look at the app name and the domain printed in small text underneath it, not just the logo. A generic name paired with an unfamiliar domain is a signal to search the developer separately before continuing.
- 2
Read every scope line, not the app's tagline
The consent screen lists each permission on its own line, in Google's own wording. Apps commonly bundle three or four scopes together, and the one you actually care about might be the third line down, not the first.
- 3
Match the wording to a real tier
'View your email messages' is read-only. 'Read, compose, send, and permanently delete' is the broad mail.google.com scope. 'Send email on your behalf' without a read verb is send-only. The exact verbs tell you which tier above you're actually granting.
- 4
Look for the unverified-app warning
If Google shows an interstitial reading 'This app isn't verified,' the developer hasn't completed review for the scopes it's requesting. That isn't automatic proof of a scam, but it does mean Google hasn't checked the app's security practices — treat it as a reason to research the developer, not a reason to click through on habit. Small, unpublished tools sit here for legitimate reasons too, so the warning is a prompt, not a verdict.
- 5
Ask whether the scope matches the job
A read-it-later app that requests gmail.modify instead of gmail.readonly is asking for more than it needs to function. A narrower request for the same feature is the better sign — most well-built integrations only request what their actual feature uses, and a developer who asks for less is usually a developer who thought about it.
- 6
Approve, then verify what stuck
After granting access, open myaccount.google.com/permissions and find the app in the list. The scopes shown there are what was actually granted — confirm they match what you thought you approved before you move on, and note the date, so a scope change later stands out against it.
Personal Gmail vs Google Workspace access#
The scope system itself is identical on a personal Gmail account and a Google Workspace (business) account, but who controls the grant is not.
| Personal Gmail | Google Workspace | |
|---|---|---|
| Who can approve the grant | You, alone | You — unless an admin has restricted it |
| Admin override | None | Admins can allow-list or block specific apps and scopes across the whole domain |
| Unverified-app warning | Shown to you directly | Can be pre-approved and suppressed for internal or admin-trusted tools |
| Restricted-scope review | Google's standard verification and security assessment | Same, plus the org's own internal app-approval process where one exists |
| How to revoke | myaccount.google.com/permissions | Same page, or an admin can revoke it org-wide from the Admin console |
| Bulk review across every account | Not applicable — one account at a time | Admin console lists every third-party app granted access across the whole domain, in one screen |
What to do when it doesn't work#
If you're on a Workspace account and a third-party app can't get past the connection screen, the most common cause isn't a Google outage — it's an admin having restricted that scope for the domain. Check with whoever manages your Workspace before assuming the app itself is broken.
Sync breaks right after you 'cleaned up' your connected apps. Revoking an app's access at myaccount.google.com/permissions takes effect within minutes, and the app has no way around it. If you meant to revoke a different app, re-approve the one you actually use and it will reconnect normally.
You don't recognize an app in your permissions list. This happens most often from an old 'Sign in with Google' grant from years ago, or from a browser extension that requested Gmail access during setup and was forgotten. Revoke anything you can't explain — a legitimate app will simply prompt you to reconnect.
An app asks you to re-approve after already having access. Google requires a fresh consent screen whenever a developer adds a new scope to an existing integration; it cannot silently expand what it already has. Treat a surprise re-approval prompt as a moment to read the screen again, not a formality to click past.
You want less access than you already granted, but revoking the app entirely would break a workflow you rely on. Some apps let you narrow permissions from inside their own settings and re-run the Google consent flow with a smaller request — check the app's own privacy or connections page before assuming all-or-nothing is the only option.
An app you never touched asks you to sign in again, out of nowhere, exactly a week after you connected it. If the developer hasn't finished Google's verification yet, Google lists the app under 'Testing' status, and tokens issued to a testing app expire after seven days by design. That's Google's policy, not a sign the app was compromised — the fix is simply to reconnect, and it will keep happening on that schedule until the developer publishes it.
A faster way: how AI Emaily's own Gmail access works#
Everything above is worth doing for any app, including ours. AI Emaily connects to Gmail through the gmail.modify scope — read, compose, send, label and move-to-trash — not the broader mail.google.com scope that also grants IMAP/SMTP-level access and permanent deletion. We don't request your Google Contacts; the same grant covers calendar events only because triage and scheduling sit in the same agent.
Every action the agent takes against your mailbox — a label applied, a draft sent — is written to an audit log you can review, and Copilot mode holds every send for your approval before it leaves your account. We build AI Emaily, and we'd rather you read this section the same way you'd read any other app's consent screen: check the scope, not the pitch.
Frequently asked
See it in AI Emaily
Keep reading
Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.