Rule-Based Application Elevation on macOS (Beta)
Explore how to implement rule-based application elevation on macOS to enhance security and simplify user permission management.
Written by Daniel Rivera
Updated at September 11th, 2026
Table of Contents
Overview
Application elevation lets you approve a specific application or installer on a Mac ahead of time, using a rule, the way the Windows agent already does. Where an elevated session grants a person administrator rights for a period of time, a rule elevates a program — so routine prompts your technicians approve over and over stop needing a live approval at all.
This is a Beta feature. It is available only on the beta agent update channel. Read Availability and Requirements below before planning a rollout. The screenshots below are from a beta build and the interface is not final, so what you see may differ in detail.
This walkthrough shows the whole flow end to end — a standard user blocked by macOS, the rule built from the resulting event, and the same action succeeding afterwards:
Availability and Requirements
- Admin Portal and API — available now. Authoring macOS rules, and reporting on macOS elevation events, are live in the portal for every organization. Enforcing those rules on a Mac still requires the beta agent below.
- The agent that enforces rules is macOS agent 2.0.1720, published to the beta agent auto-update channel on 10 September 2026. The stable channel does not include it, so a Mac on the stable channel will not enforce rules no matter how they are configured.
- macOS 14.7 or higher is required. The authorization plugin the agent uses to intercept elevation is not supported below that, even though the agent itself supports macOS 14.0 and higher for elevated sessions.
Because the portal half shipped ahead of the agent, you can author Mac rules today against Macs that cannot yet enforce them. Rules you create now are not lost — they apply as soon as the Mac is running agent 2.0.1720.
How Application Elevation Works
When a standard user does something on a Mac that needs administrator authorization — installing a package, changing a protected setting, running an installer that asks for credentials — macOS raises an authorization request and asks for an administrator's password.
On a Mac running the beta agent, the agent sees that request and checks it against your rules before macOS shows the prompt.
- If a rule matches, the agent elevates the operation and the user is never asked for admin credentials.
- If no rule matches, the request falls through to the normal macOS password prompt above, exactly as it would without AutoElevate.
- Either way, the agent reports the event, so the portal shows what was elevated and what was missed.
The user is never made an administrator. A rule authorizes the matched operation; the account is not added to the Mac's local administrators group and stays a standard user throughout. Anything the rule does not cover still prompts for an administrator password as before.
Every request the agent sees — matched or not — lands on the Elevation Events grid, which is where Mac rules are created from. This is independent of elevated sessions. A Mac can use rules, sessions, or both — see macOS Support & Elevated Sessions for the session workflow.
Elevation Modes on macOS
Elevation mode is set per computer from the Computers grid: select the Macs, click Actions, then choose Set Elevation Mode to Audit, Set Elevation Mode to Policy or Set Elevation Mode to Live. To clear a mode set on individual computers, use Remove Mode Override in the same menu; those computers go back to the elevation mode configured for their level in Settings. This is the same control the Windows agent uses.
Audit
The agent reports every elevation it sees and records which rule would have matched, but applies nothing. macOS prompts for a password exactly as it does without AutoElevate. This is the discovery phase: run a group of Macs in Audit for a week, see what your users are actually elevating, and build rules from real events rather than guesses.
Policy
Matched rules are enforced. Anything no rule matches falls through to the normal macOS password prompt.
Live
Live enforces matched rules exactly as Policy does. The part that makes Live different on Windows — the user asking a technician for approval when no rule matches — is not built for macOS yet. Until it is, treat Live as Policy on Macs.
Events are reported in all three modes, so the portal's event and rule reporting populates from the moment a Mac starts reporting — including while it is still in Audit.
Creating a Mac Rule
Mac rules are created from a recorded elevation event, so the identification details are filled in for you from what the agent actually saw. Rules carry a platform: a Mac only ever receives Mac rules, and your existing Windows rule set is not applied to Macs.
Start from an elevation event
- In the Admin Portal, open Elevation Events. Mac events list the requesting application under Name — for example PowerPreferences or System Settings — and the Had Matching Rule? column shows No for anything that fell through to the macOS password prompt. Once a rule exists, later events show Yes (View Rule).
- Select the event you want to approve, click Actions, then Convert To Rule. The Add New Rule (converting from Event) form opens.
Event Info at the top of the form is read-only and records where the event came from: Company Name, Location Name, Computer Name, Platform (macOS), Requesting Application, Authorization Right and Time of Event.
Identification criteria
Under Requesting Application, tick the parts of the application that must match for the rule to apply:
- Signing Category — the kind of signer, for example Apple system software. Apple marks every binary it ships on macOS as its own, so this cleanly separates Apple's software from third-party applications.
-
Signing ID — the signed bundle identifier, for example
com.apple.Battery-Settings.extension. Because it does not change from one version to the next, a rule on Signing ID keeps working after the application updates. - File Path — the location of the executable on disk.
- CD Hash — the code-directory hash of the exact binary. Add it when you want the rule to match one specific build and nothing else.
Signing Category and Signing ID are selected by default; File Path and CD Hash are optional and narrow the rule further. A rule must identify the application — a rule built only from an authorization right is refused — and Convert To Rule refuses a selection that contains an unsigned Mac program, naming each one, because an unsigned binary offers nothing trustworthy to pin a rule to.
Under Authorization Right, the macOS right the application asked for is pre-filled — for example system.preferences for a System Settings change, or system.preferences.network for the Network pane. Authorization rights are the macOS permissions that applications request to perform privileged actions. Leave this checked so the rule covers only that right; the checkbox is labeled Uncheck to allow all rights, and clearing it lets the matched application elevate for any right it requests.
Approval status, level and scope
The General panel sets what the rule does and where it applies:
- Approval Status — Approved elevates the matched application. Denied and Ignored are also available.
- Elevation Type — fixed to Admin. The form notes that macOS rules support Admin elevation only.
- Level — All Companies, Whole Company, Whole Location or Computer. Choosing a narrower level adds a selector for the company, location or computer the rule belongs to.
- Friendly Name and Notes — optional, but a friendly name such as "Allow modifying energy preferences" is what your team will see on the Elevation Rules grid.
Click Save. The rule appears on the Elevation Rules grid with its level, scope and friendly name, and opening it shows the original event alongside the criteria and general settings you chose.
Check the rule on the Mac
Rules normally reach a Mac within a few minutes, on the agent's next sync. To pull them straight away — when you are testing a rule you have just written, or on the phone with a user — open the AutoElevate panel from the menu bar and click the refresh icon on the This Mac row. The rules are fully synced to the agent as soon as it finishes.
Then repeat the action the event came from. With the rule in place, the setting changes without a password prompt, and the user is still not an administrator.
An action the rule does not cover still prompts — and a rule is narrower than it may look. A different System Settings pane is usually a different extension with its own Signing ID, asking for a different authorization right: a rule covering Energy does not let the same user turn off the firewall, because that is the Network settings extension requesting system.preferences.network. Those attempts appear on Elevation Events as new Had Matching Rule? No rows, which you can convert the same way — or convert with an Approval Status of Denied if you would rather rule the application out explicitly.
For the concepts behind identification criteria, see Advanced Elevation Rules: File & Publisher Certificate Identification Criteria — written for Windows, but the reasoning about how tightly to scope a rule applies equally.
What Is Not Available Yet
- The stable channel. Application elevation ships only on the beta channel today.
- The Live request flow. A Mac user cannot request approval for an application that no rule matches; the request goes to the macOS password prompt instead. Elevated sessions remain the way a Mac user asks for help.
- Windows-only rule features. Criteria and actions documented in the Windows rules articles are not all present for macOS. Build and test Mac rules against Macs rather than assuming parity.
Troubleshooting
Rules are not being applied on a Mac
Work through the requirements in order: the computer must be on macOS agent 2.0.1720 from the beta update channel, the Mac must be running macOS 14.7 or higher, and the computer's elevation mode must be Policy or Live — a Mac in Audit reports matches without applying them, which looks identical to a rule that is not working. If all of that checks out, refresh the configuration from the menu-bar panel and try again.
Convert To Rule refuses the selection
The selection contains at least one unsigned Mac program, and the dialog names them. An unsigned binary cannot be identified reliably enough to elevate, so remove those entries and convert the rest.
An elevation I expected to match did not
Find the event on Elevation Events. If Had Matching Rule? says No, compare the event's Requesting Application and Authorization Right with the rule. Two things catch people out: different panes of System Settings are often separate extensions with their own Signing IDs, and the same application can ask for a different authorization right depending on what is being changed — a rule matches only what it was built for. If the rule was built with File Path or CD Hash, an application update may have changed them; a Signing ID rule survives updates. If the Mac is in Audit, the event report records which rule would have matched without applying it.
Security Notes
- A rule is a standing approval. Unlike an elevated session, which expires, a rule elevates its program every time it matches until you remove the rule. Scope rules to programs you are willing to have elevated unattended.
- Rules match on signing identity, not on a file name. Signing Category and Signing ID come from the binary's code signature, and CD Hash pins one exact build — which is also why unsigned programs are refused.
- Keep Authorization Right checked. Clearing Uncheck to allow all rights lets the application elevate for any right it asks for, not only the one you reviewed.
- Audit changes nothing on the endpoint. It is safe to leave Macs in Audit for as long as you need; users keep getting the standard macOS prompt while you collect evidence.
- A rule elevates the operation, not the user. The account is never added to the local administrators group and remains a standard user, so everything the rule does not match still prompts. This is the main security difference from an elevated session, which grants account-level administrator rights for its whole duration.
- Portal actions are governed by roles. Who can author rules and change a computer's elevation mode follows the same role permissions as the rest of the portal — see Web Admin Portal Overview.