playbook

How to review an AI Chrome extension before install

A practical review workflow for AI Chrome extensions before they read pages, inject scripts, connect to SaaS apps, or run inside sensitive work tabs.

Published: Jun 17, 2026 Last reviewed: Jun 17, 2026 Audience: Founders, workspace admins, IT owners, operations leads, support managers, sales leaders, recruiters, and small-team security owners reviewing AI Chrome extensions before employee installation Risk: High Evidence: Chrome extension permission documentation, Chrome Web Store user data policy, Chrome activeTab guidance, Chrome Enterprise ExtensionSettings policy, and Cybergiz browser-extension approval playbooks

Bottom line

Do not install an AI Chrome extension for company work until you know three things: what pages it can access, what data it sends outside the browser, and who can remove it later. Browser extensions sit on top of email, documents, CRM, admin consoles, customer tickets, code hosting, payment pages, and identity tools. A small writing helper can become a broad data exposure path if it asks for all-sites access, content scripts, clipboard access, cookies, traffic controls, or deep SaaS account permissions.

Use this page as the pre-install review. If the extension is already installed, move straight to the AI browser extensions security checklist and run a cleanup review with the AI Tool Risk Checker.

Pre-install decision matrix

Extension request	Default decision	Approval condition
Public web research only, no work account connection	Pilot	Limit to a separate browser profile and public pages.
One specific work domain, such as Docs or a CRM page	Review	Approve only for named users, named domains, and a defined workflow.
Gmail, Google Docs, Drive, Slack, helpdesk, CRM, HR, finance, admin, GitHub, or source-code pages	Escalate	Require business owner, data owner, and security review.
`<all_urls>`, `https:///`, or “read and change data on all websites”	Usually reject	Approve only if domain restrictions can be enforced centrally.
Clipboard read, cookies, webRequest, native messaging, file URL access, or incognito access	Block by default	Require a technical review and written exception.
OAuth scopes for send, delete, admin, export, or write actions	Escalate	Use least-privilege scopes or choose another tool.
No privacy policy, vague data collection language, or unclear AI model provider	Reject	Vendor must explain prompt, page, output, telemetry, training, and retention handling.

15-minute review workflow

Use this sequence before any employee installs the extension for work:

Capture the extension name, Chrome Web Store URL, extension ID, vendor, requested user group, and business use case.
Read the Web Store permission warning and vendor privacy disclosure.
Open the extension’s manifest if the vendor publishes it, or ask the vendor for the relevant permission list.
Identify every permissions, host_permissions, optional_permissions, optional_host_permissions, and content_scripts.matches entry.
Map host access to real work systems: email, docs, CRM, support, GitHub, admin, HR, finance, or customer portals.
Check whether the extension sends selected text, full pages, screenshots, form fields, files, meeting notes, or account metadata to an AI service.
Review connected apps and OAuth scopes separately from browser permissions.
Decide whether a managed browser policy can restrict installation, runtime hosts, or blocked permissions.
Record the decision, owner, pilot scope, renewal date, and offboarding action.

If any step is unclear, do not approve the extension. Put it in a pending state and ask the vendor for the missing facts.

Manifest review checklist

Chrome extension documentation separates API permissions, optional permissions, content script match patterns, host permissions, and optional host permissions. For small teams, the manifest is where vague productivity claims become concrete access.

Ask a technical reviewer to inspect this shape:

{
  "permissions": ["storage", "activeTab"],
  "optional_permissions": ["tabs"],
  "host_permissions": ["https://docs.google.com/*"],
  "optional_host_permissions": ["https://example-crm.com/*"],
  "content_scripts": [
    {
      "matches": ["https://docs.google.com/*"],
      "js": ["content.js"]
    }
  ],
  "manifest_version": 3
}

Prefer:

activeTab over always-on all-sites access.
Specific host permissions over <all_urls>, https://*/*, or http://*/*.
Optional permissions requested only when needed.
Content scripts limited to the exact approved domains.
Read-only app scopes when an integration is needed.
Clear vendor explanations for why each permission exists.

Block or escalate:

cookies
clipboardRead
broad webRequest usage
native messaging
file URL access
incognito access
broad content script matches
sudden permission increases after an update
remote hosted code or undocumented AI data flows

Data-flow questions

Do not stop at the Chrome permission prompt. AI extensions often combine browser access with vendor-side processing, model providers, telemetry, integrations, or human review queues.

Ask the vendor or internal sponsor:

