Shadow SaaS: the surface of apps nobody approved and nobody is watching

Shadow IT existed long before generative AI became a security topic — and it's still there, in parallel, at a scale most companies underestimate. Marketing teams sign up for an automation tool, product teams connect an analytics app, someone in finance authorizes a cloud spreadsheet with "Sign in with Google" — all in minutes, with no procurement and no security review involved.

The problem is rarely the tool itself. It's that nobody on the security team knows it exists, what data it receives, or what level of access it was granted the moment someone clicked "allow" on an OAuth authorization screen.

Why shadow SaaS never actually got solved

The adoption barrier has collapsed in recent years: most modern SaaS tools don't even require a corporate card — a social login via Google or Microsoft is enough, and the account exists. That takes any new tool entering the environment completely off the radar of traditional procurement controls.

Unlike buying a server or signing an enterprise license, this kind of adoption generates no visible invoice for finance and no ticket for IT — it just appears, months later, when someone audits granted OAuth permissions and finds dozens of applications nobody remembers authorizing.

What's exposed when nothing gets vetted

Every "Sign in with Google" or "Sign in with Microsoft" grants a permission scope — sometimes read access to email, calendar, or a file in Drive or OneDrive — that's rarely reviewed again after the initial grant. A seemingly harmless productivity app can have read access to the entire corporate inbox of whoever authorized it, and keep that access indefinitely.

This is structurally different from the risk shadow AI represents — there the central risk is data leaking through a prompt; here it's persistent access granted through an integration, which outlives the tool's active use by a wide margin.

Discovery before blocking, again

The same logic that applies to shadow AI applies here: trying to block before mapping is starting at the end. CASB and SSPM (SaaS security posture management) tools can today list which applications have active OAuth in the environment, with what permission scope, and used by how many people — information that typically surprises even mature security teams the first time they run that report.

Only with that inventory in hand is it possible to decide with any real criteria: which integrations deserve formal approval, which have a permission scope disproportionate to the value they deliver, and which should be revoked without pushback, because nobody has touched them in months.

The risk that outlives the employee who leaves

A recurring pattern: an employee authorizes a dozen applications over two years at a company, leaves, and the offboarding process revokes their access to core systems — but never touches the third-party OAuth integrations they authorized individually. Those applications keep active access to corporate data, unmonitored, potentially for years.

It's the same kind of gap that shows up in machine identity with no clear owner — except here the credential was born from an individual employee's action, not a technical pipeline, which makes it even easier to forget during offboarding.

Small on its own, structural in the aggregate

No single integration looks like much of a risk — which is exactly why the sum of them becomes a blind spot. Companies that have already mapped shadow SaaS tend to discover dozens, sometimes hundreds, of applications with some level of access to corporate data, most never evaluated by anyone. That volume, more than any single app, is the real size of the problem — and why treating the security stack as a sum of isolated decisions always underestimates the actual risk.

No app is too small to audit

The right question was never "do we ban the new tool" — it's "do we know what's already connected, with what access, and does it still make sense." UNIQ helps clients build that SaaS visibility as part of the Cloud & SaaS architecture, without treating every discovered app as an incident — just as data that was missing.