An engineer at a mid-market SaaS company uploaded a customer database to a consumer LLM last quarter. The company had DNS filtering in place. The LLM domain was uncategorized at the time. By the time the category updated, the data was gone. The CEO asked why the security control missed it. The honest answer is that DNS filtering was never looking at the payload.
Choosing between a secure web gateway agent and a DNS-only filter is not a feature comparison. It is a decision about which category of threats you want visibility on and which you are willing to ignore. This post is the honest side-by-side.
What DNS Filtering Actually Sees (and Doesn’t)
DNS filtering is fast, cheap, and easy to deploy. It is also strictly limited to what DNS can see, which is less than most buyers realize.
What DNS Sees
- The domain name the client is about to resolve.
- Optionally, whether that domain is in a bad-reputation feed.
- The resolver path (your network, ISP, or the filter provider).
What DNS Does Not See
- The URL path, which is where most phishing kits hide.
- The content of the HTTPS request or response.
- File uploads, form posts, or LLM prompts.
- The distinction between personal and corporate sessions on the same domain.
A DNS filter that blocks malicious-site.com will happily allow legitimate-saas.com/upload?data=<customer-db> because it only ever saw the domain. This is why DNS filtering is a good category filter but a poor data loss prevention control.
DNS filtering blocks the front door. It cannot see what walks out the window.
Where an SWG Agent Earns Its Footprint
An agent adds installation overhead, inventory to manage, and a line item on an endpoint. It also opens up an entire category of visibility that DNS filtering cannot reach.
TLS Payload Inspection
An on-device agent terminates TLS locally and inspects the decrypted payload. That is the only way to see the actual content of a post, upload, or form submission. A cloud SWG does the same thing but in a vendor data center, which creates latency and expands your data-exposure surface.
Content-Aware DLP
A modern secure web gateway runs an LLM-based DLP classifier on the endpoint. It reads documents, forms, and prompts and classifies them by meaning. Regex cannot find MNPI in a draft memo. A language model can. DNS filtering cannot even see the payload, let alone classify it.
User and App Context
An agent knows which user is logged in, which browser profile is active, and which app is making the request. That context lets a policy block a personal Gmail session while allowing the corporate one, which is impossible at the DNS layer.
Shadow AI Control
Consumer LLMs are the fastest-growing leak path. DNS filtering treats them as categories, which is too blunt (you lose legitimate productivity use) or too loose (you block known bad domains while new ones pop up weekly). An agent with one-click shadow AI block operates on the session and payload level, which is the right granularity.
Comparison Table
| Capability | DNS Filtering | On-Device SWG Agent |
|---|---|---|
| Domain categorization | Yes | Yes |
| URL path visibility | No | Yes |
| TLS payload inspection | No | Yes |
| DLP on uploads and forms | No | Yes |
| Shadow AI control | Coarse | Granular, one-click |
| Per-user policy on shared domain | No | Yes |
| Works off the corporate network | Partial (if resolver is set) | Yes |
| Agent footprint | None | Under 100 MB RAM (modern agents) |
Hybrid Strategies and When They Backfire
Some teams deploy DNS filtering plus a partial SWG and call it a hybrid. Done right, it is a layered defense. Done wrong, it creates two tools doing the same job badly.
When Hybrid Works
DNS filtering at the network edge for quick bad-domain blocking plus an on-device agent for payload inspection and DLP is a reasonable setup. The DNS layer catches obvious junk before the agent sees it. The agent catches everything DNS misses. Each tool plays its natural role.
When Hybrid Backfires
Buying a cheap DNS filter and telling leadership it covers DLP is the most common failure. It does not. The cost saved on the agent shows up later in an incident report. Similarly, running two agents (one for DNS-adjacent categorization, one for TLS inspection) on the same endpoint doubles the footprint and creates conflicts.
A single swg agent that combines categorization, TLS inspection, and DLP on-device usually beats the hybrid on simplicity and cost. Especially if it coexists cleanly with your EDR and VPN instead of fighting them.
Decision Matrix by Use Case
Not every environment needs a full agent. Use this matrix to make the call honestly.
DNS-Only Is Probably Enough When
- The endpoint population is K-12 or guest Wi-Fi where DLP is not the goal.
- Devices are unmanaged and you cannot push an agent.
- The objective is acceptable use policy, not data protection.
- The risk surface is predominantly malware category blocking.
An Agent Is Required When
- You handle regulated data (PHI, PCI, MNPI, PII at scale).
- Shadow AI and personal cloud uploads are realistic exfil paths.
- You need per-user policy on shared domains like Google or Microsoft.
- The device leaves the corporate network regularly.
- Audit or regulatory evidence requires readable block reasons per event.
Most mid-market and enterprise teams fit the agent profile. DNS-only is the right call for narrower use cases, not a general-purpose substitute.
FAQ
What is a secure web gateway?
A secure web gateway is a control that inspects outbound web traffic to enforce acceptable use, block threats, and prevent data loss. Modern versions run as an agent on the endpoint, inspect TLS locally, and classify content with a language model rather than pattern matching.
What is the difference between a VPN and a SWG?
A VPN creates an encrypted tunnel between an endpoint and a network, usually to reach internal resources. An SWG inspects outbound web traffic for security policy regardless of where the endpoint sits. They solve different problems and are often deployed together.
Secure web gateway vs firewall, what is the difference?
A firewall controls network-level traffic by port, protocol, and address. An SWG operates at the application and content layer for web traffic, inspecting URLs, categories, and payloads. Firewalls and SWGs complement each other rather than overlap. A platform like dope.security focuses on the web layer specifically so the agent stays small and performance stays deterministic.
Can DNS filtering replace an SWG for small teams?
For very small teams that only need acceptable use controls and malware category blocking, DNS filtering is sometimes enough. The moment data loss, shadow AI, or regulated data enters the picture, DNS filtering stops being sufficient because it cannot see the payload.