Question	Required answer before approval
What content leaves the browser?	Selected text, full page HTML, screenshots, form fields, files, URLs, metadata, prompts, and outputs must be listed separately.
Which AI model or subprocessors receive data?	Vendor, model provider, hosting provider, analytics provider, and support tooling should be named.
Is customer data used for model training?	Business use requires training opt-out or contractual restriction.
How long are prompts and outputs retained?	Retention must match your data classification and deletion policy.
Can admins disable sharing, training, connectors, or sensitive domains?	Business approval needs admin controls, not employee-only settings.
Are OAuth scopes separate from extension permissions?	Gmail, Drive, Slack, CRM, GitHub, and helpdesk scopes need their own review.
What audit logs exist?	Admins should be able to see users, installs, connected apps, and major access events.
What happens on employee offboarding?	Removal from the browser and connected SaaS apps must be documented.

Sensitive-domain review

Before install, make a list of places where the extension must not run.

Domain type	Examples	Default rule
Identity and admin	IdP admin, Google Admin, Cloudflare, AWS, Vercel, GitHub org settings	Block runtime access.
Customer data	Helpdesk, CRM, support inboxes, customer portals	Require workflow approval and redaction rules.
Source code and secrets	GitHub, GitLab, CI, logs, deployment dashboards	Block unless the tool is specifically approved for engineering.
Finance and payments	Stripe, bank portals, payroll, accounting	Block.
HR and recruiting	ATS, candidate records, employee files	Require HR owner approval.
Email and docs	Gmail, Google Docs, Drive, Microsoft 365	Approve only for named workflows and named users.
Passwords and credentials	Password manager, SSO, API key pages	Block.

If the extension needs broad access for a narrow use case, the safer decision is usually to reject it or run it only in a separate browser profile with no work accounts.

Chrome Enterprise controls

If your team manages Chrome, use policy controls instead of relying on employees to interpret permission prompts. Chrome Enterprise’s ExtensionSettings policy can define installation modes, block or allow extensions, restrict runtime hosts, block permissions, and set custom blocked-install messages.

Baseline policy intent:

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

Treat this as a review pattern, not production-ready policy. Replace placeholder domains and extension IDs, test with a pilot group, and keep a rollback plan.

Approval record

Copy this into your approved-extension register:

AI Chrome extension approval record

Extension name:
Chrome Web Store URL:
Extension ID:
Vendor:
Business owner:
Admin owner:
Requested users or team:
Business use case:
Approved domains:
Blocked domains:
Requested browser permissions:
Requested host permissions:
Requested content script matches:
Connected apps and OAuth scopes:
Data sent to vendor:
Training setting:
Retention setting:
Admin controls available:
Pilot start:
Pilot end:
Approval status: Approved / Pilot / Rejected / Pending vendor answer
Renewal date:
Offboarding action:
Reviewer:
Decision notes:

Use the same register when filling out the Small Team AI Security Checklist.

Pilot plan

Run a two-week pilot before broad rollout:

Pick one low-risk workflow, one team, and one owner.
Use a managed browser profile, not personal profiles.
Disable or block sensitive domains during the pilot.
Confirm the extension does not appear on blocked pages.
Test whether permissions change after an update.
Review prompts, outputs, telemetry settings, and connected apps.
Ask users what work improved and what data they exposed.
Re-score the extension with the AI Tool Risk Checker.
Approve, restrict, or remove it based on the recorded evidence.

Employee install rule

Do not install AI Chrome extensions for company work unless the extension is on the approved list.

Request approval first if the extension can read or change website data, access all sites, use the clipboard, connect to work accounts, summarize email or documents, inject text into forms, or run on customer, source-code, finance, HR, admin, or support systems.

Personal browser profiles and personal extensions are not approved for company customer data, source code, credentials, CRM records, helpdesk tickets, internal docs, or admin consoles.

Evidence checked

FAQ

Is it enough to read the Chrome Web Store listing?

No. The listing is a starting point. You still need to review permissions, host access, connected apps, data handling, admin controls, and update behavior.

Should we approve extensions that ask for all-sites access?

Usually no. All-sites access is too broad for casual productivity use. If the extension is critical, restrict runtime hosts through managed browser policy and document the exception.

Is `activeTab` safe?

It is safer than persistent broad host access because it depends on user action, but it still grants page access in the active tab. Treat it as lower risk, not no risk.

What if the vendor says the extension only reads selected text?

Selected text can still contain customer data, source code, credentials, contract terms, or internal strategy. Ask where selected text is sent, retained, logged, and used for training.

Do unmanaged small teams need a policy?

Yes. Even without Chrome Enterprise, keep an approved-extension register, require approval for AI extensions, remove unused extensions monthly, and block use on sensitive work systems.

Recommended next step

Add every installed AI browser extension to an approved-extension register, then run the highest-risk one through the AI Tool Risk Checker and the Small Team AI Security Checklist.