playbook

AI browser extensions security checklist

A practical checklist for reviewing AI browser extensions before they read pages, write text, inject scripts, or connect to company apps.

Bottom line

AI browser extensions are high-risk by default because the browser is where employees open email, documents, CRM records, admin consoles, payment pages, customer tickets, source code, and internal dashboards. A useful writing assistant or research helper can become a data-exposure path if it can read every page, inject scripts, access cookies, capture copied text, or connect to SaaS accounts.

Do not approve an AI browser extension because the vendor sounds credible or because the Chrome Web Store listing has many users. Approve it only after reviewing permissions, host access, data collection, update behavior, connected apps, and admin controls.

Who this checklist is for

Use this page if your team is considering:

• AI writing assistants that work inside Gmail, Google Docs, LinkedIn, Notion, or CRM pages.
• Sales, recruiting, or support extensions that summarize profiles, tickets, or conversations.
• Browser research agents that read pages and send content to an AI model.
• Meeting, transcription, or note-taking extensions that run in browser tabs.
• Extensions that connect to Gmail, Google Drive, Slack, GitHub, Jira, HubSpot, Salesforce, or a helpdesk.
• Extensions that promise “autopilot,” “agent,” “reply generation,” “screen reading,” or “one-click workflow” features.

Permission risk map

Google’s Chrome Web Store Help warns that an extension with access to all data on your computer and the websites you visit can access almost anything. It also describes “your data on all websites” as access to read, request, or modify data from every page you visit.

For AI extensions, treat these permission categories as approval blockers until proven necessary:

Permission or capability	Why it matters	Default decision
All websites / broad host access	The extension may read or modify pages across email, CRM, finance, admin, and customer systems.	Block unless the business case is strong.
Specific sensitive domains	Access to mail.google.com, drive.google.com, github.com, CRM, helpdesk, or admin portals can expose regulated or customer data.	Pilot only with written scope.
Content scripts	The extension can inject code into matching pages.	Require domain limits.
tabs or browsing activity	The extension may see URLs, tab titles, or navigation context.	Approve only if needed.
cookies	Cookie access can create account/session risk.	Usually block.
webRequest or request modification	The extension can observe or affect browser traffic.	Usually block.
scripting	The extension can inject JavaScript programmatically.	Require strong justification.
clipboardRead or clipboard access	Copied passwords, customer data, or internal notes may leak.	Usually block.
File URL access	Local files can be exposed if users enable file access.	Block for normal business use.
Incognito access	Can bypass the expectation that private browsing is separated.	Block unless explicitly required.
Native messaging	Extension can communicate with a local native app.	Security review required.

Chrome permission examples

Ask the vendor or your technical reviewer to check the extension manifest and store listing. A narrowly scoped extension might ask for a single site:

{
  "permissions": ["storage", "activeTab"],
  "host_permissions": ["https://docs.google.com/*"]
}

That is still not automatically safe, but it is easier to reason about than this:

{
  "permissions": ["tabs", "cookies", "scripting", "webRequest", "storage"],
  "host_permissions": ["https://*/*", "http://*/*"]
}

Broad host access is the common danger. Chrome’s developer documentation says host permissions allow extensions to interact with matching URLs and can enable actions such as fetch requests, reading sensitive tab properties, injecting content scripts, monitoring and controlling network requests, accessing cookies, and modifying request or response headers through related APIs.

Prefer extensions that use:

• activeTab instead of always-on all-sites access.
• Specific domains instead of https://*/* or <all_urls>.
• Optional permissions requested at runtime instead of broad permissions at install time.
• Read-only app scopes instead of write, send, delete, or admin scopes.
• Clear explanations for every permission in the Web Store listing or vendor documentation.

Approval checklist

Before approving an AI extension, answer these questions:

Question	Approve only if…
What exact job does the extension do?	The use case is specific, not “AI productivity.”
Which domains can it access?	The domain list is narrow and excludes sensitive systems unless approved.
Can it read all pages?	No, unless the extension is strategically important and tightly governed.
Can it modify forms or click buttons?	Only if action behavior is documented and tested.
Can it access cookies, tabs, history, clipboard, or files?	Only with a clear reason and compensating controls.
Which SaaS apps does it connect to?	OAuth scopes are reviewed and limited.
What content is sent to the vendor or model provider?	The vendor explains prompt, page, output, and telemetry handling.
Does the vendor train on customer data?	Training and data sharing are disabled or contractually restricted.
Is there a business plan with admin controls?	Admins can manage users, data settings, and offboarding.
Can the extension be disabled centrally?	Yes, through Chrome Enterprise, MDM, browser policy, or a documented uninstall process.
What happens on update?	Permission increases trigger review before approval.
Who owns vendor review?	A named owner is accountable for renewal and removal.

Approved-extension policy sample

Use this as a lightweight policy for a small team:

AI browser extension policy

Default rule:
Employees may not install AI browser extensions for company work unless the extension is on the approved list.

Allowed without extra approval:
- Extensions already force-installed or approved by the company.
- Extensions limited to public web pages and non-sensitive workflows.

Requires approval:
- Any extension that can read or modify page content.
- Any extension that requests access to all websites.
- Any extension that connects to Gmail, Drive, Slack, GitHub, CRM, helpdesk, finance, HR, admin, or customer systems.
- Any extension that sends selected text, full pages, screenshots, files, meeting transcripts, or form contents to an AI service.

