An AI usage inventory almost always produces the same list: ChatGPT, Copilot, Gemini, perhaps Claude. What rarely appears on it are the fourteen extensions installed on the same laptop, four of which hold access to all sites and two of which grew an AI feature last year.
This article is about us as well, because we ship a browser extension. That makes it an awkward subject, and that is exactly why it is worth writing.
What "access to all sites" means
At install, the browser shows which permissions an extension is requesting. The broadest variant is access to your data on all websites. In practice: the extension can read the contents of every page you open, and usually modify them.
That is a wider reach than most AI services have. ChatGPT sees what you type into ChatGPT. An extension with these permissions sees your webmail, your CRM, your case system, the intranet, and the field you are typing into, whatever site you are on.
No vulnerability is required to get there. It is a consent someone gave once, usually within two seconds, usually with no administrator present.
Three ways this gets away from you
The permissions stay, the function changes. An extension that adjusted colours three years ago gained an AI assistant last year. The permissions were already broad enough. There was no fresh approval moment, because nothing new was requested.
Acquisitions. A popular extension is bought and the new owner inherits the installed base and the permissions. There are documented cases where that was used to add behaviour the original author never wrote, with automatic updates pushing it to everyone.
The forgotten extension. Installed for one task two years ago, quietly present ever since with full read access.
What the three share: the risk does not arise at install, it arises afterwards, and no moment exists at which anyone looks again.
Why this belongs in your AI inventory
If you are mapping which AI services are in use, an extension with an AI feature is an AI service. It processes text, it sends it somewhere, and there is a vendor behind it with a jurisdiction and terms.
So the questions are the same as for any tool: what leaves, to whom, where is that party established, what is retained, and is there a processing agreement? See approving an AI tool: what to ask the vendor.
The difference is that extensions almost never went through procurement. They arrived the way most shadow AI arrives: through somebody trying to get their work done faster.
And about ourselves
BeeSensible is a browser extension with read access to the pages it works on. If we mean the above, we owe the same answers about ourselves.
The text you type is analysed to determine what is sensitive. In local mode that happens on your own machine and no text leaves the device, not even a check value of it. In cloud mode the text reaches our processing in the EU, is evaluated in working memory and discarded immediately, with no storage. What is recorded in either case, where the organisation has analytics enabled, are value-free events: which type of data, which level, which app, which timestamp, which action. No text.
That is the question you should be putting to us, and it is the same question the other thirteen extensions deserve.
Bringing them under control
- Inventory. In a managed browser estate you can read out which extensions are installed and what permissions they hold. Without management this becomes asking people, which produces an incomplete picture.
- Work from an allowlist. Blocking everything fails, because people need them. A short approved list works, provided there is a route to add something to it.
- Reassess on ownership change. The event most often missed.
The reason to spend effort here is not that extensions are more dangerous than other software. It is that they are the only category where the employee picks the vendor, approves the permissions and accepts the terms, all inside a single click.