Santa: an execution and file access control system for macOS

Four components and what each one does

Santa consists of four parts, and the README describes the division of labour in a single sentence.

The system extension monitors for executions and file access, and makes decisions based on the contents of a local database. This is the part with the system privileges, the part that the endpoint security framework talks to, and the part that actually evaluates a rule.

The GUI agent notifies the user when a block decision is taken, which matters more than it sounds: a lockdown-mode system that silently denies a launch leaves the user with a program that mysteriously will not start and no explanation.

A background service synchronises the configuration with a remote server, so a policy change reaches a fleet without every operator editing a local file.

The fourth part is a command-line utility for managing the system, which is what an administrator uses to inspect the event database, manage rules and check the state of the system.

The name is a joke that also describes the design. Santa keeps track of binaries that are naughty or nice.

The repository is an Objective-C++ project built with Bazel, with Source/, Testing/, deps/, profiles/ and stubs/ directories at the top level, a SECURITY.md and a CODEOWNERS file, and the documentation stored in the docs/ directory and published at northpole.dev.

MONITOR mode and LOCKDOWN mode

Santa has two operating modes, and the difference between them is the difference between a logging tool and a control.

In the default MONITOR mode, all binaries except those marked as blocked are allowed to run, while being logged and recorded in the events database. Nothing is denied unless a rule says so, so deploying Santa in monitor mode on a fleet changes nothing about what runs, and it starts producing data about what does run.

In LOCKDOWN mode, only listed binaries are allowed to run. This is the allowlist model, and it is the mode that stops the spread of malware across a fleet, since a binary that was never approved cannot execute on a locked machine.

The event logging behaviour is documented separately from the modes. When the system extension is loaded, all binary launches are logged. When in either mode, all unknown or denied binaries are stored in the database to enable later aggregation. So the event store holds everything in monitor mode and the interesting subset in lockdown mode, and either way the data is there for analysis.

The README also says caching is in place, so allowed binaries are cached and the processing required to make a request is only done if the binary is not already cached. On a fleet running the same signed applications across hundreds of machines, that is the difference between a rule evaluation on every launch and an evaluation on the first launch of each binary.

Code signing rules, path rules and the failsafe certificates

The rule system is where most of the practical work of writing a policy happens.

Instead of relying on a binary's hash, or fingerprint, executables can be allowed or blocked by their code signature, through CDHash, Certificate, TeamID or SigningID rules. The point of that is breadth. A TeamID rule allows every binary signed by one publisher, so a rule set can say that everything from a vendor is fine except one specific signing ID, without enumerating versions. The README explains that rules are applied in most-specific order, which is what allows that combination in either direction.

Path-based rules work through NSRegularExpression and ICU, giving regex matching on paths rather than a literal path. The README notes this is similar to what Managed Client did, the precursor to configuration profiles, which used the same implementation mechanism through the mcxalr binary, and that this implementation is configurable via regex and does not rely on LaunchServices. Path rules hold the lowest precedence when rules are evaluated, which is stated as a detail in the wiki.

Then there are the failsafe cert rules, and they are the part of the design that shows the care behind the project. A deny rule cannot block the certificate used to sign launchd, the process with pid 1, and therefore all the components macOS depends on. Binaries in every OS update are consequently allowed automatically, and so are some entire new versions. Apple App Store binaries are excluded from that treatment, because they use certificates that change regularly for common apps. Santa also cannot block itself.

Each of these decisions removes a class of catastrophic misconfiguration, and each of them is a constraint a policy author has to understand.

Sync servers, local rules and the two rule sources

Santa can synchronise its settings and policies with a management server, which the README says allows for very rapid configuration changes. Four servers are named.

Workshop is the official sync server offered by North Pole Security, described as fully-featured, fast, scalable and enterprise-ready. Moroz is a simple Go server that serves hardcoded rules from simple configuration files. Rudolph is an AWS-based serverless sync service built primarily on API Gateway, DynamoDB and Lambda components to reduce operational burden. Zentral is a centralised service that pulls data from multiple sources and deploys configurations to multiple services.

The alternative is local configuration, and the README names the mechanisms, starting with StaticRules. The local path is the one to understand first, because the sync server does not define what a rule means, it only delivers rules to the machine that evaluates them.

The choice between the four servers is a choice about who operates what. Workshop is the vendor's commercial option and the one with a support contract. Moroz is the option for a team that wants hardcoded rules in a file and nothing else. Rudolph moves the operational burden into serverless AWS components, and Zentral is the one built for pulling configuration from several sources rather than just serving a list.

The README also notes that a synchronised policy is only as good as the server, so a compromised management server is a path to a compromised fleet. That is true of any centrally managed agent and is worth stating in a security review rather than discovering later.

What Santa does not protect against

The known issues section of the README is unusually specific and deserves to be read before deployment rather than after an incident.

Santa only blocks execution, meaning execve and its variants. It does not protect against dynamic libraries loaded with dlopen, libraries on disk that have been replaced, or libraries loaded using DYLD_INSERT_LIBRARIES. The README's mitigation is that other parts of macOS will usually protect against these avenues, as long as System Integrity Protection is enabled. That is the important dependency: Santa's coverage is narrow and the rest is delegated to SIP, so a host with SIP disabled has lost both layers.

