Skip to main content
Other MDMs cover — same profile, same package, any vendor. AgenShield does not require a specific MDM. If yours can push a custom macOS configuration profile on the device channel and install a signed package, it can deploy AgenShield with no user interaction. Get both artifacts from your install campaign first.

​
The generic recipe

Whatever your MDM console calls them, you are creating two objects:
1

A custom configuration profile

Upload agenshield.mobileconfig unmodified. It must be delivered on the device (system) channel, not the user channel. Many MDMs re-sign uploaded profiles — that is fine.
2

A package deployment

Upload the campaign’s .pkg and set it to install once on the same set of devices.
3

Assign both to the same group

Push order does not matter.
Upload the profile as-is rather than rebuilding it in your MDM’s native payload editors — it already pairs every payload with the correct extension identifiers, including the Full Disk Access grant. That grant is the one that matters: a device without it enrolls and looks healthy but cannot enforce file policy.

​
Kandji

Kandji also has native System Extension and PPPC library items. If you prefer to mirror the payloads there, use the campaign’s split profiles as the reference — and push either the native items or the uploaded profile, never both.

​
JumpCloud

Devices must be enrolled in JumpCloud MDM (not only the agent) for the approval payloads to apply. JumpCloud re-signs profiles.

​
Mosyle

​
Anything else

Ask your MDM two questions:
  1. Can it push an unmodified custom .mobileconfig on the device channel? If yes, AgenShield’s approvals will be silent.
  2. Can it install a signed, notarized .pkg? If yes, the install is silent too.
If the answer to the second is no, but it can run a root shell script, use the campaign’s install command instead — it is a one-line script that downloads and installs the signed package. You still push the profile for silent approvals.
Apple restricts the extension-approval and Full Disk Access payloads to MDM delivery. Any path that does not involve your MDM pushing a profile will prompt the user for those approvals — see the Quickstart for what that looks like.

​
Verify

The device appears under Devices in the Frontegg Portal within a minute of the package installing. If it does not, work through the MDM troubleshooting table.

​
Next

MDM enrollment reference

What each profile payload does and which prompt it removes.

Enrolled devices

Reading fleet health once devices land.