Search that question and you get setup tutorials. Composio, Activepieces, MintMCP, a dozen affiliate blogs, each walking you through the OAuth flow. None of them answer the question you asked, and the structural reason is worth naming: most of them are the company that would be holding your token. The broker is a poor source on whether to use a broker.
So here is the answer, with the primary sources attached so you can check every claim yourself.
Full disclosure: I built and maintain gws-mcp-server, one of the three options below. It is not the one I recommend for most readers. Everything factual here comes from Google’s OAuth documentation, Anthropic’s help center, and the source code of the tools involved, not from my own README.
The short version
Use Anthropic’s built-in Gmail connector. For the overwhelming majority of people asking this question, that is the right answer, and it has been since Anthropic shipped first-party Google Workspace connectors. It grants one credential to one company you already trust with your conversations, it exposes no send tool, and you can revoke it from your Google account in about fifteen seconds.
Self-host only if you have a specific reason: you want Gmail access inside an automated pipeline with no human in the loop, you need tools the connector does not have, or you are unwilling to have a hosted service hold a live token to your mailbox. Those are real reasons. They are also not most people’s reasons.
Avoid the brokered option unless you are already paying that vendor for something else. Adding a third company to the trust chain buys you convenience and costs you a copy of your mailbox credential.
”Access to Gmail” is not one thing
The consent screen you click through is granting specific OAuth scopes, and the scope is what actually defines the blast radius. Google publishes the full list with its own descriptions:
| Scope | What Google says it permits |
|---|---|
gmail.metadata | ”View your email message metadata such as labels and headers, but not the email body.” |
gmail.readonly | ”View your email messages and settings.” |
gmail.labels | ”See and edit your email labels.” |
gmail.compose | ”Manage drafts and send emails.” |
gmail.send | ”Send email on your behalf.” |
gmail.modify | ”Read, compose, and send emails from your Gmail account. This scope does not allow immediate, permanent deletion of threads and messages, bypassing the trash.” |
https://mail.google.com/ | ”Read, compose, send, and permanently delete all your email from Gmail.” |
Two of those deserve a second look. gmail.modify reads as a modest middle tier and is not one: by Google’s own description it sends mail. What it withholds is permanent deletion. That is the whole distance between it and https://mail.google.com/, the scope a lot of quick-setup guides hand you because it makes everything work on the first try.
A leaked token is worth exactly what its scope says. A gmail.readonly token in the wrong hands means someone reads your mail, including every password reset and every thread you assumed was private. A gmail.modify token means they can also send mail as you, which is the difference between a privacy incident and a fraud incident.
The tool list is not the security boundary
This is the part the tutorials skip, and it applies to every option including mine.
Anthropic’s Gmail connector has no send tool. Its help center is explicit: “Claude only reads emails and creates drafts with your explicit approval. The send function is not enabled.” Connect it and list the tools yourself and you get thread search, message reads, draft create and update, and label management. No send. That is a deliberate design constraint and a good one.
But the same page also notes that “during authentication, Google’s OAuth screen mentions email sending permissions.” The token can do more than the tools expose. Anthropic has chosen to constrain what Claude does with that token; the grant underneath it stays wide, and it is the grant Google enforces.
My own server has the same gap, and it is wider. gws-mcp-server is a thin wrapper over the Google Workspace CLI, which handles all authentication. Its six Gmail tools are list, read, thread list, thread read, label modify, and draft create. Drafts are never auto-sent. But the setup instructions tell you to run gws auth login with no flags, and what that actually grants depends on something the instructions never mention: whether you are sitting at a terminal.
Follow the README by hand and you are. In a TTY, resolve_scopes treats the no-flag case as a fall-through to an interactive scope picker. That picker is built from the CLI’s nine static SCOPE_ENTRIES, and every item is constructed with selected: true:
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/spreadsheets
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/calendar
https://www.googleapis.com/auth/documents
https://www.googleapis.com/auth/presentations
https://www.googleapis.com/auth/tasks
https://www.googleapis.com/auth/pubsub <- picker only
https://www.googleapis.com/auth/cloud-platform <- picker onlyPress Enter without toggling anything, which is what a prompt full of pre-checked boxes invites, and you have granted all nine. The last one is project-wide Google Cloud access.
Run the same command without a TTY, in a script or a container, and no picker appears. You get DEFAULT_SCOPES, the same list without pubsub and cloud-platform. Those two were removed from the defaults because Google blocks them for unverified apps, not because they were judged too broad, and the picker still offers them pre-selected.
Either way you end up with gmail.modify, the send-capable one, plus full read-write Drive, on a first-run login. My server never exposes a send tool. The token sitting on disk can send anyway, and so can anything else on the machine that reads that file.
There is one real mitigation, and I did not make it prominent in my own setup instructions. gws auth login --readonly requests the readonly variant of every scope, gmail.readonly included, and returns before the picker ever runs. That is a fair criticism of my project and I would rather write it here than have you find it later.
The service filter is not a mitigation, and I want to be specific about that because I nearly recommended it as one. gws auth login -s gmail looks like it narrows the grant to a single service. It does not. scope_matches_service returns true for cloud-platform unconditionally, under a comment reading “cloud-platform is a cross-service scope, always include.” So -s gmail hands you a picker containing Gmail and Cloud Platform, both pre-checked, and Enter grants your mailbox plus your entire GCP project. If you use the flag, deselect Cloud Platform by hand. A scope-narrowing flag that admits project-wide cloud access by design is worse than no flag at all, because you stop reading the screen.
The general rule: audit the grant, not the tool list. Go to myaccount.google.com/connections and read what each connected app actually holds. It is usually broader than you remember agreeing to.
Who holds the credential
Three architectures, three different answers to the only question that matters.
Anthropic’s built-in connector. Anthropic runs it, so Anthropic holds the OAuth credential. Their Workspace connector documentation states that “data retrieved while using connectors is stored on Anthropic servers, protected by Anthropic’s security infrastructure,” retained alongside the chat and deleted when you delete the chat, and that “we do not train our models on your Gmail, Drive, or Calendar connector data.” One party, disclosed terms, one revocation switch. If you already send Anthropic your work through the chat window, this adds no new company to the list.
Brokered SaaS. Composio, Merge, Activepieces, MintMCP and the rest sit between Claude and Google. You complete OAuth against the broker’s app, the broker stores the resulting refresh token, and the broker calls Gmail on your behalf. That is the product, and it is a legitimate architecture for a team that needs centralized connection management across many users and many services. It also means two companies now hold live credentials to your mailbox instead of one, and a breach at either one reaches your mail. Before you use one, find its actual security documentation, check where tokens are stored and encrypted, and check whether it has a current SOC 2 report. If you cannot find those answers in a few minutes, that is itself an answer.
Self-hosted. The token stays on your machine, and so does the responsibility. Concretely, for the CLI my server wraps: credentials live in ~/.config/gws, encrypted at rest with AES-256-GCM. Where the key lives depends on your operating system, and that difference matters more than the cipher does.
On macOS and Windows the key goes into the OS keyring, and resolve_key actively deletes any .encryption_key file it finds sitting beside the ciphertext. That is the case the design is written for.
Linux is not that case. The CLI pulls in the keyring crate with no platform backend enabled there, so the keyring is a mock store, and the same function writes the key to ~/.config/gws/.encryption_key and re-syncs it on every run to keep the “file backup … in sync with keyring.” Its own doc comment says the file is “never deleted.” Setting GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file does not change the outcome, because on Linux the default path already lands there. Linux is also where nearly every headless self-hosted deployment runs, which is to say: for the deployments this section is about, the key sits in the same directory as the data it protects, in every mode, by design. Encryption at rest with the key stored beside the data stops a stolen backup drive and stops close to nothing else. Do not let the phrase “encrypted at rest” do work it has not earned.
No broker is a real advantage, and it is the one architectural claim I will make for my own project. It is also not the same thing as “safer.” It moves the risk from a company’s infrastructure to yours. Whether that is an upgrade depends entirely on your laptop.
The risk nobody sets up for
Token storage is the risk people think about. Prompt injection is the one that actually gets them, and Gmail is the worst case for it.
Your inbox is an input stream that anyone on earth can write to. That is what an email address is. The moment an agent reads a message, attacker-controlled text is inside its context window, and some of that text will be instructions written for the agent rather than for you. Anthropic’s own guidance for custom connectors says it plainly: “Malicious MCP servers may include hidden instructions that try to make Claude perform unintended actions.” The same mechanism works through message bodies.
Anthropic does not claim to have solved this. Its research on prompt injection defenses reports a 1% attack success rate for Claude Opus 4.5 against an internal adaptive attacker, then says what that number is worth: “A 1% attack success rate—while a significant improvement—still represents meaningful risk.” And: “No browser agent is immune to prompt injection, and we share these findings to demonstrate progress, not to claim the problem is solved.” Elsewhere: “prompt injection is far from a solved problem, particularly as models take more real-world actions.”
Be precise about what that 1% measured. It is a browser-use benchmark, Claude in Chrome against injected page content, evaluated with a Best-of-N attacker given repeated attempts per environment. It is not a Gmail number and not an MCP number, and no published equivalent exists for either. The finding transfers. The rate does not.
Read access to Gmail on its own is survivable. What turns it dangerous is putting it in the same session as any write-capable tool. An injected instruction that reaches an agent with a shell, a Drive token, a payments API, or a send-mail scope has somewhere to go. Read-only Gmail next to a broadly scoped everything-else is the combination worth refusing.
Three things that actually reduce this, in order of how much they help:
- Cut the scope. Read-only Gmail, and nothing else in the same session that can spend money, send mail, or write to a repo.
- Keep the approval prompts on. Auto-approving tool calls is where a read-only inbox turns into an incident, because the write tool that finishes the attack is a different tool. Anthropic’s connector guidance says to review tool approval requests before allowing automatic execution, which is worth following even when it is tedious.
- Separate your accounts. If you are running agent workflows over email at all, run them against an inbox that is not the one holding your bank, your registrar, and your password resets.
What I would actually do
Most people, asking because they want Claude to help with their inbox. Built-in connector. Read and draft, no send, revocable in one click from your Google account. Stop there.
Developers who want Gmail in an agent pipeline, not a chat. Self-hosted MCP server, read-only scopes granted explicitly rather than clicked through a picker, a dedicated Google account, no other write-capable tools in the same session. Mine works for this and so do several others. Pick on scope control and on whether you can read the source, not on tool count.
Teams standardizing across many users. This is the case where a broker earns its place, because centralized revocation and audit logging across an org is a real problem that a per-laptop token does not solve. Do the vendor diligence properly. You are handing them a lot of mailboxes.
Anyone whose inbox carries legal, medical, or client-confidential material under an obligation. Check the obligation first. Anthropic’s BAA documentation lists “MCPs / Connectors” as one category and marks the whole category: “Available to use but sending data to 3rd parties via this feature isn’t covered under Anthropic’s BAA.” That is not a carve-out for third-party servers. It covers the built-in Google Workspace connector too, which by definition sends your data to Google. The same page puts the compliance burden on whoever enables the feature. Whatever your answer is, do not let a setup tutorial from a vendor be the thing that decides it.
The honest summary is that “is it safe” has no yes or no. What you are choosing is which company holds a key to your mailbox and how wide you cut that key. Cut it narrow, give it to one party, and check the grant rather than the tool list.