Fly-Direct SSE: What On-Device Inspection Changes for Security and Speed
.jpeg)
The short answer
SSE runs on one of two architectures. Cloud-backhaul inspects traffic in a vendor data center. Fly-direct inspects it on the device. Fly-direct is the on-device model, and it changes four things at once: speed (no backhaul detour), privacy (TLS decrypted locally), AI visibility (it sees traffic from desktop apps and scripts, not just browsers), and deployment (an agent pushed through your MDM, with nothing to route). It is why fly-direct has become the modern default rather than a niche alternative.
This piece is the on-device half of the story. If you want the full comparison first, see cloud-backhaul vs fly-direct.
The core inversion
A cloud-backhaul SWG moves your traffic to the inspection. A fly-direct 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. Everything fly-direct changes downstream flows from this one move.
What runs on the device
dope.security's agent, dope.endpoint, 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, then inspects the plaintext. Corporate data is never decrypted in a vendor cloud.
- Policy enforcement. URL filtering, allow and block rules, and Cloud Application Control 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
Fly-direct is not "no cloud," and the distinction matters. 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.
The cloud runs the brains. The device runs the enforcement on live traffic. That division is what lets fly-direct be centrally managed and still avoid backhauling user traffic.
What on-device inspection changes
Speed
Because there is no PoP in the path, fly-direct adds no network detour. The latency that drives most SSE migrations, 40 to 80 ms near a node and 150 to 400 ms far from one, simply does not exist. The security stops showing up as lag, even on a home connection or in another country.
Privacy and data residency
Where decryption happens is a privacy decision. A cloud proxy holds your plaintext in its infrastructure at the moment of inspection. Fly-direct decrypts on the endpoint the user already controls, so the plaintext never leaves the machine. For regulated teams in healthcare, finance, and government, that is a materially stronger data-residency position.
AI visibility
This is where the architecture gap gets sharp. People use ChatGPT and Claude not only in the browser but in desktop apps, IDEs, and command-line tools. A cloud proxy or browser extension only sees what routes through it. A fly-direct 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.
Deployment
Because there is nothing to route, deploying fly-direct 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.
| What changes | Cloud-backhaul | Fly-direct (on-device) |
|---|---|---|
| Latency per request | Backhaul detour | None from a network hop |
| Decryption location | Vendor cloud | The device |
| AI traffic seen | Proxy-routed only | Any app on the endpoint |
| Deployment | Forwarding architecture | Agent via MDM |
The honest limits of on-device
Fly-direct is not magic, and it is worth being precise about the trade-offs.
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. That capability is part of how a Fortune 100 customer scaled the agent past 18,000 devices without a long tuning cycle.
It is an agent model. Inspection lives on managed endpoints. Teams that want every control to live in a network cloud are changing approach when they adopt fly-direct. Most find the approach simpler, because there is no forwarding to architect, but it is a genuine shift, not a drop-in.
Unmanaged devices. Fly-direct protects endpoints where the agent is deployed. For contractor or BYOD scenarios, you plan coverage the same way you would any endpoint control.
Naming these honestly is the point. The right architecture is the one whose trade-offs match how your organization works, and for a hybrid, remote, AI-heavy workforce, fly-direct's trade-offs are the easy ones to accept.
The proof
On-device is not a lab idea. A Fortune 100 company runs the fly-direct agent on more than 18,000 devices. Outreach Health secured 99% of its fleet in a week and cut web-access tickets 70%. Greylock Partners moved off a legacy SSE and signed in 27 days. The City of Visalia adopted fly-direct so protection followed its mobile workforce off-network, strengthening its posture "without adding operational overhead." These are speed, privacy, and deployment claims backed by rollouts, not slideware.
For how a migration actually runs, see migrating off a cloud-proxy SSE.
Frequently asked questions
What is fly-direct SSE? The on-device SSE architecture: a lightweight agent inspects traffic on the endpoint and sends it straight to its destination, instead of backhauling it to a vendor data center. dope.security uses "fly direct" to describe it.
How does on-device inspection work? The agent decrypts TLS locally, applies policy, scans the content for threats and data leaks, and routes the request directly. Management and analytics stay in the cloud; enforcement happens on the device.
Does fly-direct mean no cloud console? No. Policy, analytics, real-time policy push, and data-at-rest scanning stay in the cloud console. Only inspection of live traffic moves to the device.
Why is on-device better for AI governance? Because it sees AI traffic from browsers, desktop apps, IDEs, and scripts at the point it leaves the machine, rather than only what routes through a proxy or browser.
Is a fly-direct agent hard to run? It is usually simpler than a cloud proxy, because there is no forwarding to build. You push the agent through your MDM and confirm policy. Rollouts of thousands of devices in days are common.
See it in action
Want to see on-device inspection on your own devices? Start a free trial or book a 20-minute demo at dope.security.
.jpg)
.jpg)
