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.

This review adds a corrected Chrome Enterprise policy example, a pilot test matrix, and a reusable approval record. It does not claim that a particular extension passed these tests. Use the browser extension allowlist template to maintain decisions and the Small Team AI Security Checklist for the wider rollout.

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

Read API permissions and site access together. Chrome separates API permissions, host permissions, and content-script matches; some capabilities require more than one of them. A short permission list is not proof of limited page access. See Chrome’s permission model.

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 with matching host access	Reading or changing cookies can create account/session risk.	Usually block.
webRequest with matching host access	Traffic observation can reveal sensitive requests; this permission alone is not a blanket right to modify traffic.	Require a documented need.
Request-changing APIs	Review declarativeNetRequest and any webRequestBlocking separately from observation.	Usually block for an AI writing helper.
scripting plus host access or activeTab	Enables programmatic script injection on permitted pages.	Require domain or invocation limits.
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 reviewer to inspect the complete manifest, including optional permissions and content scripts. These are permission fragments, not complete installable manifests. A click-invoked helper might use:

{
  "permissions": ["activeTab", "scripting"]
}

activeTab temporarily grants access after a user invocation. Access remains on same-origin navigation but ends when the tab closes or moves to a different origin. It is not a selected-text-only permission. The fragment has no persistent host grants; adding them elsewhere changes the assessment. See the activeTab documentation.

Compare that with persistent all-site access:

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

Host access can enable fetching from matching sites and reading sensitive tab properties, with related API permissions needed for capabilities such as cookie access or programmatic injection. Manifest host patterns use paths such as /*; the enterprise runtime host fields below use a different, path-free format.

In Manifest V3, most extensions cannot use webRequestBlocking; policy-installed extensions are an exception. Declarative request rules are another request-changing mechanism. Blocking webRequest alone is therefore not a complete traffic-modification policy. See Chrome’s request-blocking migration guide.

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 within an existing approval:
- Only the approved extension, workflow, domains, and data categories.
- Public-page use is not an exemption from initial review.

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

Use managed policy for installation and runtime access. runtime_allowed_hosts supplies exceptions to runtime_blocked_hosts; setting it alone does not create an allow-only boundary. allowed permits installation, while removed uninstalls an extension. Blocked required permissions prevent installation/loading; blocked optional permissions prevent granting those capabilities. See ExtensionSettings documentation.

The following is an illustrative value for ExtensionSettings, not a complete device configuration. The 32-character ID is a fake placeholder. This pilot permits one reviewed extension and restricts its runtime website interaction to HTTPS Google Docs:

{
  "*": {
    "installation_mode": "blocked",
    "blocked_install_message": "Ask IT before installing browser extensions for company work."
  },
  "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa": {
    "installation_mode": "allowed",
    "runtime_blocked_hosts": ["*://*"],
    "runtime_allowed_hosts": [
      "https://docs.google.com"
    ],
    "blocked_permissions": [
      "cookies",
      "webRequest",
      "webRequestBlocking",
      "declarativeNetRequest",
      "declarativeNetRequestWithHostAccess"
    ]
  }
}

Runtime host patterns must not contain a path, including a trailing / or /*. Google documents *://* as the all-URL pattern for these fields. A manifest pattern is not interchangeable with a runtime policy pattern. See Chrome’s Windows policy guide.

Replace the fake ID with the reviewed extension’s actual ID. Put its runtime restrictions in its own entry as shown, rather than assuming the wildcard defaults will supply them. Review existing policies before merging: replacing an entire ExtensionSettings value could disrupt other approved extensions.

This deliberately restrictive example may break the extension’s login or useful features. Record the missing dependency before considering a narrow exception; do not solve a failed pilot by allowing every host. Google Docs access is not permission to process every document, and these browser rules are not a vendor egress firewall or a revocation of server-side OAuth access.

Pilot test matrix

Run these checks in a managed test profile with synthetic documents and accounts. Results are blank until your reviewer executes them. Inspect the effective policy on the device, not only the JSON saved in an admin console.

Check	Test action	Required result and evidence
Effective policy	Open chrome://policy, reload policies, and inspect ExtensionSettings.	Record browser version, policy source/scope, effective value, and any errors or conflicts. Resolve errors before testing behavior.
Installation boundary	Try the reviewed ID and a separate unapproved test extension.	Approved ID can install if it meets the permission rules; unapproved ID is blocked. Record both results.
Allowed workflow	Run the approved feature against a synthetic document on https://docs.google.com.	Record useful output and the exact data sent. A working toolbar icon alone is not a pass.
Disallowed website	Attempt the same page-reading/injection feature on an ordinary unapproved test website.	It cannot read or alter that page. Record the attempted action and observed denial; an absent icon alone proves nothing.
Click-only access	Separately test a helper that relies only on activeTab, before and after invocation and across origins.	No access before invocation; same-origin access can persist; cross-origin navigation revokes that temporary grant. Do not infer this from a helper with persistent hosts.
Permission expansion	Inspect required and optional permissions on the pilot version and proposed update.	Reject unapproved additions; demonstrate a blocked optional request is denied when the extension offers that feature. Record unavailable tests as unverified.
Removal and account access	Remove the test extension and separately revoke its connected-app grant.	Verify browser removal and SaaS disconnection independently. Check vendor deletion requirements for already uploaded content.

If a required test fails or cannot be observed, keep the approval pending. This page’s JSON checks validate the example’s structure, not a live Chrome deployment or any vendor’s behavior.

Extension review record

Copy this record into the approval ticket. Use evidence references, not credentials, production page content, or raw customer screenshots.

Field	Fill in before approval
Extension identity	Name, store URL, exact ID, version, publisher, review date: ___
Approved workflow	User group, action, permitted hosts and data categories: ___
Access inventory	Required/optional API permissions, hosts, content scripts, SaaS scopes: ___
Vendor handling	Destinations, retention/deletion terms, training settings and evidence date: ___
Effective controls	Device/profile, browser version, policy source and sanitized evidence reference: ___
Test outcomes	Each matrix row: pass / fail / unverified, observed result, evidence reference: ___
Decision	Approve scoped pilot / reject / pending evidence; reason: ___
Ownership	Reviewer, rollout owner, expiry date, removal/revocation owner: ___
Re-review triggers	New permissions, changed hosts/publisher, new integration, incident, renewal: ___

For a first-time vendor assessment, pair the record with reviewing an AI Chrome extension before installation. Keep approval scoped to the tested version and workflow, with a process for reviewing updates rather than assuming every change produces a fresh browser warning.

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.
• Run the allowed and denied actions in the pilot matrix; visual absence is not proof of blocked access.
• 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 for Developers: declare permissions
• Chrome for Developers: activeTab permission
• Chrome for Developers: blocking web request migration
• Chrome Web Store program policy: user data and minimum permissions
• Chrome Enterprise Help: ExtensionSettings policy
• Chrome Enterprise Help: Windows extension policies and host patterns

Official references were checked on September 9, 2026. The policy and review records are examples, not results from a live extension audit.

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.

Does activeTab mean the extension can only read my selection?

No. It limits the timing and scope of a temporary tab grant, not the content to highlighted text. Review actual collection behavior and any persistent permissions separately.

Does blocking a website disconnect the vendor from our SaaS account?

Do not assume so. Browser host controls and a vendor’s connected-app authorization are separate approval items. Revoke the account grant, verify disconnection, and handle previously uploaded data under the vendor’s deletion process.

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.