playbook

Chrome Enterprise extension policy for startups

A practical startup playbook for using Chrome Enterprise extension policy to block unknown extensions, allow approved AI tools, restrict sensitive sites, and manage offboarding.

Published: Jun 23, 2026 Last reviewed: Jun 23, 2026 Audience: Startup founders, Google Workspace admins, operations leads, IT owners, engineering managers, and security-conscious teams that need lightweight Chrome extension controls Risk: Medium Evidence: Chrome Enterprise policy list, ExtensionSettings policy, extension install blocklist and forcelist policies, Chrome Web Store enterprise publishing guidance, and Cybergiz browser-extension approval templates

Bottom line

Startups do not need a heavyweight security program before they control browser extension risk. The first useful Chrome Enterprise policy is simple: block unknown extensions by default, allow only approved extension IDs, restrict where approved extensions can run, and review the allowlist every month.

Use this page after you create a Browser Extension Allowlist template. The allowlist is the decision record. Chrome Enterprise policy is the enforcement layer.

Startup policy matrix

Startup stage	Extension problem	Recommended policy
1-10 people, unmanaged browsers	Employees install personal AI extensions in work profiles.	Create allowlist, require approval, separate work and personal profiles.
10-25 people, Google Workspace in place	Gmail, Docs, Drive, CRM, and admin tabs are exposed to unknown extensions.	Block unknown extensions and allow approved IDs.
25-50 people, more SaaS tools	Approved extensions need access to only a few sites.	Add runtime allowed and blocked hosts.
Engineering or support team uses AI extensions	Source code, tickets, customer data, and logs may be visible.	Add role-based extension rules and high-risk domain blocks.
Offboarding is inconsistent	Former employees or role-changed users keep extension/OAuth access.	Pair Chrome policy with OAuth revocation and monthly review.

Minimum policy set

Use these policy concepts as the baseline:

Policy concept	What it does	Startup default
Extension install blocklist	Blocks extension installation broadly.	Block unknown extensions.
Extension install allowlist or allowed IDs	Allows specific approved extensions.	Allow only extensions in the approved register.
ExtensionSettings	Defines per-extension installation mode, blocked permissions, allowed hosts, and blocked hosts.	Use for AI extensions and sensitive workflows.
Runtime blocked hosts	Stops extensions from running on selected sensitive domains.	Block admin, finance, identity, HR, source-code, and customer-data sites.
Runtime allowed hosts	Limits approved extensions to specific sites.	Use for extensions that only need Docs, CRM, or one internal app.
Blocked permissions	Blocks risky permission categories for an extension.	Block cookies, broad traffic access, or other risky permissions where possible.
Force install	Installs an approved extension automatically.	Use sparingly for core managed tools only.

Avoid force-installing convenience AI extensions early. Approval and restriction are usually better than pushing another tool to every employee.

Default block policy

Start with a default-deny shape:

{
  "*": {
    "installation_mode": "blocked",
    "blocked_install_message": "Request approval before installing browser extensions for company work."
  }
}

Then add approved extensions one by one. Do not skip the allowlist record. You need the owner, business use case, renewal date, and offboarding action before enforcement is useful.

Approved extension policy

For a narrowly approved extension:

{
  "approvedextensionid1234567890abcdef": {
    "installation_mode": "allowed",
    "runtime_allowed_hosts": [
      "*://docs.google.com/*"
    ],
    "runtime_blocked_hosts": [
      "*://mail.google.com/*",
      "*://*.admin.example/*",
      "*://*.finance.example/*",
      "*://*.idp.example/*"
    ],
    "blocked_permissions": [
      "cookies",
      "webRequest"
    ]
  }
}

Treat this as a pattern, not copy-paste production config. Replace extension IDs and domains with your actual environment. Test on one pilot group before company-wide rollout.

Sensitive host list

Build the blocked host list from real startup workflows:

