The built-in macOS firewall is primarily an incoming-connection firewall. It is not a general per-app outbound firewall that asks whether each application may contact the internet. Use an outbound application firewall when you need to allow, deny, or monitor remote connections by app.
What Apple documents
Apple says macOS includes a firewall “to protect the Mac from network access and denial-of-service attacks.” Its documented configuration options include blocking all incoming connections, allowing signed software to receive incoming connections, and adding or denying access based on user-specified apps.
The repeated word is incoming. You can read the current wording in Apple Platform Security: Firewall security in macOS.
That built-in protection is valuable. It reduces exposure from services listening for other devices to connect to your Mac. It simply addresses a different direction from an app opening a connection to a remote server.
Incoming and outgoing firewalls solve different problems
Incoming connection control
An incoming connection begins elsewhere and targets a service on your Mac. File sharing, remote login, local development servers, and multiplayer software are common examples. The built-in firewall can block or allow this access.
Outgoing connection control
An outgoing connection begins with a process on your Mac. It may check for updates, sync data, fetch content, validate a license, send diagnostics, contact analytics, or open a peer-to-peer session. An outbound firewall decides whether that process may reach the destination.
Why the distinction matters
A Mac can be well protected from unsolicited incoming traffic while installed apps still contact remote services. Turning on the built-in firewall does not give you a dashboard of every app’s outbound destinations or a per-destination Allow/Deny policy.
An outbound app firewall supplements incoming protection; it does not make the built-in firewall obsolete. They cover different edges of the same machine.
Options for controlling outgoing connections on Mac
- Per-app outbound firewall: best match when the policy should follow a specific application.
- Packet filter: useful for address, port, protocol, and interface rules, but harder to manage by app identity.
- DNS or hosts blocking: useful for known domains, but global to the Mac and incomplete for raw IP connections.
- Router policy: sees devices and destinations, but usually cannot distinguish two apps on the same Mac.
- Virtual machine: a stronger isolation boundary when the app itself is untrusted.
Where Faraday Cage fits
Faraday Cage is a per-app outbound firewall. You select an installed application, choose a default Deny, supported Ask, or Allow policy, and review its local network evidence. This complements the built-in firewall rather than replacing its incoming protection.
The product’s distinguishing model is a targeted Cage: it does not need to interrupt every app on the Mac. The development guard plane is also designed to attribute child and helper processes through audit-token process relationships. That full guard behavior is still under signed runtime validation.
Questions to ask before choosing an outbound firewall
- Does the tool identify only the main executable, or also the helpers it launches?
- Can you distinguish a host-wide decision from an endpoint-specific rule?
- Does it upload destinations, hashes, or traffic for reputation analysis?
- What happens to new traffic if its extension, agent, or UI is unavailable?
- Does “Ask” behave differently for TCP and connectionless protocols?
Add outbound control without losing incoming protection.
Faraday Cage is in private beta while Apple capabilities and signed acceptance are completed.
Request early access ↗