EgressView — see which app is talking, and to whom

Start from a different premise

If your plan is only to keep attackers out, you have no plan for the day one gets in.

Prevention is never complete

Patching, authentication, perimeters — all necessary, all eventually bypassed. Designing as though one will fail is simply realistic.

The damage happens on the way out

Stolen data is only lost once it is sent. Most intrusions also need to reach back out for instructions before they can go further.

Outbound is the least-watched direction

Firewalls and WAFs mostly face inward. What goes the other way tends to pass quietly.

A destination alone no longer tells you anything

Attackers relay through legitimate cloud services. The destination looks like a trusted domain, because it is one.

A machine makes a small connection to a major CDN every five minutes. What is it?

You cannot answer from the destination. It could be a software updater checking in. It could be malware collecting instructions. Both can use the same address.

What separates them is which application opened the connection. That is what EgressView records.

What you see	Destination only	With the application
`cdn.example.net` — 5 min	Cannot tell	`SoftwareUpdate` — expected
`cdn.example.net` — 5 min	Cannot tell	An unfamiliar process — worth looking at

EgressView Agent showing which application reached which destination — The agent's own answer: applications on the left, destinations on the right, ribbon width the number of connections.

Two pieces, and only two

Either works on its own. Together they make one record of the whole network.

One Mac

EgressView Agent

Records that Mac's outbound connections, each with the name of the application that made it.

Which app reached which country, domain and address
Threat lists are matched on the Mac itself
Gaps in the record are shown as gaps

No Hub required. It works alone.

A whole network

EgressView Hub

Watches every device from the router, and folds in what the agents report, into one history.

Sees devices that cannot run an agent — IoT, TVs, printers
Fetches the threat lists and hands them to the agents
Runs on your hardware. Nothing goes to a cloud

Needs a Yamaha RTX or Cisco IOS router.

EgressView Hub graph map: every device on the network and the destinations each reached — The Hub's view of a whole network: devices at the centre, destinations around them — including the ones that cannot run an agent.

What it never does

Installing a monitoring tool means trusting it. So here is what it does not do.

✕

It does not read your traffic Addresses, ports, process names — metadata. Nothing is decrypted.

✕

It does not block anything It observes. A wrong verdict will not interrupt your work.

✕

It does not send your destinations away to be identified Threat lists and locations come to you; the matching happens on your own machine.

✕

It does not present a guess as a finding If nothing was checked, it says so. An empty list is never labelled "no threats".

EgressView Hub detection log: destinations that appear on a threat feed, with the device that reached them — A destination on a threat feed arrives with the device that reached it — and the matching happened on your own hardware.

Is this for you?

A good fit

You want to know what your own Mac talks to
You want the record to stay on your own hardware
You look after a home or small-office network
You have a Yamaha RTX or Cisco IOS router — for the Hub

Not a fit

You want something that blocks or defends
You need agents for Windows or Linux — macOS only today
Your router is not one of the two supported — for the Hub
You want a hosted service someone else operates

Getting started

The agent alone takes a few minutes. The Hub can come later, or never.

Download and open it. A signed, notarised installer.
Approve network monitoring. macOS asks once.
That is all. The record stays on that Mac and is sent nowhere.

Get the Mac agent Set up the Hub