Quick answer: Egress filtering is the practice of controlling which outbound connections a device or network is allowed to make, traditionally by writing IP, port, and protocol rules at the network boundary. That model was built for a network you owned and a laptop that stayed on it, so in 2026 it has two problems: it stops applying the moment the device leaves the building, and even when it does apply it can tell you a machine reached a server without ever telling you which SaaS tenant, which account, or which AI tool the data actually went to. dope.security moves egress control onto the device itself, so the policy travels with the user and inspects the request rather than guessing from the destination address.

Most teams still have egress rules. Most of those rules are now describing a network the workforce barely touches.

If you are working through the wider filtering stack, our comparison of the top URL filtering tools covers where each control sits, and URL filtering versus DNS filtering explains why domain-level blocking runs out of road under HTTPS.

What is egress filtering?

Egress filtering controls traffic leaving your environment. Ingress filtering controls traffic coming in. Most organizations spent two decades investing heavily in the second and treating the first as an afterthought, on the reasonable assumption that outbound traffic was their own users doing their jobs.

Classic egress filtering is a firewall or router job. You define what is allowed to leave: permitted destination ranges, permitted ports, permitted protocols, and a default deny for everything else. Done well, it does real work. It stops a compromised host from reaching a command and control server on an unusual port, it stops data being pushed out over protocols nobody has a business reason to use, and it makes lateral movement noisier and slower.

None of that has stopped being true. What has changed is how much of your actual risk it can still see.

How traditional egress filtering works, and what it can see

A network egress rule evaluates a packet using the information in the packet: source address, destination address, port, protocol, and sometimes the server name in the TLS handshake. That is the whole vocabulary.

In 2003 that vocabulary was rich enough, because a destination address meant something. One IP was one server was one application. In 2026 the same rule evaluates a connection to a hyperscaler address range shared by tens of thousands of tenants, over port 443, encrypted, and it has to make an allow or deny decision on that basis alone.

So the rule allows it. Almost all of them do, because blocking 443 outbound is not a policy anyone survives. Which means the single most important egress path in your organization is governed by a rule that says "yes."

The three questions egress rules cannot answer

Ask an egress rule the questions a security team actually has in 2026 and it comes back empty on all three.

• Which account was that? An egress rule sees a connection to a SaaS provider. It cannot tell a corporate tenant from an employee's personal account on the same domain, because that distinction lives in an HTTP header inside the encrypted session, not in the packet header. Allowing corporate ChatGPT while blocking personal ChatGPT is impossible at the network layer for exactly this reason. dope.security inspects inside the decrypted session on the device and enforces it with Cloud Application Control.
• What was in it? An egress rule sees bytes leaving. It cannot see whether those bytes were a lunch order or a customer database, because it never opens the payload. Dopamine DLP classifies uploads and AI prompts on the device before the request completes, using zero-retention APIs.
• Which application sent it? Process identity does not travel over the wire, so a network control sees a socket, not the binary behind it. An agent on the endpoint knows whether that connection came from a browser, a desktop AI client, an IDE, or a script.

Every one of those gaps has the same root cause. The control is standing in the wrong place to see the thing it is being asked about.

Then the laptop leaves the building

This is the failure mode that gets least attention and costs the most.

An egress rule is a property of a network. When the device is on that network, the rule applies. When the user takes the same laptop to a home office, a client site, a hotel, or an airport lounge, the rule simply is not there. The device now egresses through a network you have no relationship with, under no policy at all, doing exactly the same work with exactly the same data.

For a hybrid workforce that is not an edge case, it is most of the week. You did not weaken your egress posture, you just stopped having one for the majority of working hours, and nothing in your firewall logs will tell you that because the traffic never showed up.

Greylock Partners hit this exact wall. A distributed, device-first venture team meant perimeter-shaped controls kept missing traffic that never crossed the perimeter, and DNS-layer filtering could not see inside HTTPS either. They moved to dope.security and went from first proposal to signed contract in 27 days. The full account is in why Greylock ditched Cisco Umbrella.

Cloud proxies moved the egress point, they did not fix it

The standard answer to the roaming problem is to force traffic back through a control point in the cloud. Install a forwarding agent, route everything to the vendor's nearest point of presence, inspect there, then send it on. The egress point moves from your building to their data center, and the policy follows the user again.

That genuinely solves the coverage gap. It introduces three new bills.

• Latency on every request. Traffic detours to a point of presence and back before it reaches its destination. Measured cloud-proxy latency runs roughly 40 to 80 ms when the user is near a point of presence and 150 to 400 ms when they are not, on every request, and a modern page makes a lot of requests. Netskope's own SLA puts decrypted traffic at 50 ms against under 10 ms undecrypted. dope.security inspects in-process on the device, so there is no detour to pay.
• A shared control plane. Concentrating every user's egress in one cloud service means an outage there is an outage everywhere. Cloudflare's November 2025 global incident took roughly five hours of 5xx errors across its edge, and Palo Alto's Strata Cloud Manager ran impaired for around 28 days from 31 March 2026. dope.endpoint falls back to cached policies when the console is unreachable, so the blast radius is one device rather than the fleet.
• Your plaintext in someone else's building. Everything an employee does on a work device, including banking and medical portals, now decrypts inside a third party's infrastructure. On-device inspection keeps the plaintext on the machine it originated on, which is a materially easier conversation with a privacy team or a regulator.

Curious what the detour costs on your connection? The Fly-Direct Speed Test measures your real round-trip latency in the browser and shows app-by-app load times against a legacy cloud-proxy path. See how Fly Direct SWG works, or book a 20-minute demo.

Takeaway: routing egress through a data center buys back coverage by charging you latency, a shared failure domain, and your users' plaintext.

Egress control that runs where the traffic starts