Scripts are ignored entirely. Any execution that is not a binary is not considered. The reason given is a balance of administration cost against benefit, and the note that a number of applications make use of temporary generated scripts which cannot practically be allowlisted. The project says it is willing to revisit the decision, or at least make it an option, if that would be useful to others.

That script exclusion has a consequence worth thinking through. A rule set that allowlists interpreters without constraining their arguments allows a great deal of execution through a path the policy cannot see, which is a gap in the allowlist model rather than a bug in the implementation.

The README is also clear about expectations. No single system or process will stop all attacks, or provide complete security, and Santa is written with the intention of helping protect users from themselves, for the case where someone downloads malware and trusts it, grants it credentials or allows unknown software to exfiltrate data. It is part of a defence in depth strategy, and the recommendation is to keep protecting hosts in other ways as well.

The userland components check each other's signatures

One security design decision is worth pulling out of the feature list, because it is the kind of detail that separates a system extension from a well built daemon.

Each of the userland components, the daemon, the GUI agent and the command-line utility, communicates with each other using XPC and checks that their signing certificates are identical before any communication is accepted.

The reasoning is straightforward. The system extension is privileged and makes the decisions. If an attacker could replace the command-line utility with their own build, they would have a process that talks to the privileged component and can request decisions or read state, and the trust boundary would be broken by a local file replacement rather than by a kernel exploit. Comparing the signing certificate of the peer before accepting a message closes that path, and it does so with the mechanism macOS already provides for code signing.

This is also a constraint on how the system can be built and distributed. The userland components have to be signed consistently, which is why the Makefile has separate release targets that build for arm64 and x86_64 in one invocation, and why the project has release variants that force a particular sync protocol version at compile time.

The repository also has a SECURITY.md with a disclosure policy, and the README asks people who find a vulnerability to read it rather than filing a public issue.

How Santa compares with EDR tools, Gatekeeper and Jamf

The usual comparison on macOS is with endpoint detection and response tools, and the difference in approach is where the decision point is.

An EDR product watches behaviour and looks for malicious patterns, and it is good at spotting things it has seen before. Santa makes an explicit allow or deny decision on a specific event, execution or file access, against a policy the administrator writes. It answers a narrower question, do we know this binary, and it answers it without needing a cloud service or a model. For a regulated environment that has to show a reviewer exactly which rule allowed or denied a launch, that is a different and more auditable answer.

Gatekeeper is the built-in macOS mechanism and the comparison is uncomfortable for Santa in one respect. Gatekeeper already has a code signing based allowlist, it is on by default, and it requires no agent. What Gatekeeper does not do is per-machine allowlist management from a server, event logging of launches, and the rule specificity Santa offers. Gatekeeper also has a user prompt model rather than a fleet policy model.

Jamf is the management layer comparison, and here Santa needs a sync server, which the README lists as Workshop, Moroz, Rudolph or Zentral. That is a real operational cost. Jamf can push configuration profiles to a Mac, and it could in principle carry Santa's rule set, but Santa's own sync server is the path the project supports.

For a small team without a management server, all of this is why Santa is probably the wrong first choice. For a security team with a fleet and a policy requirement, the event logging and the rule specificity are what justify the extra moving parts.

Licence, releases and what to check before deploying

The licence is Apache-2.0, and the README links the LICENSE file in the repository. Apache 2.0 carries an explicit patent grant and requires that a modified version states the change, which is the right licence for a component a company is likely to modify and redistribute internally.

The project is not archived and the last push was on 2026-10-19, so it is being worked on actively. The recent releases follow a date-based version scheme, with 2026.8 from 2026-09-16, 2026.7 from 2026-08-04 and 2026.6 from 2026-07-10, which is a reasonable cadence for something deployed across a fleet. A macadmins Slack channel is named as the place to ask questions, which is where this kind of tool's community actually lives.

Four things to check before rolling it out. Whether System Integrity Protection is enabled on every host, since the README leans on macOS to cover the execution avenues Santa does not handle. Whether your rule set is written against code signing rather than hashes, because a hash-based rule set goes stale with every update and the failsafe cert rules only protect the OS components. Whether you can operate a sync server, or whether you will start with local StaticRules and accept manual distribution. And whether the machine has the disk space and CPU for the event database, since every binary launch is logged and a busy machine generates a lot of records.

The last point is the one that catches people out. Santa is cheap to deploy and the database is not free, so the storage question should be answered before the pilot, not after.

Editorial conclusion

Santa suits a Mac fleet with a management server in place, particularly a security team that needs to know which binaries ran and wants to deny an executable that appears on a watch list without shipping a policy to every machine by hand. It is the wrong tool for a single personal Mac, where the administration cost outweighs the benefit, and the wrong tool for protecting a machine against a determined local attacker, because the README is explicit that it only intercepts execve and does not cover dlopen or replaced libraries on disk. Before deploying, read the known issues section and confirm that System Integrity Protection stays enabled on your hosts, since the README leans on macOS itself to cover the avenues Santa does not.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. northpolesec/santa on GitHub
3. Project website
4. README
5. Releases