Host category	Examples	Default extension rule
Identity and admin	Google Admin, IdP, Cloudflare, Vercel, AWS, GitHub org settings	Block extension runtime access.
Customer data	Helpdesk, CRM, customer portals, support inboxes	Restrict to approved tools and roles.
Source code and production	GitHub, GitLab, CI, logs, error trackers, deployment dashboards	Block unless approved for engineering.
Finance and payments	Stripe, bank, payroll, accounting, invoicing	Block.
HR and recruiting	ATS, employee files, candidate records	Restrict with HR owner approval.
Email and documents	Gmail, Google Docs, Drive, Microsoft 365	Restrict to named workflows.
Credentials	Password manager, secrets vault, API key pages	Block.

If an AI extension claims it needs all-sites access, use this list to decide where it must not run.

Rollout checklist

Roll out in this order:

Create an extension allowlist with owner, extension ID, approved roles, allowed sites, blocked sites, permissions reviewed, review date, and renewal date.
Inventory currently installed AI browser extensions.
Mark each extension as Approved, Restricted, Pilot, Pending, Blocked, or Removed.
Decide the first blocked host list: identity, finance, HR, admin, source-code, and customer-data systems.
Pilot Chrome policy with one browser profile or one group.
Confirm blocked installs show a clear message.
Confirm approved extensions still work on allowed sites.
Confirm approved extensions do not run on blocked sites.
Document rollback steps before broader rollout.
Re-score high-risk tools with the AI Tool Risk Checker.

Do not start with a complex company-wide policy. Start with one group, one blocked default, and a short allowlist.

Role-based rules

Small teams can still apply role rules:

Role	Extension policy
Everyone	Block unknown extensions.
Sales	Allow approved CRM/email assistant only if Gmail and CRM scopes are reviewed.
Support	Restrict tools that can read customer tickets or Gmail threads.
Engineering	Block extensions on source-code, CI, secrets, logs, and production dashboards unless approved.
Recruiting	Restrict tools that touch candidate email, ATS pages, and interview notes.
Finance/HR/Admin	Block AI extensions on finance, HR, payroll, identity, and admin consoles.

If your Chrome management setup cannot easily express this yet, keep the policy simpler: one company default and a small list of tightly approved extensions.

Exception record

Copy this when an extension needs more access than normal:

Chrome extension policy exception

Extension name:
Extension ID:
Vendor:
Requested policy exception:
Business owner:
Admin owner:
Users or group:
Allowed hosts:
Blocked hosts:
Blocked permissions:
Reason broad access is needed:
Data types exposed:
Compensating controls:
Pilot start:
Pilot end:
Renewal date:
Rollback plan:
Reviewer:
Decision: Approved / Restricted / Pilot / Rejected

An exception without a renewal date should be treated as rejected.

Maintenance cadence

Use this cadence:

Frequency	Action
Weekly during rollout	Review policy blocks, user complaints, and broken workflows.
Monthly	Review allowlist owners, unused extensions, blocked attempts, and new requests.
Quarterly	Re-check high-risk extensions, vendor ownership, permission changes, and OAuth scopes.
During offboarding	Remove extension access, revoke connected apps, and update the allowlist.
After incident	Move affected extension to blocked or restricted status until root cause is closed.

Record maintenance in the Small Team AI Security Checklist.

Evidence checked

FAQ

Should a startup block all browser extensions?

Block unknown extensions by default, then allow approved ones. A blanket block with no approval process will push employees toward unmanaged personal profiles.

Should we force-install approved AI extensions?

Usually no. Force-install only core managed tools with clear business value. AI convenience extensions should usually be allowed for specific roles, not pushed to everyone.

What should we block first?

Start with password managers, identity provider pages, admin consoles, payment systems, payroll, HR, source-code repositories, CI/CD, production dashboards, customer support tools, and Gmail/Docs/Drive unless a workflow is approved.

Is Chrome policy enough for Gmail and Drive access?

No. Chrome policy controls browser extension installation and runtime behavior. If the tool uses Google OAuth, also review and revoke connected app scopes.

What if an employee needs an extension urgently?

Use a time-limited Pilot exception with named users, allowed hosts, blocked hosts, renewal date, and rollback plan.

Recommended next step

Create a short allowlist, block unknown extensions for one pilot group, and map the highest-risk extensions through the Browser Extension Allowlist template before enforcing the policy company-wide.