Are AI Email Assistants Safe? A Privacy Checklist for 2026

No AI email assistant is risk-free. Whether its risk is acceptable depends on the OAuth scopes it requests, what message content leaves the mailbox, retention and deletion rules, model-training use, permitted human access, subprocessors, and data sales or transfers. Before you click “Allow,” answer the seven questions below from the consent screen and binding privacy terms. If a vendor cannot answer them plainly, do not grant access.

Verification note: This is a documentary guide checked against current sources on August 3, 2026. We did not hands-on test the named product or workflow during this review, so claims are limited to the cited documentation. Interfaces can vary by account, region, rollout, and app version.

An AI email assistant is any tool that connects to your mailbox — usually through OAuth — and reads, sorts, summarizes, drafts, or acts on your email for you.

We build a tool that asks for the same kind of access. Flick (flicked.email) is a swipe-to-triage email client, and we ask people to connect their Gmail to it. That means we've spent a lot of time on the other side of this question, deciding what a tool like ours should be allowed to see. This guide is the checklist we'd want you to run on us — and on everyone else.

What can an email app actually see once you click "Allow"?

More than most people assume. Email access is granted through OAuth scopes — permission tiers that range from "see your address" to "read, modify, and send mail on your behalf." The consent screen you skim past is the only moment a vendor is forced to tell you exactly which tier it wants.

This is not a hypothetical concern. In 2018, Google explained that non-Google apps requesting Gmail access go through automated and manual developer review and should request only data relevant to their function. A third-party app can read the data authorized by its granted scope; Google's own handling of Gmail is a separate question.

For external production apps, sensitive and restricted scopes trigger Google OAuth verification requirements; restricted scopes add an annual security assessment, while sensitive scopes do not automatically require that third-party assessment. Google also documents exemptions, including internal-use and limited testing cases, and unverified apps can display a warning and face a user cap rather than being technically unable to run (verification exemptions; unverified apps). The Workspace API user-data policy prohibits selling Workspace API data to advertising platforms, brokers, or resellers and limits human reading to documented user consent, aggregated and anonymized internal operations, security, or legal compliance.

Good fences. But a fence is not a substitute for reading the gate sign. Verification tells you a vendor cleared Google's bar — it doesn't tell you what the vendor does inside the boundary of what's allowed, or what happens if it quietly changes its mind.

What is the worst case? Ask Unroll.me

The canonical cautionary tale in this category is an unsubscribe tool. In April 2017, the New York Times revealed that Unroll.me — a free service that cleaned up newsletter subscriptions — was, in TechCrunch's words, using "the premise of 'free' but not very useful 'email management' services to gain access to people's email inboxes in order to data-mine the contents for competitive intelligence," and selling the gleaned insights "to the likes of Uber." The famous example: Lyft ride receipts, scraped from user inboxes and sold to Uber via Unroll.me's parent company.

The story did not end with an apology. In 2019, Unrollme Inc. settled FTC allegations that it deceived consumers about access to and use of personal emails. In May 2018, TechCrunch reported that the company stopped serving EU users around GDPR's application date. That sequence documents business and regulatory events; it does not establish the company's private motive for leaving the market.

The lesson is not "unsubscribe tools are evil." The lesson is that "free email cleanup" has a documented history of being a data business wearing a productivity costume. It's the reason we wrote a whole piece on what to look for in an Unroll.me alternative, and it's the reason this checklist exists.

What seven questions should you ask before connecting an AI to your inbox?

Run every mailbox tool — ours included — through this table before you connect.

#	Question	Good answer	Walk away if
1	Which OAuth scopes does it request?	The narrowest set that can do the job, listed plainly on the consent screen	It wants full read/write/send access for a feature that only needs metadata
2	Does message content leave my mailbox?	A clear description of what is processed, where, and for how long	The privacy policy is vague about processing, storage, or third-party processors
3	Is my mail used to train AI models?	An explicit "no" for generalized models, in the privacy policy — not a blog post	Training use is unmentioned, or buried in an opt-out
4	Can employees read my mail?	A precise policy matching Google's allowed cases: documented consent for specific data, aggregated/anonymized internal operations, security, or legal compliance (Workspace policy)	Open-ended access for unspecified service improvement
5	Does the vendor sell or share inbox-derived data?	A binding "no" covering affiliates and "trusted partners"	Unroll.me-style language about sharing with a parent company or partners
6	How do I revoke access, and what happens to collected data?	Revocation instructions plus a stated deletion path	Revocation is undocumented, or deletion requires a support ticket that goes nowhere
7	What is its Google verification status?	For an external production app, approval for the requested sensitive/restricted scopes; an annual security assessment applies to restricted scopes (requirements)	An unexplained unverified-app warning, or claims that a warning proves the app cannot operate

If a vendor's answers to questions two through five exist only in marketing copy, treat them as unanswered. Marketing copy is not binding. Privacy policies are.

Why does less access beat smarter AI?

Here is the claim we'd put on a billboard, if we were the billboard type: the safest AI email feature is the one that needs the least of your mail.

Every scope you grant is attack surface. And with LLM-based assistants, the mail itself becomes attack surface — because an AI that reads message bodies can be manipulated by message bodies. In June 2025, the EchoLeak vulnerability (CVE-2025-32711) showed exactly this: an AI command injection in Microsoft 365 Copilot allowed attackers to exfiltrate information with no user interaction — a malicious email, read by the assistant, was enough. Microsoft scored it 9.3, critical; NIST scored it 7.5, high. Either way: the assistant's intelligence was the vulnerability.

