macOS for defenders: launchd, TCC, MDM and the unified log

How privileged software runs on macOS: launchd and daemons

Start where Chapter 15 started, with the question of how privileged software comes to be running at all. On Windows the answer was the service. On macOS it is launchd and the programs it supervises.

launchd is the first user-space process the system starts at boot, and it is the ancestor of everything else that runs. Its job is to start and supervise background programs, restarting them if they fail and starting them on demand. Those background programs come in two kinds, and the distinction is worth holding lightly. A daemon runs system-wide, started before and independently of any user logging in, under a system account rather than a person's. A launch agent runs inside a particular user's logged-in session. A security agent on a Mac is a daemon: it runs for the whole machine, before and after any user is at the keyboard, which is the macOS form of what Chapter 15 called running as LocalSystem.

The point that carries across all three operating-system chapters holds here too. A daemon belonging to the organisation's security tooling gets onto the Mac only through an administrative install on a managed machine. The personal Mac on a researcher's kitchen table runs no such daemon, because nobody with the organisation's authority installed one, which is the bring-your-own-device blind spot once more, now in macOS clothing.

No registry: configuration profiles and the defaults system

Here the platforms diverge in a way that trips up Windows-trained defenders, so it is worth stating flatly: macOS has no registry. There is no single hierarchical database of machine-wide settings with a protected hive an administrator writes into. macOS keeps configuration as preferences, a system of property-list files usually manipulated through a tool called 'defaults', and for organisational control it uses configuration profiles.

A configuration profile is a signed document that expresses policy: settings, restrictions, certificates, and the permissions discussed later in this chapter. A profile can be installed by hand, but in an organisation it is delivered by the management system. The conceptual equivalence to draw for the reader is this. On Windows the organisation enforces a setting by writing a value into a protected registry hive the user cannot reach. On macOS the organisation enforces a setting by installing a managed configuration profile, and a profile delivered by the management system the device is enrolled in is the one the user cannot casually remove. The browser policies that matter for shadow AI, forcing the Edge for Business work profile, constraining other browsers, force-installing or locking an extension, arrive on a Mac as profile payloads, not as registry keys, but they do the same job by the same logic of an enforced setting the user does not own.

MDM is the only substrate: there is no Group Policy

The next divergence is larger. macOS has no domain join, no Group Policy, and no Active Directory mechanism that reaches into the operating system the way Group Policy reaches into Windows. The single supported way an organisation manages a Mac is the MDM protocol, the mobile-device-management framework Apple itself defines, which products such as Microsoft Intune and Jamf Pro speak on the organisation's behalf.

This is exactly why the device-state report, every time it touches macOS, says onboarding happens 'via Intune, JAMF or another MDM' and never via Group Policy or a domain. There is no other road. Microsoft's own documentation makes the dependency explicit: to bring a Mac into Purview's data-loss tooling the device must already be managed through Intune, Jamf Pro or another MDM, with the Defender for Endpoint agent deployed first. (high) Management on a Mac is MDM or it is nothing.

The consequence for the device-state ladder from Chapter 14 is that the Mac's rungs are coarser than Windows'. The rich middle that Windows offers, where the Edge work profile can carry policy onto a device that is not fully enrolled, is thinner on the Mac. Apple also ties its strongest management to supervision, the state of a device enrolled through Apple Business Manager and automated device enrolment, which is the macOS analogue of the distinction between a corporate-owned and a personally-owned device. Supervision is what lets an organisation pre-grant the permissions the next section describes, and a bring-your-own Mac will not have it. The full join-state taxonomy is Chapter 20's subject; what matters here is that on a Mac the meaningful line is between unenrolled and MDM-enrolled, and the strongest controls sit behind supervised enrolment specifically.

TCC and the Endpoint Security framework: Apple's fences inside the privileged side

Now the heart of the chapter, and the part with no clean Windows parallel. On Windows, an agent running with system privilege can broadly watch what the machine does. On macOS, privilege and permission are two different things, and Apple keeps them apart deliberately.

The mechanism is TCC, for Transparency, Consent and Control. TCC gates access to a list of sensitive resources behind explicit consent: the camera, the microphone, screen recording, the contents of the Documents, Desktop and Downloads folders, the sweeping permission called Full Disk Access, and the ability to automate or observe other applications. The feature that surprises Windows-trained defenders is that TCC applies even to software running with root privilege. An agent can be a daemon, running with the highest privilege the system offers, and still be unable to read a protected folder or watch the screen until it has been granted that specific permission through TCC. That is precisely what happened to the agent in the opening scene. It was running; it had not been granted what it needed to see.

The way an organisation removes that surprise is to pre-grant the agent its permissions through the management system, using a profile payload that declares, in advance, which TCC permissions the agent is allowed, so that the user is never prompted and cannot refuse. This pre-grant is reliable only on a supervised, MDM-enrolled device. On a personal Mac the permissions fall back to the user, who can decline them and revoke them later. So on the Mac the consent system does not merely add a step; it hands the user a veto that on Windows they would not have.

