What is a next-gen SWG? A plain-English answer, minus the vendor soup

"Next-gen SWG" is a label every vendor in the category uses. The thing it refers to has changed three times in the last eight years.

If you're researching secure web gateway options, the vendor soup is disorienting. Who's actually doing something different, and who's just slapping the label on the same proxy in a different data center?

This post cuts through it. Short definition, five capabilities a next-gen SWG has to have, and the one architecture question that actually separates the options.

The short definition

A next-gen SWG goes past URL categorization and basic malware scanning. It inspects traffic, enforces data loss prevention, controls SaaS tenant access, governs AI use, and delivers real-time analytics. The "gen" part is the move beyond the 2010-era proxy that just blocked dirty sites.

That's the feature definition. There's a second definition that matters more, and we'll get to it in the architecture section.

The five capabilities

A working list of what's table stakes in 2026.

1. On-device or cloud-based SSL inspection

Most of the internet is encrypted. A SWG that can't inspect TLS can't enforce DLP, anti-malware, or Cloud Application Control on encrypted traffic. It's a URL filter with aspirations.

The question isn't whether SSL inspection is happening. The question is where it's happening, and we come back to that.

2. Real DLP, not a feature checkbox

First-gen cloud SWGs advertised "DLP" but mostly ran a few regex patterns against HTTP request bodies. Credit card numbers, maybe SSNs, a couple of keyword lists.

Next-gen SWG DLP is integrated with endpoint DLP, handles unstructured content (AI prompts, free-text pastes, nested documents), and classifies with language models, not just pattern matchers. Dopamine DLP in dope.security is the endpoint layer; it plugs into the SWG policy engine instead of being a bolt-on.

3. Cloud Application Control

SaaS-aware enforcement at the tenant level. Not just "allow or block ChatGPT" but "allow ChatGPT only when signed in to our corporate tenant; block personal logins at the OAuth layer."

Most SWGs don't do this. Ones that do, do it in a way that requires separate licensing or a separate product. A next-gen SWG treats CAC as a first-class control.

4. AI governance

A category that didn't exist three years ago and is now a board-level concern. A next-gen SWG needs to discover AI tool usage, categorize personal-vs-corporate accounts, enforce policy per tool, and integrate with endpoint DLP to inspect prompt content.

If an SWG vendor's AI governance story is "we can block chatgpt.com," that's not a next-gen answer. That's Layer 1 of a four-layer problem.

5. Real-time analytics

Policy changes should push in seconds, not the 30 to 60 minutes of legacy polling. Logs should be queryable in-console, not exported nightly to a SIEM. Discovery should be continuous, not weekly.

In dope.console, policy updates propagate in seconds across all connected dope.endpoints. That's not a feature, it's a consequence of the architecture. Which brings us to the actual question.

The architecture question

Here's the thing most buyers don't ask: is the inspection still happening in a data center?

Three eras of SWG architecture:

Appliance era (pre-2015). Box in your DC. Traffic was hair-pinned to the box, inspected, and sent back out. Worked for office workers. Broke as soon as anyone left the building.

Cloud-proxy era (2015–present for most vendors). Same appliance, moved to the vendor's cloud. Traffic gets routed to a regional PoP, inspected, and forwarded. Latency tax per request. Privacy concerns because traffic passes through third-party infrastructure. Breaks in restricted geographies like China. This is where Zscaler, Netskope's core, and Cisco Umbrella's enterprise SWG sit.

Agent-based era (dope.security). Inspection runs on the endpoint itself through a native agent. Traffic flies direct to destination. No backhaul, no PoP latency, no third-party in the trust chain. The agent falls back to cached policies during console outages, so nothing breaks when the cloud is having a bad day.

When a cloud-proxy vendor says "next-gen SWG," the architecture is usually the 2015-era cloud proxy with more features piled on top. The features are real. The architectural limits are also still there: latency, backhaul, data residency, geography.

When dope.security says "next-gen SWG," the architecture is different. Inspection is on-device. That's the "next" in next-gen for our stack.

A five-point evaluation checklist

If you're in an active SWG evaluation, here's what to ask in a demo.

1. Architecture. On-device or cloud proxy? Can traffic ever leave the device in plaintext? What happens during a cloud console outage?

2. Performance. Measured latency added per request, under load. Agent memory and CPU footprint at idle and under stress. For cloud-proxy vendors, how many PoPs, where, and what's the nearest-PoP latency to your user base?

3. Geography. Does it work in the countries your people live in? Ask specifically about China, because most cloud proxies struggle there.

4. Policy velocity. Time from "change in console" to "enforced on every endpoint." Seconds is the right answer. Minutes is tolerable. Hours means your SWG is actually a batch job.

5. Console count. Is the SWG, CASB, DLP, and AI governance in one console with consistent UX? Or are they separate products with a shared login and three different sets of docs? Run the integration story by a demo that switches between features live.

These questions will clarify what "next-gen" means for each vendor.

Where dope.security fits on the definition

We built dope.SWG as an agent-based next-gen SWG from day one. Not as an appliance that we moved to the cloud, and not as a proxy that we added features to.

• Inspection happens on dope.endpoint, a native agent for Mac and Windows, under 100 MB of RAM.
• SSL inspection is on-device, with root trust deployed via MDM.
• DLP (Dopamine DLP) and CAC are in the same console, not separate products.
• AI governance covers ChatGPT, Claude, Google, and Microsoft 365 at the tenant level.
• Policies push in seconds from dope.console.
• Works in China and other restricted geographies where cloud proxies have persistent issues.

See the comparison

If you're evaluating against Netskope, Zscaler, or Cisco Umbrella, the side-by-side is on the site. The architectural differences show up fastest in a real trial, not in a feature table.

‍