The Permission Portfolio: Auditing Browser Extensions and AI Plug-Ins in 2026

The software layer nobody procured

Most UK organisations can produce a reasonably accurate list of the SaaS platforms they pay for. Far fewer can describe the small programs sitting inside their staff browsers, reading pages, modifying interfaces and, in some cases, holding tokens that reach email, calendars and customer records. These tools rarely pass through procurement. They arrive because a member of staff found a useful sidebar, a summarising assistant, a password helper, a tab manager or a plug-in that promises to draft replies faster.

The result is an extension estate that grows by accretion. It is not a single system with an owner, a renewal date and a supplier review. It is a scattered set of permissions attached to individual browser profiles, sometimes synced across devices, occasionally abandoned but still installed. For decision-makers in 2026, the question is not whether browser extensions belong in the workplace. They plainly do. The question is whether the organisation can say which ones are present, what they can reach and why they are still there.

This is cyber security work, but it should not be framed as a campaign against convenience. A blanket ban tends to drive usage underground and encourages staff to find workarounds. A more durable approach is to treat extensions as a portfolio: visible, scored, reviewed and governed by a policy that distinguishes between low-risk utilities and tools that can read the contents of a mailbox.

Why permission sprawl is the real issue

The risk from a browser extension is rarely about the code alone. It is about the combination of access and context. A plug-in that changes the colour of a web page is not equivalent to one that can read and modify data on every site a user visits. A tool that requests access to all sites, the clipboard and the ability to manage downloads is in a different category from a narrow utility confined to a single domain.

Permission sprawl becomes more serious when the browser is the working environment. For many UK teams, the browser is where email, finance systems, HR platforms and customer relationship management tools are used. An extension with broad host permissions may be able to observe page content across those services. If it also holds an OAuth token or a session cookie, the consequences of a compromised update or an over-broad integration can extend well beyond the individual user.

AI assistant plug-ins deserve particular attention. They often request access to page content, form fields and sometimes email or calendar data in order to generate summaries, drafts or meeting notes. That can be genuinely useful, but it also creates a data flow that may not have been assessed. Staff may assume that because a tool appears in a reputable browser store, it has been approved by the organisation. In practice, store listing is not a security review, and popularity is not a control.

Build a simple inventory before debating policy

An audit does not need to begin with a complex platform rollout. It can begin with a structured request for information and a small number of technical checks. The aim is to produce a defensible picture of what is installed, not to achieve perfect real-time visibility on day one.

A practical inventory should capture the extension name, the browser and profile where it appears, the user or team associated with it, the source store, the permissions requested, whether it is still actively used and whether it was ever approved. For managed devices, endpoint management or browser management tools may be able to report installed extensions centrally. For unmanaged or hybrid estates, a short survey combined with a review of browser sync settings may be necessary.

The inventory should also distinguish between extensions and AI plug-ins that are embedded in approved platforms. An AI feature switched on inside a sanctioned productivity suite is a different risk decision from a third-party extension that reads the same data. Both matter, but they follow different approval routes.

A risk score that supports decisions

A simple scoring method is more useful than a lengthy questionnaire that nobody completes. Score each extension against a handful of factors: breadth of host permissions, access to sensitive data such as email or customer records, ability to modify page content, whether the publisher is known and contactable, whether the extension auto-updates, and whether there is a clear business owner. Add a flag for tools that are no longer used but still installed.

The output should place extensions into three broad groups. Low-risk utilities can remain with normal user guidance. Medium-risk tools should require a named owner, a documented purpose and a periodic review. High-risk tools, particularly those with broad access to email or SaaS data, should be paused pending a security assessment or replaced with a safer alternative.

This scoring approach also helps with the awkward conversations. Rather than arguing about whether a particular extension is good or bad in the abstract, the organisation can discuss specific permissions and specific data flows. That is a more productive basis for a decision, and it creates a record that can be revisited when the tool updates or changes hands.

Policy controls that preserve productivity

Good policy sets boundaries without pretending that staff will never use browser tools. A UK organisation might permit extensions from a defined allow-list, require approval for anything that requests access to email or all sites, and prohibit tools that cannot be traced to a identifiable publisher. Browser management can enforce some of this automatically, but the policy should still be understandable to the people it affects.

Review cadence matters. Extensions change ownership, update permissions and sometimes become dormant. A quarterly review of the highest-risk tools, combined with an annual full inventory, is a proportionate rhythm for many organisations. The review should ask whether the business need still exists, whether a sanctioned platform now provides the same function and whether the permission set has expanded since approval.

Staff should also have a clear route to request a new tool. If the only available answer is a silent refusal, shadow usage will return. A short approval form that asks what data the tool needs and why can be enough to separate genuine productivity gains from unnecessary exposure.

The board-level point

Browser extensions are a useful test of whether an organisation's cyber governance reaches the tools people actually use. They sit outside traditional procurement, they cross the boundary between personal productivity and corporate data, and they change frequently. An organisation that can inventory them, score their permissions and explain its policy is in a stronger position than one that can only say it trusts staff to be sensible.

The work is not glamorous. It involves spreadsheets, browser settings and conversations about why a particular assistant is still installed. But it closes a gap that many UK organisations have not yet examined, and it does so without removing the everyday tools that make modern work practical.