Underneath TCC sits a deeper architectural shift. Apple has deprecated the kernel extension, the old way a security vendor inserted code into the macOS kernel to watch the system. macOS Catalina was the last release to fully support legacy kernel extensions, and Apple has since moved security vendors into user-space system extensions, observing the system through Apple-defined frameworks rather than from inside the kernel. (high) The relevant framework for an endpoint agent is the Endpoint Security framework, through which an agent subscribes to a curated stream of process, file and, by way of the related Network Extension framework, network events. On recent Apple silicon Macs, loading a third-party kernel extension at all requires the user to approve it, restart, and reduce the machine's secure-boot posture, which is a deliberate disincentive. (high)

Tie this back to Chapter 14. There, the model said a control sitting in or near the kernel can observe the system calls a process makes, and therefore see what the process actually does. macOS now answers: not by reading syscalls from the kernel, you do not. You observe the event stream Apple chooses to expose, from user space, limited to the event types the Endpoint Security framework defines, and only with the entitlements and TCC grants Apple's framework requires. The privileged side of the boundary still exists, but Apple has narrowed what standing on it lets you see. The unified log, the system-wide structured logging facility on macOS, is where much of this activity surfaces and is a useful detection and forensic source, but it too shows what the system records, not whatever an agent might wish to capture.

Reading shadow AI controls down the macOS stack

With the mechanisms in hand, walk the same path down the stack as Chapter 15, and let the divergences carry the section.

The outermost control blocks the AI site from the device. Defender for Endpoint runs on managed Macs, deployed by MDM, and its network protection feeds Cloud Discovery so that traffic to AI services can be both seen and blocked on a managed Mac. (high; source reports) The honest qualification is that network protection on macOS rides on a Network Extension, an Apple-mediated user-space mechanism, not a kernel filter, so its behaviour and coverage are not identical to Windows and should not be assumed to be. The lesson of the chapter is to expect macOS parity to be partial until tested.

The control that reads the paste or the prompt before encryption is where macOS quietly does less, and this explains the device-state report's most-quoted macOS caveat. Endpoint data-loss prevention does exist on a managed Mac, but with a smaller set of conditions than on Windows. Content scanning is more limited, several activities are not yet supported, and copy-to-clipboard enforcement carries caveats, so the specific exfiltration paths an organisation cares about, paste, drag and upload into an AI tool, have to be tested rather than assumed. (medium) The reason is now legible: the agent has no Windows-style latitude, it works through the Endpoint Security framework and through TCC-gated access, so what it can see is bounded by what Apple's framework surfaces and what permission has been granted. There is a second, sharper instance of the same point. The Microsoft Purview browser extension for Chrome and Firefox, which on Windows is force-installed to catch sensitive data going into AI sites, is not used on macOS at all; Endpoint DLP on the Mac relies on Defender hooks in supported browsers instead. (high) The clean Windows approach of pushing a compliance extension into Chrome simply does not transfer.

Then there is a control that is absent rather than merely reduced. There is no Intune App Protection, no mobile-application-management path, for macOS desktop applications. (high) The story that exists on iOS and Android, where copy-and-paste from Outlook into a consumer AI app can be blocked without managing the whole device, has no macOS-desktop equivalent. Microsoft's substitute on the Mac is the same one it offers on unmanaged Windows: the Edge for Business work profile and its inline data-loss prevention, which works on macOS in the work profile and needs no device onboarding. (high) The consequence is stark. On a personal Mac, the only surviving prompt-level control is Edge for Business inline DLP inside the work profile, and the user steps around it by opening Safari, Chrome, or Edge's personal profile, just as on Windows but with even fewer controls standing behind it.

The innermost control stops the local AI client, and here macOS has no AppLocker and no App Control for Business. Its own mechanisms are Gatekeeper, which checks that software is signed and notarised by Apple before it is first allowed to run, and, for managed fleets, MDM-delivered restrictions on which applications may be installed or opened, within the broader posture of a supervised, locked-down device. Gatekeeper is a baseline integrity check, not an enterprise allowlist, so the crisp Windows answer, that App Control in enforced mode refuses the launch, has only a softer macOS analogue. The locally-run-model problem from Chapter 15 returns with more force. A researcher running a model under a tool like Ollama on a personal Mac is reachable by essentially nothing the organisation owns: no network connection for network protection to block, no browser session to inspect, no cloud sign-in to police, and no enterprise application control to refuse the launch.

The payoff mirrors Chapter 15 with one added clause. Every macOS shadow AI control still reduces to placing something on the privileged side of the device through MDM. But Apple has interposed TCC and the Endpoint Security framework so that standing on the privileged side grants less than it does on Windows. The macOS column of the device-state matrix is not Windows with footnotes. It is a platform where the vendor has deliberately narrowed what any agent, including the organisation's own, is permitted to see.

Last updated 9 August 2026