On-Device SWG: How Endpoint-Based Web Inspection Actually Works

The short answer

An on-device Secure Web Gateway runs inspection on the endpoint itself instead of routing traffic to a cloud proxy. A lightweight agent on the laptop decrypts TLS locally, applies your policy, scans for threats and data leaks, and sends traffic straight to its destination. dope.security calls this Fly Direct.

The result is the same security jobs a cloud SWG performs, URL filtering, SSL inspection, anti-malware, Cloud Application Control, DLP, done in a place that removes the backhaul detour and keeps corporate data local. This is the hero half of the two-architecture story in the SSE architecture guide.

The core idea

A cloud SWG moves your traffic to the inspection. An on-device SWG moves the inspection to your traffic.

That single inversion is the whole design. Because the inspection engine lives on the endpoint, there is no point of presence to route to, no detour to pay for, and no third-party cloud decrypting your sessions. The traffic goes where it was always going, and the checking happens on the way out.

What runs on the device

The dope.endpoint agent sits on the laptop and does the real-time work:

• Local TLS decryption. The agent decrypts the encrypted session on the device, using a certificate trusted through your MDM. See on-device vs cloud SSL inspection.
• Policy enforcement. URL filtering, allow and block rules, and Cloud Application Control all evaluate locally.
• Threat and data inspection. Anti-malware scanning and Dopamine DLP run on the decrypted content, catching threats and sensitive data before traffic leaves.
• Direct routing. Once policy passes, the request goes straight to its destination. No stopover.

The agent is deliberately light: under 100 MB of RAM, running at up to 4x the performance of legacy proxy SWGs, so it does its job without the user noticing.

What still runs in the cloud

On-device does not mean everything lives on the laptop. The split is deliberate:

• dope.console is the single cloud management layer for policy, analytics, and administration.
• Policy push happens from the cloud in real time, so a change reaches every device in seconds rather than waiting on a polling cycle.
• CASB Neural scans Microsoft 365 and Google tenants for exposed data at rest, which is cloud-side work by nature. See CASB Neural.

The cloud runs the brains: management, intelligence, and data-at-rest scanning. The device runs the enforcement on live traffic. That division is what lets the model be centrally managed and still avoid backhauling user traffic.

Why the endpoint is the right place for AI visibility

AI traffic is the clearest case for on-device. People use ChatGPT and Claude not just in the browser but in desktop apps, IDEs, and command-line tools. A cloud proxy or browser extension only sees what routes through it. An on-device agent sees traffic at the point it leaves the machine, whatever app produced it. That is why on-device can govern AI use that browser-based and proxy-based tools miss. See browser extensions and cloud proxies can't see all shadow AI.

Handling the hard parts honestly

On-device inspection is not magic, and two practical points matter.

Certificate pinning. Some apps pin certificates and will not accept any inspection, on-device or cloud. dope.security surfaces those SSL errors so admins can create bypasses in a few clicks instead of chasing broken traffic. This is one reason a Fortune 100 customer could scale the agent to more than 18,000 devices without a long tuning cycle.

It is an agent model. Inspection lives on managed endpoints, deployed through your MDM. Teams that want every control to live in a network cloud are changing approach. Most find the approach simpler, because there is no forwarding architecture to build.

Deployment: what changes

Because there is nothing to route, deploying an on-device SWG is a push, not a project. No PAC files, no tunnels, no connector mesh. You deploy the agent through Intune, Jamf, or your MDM of choice, confirm policy, and you are enforcing.

The record backs it up: Outreach Health secured 99% of its fleet in a week, a Fortune 100 scaled from 900 to more than 18,000 devices in weeks, and one Cisco Umbrella customer migrated 2,000 machines in two days. See migrating off a cloud-proxy SSE.

Frequently asked questions

What is an on-device Secure Web Gateway? A SWG that inspects traffic on the endpoint using a local agent, rather than routing it to a cloud proxy. It performs the same jobs, URL filtering, SSL inspection, malware scanning, DLP, without the backhaul detour.

How does on-device inspection work? A lightweight agent on the device decrypts TLS locally, applies policy, scans the content, and sends traffic straight to its destination. Management and analytics stay in the cloud; enforcement happens on the device.

Does on-device SWG mean no cloud at all? No. Inspection of live traffic runs on the device, but management, policy push, analytics, and data-at-rest scanning stay in the cloud console. The device handles enforcement; the cloud handles the brains.

Is an agent-based SWG hard to deploy? It is usually simpler than a cloud proxy, because there is no forwarding to architect. You push the agent through your MDM and confirm policy. Rollouts of thousands of devices in days are common.

How does on-device inspection affect performance? It removes the backhaul detour, so it adds no network latency. dope.security runs in under 100 MB of RAM at up to 4x the performance of legacy proxy SWGs.

See it in action

Want to see endpoint-based inspection on your own devices? Start a free trial or book a 20-minute demo at dope.security.