Never allowed without security review:
- Cookie access.
- Clipboard reading.
- Broad webRequest or traffic modification.
- File URL access.
- Native messaging.
- Access to password managers, payment systems, identity provider admin pages, production consoles, source-code secrets, or regulated data.

Request process:
The employee submits the extension name, Chrome Web Store URL, business use case, requested domains, requested permissions, connected apps, and vendor privacy link. Approval expires after 6 months unless renewed.

Chrome Enterprise controls

If you can manage Chrome, use policy instead of relying on employee judgment. Chrome Enterprise documentation describes controls that can:

• Allow or block extension installation.
• Block extensions based on requested permissions.
• Force-install approved extensions.
• Remove previously installed extensions.
• Restrict runtime hosts so extensions cannot interact with sensitive domains.
• Allow specific runtime hosts for approved extensions.
• Display a custom blocked-install message.

For a small team, a practical baseline is:

{
  "*": {
    "installation_mode": "blocked",
    "blocked_install_message": "Ask IT before installing browser extensions for company work.",
    "runtime_blocked_hosts": [
      "*://*.bank.example/*",
      "*://*.admin.example/*",
      "*://*.idp.example/*"
    ]
  },
  "approvedextensionid1234567890abcdef": {
    "installation_mode": "allowed",
    "runtime_allowed_hosts": [
      "*://docs.google.com/*"
    ],
    "blocked_permissions": [
      "cookies",
      "webRequest"
    ]
  }
}

Treat this as a policy shape, not a copy-paste production config. Replace placeholder domains and extension IDs with your actual approved list, and test on a pilot group before applying broadly.

Manual review for unmanaged teams

If you do not have Chrome Enterprise, Intune, or another browser management tool, keep the process simple:

1. Create an approved-extension spreadsheet.
2. Include extension name, store URL, vendor, owner, business purpose, permissions, allowed domains, connected apps, approval date, renewal date, and uninstall owner.
3. Review all employee-installed browser extensions monthly.
4. Remove extensions that are unused, abandoned, renamed unexpectedly, sold to a new vendor, or requesting new permissions.
5. Keep a separate blocked list for high-risk categories.

Blocked categories

Block or escalate extensions that touch:

• Password managers and credential pages.
• Identity providers and admin consoles.
• Payment processors, banking, payroll, and finance systems.
• Healthcare, legal, HR, and regulated records.
• Customer support tools with private customer content.
• Source-code repositories, CI/CD systems, secrets, and production dashboards.
• Email and calendar unless the vendor and scopes are approved.
• Browser history, cookies, clipboard, screenshots, or file URLs.

Vendor review questions

Ask these before approval:

• What data does the extension collect from pages, selected text, forms, screenshots, files, or connected apps?
• Is data sent to the vendor’s servers, a third-party model provider, or both?
• Is customer content used for model training, product improvement, or human review?
• Can business customers disable training and retention?
• Are prompts and outputs retained, and for how long?
• Which subprocessors receive content?
• Is SSO, SCIM, audit logging, or admin offboarding available?
• Can admins disable individual integrations or domains?
• Does the privacy policy match the Chrome Web Store privacy disclosure?
• What happens if the extension is acquired or changes ownership?

Pilot plan

Run a two-week pilot before company-wide approval:

• Pick one low-risk workflow.
• Use a test account or a small group.
• Block sensitive domains during the pilot.
• Confirm that the extension does not appear on pages where it should not run.
• Check whether it requests new permissions after update.
• Document whether the workflow saves enough time to justify the access.
• Re-score the tool with the AI Tool Risk Checker before rollout.

Decision rule

Approve the extension only when the business value is specific, permissions are narrow, connected apps are understood, sensitive domains are blocked, and there is a named owner for renewal and removal.

Reject it when the extension needs all-sites access for a vague productivity promise, requests cookies or traffic modification without a clear reason, cannot explain data retention, or has no business admin controls.

Alternatives

Before approving a standalone AI extension, check whether the same workflow can be handled inside a tool your company already manages:

• Google Workspace or Microsoft 365 built-in AI features.
• ChatGPT Business or Enterprise with controlled apps.
• Claude Team or Enterprise with approved data rules.
• CRM, helpdesk, or meeting tools with native AI features.
• A browser profile dedicated to low-risk public research.

Built-in AI is not automatically safe, but it is often easier to govern than many separate browser extensions with overlapping permissions.

Evidence checked

• Chrome Web Store Help: permissions requested by apps and extensions
• Chrome for Developers: declare permissions
• Chrome Enterprise Help: Chrome app and extension permissions
• Chrome Web Store program policy: user data and minimum permissions
• Chrome Enterprise Help: ExtensionSettings policy
• Chrome Extensions: enterprise publishing options

FAQ

Are Chrome Web Store extensions reviewed by Google?

The Chrome Web Store has policies and review processes, but review is not a substitute for company approval. Your team still needs to inspect permissions, data access, and the vendor’s business controls.

Is “read and change all your data on all websites” always bad?

It is not always malicious, but it is too broad for casual approval. It means the extension can affect many sensitive workflows, so it needs a strong business case and controls.

Is an extension safe if it only reads selected text?

Not automatically. Selected text can still contain customer data, contracts, credentials, or internal notes. Check where selected text is sent and retained.

Should we allow employees to install AI extensions on personal browser profiles?

Not for company work. If employees use personal profiles for company systems, the company loses visibility and control over extension risk.