Originally published on ExtensionBooster.

AI Chrome extension privacy stopped being a footnote once Google's Chrome team reported at I/O 2026 that 17% of extensions created for the Chrome Web Store in the past year use AI. Each one ships part of a user's page to a model. Here is how to send less, ask properly, and prove what you sent, with code you can drop into a Manifest V3 extension.

Why users are suspicious (and why badges didn't help)

Two investigations from late 2025 set the tone:

  • Koi Security (December 2025): four extensions from one publisher, with more than 8 million combined users, captured conversations from roughly ten AI platforms, including ChatGPT, Claude and Gemini. The main one patched fetch() and XMLHttpRequest, collected by default, and had no off switch.
  • OX Security (December 30, 2025): two AI sidebar extensions with more than 900,000 combined users sent ChatGPT and DeepSeek conversations plus every open tab URL to a remote server every 30 minutes, behind a consent prompt for "anonymous, non-identifiable analytics."

In both cases at least one extension carried a Featured badge, so a badge is no longer proof of safety. What your extension visibly does is.

What the Chrome Web Store actually requires

There is no separate AI policy. The general user data rules apply, and the July 2026 update (enforced from August 1, 2026) tightened them:

Rule What it means for an AI feature
Strictly necessary data Only send what the single purpose needs
Limited third-party transfers Passing data to a model API must be necessary for that purpose
No human reading by default Exceptions need explicit consent, anonymized aggregates, or security/legal reasons
Browsing activity Only as a prominently described, user-facing feature
In-product disclosure Consent must live inside the extension UI; a privacy policy or listing text alone does not count
Secure transport HTTPS for anything that leaves the browser

The same update also bans extensions built to get around AI services' safety guardrails.

Know what your model provider keeps

Retention and training terms differ by provider and tier, and your users inherit them:

Provider and tier Trains on your inputs? Retention and review
OpenAI API (default) No, unless you opt in Abuse-monitoring logs up to 30 days; Zero Data Retention needs approval
Gemini API, unpaid May be used to improve Google products Human reviewers may read inputs and outputs after they are disconnected from your account
Gemini API, paid No Logs kept for a limited period to detect abuse
Chrome built-in AI (on-device) Text stays on the device No server involved

Rule of thumb: never route personal data through the free Gemini tier.

Send less: selection-only, redacted, behind consent

Swap all-sites access for activeTab or a context menu, so the user chooses exactly what leaves the page. A minimal service worker:

// background.js (MV3) import { redact } from './redact.js'; import { hasAiConsent } from './consent-store.js'; chrome.runtime.onInstalled.addListener(() => { chrome.contextMenus.create({ id: 'explain', title: 'Explain selection with AI', contexts: ['selection'], }); }); chrome.contextMenus.onClicked.addListener(async (info) => { if (!(await hasAiConsent())) { chrome.tabs.create({ url: chrome.runtime.getURL('consent.html') }); return; } const text = redact(info.selectionText).slice(0, 4000); // Only the text goes out: no URL, no page title, no user ID. await fetch('https://api.your-backend.example/explain', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ text }), }); });

Scrub the obvious secrets before they leave:

// redact.js const rules = [ [/[\w.+-]+@[\w-]+\.[\w.-]+/g, '[email]'], [/\b(?:sk|pk|ghp|xox[bp])[-_][A-Za-z0-9_-]{10,}/g, '[token]'], [/\b\d(?:[ -]?\d){12,18}\b/g, '[card-number]'], [/\+?\d[\d ().-]{7,}\d/g, '[phone]'], ]; export const redact = (s) => rules.reduce((t, [re, sub]) => t.replace(re, sub), s);

Two more habits: keep the model API key on your own backend, and ship a default block list (online banking, health portals, password managers) where AI stays off, which users can extend.

Ask clearly, then show your work

Before the first request, open a consent page that answers four questions in plain words: what is sent, where it goes, how long it is kept, and who can read it. Give "Turn on AI features" and "Not now" equal visual weight, and keep the rest of the extension working if the user declines. Version the consent so a changed data flow asks again:

// consent-store.js const CONSENT_VERSION = 2; export async function grantAiConsent() { await chrome.storage.local.set({ aiConsent: { v: CONSENT_VERSION, at: Date.now() } }); } export async function hasAiConsent() { const { aiConsent } = await chrome.storage.local.get('aiConsent'); return aiConsent?.v === CONSENT_VERSION; }

After consent, keep it visible: a "sent to AI" indicator, a local history of the last 20 requests in chrome.storage.local, and a single AI on/off switch in the popup. Then say the same thing on your listing: name the model provider, what is sent and how long it is kept, and make sure your Privacy practices answers, policy and description all match. When a review raises privacy, reply within a day with specifics.

Key takeaways

  • 17% of new Chrome Web Store extensions use AI, and two 2025 incidents showed Featured badges don't prove safety.
  • Consent must live inside the extension; a privacy policy alone does not satisfy the store.
  • Send only the user's selection, redacted and truncated, never URLs or IDs you don't need.
  • Pick a model tier that doesn't train on inputs, and keep the API key server-side.
  • Version your consent, show what was sent, and keep listing, disclosures and policy consistent.

The original post has the full nine-point checklist and FAQ in its guide to AI Chrome extension privacy and earning user trust, and ExtensionBooster has more resources on growing Chrome extension ratings and reviews.

If you ship an AI feature in an extension, what do you send to the model today: the full page, the selection, or something in between?