Enable Gatekeeper

What the Gatekeeper enforcement Worklet does

This Automox Worklet™ enforces Gatekeeper on macOS endpoints by detecting when Apple's code-signing assessments are disabled and turning them back on. Gatekeeper is the system service that validates a Developer ID signature and a notarization ticket before the kernel allows an application to launch. When assessments are off, any unsigned binary can run, and the protections that Apple ships by default no longer hold.

The evaluation script captures the second token of spctl --status output. If that token reads "enabled," the script exits 0 and remediation never fires. If it reads "disabled," the script exits 1 and Automox schedules remediation on the next policy run. The remediation script re-checks the state, then calls spctl --master-enable to restore assessments. The flow is idempotent, so the policy can run on a recurring schedule with no risk of toggling state on already-compliant endpoints.

The Worklet does not modify the Gatekeeper rule database, does not approve or deny specific apps, and does not change quarantine attributes on existing files. It restores the global assessment switch only. Per-app exceptions a user has accepted through System Settings stay in place after remediation. Apps that were launched while Gatekeeper was disabled retain their existing run history, so a follow-up audit pass with codesign --verify or spctl --assess is the right way to inspect what ran during the gap.

Why enforce Gatekeeper across the Mac fleet

Gatekeeper is the runtime gate that prevents unsigned and unnotarized Mach-O binaries, .pkg installers, and .dmg images from launching on macOS. With assessments disabled, an attacker who lands a payload on disk – through a phishing download, a malicious Safari extension, or a supply-chain compromise of a developer tool – gets a free path to execution. Notarization checks for known malware hashes are also bypassed when Gatekeeper is off, so even payloads Apple has explicitly flagged can run. CIS Benchmark 2.6.x for macOS requires Gatekeeper to be enabled, and NIST 800-53 controls SI-3 (malicious code protection) and CM-7 (least functionality) treat code-signing enforcement as a baseline expectation.

A user or developer who runs sudo spctl --master-disable to ship a one-off internal build leaves a code-execution hole that no MDM dashboard surfaces by default. Run this Worklet on a daily policy against your macOS device group so spctl --master-enable fires on the next agent check-in for any Mac that drifted, with a clear audit trail in Automox activity logs and a non-zero exit code recorded when remediation runs.

How Gatekeeper enforcement works

1. Evaluation phase: The evaluation script runs spctl --status and parses the second field with awk. "assessments enabled" returns the token enabled and the script exits 0, marking the endpoint compliant. "assessments disabled" returns disabled and the script exits 1, which queues remediation. No state is changed during evaluation.

2. Remediation phase: The remediation script re-checks spctl --status, exits 0 if Gatekeeper has been re-enabled between evaluation and remediation, and otherwise calls spctl --master-enable to restore assessments. Once enabled, the kernel resumes Developer ID and notarization checks at launch time, the quarantine bit on freshly downloaded files is honored again, and spctl --assess --verbose starts returning structured pass or reject output for individual binaries.

Gatekeeper enforcement requirements

• macOS endpoint running 10.15 Catalina or later (the Automox agent's supported Mac matrix)

• Root privileges for the Automox agent, which the default agent context already provides – spctl --master-enable requires root

• Bash interpreter at /bin/bash (present on every supported macOS release)

• No policy variables to configure; the Worklet runs against the global Gatekeeper state and accepts no parameters

• No conflicting MDM configuration profile setting AllowIdentifiedDevelopers to false – an MDM-pushed exception will override spctl changes on the next mdmclient sync

Expected Gatekeeper state after enforcement

After remediation, spctl --status returns "assessments enabled" and Gatekeeper rejects launch attempts for binaries that lack a valid Developer ID signature or a current notarization ticket. Users who try to run an unsigned application see the standard macOS dialog explaining that the app cannot be opened because Apple cannot check it for malicious software. The only path around the dialog is a right-click Open with an admin password, which writes an explicit user exception to the Gatekeeper rule database and is captured in the unified log under the syspolicyd subsystem.

Validate the change by running spctl --status for the global state and spctl --assess --verbose /Applications/Safari.app for a representative system binary. A valid response reads "accepted source=Apple System." For a notarized third-party app, codesign --verify --deep --strict --verbose=2 /Applications/<app>.app confirms the signature chain. For audit evidence, capture spctl --status output alongside the Automox policy run identifier; the pairing closes the loop on CIS 2.6 compliance reporting across the fleet.