OAuth Finds the SaaS Employees Sign Into. Our Chrome Extension Finds the Rest.

Why OAuth discovery is the right foundation

Lutril already discovers SaaS by reading OAuth grants from Google Workspace and Microsoft Entra ID. Every time an employee clicks "Sign in with Google" or "Sign in with Microsoft" to start using a new tool, the identity provider records a grant: which application was authorized, which scopes it was given, which user authorized it, and when. We read those grants through admin consent and turn them into a live inventory.

This is a strong baseline, and we want to be clear about why. It needs no endpoint agent. It is admin-consented, so it works across the whole organization from one connection rather than waiting for software to land on every laptop. And it is precise about the thing that matters most for risk: the scopes. For each discovered app, you see exactly what it can read or write (calendar, mail, files, full Drive access), who granted that access, when it was first seen, and who the first authorizer was. That is the difference between knowing an app exists and knowing what it can actually do with your data.

For most teams, connecting Google and Microsoft surfaces more apps in the first hour than the last year of asking around did. It is low friction, it is accurate, and it should be the first thing you turn on.

The structural blind spot

OAuth discovery has a boundary, and it is important to name it precisely. It is not a flaw in the approach. It is a coverage limit that follows directly from how the data is generated.

An OAuth grant only exists when an employee authorizes an app through your identity provider. If a tool offers "Sign in with Google," the grant is created and we see it. But a large share of SaaS does not get adopted that way. An employee finds a tool, signs up with their work email and a password, and starts using it. No OAuth handshake happens. No grant is ever recorded. The app is, by construction, invisible to grant-based discovery.

You can close part of this gap with network logs or a proxy, but those approaches are heavy: they require infrastructure changes, they often miss devices off the corporate network, and they tend to drown teams in raw traffic that has nothing to do with SaaS. We wanted something lighter, more accurate, and built specifically to report known SaaS usage and nothing else.

The launch: a Lutril browser extension

Today we are launching a Lutril browser extension, Chrome first, with Firefox next. It closes the email-and-password gap by reporting the known-SaaS domains an employee visits. If someone uses a tool in the browser, the extension can tell you the tool is in use, even when no OAuth grant was ever created.

Because a browser extension is the most sensitive thing you can deploy to an employee's machine, we will lead with privacy, since that is the first and most reasonable objection. The design choices below are not add-ons. They are the point.

It is force-installed, and employees do nothing

The extension is pushed to managed browsers through your MDM, the Google Workspace Admin console or Microsoft Intune. There is no install step for the employee, no login, no popup, no account to create. Admins generate one enrollment token and push it through managed configuration. From the employee's side, nothing changes about how they browse. That zero-friction deployment is what makes org-wide coverage realistic rather than a rollout project that stalls at 30 percent.

What it sends, and what it never sees

The single most important property of the extension is what it does not transmit. The filtering happens on the device, before anything leaves it.

To be concrete about each line:

• On-device filtering. The extension carries a curated catalog of known SaaS domains. It transmits a hostname only if that domain is on the catalog. A visit to your bank, your webmail, an internal wiki, or a news site matches nothing and never leaves the machine. There is no general browsing log, on your servers or ours.
• Hostnames only. When a known SaaS domain does match, the extension reports the hostname, for example notion.so, and nothing more. No full URL, no path, no query string, no page content. The signal is "this person uses Notion," not "this is the page they were on."
• Minimal permissions. The extension watches top-level navigations to know which site loaded. It does not request permission to read page content, and it does no scraping. The permission surface is deliberately small so a security reviewer can reason about it quickly.
• Per-device enrollment tokens. Each install enrolls with a per-device token that can be revoked individually, so you can cut off a single device without touching the rest of the fleet.
• Optional anonymized mode. If you operate in a works-council or GDPR context where per-user attribution is sensitive, you can run the extension in an anonymized mode that reports app usage at the organization level without attributing it to individuals. You still see which tools are in use, without naming who used them.

One inventory, two lenses

Apps the extension discovers do not land in a separate report. They flow into the same Shadow IT inventory as your OAuth-discovered apps, tagged with a "Browser Extension" source. Lutril then correlates the two signals by vendor, which is where the picture gets useful.

• An app seen by both SSO and the extension shows both sources. This is your high-confidence, actively-used inventory: authorized through your IdP and observed in real use.
• An app seen by OAuth only was authorized through SSO. You have the scopes and the authorizer, which is the right view for scope and access risk.
• An app seen by the extension only is the email-and-password Shadow IT that grant-based discovery could never surface. This is the category that was previously invisible.

Per-user attribution shows who used what, so a finding is actionable rather than just a count. Here is a sample of how the two sources resolve in one inventory:

The "Extension" rows are the ones that matter for this launch. Linear and Typeform were adopted with a work email and a password. No OAuth grant exists for either, so neither would have appeared in a grant-based inventory at all. The extension is what makes them visible, and per-user attribution tells you exactly which nine people are in that Linear workspace.

Deployment in practice

The whole rollout is an admin task. Employees are never asked to do anything. A short version:

1. Connect Google and Microsoft. This turns on the OAuth baseline and gives you the SSO-authorized inventory with scopes immediately.
2. Generate the extension enrollment token. In Settings, create the enrollment token Lutril uses to associate installs with your workspace.
3. Push the extension through your MDM. Force-install it via Google Workspace Admin or Microsoft Intune, and attach the managed configuration: the enrollment token, your workspace slug, and the user email (substituted per device by the MDM so each install reports the right person).
4. Watch the inventory fill in. Discovered domains roll up into the same Shadow IT inventory automatically, tagged by source and correlated against your OAuth grants.

When to use which

These are not competing approaches. They cover different surfaces, and the value is in running both. The short version of where each one earns its place:

OAuth tells you what an app is allowed to do with your data. The extension tells you the app is in use at all. Neither replaces the other. Run the OAuth baseline for scope risk, add the extension for the email-and-password long tail and the usage signal, and the Shadow IT inventory stops being an estimate and starts being a record.

If you have already connected Google and Microsoft, generating the extension token and pushing it through your MDM is a short afternoon, and it surfaces a category of Shadow IT you have never been able to see before. If you have not connected an identity provider yet, start there: it is the baseline everything else builds on.