There is a third option, and it is the one the shape of the problem keeps pointing at. Put the control at the point the traffic originates, which is the device.

dope.SWG runs a native agent on Mac and Windows that inspects SSL on the endpoint and applies URL filtering, Cloud Application Control, anti-malware, and Dopamine DLP locally. Traffic then flies direct to its destination with no backhaul. Because the control lives on the machine, three things change at once:

• Coverage stops depending on location. Office, home, hotel, or an airport in another hemisphere, the same policy applies, because it was never a property of the network.
• The vocabulary gets richer. The agent sees the process, the full URL, the tenant, and the payload, so egress decisions can be written about applications and accounts instead of address ranges.
• The detour disappears. Inspection happens before the packet hits the wire, which is why dope.security delivers up to 4x the performance of legacy proxy SWGs, and why it works in China and other restricted regions where backhauling to a foreign data center falls apart.

For the architecture comparison in detail, see cloud proxy versus on-device SWG and what a next-gen secure web gateway actually means.

Egress filtering versus the controls it gets confused with

Four different things get called egress control in vendor decks, and they answer different questions. Here is the honest split, with what each one can and cannot do.

Network egress filtering

Firewall or router rules evaluating outbound connections by destination address, port, and protocol. Strong at blocking unusual protocols and constraining a compromised host, blind to anything inside an encrypted session, and only in effect while the device sits behind it. Keep it. Do not expect it to govern SaaS.

DNS filtering

Blocks or allows a domain at name resolution. Fast and cheap to run, and it never sees a URL path, a request payload, or a tenant identifier, because the decision is made before the connection exists. Encrypted DNS makes it easier to route around. dope.security applies policy after the request is formed and decrypted on the device, so a path, an account, and a payload are all in scope.

URL filtering in a secure web gateway

Evaluates the full URL rather than the domain, which requires SSL inspection to work on HTTPS. Legacy gateways do that inspection in a data center, which is what adds the detour. dope.security does it on the endpoint, which is why URL filtering, Cloud Application Control, and DLP can share one decision point without a round trip.

Data loss prevention

Inspects content rather than destinations, and answers what left rather than where it went. Network and cloud DLP see data after it lands or go blind under TLS. Dopamine DLP classifies uploads and AI prompts on the device before the request completes, using zero-retention APIs, so the answer arrives while you can still act on it.

You need more than one of these. The question is how many separate consoles, agents, and SKUs it takes to get them, which is the difference between a platform assembled through acquisitions and one built as a single agent.

An egress checklist for a workforce that is not in the building

• Keep your network egress rules. They still stop unusual ports and protocols and they still slow down a compromised host. This is not an argument for deleting them.
• Measure what fraction of working hours they actually cover. Compare devices seen on the corporate network against total managed devices. The gap is your real exposure.
• Write policy about applications and accounts, not addresses. If a rule cannot distinguish a corporate tenant from a personal one, it is not an egress policy for SaaS, it is a connectivity rule.
• Decide where decryption happens before you decide who does it. That single choice determines your latency, your blast radius, and your data residency story.
• Include non-browser egress. Desktop AI clients, IDE integrations, CLI tools, and scripts all egress, and browser-bound or isolation-based controls never see them.

Where this ends up

Egress filtering was never the wrong idea. Controlling what leaves is still the most direct way to stop data loss, and it always will be. What changed is that the exit is no longer a router in your building. The exit is a laptop, and it is wherever the person holding it happens to be.

Control the exit where the exit actually is. Try dope.SWG free or book a 20-minute demo.

Frequently Asked Questions

What is the difference between ingress and egress filtering?

Ingress filtering controls traffic entering your environment and is aimed at keeping attackers out. Egress filtering controls traffic leaving it and is aimed at stopping data going where it should not and cutting off compromised hosts from their infrastructure. Most organizations have far stronger ingress controls, which is why exfiltration is usually the easier direction for an attacker to move in.

Is egress filtering still worth doing if all traffic is encrypted?

Yes, but it stops being sufficient on its own. Network egress rules still block unusual ports and protocols and constrain what a compromised host can reach. What they cannot do is distinguish between two connections to the same encrypted SaaS destination, which is where most modern data loss happens. Pair the network rules with inspection that can read inside the session, which dope.security does on the device.

Does a firewall do egress filtering?

A firewall does network egress filtering, evaluating outbound connections by address, port, and protocol. It only applies while the device is behind it, and it evaluates the packet rather than the request inside it. That is enough for infrastructure-level controls and not enough to answer which SaaS tenant or which AI tool received the data.

How do you apply egress policy to remote and travelling employees?

There are two workable models. Route their traffic back to a cloud proxy so the policy applies at the vendor's point of presence, which restores coverage but adds a detour of roughly 40 to 80 ms near a point of presence and 150 to 400 ms when far from one. Or run the control on the device, which is what dope.security does, so policy follows the user with no backhaul and no dependence on which network they joined.

Can egress filtering stop employees uploading data to AI tools?

Not on its own. A network egress rule can block an AI domain outright, which usually gets reversed within a week, but it cannot allow the corporate tenant while blocking personal accounts on the same domain, and it cannot see what is in a prompt. dope.security handles this in three layers: shadow IT discovery to find which AI tools are in use, SWG policy to allow or block them, and Cloud Application Control to restrict access to approved tenants, with Dopamine DLP inspecting prompts and uploads for sensitive data.

What should an egress filtering policy actually cover in 2026?

Four things. Which destinations and protocols are permitted at the network layer, which applications are permitted to egress at all, which SaaS tenants and accounts are approved for the applications you do allow, and what categories of data are never allowed to leave regardless of destination. The first is a firewall job. The other three need something that can see the process, the account, and the payload, which means running at the device.