checklist

Browser extension allowlist template for small teams

A copyable browser extension allowlist template for approving AI Chrome extensions by role, domain, permission, owner, review date, and offboarding action.

Published: Jun 21, 2026 Last reviewed: Jun 21, 2026 Audience: Small-team founders, Google Workspace admins, IT owners, operations leads, security-conscious managers, and team leads building an approved list for AI browser extensions Risk: Medium Evidence: Chrome extension permission documentation, Chrome permission warning guidance, Chrome Web Store user data policy, Chrome Enterprise ExtensionSettings policy, and Cybergiz browser-extension review playbooks

Bottom line

Small teams should not manage AI browser extensions by memory, Slack approvals, or employee preference. Use a simple allowlist that records which extensions are approved, which roles may use them, which sites they can run on, which permissions were reviewed, who owns the decision, and when the extension must be rechecked.

Start with the copyable Browser Extension Allowlist template, then use this page to fill it out with enough detail to survive employee turnover, extension updates, and offboarding.

Allowlist decision matrix

Extension situation	Allowlist status	Required note
Needed for a specific low-risk workflow and limited to public pages	Approved	Record role, workflow, and review date.
Needed for one approved SaaS domain	Approved with restrictions	Record allowed domain, blocked domains, and owner.
Requests broad host access but business need is strong	Pilot	Limit users and runtime hosts before full approval.
Reads Gmail, Docs, Drive, CRM, support, HR, finance, source code, or admin pages	Restricted	Require data-owner approval and a renewal date.
Requests cookies, clipboard read, broad webRequest, native messaging, file URL access, or incognito access	Blocked by default	Escalate only with technical review and a written exception.
Vendor privacy, training, retention, or subprocessors are unclear	Pending	Ask the vendor for answers before installation.
Extension is unused, abandoned, sold, renamed unexpectedly, or requests more access after update	Remove	Record removal date and offboarding owner.

Copyable allowlist

Copy this into a spreadsheet, Notion page, or internal doc:

AI Browser Extension Allowlist

Owner: [Name]
Scope: [Company / team / role]
Last reviewed: [Date]
Next review: [Date]

Approved and restricted extensions

| Status | Extension | Extension ID | Vendor | Approved roles | Business use case | Allowed sites | Blocked sites/data | Permissions reviewed | Connected apps | Admin owner | Review date | Renewal date | Offboarding action |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Approved / Restricted / Pilot / Pending / Blocked / Removed | [Name] | [ID] | [Vendor] | [Roles] | [Workflow] | [Domains] | [Sites or data] | [Yes/No] | [Gmail/Drive/CRM/None] | [Name] | [Date] | [Date] | [Remove extension + revoke OAuth] |

Keep the table short enough that a founder or workspace admin can review it monthly. The point is not compliance theater. The point is knowing which extensions can touch sensitive work tabs.

Minimum columns

Do not approve an AI extension unless the allowlist has these fields:

Column	Why it matters
Status	Separates approved, restricted, pilot, pending, blocked, and removed extensions.
Extension name and ID	Names can change; extension IDs are more stable for policy enforcement.
Vendor	Ownership changes should trigger a review.
Approved roles	Approval should follow business need, not individual preference.
Business use case	Prevents vague “productivity” approvals.
Allowed sites	Shows where the extension is expected to run.
Blocked sites or data	Makes sensitive-domain restrictions explicit.
Permissions reviewed	Confirms someone checked Chrome permissions and host access.
Connected apps	Browser access and OAuth access are separate risks.
Admin owner	Someone must own renewal, removal, and incident handling.
Review and renewal dates	Extensions update; approvals should expire.
Offboarding action	Removal must include browser extension and connected app access.

Status rules

Use consistent status labels:

Status	Meaning	Action
Approved	Normal work use is allowed within documented scope.	Review every 60-90 days.
Restricted	Use is allowed only for named users, roles, domains, or workflows.	Review every 30-60 days.
Pilot	Limited trial before approval.	Set an end date and success criteria.
Pending	Missing vendor, permission, data-flow, or owner information.	Do not install for work yet.
Blocked	Not allowed for company work.	Block through browser policy where possible.
Removed	Previously allowed, now uninstalled or revoked.	Keep for audit and re-request context.

Approval questions

Answer these before moving a row to Approved, Restricted, or Pilot:

