checklist
AI browser extension risk scoring matrix
A practical scoring matrix for rating AI browser extensions by permissions, data access, OAuth scopes, automation behavior, vendor risk, deployment scope, and offboarding complexity.
Use this matrix before approving an AI browser extension for a team, not after it has already spread across every laptop.
The score is not a legal or compliance opinion. It is a fast operating tool for deciding whether an extension should be allowed, restricted to a pilot group, or blocked until a stronger business case exists. If the result is unclear, run the extension through the AI Tool Risk Checker and record the decision in the Small Team AI Security Checklist.
Bottom line
An AI browser extension becomes high risk when it combines broad page access, sensitive work apps, OAuth access, automation, weak vendor signals, and loose offboarding. A narrow extension that runs only after a user click on one approved domain is a different risk from an assistant that can read every page, connect to Gmail or Drive, and act across customer systems.
Use the total score for the normal decision, then apply the critical triggers as overrides.
Scoring levels
| Score | Meaning | Default decision |
|---|---|---|
| 0 | No meaningful browser or account data access. | Allow if there is a real business use case. |
| 1 | Limited, user-triggered, low-sensitivity access. | Allow with an owner and review date. |
| 2 | Narrow but persistent access or moderate business data. | Restrict to the relevant role or host. |
| 3 | Broad access to sensitive business systems or persistent automation. | Pilot only with admin review and logging. |
| 4 | Critical access to all sites, regulated data, account systems, source code, finance, HR, admin consoles, or weak vendor/offboarding controls. | Block unless leadership records an exception. |
Score each dimension from 0 to 4, then add the six scores.
Risk scoring matrix
| Dimension | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| Permission scope | No page access. | activeTab or equivalent user-triggered access on one approved page. | Limited host permissions for approved work domains. | Persistent access to several work apps. | Broad host access such as all HTTP/HTTPS sites, file URLs, incognito access, or sensitive browser APIs. |
| Data sensitivity | Public pages only. | Low-sensitivity internal pages. | Routine customer or operations data. | Customer records, support tickets, private docs, CRM notes, or meeting transcripts. | Password manager, SSO, admin, finance, HR, regulated data, source code, production, Gmail, Drive, or Docs at scale. |
| OAuth and connectors | No OAuth or connected app. | Basic sign-in only. | Read-only scope for one approved app. | Write scopes or access to customer/support systems. | Gmail, Drive, Docs, CRM, Slack, source-control, password-manager, or admin scopes without narrow limits. |
| Automation behavior | Passive helper with no data export. | User-clicked summary or rewrite. | Copies selected data into an AI service. | Agentic actions, auto-fill, auto-send, auto-update, or cross-app workflows. | Can submit forms, send messages, alter records, trigger workflows, or operate without clear human confirmation. |
| Vendor and update risk | Known vendor, clear policy, enterprise controls, stable update history. | Known vendor with acceptable documentation. | Small vendor but clear privacy/security docs and support channel. | Thin documentation, unclear subprocessors, or frequent permission changes. | Unknown vendor, no useful policy, suspicious update history, or no way to identify support/security owner. |
| Deployment and offboarding | One test user, easy removal, no account connection. | Small role group with owner. | Department deployment with allowlist record. | Many users or multiple roles; OAuth and extension removal both required. | Broad deployment, unmanaged installs, no inventory, no offboarding owner, or hard-to-revoke account connections. |
Permission score
Start with the Chrome extension permissions, then inspect host permissions and content script match patterns. Chrome documents separate permission areas such as permissions, optional_permissions, content_scripts.matches, host_permissions, and optional_host_permissions; host permissions can allow an extension to interact with matching URLs.
Use this quick rule:
| Permission pattern | Suggested score | Notes |
|---|---|---|
| No content scripts, no host permissions | 0 | Still check OAuth and vendor risk. |
activeTab only | 1 | Chrome describes activeTab as temporary access after a user invokes the extension. |
| One approved host, such as the public website CMS | 2 | Require a business owner and renewal date. |
| Multiple sensitive work hosts | 3 | Use a pilot group and a host allowlist. |
| All URLs, file URLs, incognito access, cookies, tabs, webRequest, or broad content scripts | 4 | Treat as a critical trigger when paired with sensitive data. |
Do not score only from the Chrome Web Store permission label. Open the extension details, review the manifest when possible, and compare it to the pre-install review workflow.
Data access score
The same permission can mean different things depending on where employees use it. A summarizer on public web pages is not the same risk as a summarizer on Gmail, Google Docs, a CRM, or a password manager.
| Data exposed in normal use | Suggested score | Approval rule |
|---|---|---|
| Public web pages | 0-1 | Allow if the extension does not export hidden page data. |
| Internal wiki or process docs | 1-2 | Restrict to role and purpose. |
| Support tickets, sales notes, customer files, meeting transcripts | 3 | Require customer-data approval and retention rules. |
| Gmail, Drive, Docs, SSO, admin consoles, source code, finance, HR, password manager | 4 | Block or require a written exception. |
If the extension can read Gmail or Docs, use the deeper checklist in AI extensions that can read Gmail or Google Docs before approving it.
OAuth and connector score
Browser permissions are only half the review. Many AI extensions also ask users to sign in with Google or connect SaaS accounts. Google Workspace app access controls let admins review configured apps, accessed apps, and apps pending review; Google also distinguishes access levels such as Trusted, Specific Google data, Limited, and Blocked.
Score OAuth separately:
| OAuth pattern | Suggested score | Required evidence |
|---|---|---|
| No OAuth or connected account | 0 | Confirm the extension still works without account sync. |
| Basic sign-in only | 1 | Record the OAuth client and vendor. |
| Read-only access to one approved service | 2 | Record exact scope and owner. |
| Write or export access to a customer/work system | 3 | Require admin approval and a pilot limit. |
| Gmail, Drive, Docs, CRM, Slack, source-control, password manager, admin, finance, or HR scopes | 4 | Treat as critical unless tightly scoped and approved. |
When Google Workspace is the source system, check API Controls before approving the extension and again during offboarding.
Automation score
AI browser extensions often move from “summarize this page” to “take action for me.” Score action-taking higher than reading.
| Behavior | Suggested score | Control |
|---|---|---|
| Summarizes selected text after a user click | 1 | Require the user to choose the text. |
| Reads the full current page after a click | 2 | Restrict hosts and data types. |
| Writes drafts, fills forms, updates fields, or copies data between apps | 3 | Require human confirmation and audit notes. |
| Sends messages, submits forms, updates CRM/customer records, changes admin settings, or runs hidden workflows | 4 | Block unless the workflow has a documented approval path. |
Do not approve action-taking behavior just because the UI feels like a chat assistant. Score the real system effect.
Vendor and update score
Small teams often skip this dimension because it feels less urgent than permissions. That is a mistake. Browser extensions can update quickly, and permission changes can change the risk profile.
Score 3 or 4 when:
- The vendor does not clearly identify the company, support path, privacy policy, or security contact.
- The extension changed permissions recently without a clear release note.
- The vendor gives no useful explanation of data retention, model training, subprocessors, or deletion.
- The extension is maintained by an individual account for a critical team workflow.
- The vendor cannot support workspace-level administration, auditability, or revocation.
If the tool is useful but vendor confidence is weak, keep the pilot narrow and make renewal explicit.
Deployment score
Deployment risk grows with the number of users and the difficulty of removal.
| Deployment scope | Suggested score | Admin action |
|---|---|---|
| One reviewer account | 0-1 | Time-box the test. |
| One role group | 1-2 | Add it to the browser extension allowlist. |
| Whole department | 3 | Require Chrome policy and OAuth review. |
| Company-wide, unmanaged, or hard to inventory | 4 | Block until inventory and offboarding are ready. |
If you use Chrome Enterprise controls, map the decision to allowlist/blocklist rules and keep the extension ID in the approval record.
Decision thresholds
| Total score | Decision | Required action |
|---|---|---|
| 0-4 | Low | Allow with owner, use case, and review date. |
| 5-8 | Medium | Restrict to role, approved hosts, and approved data types. |
| 9-13 | High | Pilot only with admin owner, blocked hosts, OAuth review, and renewal date. |
| 14+ | Critical | Block unless there is a written exception and compensating controls. |
Critical triggers override the total score. Treat the extension as critical if any of these are true:
- Broad all-sites access plus customer, employee, financial, source-code, or admin data.
- Access to password managers, SSO, admin consoles, finance, HR, production, or source-control pages.
- OAuth access to Gmail, Drive, Docs, CRM, Slack, source control, or password managers without narrow controls.
- Automated sending, submitting, updating, or record-changing behavior.
- Unknown vendor, no usable policy, or no support/security contact.
- No inventory, no extension owner, or no offboarding path.
Approval record
Copy this into your approval tracker.
AI browser extension risk score
Extension name:
Extension ID:
Vendor:
Business owner:
Admin owner:
Users or group:
Requested use case:
Permission score:
Data access score:
OAuth and connector score:
Automation score:
Vendor and update score:
Deployment score:
Total score:
Critical triggers:
Allowed hosts:
Blocked hosts:
OAuth scopes reviewed:
Data types exposed:
Decision: Approved / Restricted / Pilot / Blocked
Renewal date:
Offboarding owner:
Reviewer:For removal steps, keep the browser extension offboarding checklist linked from the same record.
Review cadence
| Situation | Review timing |
|---|---|
| New low-risk extension | After 30 days, then every 6 months. |
| Medium-risk extension | After 30 days, then every quarter. |
| High-risk pilot | Weekly during the pilot, then decide approve/restrict/block. |
| Permission change | Re-score before allowing the new version. |
| New OAuth scope or connected app | Re-score before users authorize it. |
| Role change or employee exit | Run the offboarding checklist immediately. |
Evidence checked
- Chrome Extensions: Declare permissions
- Chrome Extensions: The activeTab permission
- Chrome Extensions: Match patterns
- Chrome Enterprise policy list: ExtensionSettings
- Chrome Enterprise policy list: ExtensionInstallBlocklist
- Chrome Enterprise policy list: ExtensionInstallAllowlist
- Google Workspace Admin Help: Control which apps access Google Workspace data
- Cybergiz: Browser extension allowlist template
- Cybergiz: Browser extension offboarding checklist
- Cybergiz: AI Tool Risk Checker
FAQ
Should activeTab always be allowed?
No. activeTab is usually lower risk than persistent all-site access because it depends on a user action and is temporary, but the risk still depends on where employees use it and what the extension sends to the vendor.
Is a Chrome Web Store listing enough evidence?
No. Use the listing as a starting point, then review permissions, host access, OAuth scopes, vendor documentation, and deployment controls. For employee guidance, pair this matrix with the Chrome AI extension permissions explainer.
What score should block an extension?
Block at 14 or higher by default. Also block any extension with a critical trigger unless the business owner records an exception and the admin owner can enforce the required controls.
How should a small team handle an extension that only one executive wants?
Score it like any other extension. If it touches sensitive systems, use a named pilot account, limited hosts, an expiration date, and explicit offboarding. Executive preference is not a control.
Should browser extensions be reviewed separately from SaaS AI tools?
Yes. Browser extensions can observe the pages employees visit and may combine page access with account-level OAuth. Review the browser layer and the connected-app layer separately, then keep the final result in your AI tool inventory.
Recommended next step
Pick the highest-risk AI extension already installed by your team, score it with this matrix, then run the result through the AI Tool Risk Checker. If the score is medium or higher, add the decision to the Small Team AI Security Checklist and set a renewal date.