Installing an AI extension in your browser takes less than a minute. Before it activates, a permission screen appears that few people read all the way through: "read and change all your data on the websites you visit." That is the exact wording Chrome for Developers, Google's own documentation, attaches to any extension able to inject code into any open page — from a text summarizer to a translation sidebar.
The problem is that this permission does not distinguish ordinary pages from internal systems. It applies equally to the news site someone reads on a break and to the finance system they use all morning. According to the Enterprise Browser Extension Security Report 2025, from security firm LayerX, published in April 2025, 53% of extensions installed in enterprise environments can access sensitive data — passwords, page content, and browsing information. Among extensions that use AI, the share carrying permissions classified as high risk climbs to 58%.
For anyone deciding on technology at a company, the standalone number matters less than what it implies: an unknown third party the company never vetted or contracted ends up seeing the screen exactly as the employee does — at all times, in whatever system happens to be open.
What the permission actually authorizes
A browser's permission screen has no way to know the intent behind the code it is approving. A text summarizer and a password-stealing script technically use the same capability: a script that runs inside the page and can read or change anything in it. That is why the browser assumes the worst case and shows the broadest warning it has, regardless of whether the extension deserves that level of trust.
The same LayerX research helps explain why this risk stays invisible to most companies: 54% of installed extensions come from an unidentified author — just a generic email address —, 51% have not been updated in over a year, and 26% reach an employee's computer outside the official browser store, with no prior review at all.
None of these numbers describes any one extension as malicious. They describe an environment where the company does not know who wrote the program reading its employees' screens, or whether it will still be the same program tomorrow.
When the trusted extension becomes the way in

That last part — "still the same program tomorrow" — is exactly what real incidents make clear. In December 2024, according to security outlet The Hacker News, at least 35 Chrome extensions were compromised and more than 2.6 million installs were exposed to data theft. The way in was not a technical flaw in the browser: it was a phishing email addressed to the people who maintained those extensions, disguised as a notice from the Chrome store itself.
One of the companies hit, Cyberhaven, had an employee's account hijacked by that same kind of email. According to SecurityWeek, the attackers published a tampered version of the company's extension on the official Chrome store; it circulated for more than 24 hours before being pulled, collecting session credentials and account identifiers from anyone who had it installed — including people who never clicked anything suspicious, because the update simply arrived on its own, the way any trusted extension updates.
The same pattern shows up in newer AI tools. In November 2025, security firm SquareX disclosed, per SiliconANGLE, a barely documented feature in Perplexity's AI browser Comet: an internal channel that lets certain extensions run commands directly on the user's device — something traditional browsers block by default. No extension needs to be malicious from day one to become a problem; an update, a compromised developer account, or an obscure feature is enough.
What Has to Be in Place
A governed AI environment does not solve this with a "banned extensions" policy — it solves it with verifiable mechanisms that replace the plugin of unknown origin.
Sign-in through corporate identity, not an unknown personal account. Access to AI comes from the company's own user directory — each employee's digital badge; when someone leaves, access drops with them, without depending on someone remembering to revoke an extension installed on every machine.
Connections to systems function by function, never the whole tool. Instead of giving an AI agent full access to a finance or email system — the same "read and change everything" logic browser extensions rely on —, only the specific function a task needs gets turned on.
Human approval before a sensitive action. Critical documents and higher-risk actions can require two-step review and approval, with the person proposing separate from the person approving — configurable, not applied to every response.
An audit trail for every connection and every permission granted. Unlike an extension someone installed on their own, every link to a system gets logged: who authorized it, when, and with what scope.
Closing exactly that gap — the same "see everything" power going to a third party with no contract and no control — is why Skyller was designed the way it is: identity coming from the company directory, role-based access, and approval built in as the default, not as an extra setting.
The gain from swapping the loose plugin for a corporate agent

The security case alone is enough to justify the change, but there is a practical gain that often carries more weight in day-to-day decisions. When each employee decides on their own which extension to install, the company ends up with dozens of isolated tools, each one seeing a slice of a single person's screen — with no overall view for IT of what is actually connected.
A corporate AI environment flips that logic: a connection to a system gets approved once, by function, and becomes available to whoever needs it, under the same access control applied to any other company system. A platform like Skyller, for instance, keeps that kind of connection configurable function by function — instead of handing over full power all at once. IT stops discovering extensions after the fact and starts deciding, ahead of time, what is and isn't allowed to see the work screen.
That also changes the conversation about risk. Instead of asking "which extensions are installed on company computers today" — a question that, as the LayerX numbers show, most companies cannot actually answer —, the question becomes "which connections have we approved, for whom, and with what scope." The second question has an objective answer. The first, in ordinary corporate practice, rarely does.
A Starting Roadmap
Before deciding to ban or allow AI extensions on a case-by-case basis, it's worth bringing these questions to the next conversation with IT:
- Inventory what's already installed. Without that list, no decision about AI extensions is based on fact — it's a guess about what the team might be using.
- Check who has "read and change everything" access, and where. Not every extension with that permission is a problem, but no decision should be made without knowing which ones have it.
- Offer an official path before banning the personal alternative. A policy without an alternative tends to reduce the visibility of the use, not the use itself.
- Treat an extension update like a vendor change. The program the company approved yesterday may not be the one running today, without anyone having decided that.
- Measure the scope of each connection, not just whether it exists. The right question isn't "does the team use AI in the browser," it's "what can this specific connection see and change."






