Browser and Endpoint Evidence

Endpoint management already reports installed software and, in many configurations, browser extensions. For AI discovery this is the most informative technical source.

Applying the boundary described in “Browser and Endpoint Evidence” requires a clear operational purpose and a record that can be reviewed without reading private content. Teams considering work time tracking tools can use workload and time evidence to understand how approved processes are actually used, while keeping AI discovery, security telemetry and employee monitoring separate and proportionate.

For an independent benchmark, compare the local approach with OWASP GenAI Security Project; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

What it shows

Installed AI clients and desktop applications.

Browser extensions, which is where a great deal of this lives.

Which approved applications have AI features enabled.

And developer tooling: coding assistants, local model runners.

The extension problem specifically

Extensions can read page content, and many AI extensions do by design.

Which means an extension on a browser used for a confidential system is sending that content somewhere, regardless of what the user intended.

This is the single most concrete risk discovery usually finds, and it is invisible to network logs because the traffic looks like ordinary browsing.

List your installed extensions. Most organisations have never looked.

Local models

A growing category: models running on the device itself.

Lower data risk, because nothing leaves.

Higher resource cost, and a licensing question about the model weights.

Worth finding and worth treating differently from cloud services, since the main risk — data leaving — does not apply.

The line to watch

Endpoint tooling can report far more than installed software: what is typed, what is on screen, what is in the clipboard.

For discovery you need the software inventory, not the activity.

Resist the extension of scope, because once this programme is collecting keystrokes it is a monitoring programme and the consultation requirements and the trust position both change.

Its own note covers prompt content and why it is a separate decision.

Making it useful

Inventory by tool, counted, with department attribution at a level above the individual.

Flag anything with page-reading permissions.

And compare against the approved list to find what people installed and what arrived with an update.

The update surprise

Tools gain AI features in updates without anybody choosing.

An approved tool in January can be an AI tool in March.

Which means this is not a one-off check, and the policy section's point about reviewing as tools change applies here first.

What to check

Do you have a list of installed browser extensions?

Which of them can read page content?

Has anybody checked which approved tools gained AI features this year?

And is your endpoint collection limited to inventory rather than activity?

The point

Browser extensions can read page content by design, which means one on a machine used for a confidential system is sending that content somewhere regardless of intent..

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.