Now compare that to the most useful "AI-adjacent" email feature there is — unsubscribing — which needs no intelligence at all. One-click unsubscribe is defined by RFC 8058, published in January 2017: the sender declares an HTTPS unsubscribe endpoint in the List-Unsubscribe header, marks it one-click-capable with List-Unsubscribe-Post, and covers the relevant headers with a qualifying DKIM signature. Sending the request is a deterministic HTTP POST; whether the sender suppresses the address and later mail stops is a separate outcome. No model needs to read the message body to initiate that request. Google requires senders of more than 5,000 messages a day to personal Gmail accounts to include the mechanism on covered marketing and subscribed mail, and warns that non-compliant messages might be marked as spam or not delivered as expected. We wrote up the full mechanics in our one-click unsubscribe explainer, and covered whether unsubscribing actually works and when it's safe separately.

The pattern generalizes. Before you accept "our AI reads your email to help you," ask whether the job could be done by parsing structure instead of prose. Deterministic header parsing can't be prompt-injected, can't hallucinate, and can't leak what it never read. When a vendor insists it needs your message bodies, the honest follow-up is: for which feature, exactly?

How does Flick answer its own checklist?

Fair is fair. Here is our own row-by-row, answered only from facts we can stand behind — and where a blog post is the wrong place for a promise, we say so instead of improvising one.

#	Question	Flick's answer
1	Which scopes?	Flick's current privacy policy identifies Gmail's gmail.modify scope. Google's scope reference describes that restricted scope as reading, composing, and sending mail; Flick's separate product policy says the service saves approved replies as drafts and never sends on the user's behalf. Confirm the exact consent-screen scope before connecting; this documentary review did not run OAuth.
2	Does content leave?	The policy says Flick reads sender, subject, snippets, and thread metadata to build the deck. For an AI draft, thread content is sent request-scoped to Anthropic and is not persisted. Direct code inspection on 2026-08-03 found approved draft text stored encrypted in an outbox with a 24-hour expiry and removed after provider draft creation is confirmed; account deletion is the fallback purge for any remaining records. Flick says it does not store a copy of the mailbox. This is documentary code evidence, not a production storage audit.
3	Trains AI on my mail?	The policy says neither Flick nor its instruction to Anthropic uses mail to train a model. Separately, Google's Workspace policy prohibits using Workspace API data to train a generalized model beyond that user's personalized feature. This review did not independently audit processor logs.
4	Humans read mail?	Flick's public policy incorporates Google Limited Use but does not publish a more detailed, separate human-access procedure. Google's rule still allows documented consent for specific data, aggregated/anonymized operations, security, and legal compliance. Ask support for the operational details if this is a deciding risk.
5	Sells or shares data?	The policy says Flick never sells data or shares it with ad networks. As checked August 3, 2026, its complete published service-provider list is Folderly (verified Gmail OAuth client), Nylas (email connectivity), Google (OAuth and Gmail APIs), Google Analytics (aggregate product/site analytics), Anthropic (requested AI drafting), Vercel (application hosting), Railway (database hosting), and Stripe (web payments). This is a documentary match to the live policy, not an audit of processor configuration.
6	Revocation and deletion?	Removing access in Google Account connections revokes the Google connection. Flick's policy says Settings → Delete account starts deletion of eligible application data. Provider email already changed by an action remains at the provider; payment, tax, refund, dispute, security, and legally required records may be retained, and external subscriptions may need separate cancellation.
7	Verified?	Flick's policy says Gmail connections use Folderly's Google-verified client, which is why the consent screen shows Folderly. This review did not connect an account; verify that identity and any warning on the live consent screen before granting access.

The same skepticism should apply to sender research. Flick's Exit Gap work-list does not currently let you look up an A–F honor grade: as of August 3, 2026, it contains 150 senders, four capability-only observations, and zero published sender-honor grades. A capability observation says that a message exposed a machine unsubscribe route; it does not say the sender acted on a request. Before a grade can support a trust decision, the sender needs at least three probes across at least 48 hours with the evidence preserved. The dedicated founder-run burner-mailbox observation cycle has not happened yet.

How do you revoke access if you change your mind?

Revocation and deletion are separate. Go to Google Account connections, find the app, and remove its access; Google says this stops the third party from accessing the Google Account through that connection. Google also warns that you may need to contact the developer to delete data it already collected. Revoking closes future authorization; it does not itself prove stored copies were deleted.

So make deletion part of the exit: revoke the scope, then email the vendor and request deletion of previously collected data. A vendor that handles that request gracefully is one you can consider reconnecting. A vendor that can't tell you what it stored is answering question six for you — just not the way you hoped.

FAQ

Is it safe to give AI access to your email?

No connection is risk-free. Treat the risk as potentially acceptable only when the app requests the minimum scopes, explains processing and retention, offers revocation and deletion, names subprocessors, and makes its commitments in binding privacy terms. Google's Workspace policy limits sales, transfers, AI training, and human access, while external production apps requesting sensitive or restricted scopes normally face verification requirements with documented exemptions (Google).

Can AI email assistants read all my emails?

If you grant a full-mailbox read scope, yes — that's exactly what the scope authorizes. The consent screen at connect time is the definitive list of what a tool can see, which is why skimming past it is the single most expensive habit in email privacy. Tools built on structured data — headers, senders, metadata — can do real work without ever touching message bodies.

Do AI email tools train models on my emails?

Under Google's Workspace API policy, apps may not use Workspace API data to train a generalized AI or machine-learning model beyond that specific user's personalized model for the approved feature. A vendor should also state its own policy and processor terms. If training use is unmentioned, the answer is unknown—not evidence of either use or non-use—so ask before granting access.

How do I revoke an app's access to my Gmail?

Open myaccount.google.com/connections, select the app, and remove its access — it takes effect immediately. Data the app already collected isn't deleted by revocation, so follow up with the vendor and request deletion directly. Google's documentation is explicit that you "may need to contact the developer" for that step.