What exact workflow does the extension support?
Which roles need it?
Which domains can it read or modify?
Does it request <all_urls>, https://*/*, or broad website access?
Does it use content scripts on email, documents, CRM, helpdesk, admin, HR, finance, or source-code pages?
Does it request clipboard read, cookies, webRequest, native messaging, file URL access, or incognito access?
Does it connect to Gmail, Drive, Slack, GitHub, CRM, helpdesk, calendar, or another SaaS app?
What content is sent to the vendor or model provider?
Can business customers disable training or retention?
Can admins remove users, revoke OAuth grants, and see installed users?
What happens if permissions increase after an extension update?

For high-risk answers, use the full AI Chrome extension pre-install review before approval.

Chrome Enterprise policy mapping

If your team manages Chrome, map the allowlist into policy controls. Chrome Enterprise’s ExtensionSettings policy can define installation mode, blocked permissions, runtime allowed hosts, runtime blocked hosts, and custom blocked-install messages.

Allowlist field	Chrome Enterprise control to consider
Status = Blocked	`installation_mode: blocked`
Status = Approved	`installation_mode: allowed` or force install only when justified
Allowed sites	`runtime_allowed_hosts`
Blocked sites/data	`runtime_blocked_hosts`
High-risk permissions	`blocked_permissions`
Company-wide default	Block unknown extensions by default, then allow listed extension IDs
Employee explanation	`blocked_install_message`

Example policy intent:

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

Treat this as a policy shape. Test with a small group before applying it broadly.

Review cadence

Use this lightweight cadence:

Trigger	What to do
Monthly	Remove unused extensions and confirm owners.
Every 60-90 days	Re-review approved extensions and update renewal dates.
Permission increase	Move to `Pending` until reviewed.
Vendor acquisition or rename	Re-check privacy, subprocessors, and ownership.
New sensitive workflow	Re-score with the AI Tool Risk Checker.
Employee offboarding	Remove extension, revoke OAuth grants, and remove browser profile access.
Incident or suspected data exposure	Move to `Blocked` or `Restricted` until root cause is closed.

Offboarding checklist

When a user leaves the company or no longer needs the extension:

Remove the extension from the managed browser profile or employee device.
Revoke OAuth grants in Google Workspace, Microsoft 365, Slack, GitHub, CRM, or the connected SaaS app.
Remove the user from the vendor workspace.
Rotate exposed credentials if the extension touched secrets, tokens, cookies, or admin pages.
Check whether the extension stored exports, prompts, screenshots, or summaries.
Update the allowlist row with removal date and owner.
Record the offboarding action in the Small Team AI Security Checklist.

Blocked category starter list

Block these categories unless a written exception exists:

Extensions that read or modify all websites for a vague productivity use case.
Extensions that run on password manager, identity provider, admin, payment, payroll, HR, legal, production, or source-code pages.
Extensions with cookies, clipboard read, broad webRequest, native messaging, file URL access, or incognito access.
Extensions with unclear AI model provider, training, retention, or human review behavior.
Extensions that connect to Gmail, Drive, Slack, CRM, helpdesk, or GitHub without role-based approval.
Extensions that cannot be removed centrally or that have no named owner.

Evidence checked

FAQ

Is an allowlist enough by itself?

No. The allowlist is the decision record. If your team manages Chrome, enforce it with browser policy. If you do not manage Chrome yet, use it as the manual source of truth for monthly reviews and offboarding.

Should we allow personal browser extensions for work?

No. Personal extensions should not run in work profiles that access customer data, source code, admin consoles, credentials, HR records, finance systems, or internal documents.

What if an extension is useful but needs broad access?

Put it in Pilot or Restricted, limit the users and domains, document the business reason, and set a short renewal date. Reject it if you cannot explain or enforce the access.

How often should we review the allowlist?

Monthly is enough for a very small team if you also review immediately after permission changes, vendor changes, incidents, and offboarding events.

What should we do first if we already have many extensions installed?

Export or inventory the installed extensions, put every AI-related extension into the allowlist, mark unknowns as Pending, and run the riskiest ones through the AI Tool Risk Checker.

Recommended next step

Copy the Browser Extension Allowlist template, add every AI browser extension currently used by your team, and mark anything with broad host access as Pending until reviewed.