Everyday AI data handling
Review AI browser add-on access
An AI browser extension can access company-page information only through the capabilities and access actually granted to it, combined with its implementation. Review the manifest, effective site grants and vendor data handling before approving confidential apps. An AI label or a familiar browser icon does not define the extension’s access boundary.
For Managed-browser and endpoint IT
Check declared capability and the permission actually granted.
Inert Chrome manifest example using reserved invalid hosts, with no scripts or extension installed.01
Read the permission declarations
Chrome documents several distinct manifest fields: API permissions, optional permissions, host permissions, optional host permissions and content-script match patterns. Review the fields that the actual extension uses rather than reducing the decision to a single install warning.
A declaration describes a capability or requested scope. It does not prove what the extension collects, where it sends information or whether the user has granted an optional permission. Match the declared capability to the extension’s purpose and obtain current vendor information about its implementation and recipients.
Source context: Chrome for Developers: Declare permissions
02
Make the allowed site scope concrete
For a tool intended to assist with an approved helpdesk, identify the exact application hosts it needs. Access to unrelated payroll, finance or customer systems requires its own justification. A broad pattern can cover more pages than the task requires, so examine domain and subdomain matching carefully.
The inert example manifest includes one required synthetic host and one optional synthetic documentation host. It contains no scripts and is not an install package. Its purpose is to show a concrete declared allowlist, not to configure a real extension or promise that the corresponding page access is already granted.
| Manifest field | Example scope | Review question |
|---|---|---|
| host_permissions | helpdesk.example.invalid only | Required for the approved task? |
| optional_host_permissions | docs.example.invalid only | When would a separate grant be needed? |
| content_scripts.matches | Inspect the real extension | Which pages can receive injected code? |
| permissions | Inspect the real extension | Which additional browser APIs are requested? |
Source context: Chrome for Developers: Declare permissions
03
Check the effective grant and change process
Compare the installed version and effective site access with the reviewed manifest. Optional capabilities may be granted at runtime, and permission changes may produce new warnings. Identify who can approve a broader scope through the organisation’s managed-browser process.
A policy record should distinguish declared, requested, granted and observed access. The worksheet leaves the real grant unverified. Do not treat a vendor’s narrow example as evidence that its current installed package or every user’s configuration has the same scope.
Source context: Chrome for Developers: Declare permissions
04
Review what happens after access is available
Ask which page data the extension processes for the feature, whether it obtains more context than the visible selection, and which service receives that information. Host permission is not a provider-retention policy or an employer disclosure approval.
Use a fictional task and synthetic site labels for the initial review. The downloadable record has no company credentials or actual application URL. If a live verification is needed, the authorised administrator should use an approved test environment and defined observations rather than exposing a confidential production page.
05
Keep approval tied to the extension version and task
Close the decision with the extension identity, reviewed version, necessary hosts, optional grants, data recipients and owner. Make a broader host request, changed permission or significant feature update a reason to revisit the approval.
This is a technical site-access review, not a claim that all AI extensions are harmful or that browser permissions alone establish safe data handling. Aona’s own supported AI input paths must be assessed separately from another extension’s capability to read or transmit page content.
Put it into practice
Browser extension permission and site review
Compare native manifest fields with a specific approved-host example and the actual grant.
Inert Chrome manifest example using reserved invalid hosts, with no scripts or extension installed.
| State | What it means | Evidence |
|---|---|---|
| Declared | Manifest requests a capability | Current package manifest |
| Granted | Browser or administrator allows it | Effective site-access record |
| Observed | Approved test shows an operation | Scoped synthetic observation |
| Permitted use | Employer approves that data/task | Owner decision |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# AI extension site-access review
manifest.review-only.json is an inert manifest illustration. It includes reserved invalid hosts and no code. Do not install it or treat it as a real vendor package. It makes no network requests or browser changes.
Compare its concrete required/optional host scopes with the current extension being reviewed. Complete site-access.csv and the decision record with non-secret administrative evidence. An installed extension’s implementation and data recipients require their own review.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/ai-browser-extension-company-data/
Source review: 2026-09-21
- Chrome for Developers: Declare permissions: https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions
manifest.review-only.jsonInspect
{
"manifest_version": 3,
"name": "Synthetic permission review only",
"version": "0.0.0",
"description": "Inert teaching example with no scripts. Not an install package.",
"permissions": [],
"host_permissions": [
"https://helpdesk.example.invalid/*"
],
"optional_host_permissions": [
"https://docs.example.invalid/*"
]
}
site-access.csvInspect
host_or_capability,declared_scope,needed_for_task,effective_grant,recipient_or_purpose,owner,decision
helpdesk.example.invalid,Required example host,REVIEW,UNVERIFIED,RECORD,ASSIGN,OPEN
docs.example.invalid,Optional example host,REVIEW,UNVERIFIED,RECORD,ASSIGN,OPEN
Unrelated company apps,Not in example allowlist,REVIEW,UNVERIFIED,RECORD,ASSIGN,OPEN
Additional API permissions,Review actual package,REVIEW,UNVERIFIED,RECORD,ASSIGN,OPEN
approval.mdInspect
# Extension access decision
Extension identity/version: ____________________
Approved task and hosts: ____________________
Required versus optional grants: ____________________
Content-script and additional API scope: ____________________
Data recipients/handling: ____________________
Change approver: ____________________
Decision: NOT YET REVIEWED
No actual grant is made by this file.
Before you proceed
Keep these distinctions clear
- Reviewing only the product name
- The installed manifest and effective grants describe access more precisely than an AI label.
- Treating host access as data approval
- The organisation still needs to understand collection, recipients and permitted use.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee AI usage and input paths on installed endpoints.
This guide does not claim Aona audits or blocks every third-party extension’s DOM access or network transmission.
Bring the approved task and extension data path to a scoped coverage discussion, using a synthetic page rather than confidential content.
Review your use caseFAQ
Questions for this decision
Does a host permission prove the extension reads every page there?
Are optional permissions irrelevant after installation?
Can I install the example manifest as a working AI extension?
Does approval for one confidential app cover all company sites?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Chrome for Developers: Declare permissions
Defines required/optional API and host permissions and content-script match patterns.
vendor · checked 2026-09-21