Application allowlisting

Elevation control answers "may this run as admin?" Allowlisting answers a stricter question: "may this run at all?" On macOS, ElevateIQ enforces it with Apple's Endpoint Security framework: unapproved binaries are stopped at launch, before any code executes.

Two layers, one vocabulary

Allowlisting is a separate enforcement layer from elevation, but it reuses the same rule engine, identity fields, event pipeline and scoring. An execution rule looks and behaves like an elevation rule; only the question it answers differs.

Modes

Set in Settings → Elevation → Application Allowlisting, independent of the elevation policy mode:

Mode	Behavior
Off	No execution monitoring; execution rules are not sent to agents.
Audit	The agent observes every launch and reports it; nothing is ever blocked. The safe first step, and where every rollout must start.
Enforce	Default-deny: only binaries matching an Allow execution rule (or trusted OS binaries) may launch.

Auto-trust OS platform binaries (on by default) passes Apple's own signed system binaries without a rule. Leave it on: it is load-bearing for both performance and not breaking the OS on enforce day.

Execution events

In Audit and Enforce, launches appear under Requests → Execution. Each observation carries the binary's macOS identity and a decision:

Decision	Meaning
Allowed	A rule or OS auto-trust positively covers this binary.
Would block (audit)	Nothing covers it: Enforce mode WOULD have stopped this launch. These rows are your work queue before flipping to Enforce.
Blocked	Enforce mode stopped the launch.

Identity fields

Field	Meaning
team_id	The Apple Developer Team ID of the signer: the vendor anchor, stable across the vendor's apps and updates.
signing_id	The bundle signing identifier ("com.google.Chrome"): pins one app within a vendor.
cdhash	The code-directory hash: pins one exact build. The only anchor an unsigned binary has.
exe_path / parent_process	Where it ran from and what launched it.
user	Which endpoint user launched it.

Building the allowlist: promote from reality

Each event row has an Allow button that opens the rule form pre-filled with the binary's verified identity. The prefill prefers the durable anchor: Team ID plus Signing ID, which survives app updates. Only unsigned binaries fall back to the CDHash pin. The recommended rollout:

Set mode to Audit and let the fleet run for one or two representative weeks.
Work through the Would block rows, promoting legitimate software to Allow execution rules.
When new Would block events slow to a trickle you recognize, flip to Enforce.

Execution rules

Two actions in the same rule engine: Allow execution and Deny execution (deny wins, and requires a reason shown to the user). Allow rules can additionally fence what an allowed app may spawn:

Child process policy	Meaning
all	The allowed app may spawn anything.
none	No child processes.
listed	Only children matching an explicit list (by team ID, signing ID, cdhash or path).

Honest limits

The script gap. Allowlisting gates the interpreter, not the script. If bash or python3 is allowed, any script runs through it. Default-deny protects compiled binaries; treat interpreter allowances as deliberate policy decisions.

Fail-open on agent crash. If the monitoring process crashes, macOS allows all launches until it relaunches (Apple's design, common to every Endpoint Security product). The agent is supervised for fast relaunch, but the window cannot be eliminated.

Requirements

macOS agent with the Endpoint Security capability (Apple grants this entitlement per developer; it ships with the agent).
An MDM-delivered privacy profile granting the agent Full Disk Access. This cannot be self-granted by the agent.