Zero Trust Shouldn't Mean Routing Everything Through a Third Party

Short answer: To enforce policy, a broker-based model often has to decrypt and inspect your traffic inside the vendor's cloud. That means your users' sessions become plaintext in infrastructure you don't own, and your data crosses regions you didn't choose. On-device Fly Direct inspects locally, so decrypted traffic stays on the machine and only the encrypted, allowed connection goes out. Zero trust is supposed to reduce exposure, not relocate it to a third party.

The irony of centralized inspection

Zero trust exists to shrink the blast radius: assume breach, limit trust, contain damage. Then many implementations route every session through a single cloud service that decrypts and inspects it. You've built one place that sees the plaintext of your whole organization's traffic. That's a large, attractive, centralized target, which is exactly the kind of thing zero trust philosophy warns against.

It's not that the vendor is careless. It's that the architecture concentrates exposure by design. Every decrypted session has to pass through the shared inspection plane to get a decision, so the plane necessarily has the keys and the visibility to read it. You've traded a distributed risk, traffic scattered across many endpoints, for a concentrated one, all of it readable in a single third-party system. Concentration is convenient for the attacker.

Where decryption happens matters

There are only two places to break and inspect encrypted traffic: in a cloud service, or on the device. A broker model leans on the former. Fly Direct uses the latter. dope.security performs SSL inspection on the endpoint, so the traffic is decrypted, evaluated, and re-secured locally, and only the encrypted connection continues to its destination. The plaintext never traverses a third-party data plane.

We compared this directly in our real-world SWG tests on speed, break/inspect, and privacy. On-device inspection is the privacy-preserving option because it keeps the decrypted content on the machine that already had it. The endpoint was always going to see its own plaintext; that's where the user typed it. Inspecting there adds no new party to the secret. Inspecting in a cloud does.

Data residency gets simpler, not harder

When inspection happens in a vendor cloud, your traffic goes wherever that cloud routes it, sometimes to a PoP in another country, especially during a reroute or outage. For teams with data-residency obligations, that's a compliance headache you have to reason about continuously. You don't just have to trust the vendor's steady-state routing; you have to account for where traffic lands when a region fails and sessions shift to the next-nearest PoP.

On-device inspection sidesteps it. The decrypted content stays on the endpoint in the user's location. There's no cross-region hop to inspect, and no third-party inspection plane to include in your data map. The same property that makes on-device work in restricted geographies makes residency cleaner: traffic goes direct instead of touring someone else's regions.

That simplicity pays off in audits. 'Decrypted content is inspected on the managed endpoint and never transits our inspection cloud' is a short, verifiable statement. Reconstructing which regions a shared PoP network touched, under both normal and failover conditions, is not. Fewer parties in the data flow means a smaller data map and a shorter list of processors to document.

The compliance and vendor-risk angle

Every third party that can read your plaintext is a line in your vendor risk assessment, a set of subprocessors to track, and a dependency your regulators will ask about. Centralized inspection makes the security vendor one of the most privileged data processors you have, because it can see nearly everything. That's a lot of trust to concentrate, and a lot to document and defend.

Moving inspection on-device shrinks that surface. The vendor provides the agent and the control plane for policy and telemetry, but the decrypted session content is handled on your own managed device, not in the vendor's data plane. You still do diligence, but you're documenting a smaller, more contained flow.

What about AI DLP and the cloud

Fair question: doesn't AI content classification involve a model that might run remotely? dope.security uses zero-retention classification, meaning content isn't retained or used for training, and the enforcement decision is made at the endpoint.

The honest guidance for any buyer, us included, is to verify exactly which fields leave the device, where any classification runs, and the retention terms, contractually and technically. Don't accept 'on-device architecture' as a synonym for 'nothing ever leaves.' Ask for a data-flow diagram, confirm the processing region and retention, and check the subprocessor list. We say the same in how to stop sensitive files reaching AI. The right posture is 'trust, then verify the data flow,' and it applies to every vendor including this one.

The honest scope

Broker-based ZTNA didn't set out to weaken privacy. It's a side effect of centralizing inspection, and for some private-app use cases that trade-off is acceptable and well-contained. The argument is simply that the device is a better place to decrypt your own traffic than a shared third-party cloud, both for exposure and for data residency.

For the web, SaaS, and AI plane, on-device inspection gives you the zero trust outcome without the centralized plaintext. You keep the verification and the content control, and you drop the requirement to route your organization's decrypted traffic through infrastructure you don't own. That's a better privacy posture that happens to also be faster, which is why the two arguments tend to travel together.

Breach blast radius is an architecture choice

Zero trust talks constantly about blast radius, the amount of damage a single compromise can do. Apply that lens to the inspection point itself. If your architecture decrypts every user's traffic in one shared cloud plane, then a compromise of that plane is a compromise of nearly everything, because that's where the plaintext and the keys live. The blast radius is the whole organization, concentrated in one place.

On-device inspection distributes that surface across managed endpoints, each holding only its own traffic, with no central plaintext store to breach at once. Neither model is magic, and endpoints carry their own risks that you manage with the rest of your endpoint security. But on the specific question of 'how much can one breach read,' decentralizing inspection is the more zero-trust-consistent answer. It's worth asking any vendor where the single largest concentration of your readable data would sit under their design, and exactly what protects it.

Frequently asked questions

Does broker-based zero trust decrypt my traffic in the cloud? To inspect encrypted traffic and enforce content policy, it generally must decrypt somewhere. In a cloud model, that's the vendor's infrastructure. On-device enforcement decrypts and inspects on the endpoint instead.

How does on-device inspection help with data residency? Decrypted content stays on the device in the user's location, and traffic goes direct to its destination, so there's no cross-region cloud inspection hop to account for, even during a failover.

Does any content leave the device for AI DLP? dope.security uses zero-retention classification and makes the enforcement decision on the endpoint. Verify the exact data flow, processing location, and retention terms as part of any evaluation, which we recommend for every vendor.

Why is centralized inspection a bigger target? Because it holds the keys and visibility to read the plaintext of many users' traffic in one place. Concentrating that much readable data is exactly the risk zero trust philosophy warns against.

Does on-device inspection reduce my vendor-risk surface? It shrinks it. Decrypted session content is handled on your managed device rather than the vendor's data plane, so there are fewer privileged processors to document and defend.

What should I ask a vendor to verify privacy claims? Request a data-flow diagram showing which fields leave the device, the processing region, retention terms, and the subprocessor list. Apply this to any vendor claiming an on-device model, including dope.security. A vendor confident in its architecture will hand that over without friction, and the diagram tells you more than any marketing claim about where your decrypted data actually goes.

Keep your plaintext at home

Inspect on the device, not in someone else's cloud. Book a 20-minute demo or start an instant trial with your corporate email.

Further reading: Meet Dopamine DLP and the dope.SWG product overview.