Your Mac is talking right now. Not metaphorically: at this moment, several dozen processes hold open sockets to servers you have never heard of, and most of that is fine. Update checks, sync, push notifications, telemetry, a font being fetched. The point of network monitoring is not to panic about the volume but to be able to answer one question about any single line of it: which app, to whom, and why. macOS gives you three free tools that get you part of the way. This article explains what each one shows, where it stops, and what a per-app firewall adds on top.
Activity Monitor: totals, not destinations
Open Activity Monitor, click the Network tab, and you get the honest overview Apple designed it for. Apple’s guide describes the bottom panel: packets in and out, data received and sent in megabytes, and a graph you can switch between packet and data throughput. The process list above it tells you how much each process has sent and received. What it does not tell you is where. There is no column for the remote host, no port, no country. Activity Monitor answers “is something using a lot of bandwidth?” and stops there. It is the right tool for spotting that a helper process has uploaded two gigabytes overnight, and the wrong tool for finding out to whom.
lsof: a snapshot of every open socket
The command-line tool lsof lists open files, and on Unix a network socket is a file. With the -i option, which the macOS man page describes as selecting files whose internet address matches, you get every open connection with the owning process name, its process ID, the protocol, and the local and remote address and port. Add -n and -P to keep addresses and ports numeric rather than waiting on reverse DNS. The result is the most complete free picture you can get of the present moment, and the emphasis is on moment: lsof is a snapshot. A connection that opened, sent a kilobyte and closed in the half-second before you pressed Enter is simply not there. It also identifies the process by name and PID, not by who signed it, so a binary called “Adobe Update Helper” in a temporary folder looks exactly like the real thing.
nettop: the same view, updated live
nettop is the closest thing macOS ships to a live connection monitor. Its man page describes it as displaying a list of sockets or routes with periodically updated network statistics. In practice you see each process, its open connections, bytes in and out per connection, the interface in use and the connection state, refreshing every second. It fixes lsof’s snapshot problem and remains the best built-in answer to “what is that app doing right now.” Its limits are the same as lsof’s in every other respect: no identity beyond a process name, no notion of country or organisation behind an address, no memory of what happened an hour ago, and no way to say no. You can watch a connection with nettop; you cannot stop it.
The built-in firewall does not help here
People often assume that turning on the firewall in System Settings covers this. It does not. Apple’s own guide is careful with its words: the macOS firewall protects your Mac from unwanted contact initiated by other computers. It is an inbound filter. It has nothing to say about what your applications send out, which is the direction every question in this article points. For outbound, per-application control, Apple provides the Network Extension framework, whose content filter providers let a third-party app see and filter network flows with the identity of the application that made them. That is the foundation modern per-app firewalls on macOS build on, and it is what turns a list of sockets into a list of decisions.
What a per-app firewall adds
Four things, concretely. Identity: a flow is attributed to a signed application, so a rule for Slack applies to Slack and not to anything that happens to share its name; FireAI’s per-app rules follow the app’s code signature for this reason. Visibility: every connection is shown as it happens, including the ones that last half a second. Context: the raw IP address is resolved to the organisation and country behind it, which FireAI shows on a live world map with blocked connections in red. And control: a connection can be allowed or denied by host, domain, IP or port, and an unknown app has to ask before its first connection, with the on-device model’s reason for its verdict shown in the prompt. If you disagree with a decision the AI made, you undo it, and the undo becomes a visible rule you can read later or export as a text file.
FireAI also accepts plain-language orders, in English or French, such as “block Microsoft Teams”, which is a faster way to write a rule than a dialog with four fields. What it does not do is worth stating just as plainly: it does not inspect the content of encrypted traffic, it does not scan files, and it does not examine processes or memory. It works at the level of who is connecting to what, and it is honest about that boundary.
How to read one connection
Take any line from nettop or from a firewall log and ask three questions. First, the company: who owns the address? Most traffic goes to a handful of hosting providers and content networks, and a music app talking to Amazon or Cloudflare is usually just talking to its own backend. The pattern to notice is mismatch: a note-taking app connecting to an advertising network, or a screenshot utility connecting to a hosting provider it has no reason to use. Second, the country: not because a foreign server is bad, but because a change is informative. An app that has connected to Ireland for a year and today connects to a new country for the first time has changed something. Third, the port. 443 is HTTPS and covers almost everything; 80 is plain HTTP and should be rare in 2026; 53 is DNS; 22 is SSH; 445 is SMB file sharing; 5353 is Bonjour on the local network. A consumer app opening port 22 or 445 to an address on the internet is unusual enough to justify a question.
Patterns worth a second look
- Beaconing: the same process contacting the same address at a fixed interval, every sixty seconds or every ten minutes, with tiny payloads. MITRE ATT&CK describes command and control as the adversary trying to communicate with compromised systems to control them, and a regular heartbeat is the most common shape that takes. Update checks also beacon, so the tell is an unfamiliar process, not the rhythm alone.
- Tor exit nodes: the Tor Project publishes its exit node list, and there is no ordinary reason for a productivity app to reach one. FireAI applies that list locally as one of its threat-intelligence feeds.
- Plain HTTP carrying credentials: a login form, an API key or a card number sent over port 80 is readable by anyone on the path. FireAI’s unencrypted data guard is built for exactly this case and stops card numbers, passwords and API keys from leaving over plain HTTP.
- A first connection from a long-installed app: an app that has been silent for months and suddenly opens a socket has updated, been replaced, or been hijacked by a plugin. All three are worth knowing.
- Unsigned or unknown binaries going online at all: on a Mac where everything you use is signed, an unsigned binary making its first connection is the single most useful alert a firewall can raise. FireAI’s stricter security modes, Paranoid and Under attack, block unsigned apps outright.
- Addresses on published blocklists: Spamhaus describes its DROP list as ranges so dangerous that it provides them free to anyone who wants that layer of protection; FireHOL aggregates and documents public IP feeds focused on attacks and abuse; abuse.ch runs community-driven threat intelligence platforms. FireAI applies these feeds locally, as system-wide IP blocklists, without sending your traffic anywhere.
DNS filtering, honestly
DNS is where a lot of network filtering products live, so it is fair to ask where FireAI stands. Today, FireAI filters on the connection itself: it applies threat-intelligence feeds and IP blocklists to the addresses your apps actually reach, and per-app rules can match a host or domain name. What it does not yet do is act as your DNS resolver or offer encrypted DNS of its own; that is planned, and we would rather say so than imply it. There is a practical consequence to understand. Encrypted DNS, specified as DNS over TLS in RFC 7858 and DNS over HTTPS in RFC 8484, and supported system-wide on macOS since Apple’s WWDC 2020 session on enabling encrypted DNS, hides your queries from anyone on the network path. That is good for privacy and it also means a filter that only watches DNS queries goes blind when a browser uses its own DoH resolver. A filter that acts on the destination address still sees the connection, because the app still has to open it. Neither approach is complete on its own, which is why the honest position is “both, eventually” rather than a claim that one replaces the other.
A practical routine
You do not need to watch the network all day. A workable routine is three minutes once a week: open FireAI’s list of connections, go through it application by application, and look at the ones you do not recognise. Check the company and country behind anything new. Write a rule for what you decide, so you never review the same connection twice, and export your rules once in a while so a fresh Mac starts with your decisions rather than from zero. The free tools will always be there when you want the raw view; a per-app firewall is what makes that view something you can act on.
How FireAI and HisnLabs fit in
lsof and nettop will show you a snapshot; what they cannot do is stop a connection, remember your decision, or tell you in plain words which company and country sit behind an IP address — and that gap is exactly the one FireAI was built to fill.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.