Introduction
If your Macs are already enrolled in Microsoft Intune, you can push the Level agent to them without touching each machine. This guide walks through the three pieces of a working deployment:
The PKG app that installs and registers the agent.
A PPPC profile that grants the privacy permissions Level needs on macOS.
A Level automation that creates the macOS service account for patch management on Apple Silicon.
ℹ️ NOTE: The service account step matters only on Apple Silicon Macs, and only for patch management. Intel Macs and remote-control-only deployments can skip it. See macOS Service Account for the full picture.
⚙️ PREREQUISITES
Macs enrolled in Microsoft Intune, with access to the Microsoft Intune admin center
A Level account with permission to add devices
The Level install key for the group you want devices to land in (get it from Add new device → macOS in Level)
For the service account step: an existing admin account on each Mac that holds a SecureToken (this is the single most common thing that breaks zero-touch service account creation, more on this below)
Install Level on macOS via Intune
Step 1: Download the macOS installer from Level
In Level, open the Device Listing and click Add new device.
Select macOS from the operating system dropdown.
Open the Installer tab.
In the architecture dropdown, select ARM64 for Apple Silicon or x64 for Intel.
Optionally select a device group so the install key includes the group ID.
Click Download installer to save the PKG.
🖥️ PLATFORM NOTE:
Apple Silicon (M1/M2/M3): Download the ARM64 package. This is the one that needs the service account in Step 4.
Intel: Download the x64 package. The PKG is architecture-specific, so a package built for one architecture won't install on the other.
⚠️ WARNING: Because each PKG is architecture-specific, an ARM64 package won't run on Intel Macs and vice versa. If you manage both, create a separate Intune app per architecture and scope each assignment to the matching devices.
Step 2: Create the PKG app in Intune
In the Intune admin center, go to Apps → macOS → Add.
For App type, select macOS app (PKG), then click Select.
Click Select app package file, browse to the PKG you downloaded, and click OK.
On the App information page, set the Publisher (for example,
Level) and choose a Category such as Computer management. Click Next.
Add the post-install script
Intune runs the PKG with a plain installer -pkg, which installs the agent but does not register it with your Level account. The post-install script is where registration happens, using your install key.
Paste your registration command into the post-install script field, then click Next.
⚠️ WARNING: The install key links new devices to your Level account and (if you selected a group) the target group. Treat the script as sensitive and limit who can read the Intune app configuration.
Set requirements and detection rules
On the Requirements page, set the minimum operating system to match the oldest macOS you actually support. Level supports macOS 11 (Big Sur) and later. Click Next.
On the Detection rules page, enter the Level agent's bundle ID and version so Intune can tell whether the app is already installed:
App bundle ID:
io.level.agentApp version: the version of the agent in the PKG you downloaded
Click Next, review, and click Create.
💡 TIP: You can read the installed version on any Mac that already has the agent with defaults read /Applications/Level.app/Contents/Info CFBundleShortVersionString. Match Intune's detection version to the version in the package you're deploying.
Step 3: Deploy the PPPC profile for privacy permissions
macOS blocks Level from screen recording, controlling the machine, and reading files until it's granted the matching privacy permissions. A PPPC (Privacy Preferences Policy Control) profile pushed through Intune handles most of this without anyone touching the Mac.
Level publishes an official sample profile. Start there: Download Level - PPPC.mobileconfig
The profile targets the Level agent by bundle ID (io.level.agent) and Team ID (BNB82BTKXQ), and it does two things:
Grants Full Disk Access and Accessibility silently via MDM policy.
Allows a standard (non-admin) user to approve Screen Recording without needing admin credentials.
⚠️ WARNING: Apple does not allow MDM to grant Screen Recording or System Audio Recording silently. The profile only removes the admin requirement. A person still has to approve Screen Recording (and System Audio, if you use audio during remote control) on each Mac the first time. Budget for that in your onboarding steps.
To deploy it through Intune:
Go to Devices → macOS → Configuration → Create → New policy.
Set Profile type to Templates, choose Custom, and click Create.
Give the profile a Name, then click Next.
On the configuration page, set a Custom configuration profile name and upload the
.mobileconfigfile. Click Next.Pick your Assignments, click Next, then Create.
Step 4: Create the macOS service account (Apple Silicon only)
On Apple Silicon Macs, Level uses a dedicated service account to unlock FileVault and install updates without an interactive login. It's normally created during a manual install, but a silent Intune install skips that prompt, so you create it afterward.
The customer who built this workflow does it with a Level automation: a group-linked automation that runs a short script on each new Mac in the target group, pulling the authorizing admin credentials from custom fields.
Set up the custom fields
Create two custom fields (workspace, group, or device scope, depending on how your admin credentials vary) and populate them per your environment:
cf_admin— the username of an existing admin on the devicecf_admin_password— that admin's password
⚠️ WARNING: cf_admin and cf_admin_password are the credentials of an existing admin that authorizes creating the service account. They are not the service account's own credentials, and that authorizing admin must hold a SecureToken. If it doesn't, creation fails with "The provided admin credentials are valid, but the account lacks a secure token," even though the credentials are correct. See the SecureToken section of macOS Service Account for how to grant one or use an MDM bootstrap token.
The script
Add a Run Script action to the automation and paste this.
#!/bin/bash
/usr/local/bin/level --create-service-account --admin-name={{cf_admin}} --admin-password={{cf_admin_password}}
echo "Service account exit: $?"
echo "$(date '+%Y-%m-%d %H:%M:%S') done"
💡 TIP: Guard the script so it's a clean no-op on Intel Macs and machines where the binary isn't present yet:
#!/bin/bash
if [ ! -x /usr/local/bin/level ]; then echo "Level not installed yet"; exit 0; fi
if [ "$(uname -m)" != "arm64" ]; then echo "Intel Mac, service account not needed"; exit 0; fi
/usr/local/bin/level --create-service-account --admin-name={{cf_admin}} --admin-password={{cf_admin_password}}
echo "Service account exit: $?"
echo "$(date '+%Y-%m-%d %H:%M:%S') done"
Trigger it on new devices
Scope the automation to the group your Intune-installed Macs land in, and use a trigger that runs it once per device as it joins. That way every new Mac gets its service account created shortly after enrollment, without manual steps.
ℹ️ NOTE: --create-service-account is a no-op on Intel Macs. The account is only needed where Level has to unlock FileVault at boot, which is the Apple Silicon patch-management case.
Step 5: Confirm the deployment
Sync a test Mac (System Settings → General → Device Management, or wait for the next check-in).
Confirm the agent installed and the device appears in your Level Device Listing within a few minutes.
Check that the PPPC profile applied: Full Disk Access and Accessibility should show as granted for Level.
Have someone approve Screen Recording on the Mac (Apple requires this by hand).
On Apple Silicon, confirm the service account exists. You can check from the automation run history, or run
sudo /usr/local/bin/level --check-service-accounton the device.
ℹ️ NOTE: If a Mac installs but never shows up in Level, the post-install registration is the usual culprit, followed by an AV/EDR tool blocking the agent. See Offline Troubleshooting and AV/EDR False Detections.
FAQ
The PKG installed but the Mac never showed up in Level. What went wrong? Almost always the post-install registration. Intune's
installer -pkginstalls the app but doesn't register it, so if the post-install script is missing, wrong, or has a stale install key, the agent installs but never checks in. Confirm the script ran and the key is current. If registration looks fine, check whether an AV/EDR tool quarantined the agent.Do I need the service account at all? Only on Apple Silicon, and only for patch management. Remote control, monitoring, and scripts all work without it. If you're not using Level to install macOS updates, you can skip Step 4 entirely.
My service account script fails even though the admin username and password are correct. Why? The authorizing admin almost certainly lacks a SecureToken. macOS won't let a non-SecureToken admin grant one to another account, and the service account needs a token to unlock FileVault. Use an admin that has a SecureToken, or grant one via an MDM bootstrap token. The macOS Service Account article covers the fix.
Can I deploy to Intel and Apple Silicon at once? Not with a single app. The PKG is architecture-specific, so create one Intune app for the ARM64 package and one for x64, and assign each to the matching devices. Detection rules can use the same bundle ID (
io.level.agent); just match the version to each package.Why does a tech still have to click something for Screen Recording if the profile handles permissions? Apple doesn't allow MDM to grant Screen Recording or System Audio Recording silently. The profile removes the admin requirement so a standard user can approve it, but the approval itself is still manual. Full Disk Access and Accessibility do apply silently.
Where do I set which group the Macs land in? Select the group when you copy the install key in Level (Add new device → macOS). The group ID rides along in the key that your post-install script uses. To land devices in different groups, use a separate key per group.
Who can see the admin password I stored in a custom field? Anyone with permission to view that custom field's scope, and it may surface in automation run output. Scope it narrowly, restrict access, and prefer a managed local admin with a bootstrap token over a shared password where you can.