The average mid-market company now runs more than 370 SaaS apps, and IT has visibility into roughly a third of them. The rest get signed up for with a credit card and a work email between standup and lunch. A legacy secure web gateway was never built for that pace, and by 2026 the gap has become the single biggest source of silent data exfiltration in most environments.
This post explains what a modern secure web gateway actually sees, what it should control, and how to tell the difference between marketing sprawl coverage and real tenant-level enforcement.
Why SaaS Sprawl Outruns Legacy SWGs
Old-school SWGs were designed to categorize destinations. Gambling, adult content, social media, webmail. That worked when employees opened ten websites a day. It does not work when every function in the business has three overlapping SaaS tools and most of them share a parent domain.
Category Lookup Is Not Visibility
A domain-category match tells you that traffic went to a productivity suite. It does not tell you which tenant, which account, or which action. A user uploading a customer list to their personal workspace and a user collaborating on a sanctioned corporate doc look identical at the category layer.
Backhaul Adds Friction, Not Insight
When every packet rides a tunnel to a cloud security stack, performance drops and users route around the gateway. PAC files get edited, split tunneling gets enabled, and new SaaS apps quietly skip inspection. Latency is the enemy of coverage.
Shadow SaaS Signs Itself Up
By the time a domain shows up in a discovery report, the trial is usually over and the data is already inside the vendor. A legacy secure web gateway that only reviews logs weekly will always be one payroll cycle behind the business.
What Next-Gen Visibility Looks Like
A modern swg inspects traffic on the device, before it leaves the user’s machine. That placement changes what the product can see and what it can do.
Tenant-Aware Inspection
On-device SSL inspection with native HTTP/2 support lets the agent parse the actual session and pull out tenant identifiers. The console can now distinguish a corporate Google Workspace tenant from a personal Gmail, or a sanctioned Notion workspace from a side-project one, without breaking the protocol.
Action-Level Policy
Visibility is not enough. You want to allow read access to a sanctioned tenant, block upload to a personal tenant, and warn on download from a newly discovered tenant. Action-level rules require the gateway to understand verbs, not just destinations.
Zero-Config Classification
When an employee pastes a customer list into a GenAI prompt, the agent should recognize PII without anyone writing a rule. Modern swg engines use LLM comprehension to read content and classify sensitivity the way a human reviewer would, not the way a 2015 regex library did.
The question is never “did the traffic go somewhere risky.” The question is “what did the user do, in which tenant, with what content.”
Control Patterns That Scale
Once you can see tenant and action, the useful policies write themselves. Three patterns cover most of SaaS sprawl.
Sanctioned vs Personal Tenant Split
Allow the corporate tenant, block personal ones on the same domain. Users keep their workflow; data stops leaking into accounts IT does not own.
One-Click Shadow AI Block
New GenAI tools ship every week. A capable agent detects traffic to these services and lets an admin flip a single toggle to block upload across the fleet. No wizard, no ticket, no waiting for a category update.
Discovery With Teeth
Legacy discovery produces a report. Next-gen discovery produces a policy suggestion attached to each new app, so the reviewer can approve, restrict, or block in the same pane. Coverage improves without adding headcount.
Legacy vs Next-Gen SWG at a Glance
| Capability | Legacy SWG | Next-Gen SWG |
|---|---|---|
| SaaS discovery | Domain category lookup | Tenant-aware, per-session |
| Policy granularity | Allow or block by category | Allow, warn, or block by action |
| Shadow AI control | Add-on, weeks to deploy | One-click block, fleet-wide |
| Performance | Backhaul through data center | Direct-to-internet, on-device |
| Footprint | Heavy proxy, PAC files | Sub-100MB agent, no tunnels |
Where Teams Go Next
SaaS sprawl is not a policy problem, it is an architecture problem. Gateways that live in a data center cannot keep up with tenants that live in a browser tab. Teams that move enforcement to the endpoint stop fighting discovery lag and start governing the actions that actually create risk.
Start with an inventory of sanctioned tenants, measure how much traffic to the same domains hits personal accounts, and decide whether the current gateway can even tell the difference. If it cannot, that is the gap to close first.
FAQ
What is the difference between SWG and SASE?
A secure web gateway inspects and controls user web traffic. SASE is a broader architecture that combines SWG, CASB, ZTNA, and SD-WAN into a single delivery model. The swg is one pillar of SASE, not a replacement for it. Most teams adopt a modern SWG first and expand into SASE over several quarters.
What exactly is CASB?
CASB, or cloud access security broker, focuses on visibility and policy for sanctioned SaaS applications. It typically integrates via API and inline proxying. A next-gen SWG with tenant-aware inspection overlaps with inline CASB features, which is why many teams now consolidate the two into one agent.
CASB vs SWG: which does my team need?
If you only need to govern a handful of sanctioned apps deeply, a dedicated CASB covers it. If shadow SaaS and personal-tenant exfiltration are the real problems, a modern SWG with tenant awareness is the higher-leverage choice. Platforms like dope.security combine both in one on-device agent, so you do not have to pick.
Does a next-gen SWG replace my existing proxy?
Usually yes. Once enforcement moves to the endpoint, the legacy proxy and its PAC files become a source of drift. Most teams run both for a few weeks of validation, then retire the proxy once tenant-level policies prove out.
