Trusting an app on a Mac is not a single yes-or-no decision. It is four separate questions, each answered by a different mechanism: who built it, has Apple checked it, what is it allowed to touch, and what does it actually do once it is running. Apple documents the first three in detail. The fourth is the one you have to observe yourself, and it is the one that catches an app that passed the first three and then went wrong.
App Store or direct download
Apple’s support page Safely open apps on your Mac calls the App Store the safest place to get software, for two concrete reasons: Apple reviews each app before accepting it, and Apple can remove an app quickly if a problem is found later. App Store apps must also run inside the App Sandbox, which Apple’s Gatekeeper and runtime protection page describes as limiting what data an app can reach and forcing it to use macOS APIs to talk to other apps.
That does not make every direct download suspect. A great deal of legitimate Mac software is distributed outside the store because the sandbox forbids what it needs to do (disk utilities, development tools, firewalls included). The difference is that for a direct download, the review step is replaced by two lighter checks that Apple describes on the same pages: a signature that says who built the app, and a notarization scan.
Developer ID and notarization: what they prove
A Developer ID certificate is issued by Apple to a developer enrolled in the Apple Developer Program, and it lets Gatekeeper confirm that an app was signed by that developer and has not been modified since. That is all a signature proves: identity and integrity. It says nothing about intent. A signed app can still be a bad app; the signature just means Apple knows whose name is on it and can revoke it.
Notarization is the second check. Apple’s developer documentation on notarizing macOS software before distribution describes it as an automated scan of Developer ID-signed software for known hostile content and code-signing problems, after which Apple issues a ticket that Gatekeeper can read. Apple’s support page is careful about the wording: notarization means “Apple checked it for malicious software and none was detected”. It is a scan against what Apple already knows, not a review of what the app does, and Apple can revoke a notarization later if it learns better.
The quarantine flag
The mechanism that ties these checks to a specific download is an extended attribute on the file, com.apple.quarantine, which Safari and most other browsers and messaging apps set on anything they save. When you first open a file carrying that attribute, Gatekeeper performs its checks and asks for your approval. Apple’s Gatekeeper page describes the default as checking all software for known malicious content the first time it is opened. You can see the attribute yourself with the Terminal command xattr -l on a downloaded file.
If an app is not signed or not notarized, macOS refuses to open it and offers a path to override. Apple’s support page Open a Mac app from an unknown developer explains the steps and then adds a warning worth quoting in substance: overriding these settings is the most common way a Mac gets infected, and Apple recommends finding another app instead, even when the developer seems established. The practical rule follows directly. An override should be a rare, deliberate act for software you have a specific reason to trust, never a reflex.
Permissions: what an app is allowed to touch
The third question is scope. Since macOS 10.15, Apple’s Platform Security Guide page on controlling app access to files explains, apps must ask before reading your Desktop, Documents, Downloads, iCloud Drive or network volumes, and access to the camera, microphone, screen recording, keystroke monitoring and Full Disk Access is granted only through explicit prompts or a manual change in System Settings, Privacy & Security. The system behind these prompts is called TCC (Transparency, Consent and Control), and its principle, in Apple’s words, is that users should have full transparency, consent and control over what apps do with their data.
Permissions are a trust signal in themselves. A clipboard manager that asks for Accessibility access has a reason. A wallpaper app that asks for Full Disk Access and Screen Recording does not. The mismatch between what an app is for and what it asks for is often visible before the app has done anything at all, and it costs nothing to decline and see whether the app still works.
Network behaviour: the question the other checks cannot answer
Signing, notarization and permissions are all evaluated before or at the moment of a request. None of them observe the app over time, and none of them look at the one activity that turns a privacy problem into a security one: sending data off the Mac. An app can be signed by a real developer, notarized by Apple, granted only the permissions it plausibly needs, and still upload your contacts to an analytics broker, poll a tracking endpoint every few minutes, or, after a routine update replaces its code, start talking to a server it never contacted before.
Reading network behaviour as a trust signal means asking a few concrete questions about each app. Does it connect at all, and if so, is that expected for what it does? Which hosts does it talk to, and are they the developer’s own, a recognisable service, or a list of advertising and analytics domains? Does it use encrypted connections, or does anything leave over plain HTTP? Does its behaviour change after an update? And does it connect on a schedule when you are not using it? None of these require expertise; they require seeing the connections, which macOS does not show you by default.
This is what FireAI is for. Its live map shows every connection each app makes, with the destination, the country and the network behind it, and its Private AI review, an on-device model, judges each new connection from an unknown app using destination reputation, whether the binary has been seen before, port and protocol, and whether the link is encrypted, then explains its reason in plain language. Its unencrypted data guard stops card numbers, passwords and API keys leaving over plain HTTP regardless of which app is sending them. Every AI decision becomes a visible rule you can undo, and rules can be written in plain English or French (“block Microsoft Teams”) or exported as a text file.
Blocking what is unsigned, and following the signature
Two FireAI design choices come straight from Apple’s model above. First, its stricter security modes, Paranoid and Under attack, block unsigned apps from connecting at all, along with telemetry and trackers, which turns Apple’s “are you sure?” dialog into a network-level default: an unsigned binary can run if you insisted, but it cannot phone anyone. Second, FireAI’s per-app rules follow the app’s code signature rather than its name or path. An impostor named “Slack.app” in the Downloads folder does not inherit the rule you wrote for the real Slack, because the signature does not match; and when the real app updates, the rule carries over, because it does. This is the same identity Apple uses for Gatekeeper, applied to the network.
What this does not do
FireAI does not scan an app’s files, does not inspect its code or memory, and is not an antivirus; it cannot tell you a download is hostile before you run it. If you have allowed an app, traffic that hides inside that app inherits its permission. Encrypted traffic to a reputable destination is judged by destination and pattern, not content. And no firewall replaces the first three checks: the cheapest, most reliable trust decision on a Mac is still to prefer the App Store or a Developer ID-signed, notarized download, to refuse the override dialog, and to decline permissions an app has no visible reason to need.
Put together, the four questions give a working definition of a trustworthy Mac app: signed by a known developer, notarized by Apple, asking only for what it plausibly needs, and talking only to servers that make sense for what it does. Apple lets you check the first three at install time. The fourth you can only see by watching, which is why it is the one worth adding.
How FireAI and HisnLabs fit in
Apple answers the first three trust questions at install time; FireAI exists for the fourth, showing what each app actually does on the network and keying every rule to the same code signature Gatekeeper already relies on.
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.