Entitlements and sandboxing constraints for apps

Regular third-party apps generally do not need a special entitlement to use the background task management APIs, but there are important sandboxing rules and entitlements related to how background helpers run…

App sandbox considerations

If an app is sandboxed (e.g. an App Store app or one that has elected to use App Sandbox), any helper it registers via SMAppService must also run in a sandbox. Initially, Ventura allowed a sandboxed app to spawn a non-sandboxed login item (with broader system access)… d a loophole that could be abused. Apple closed this in macOS 14.2 by requiring that the helper carry an App Sandbox entitlement as well. In practice, this means the helper either uses the com.apple.security.inherit entitlement to inherit the container of the main app, or it has its own sandbox profile. Apple’s Developer Technical Support explicitly advised that if your main app is sandboxed, you must sandbox the helper too (or as a workaround, distribute the app unsandboxed). This change ensures background helpers don’t become a sneaky way to escape the sandbox; previously, a sandboxed app could install a LaunchAgent that had no sandbox, running with user privileges but outside the container; after 14.2, that’s no longer allowed.

Installing helpers (SMPrivilegedExecutables)

For privileged LaunchDaemons (running as root, typically in /Library/PrivilegedHelperTools installed via SMJobBless), the app needs the com.apple.sm.agent entitlement and associated code signing certificates. Those privileged helpers are also tracked by backgroundtaskmanagementd. For example, the Zoom daemon is a privileged helper (root-run); it was registered as a “legacy daemon” in BTM. Apps using SMJobBless declare the helper in their Info.plist and have a signing entitlement, but that is part of ServiceManagement rather than BTM specifically. BTM will manage such items once installed, regardless of entitlement, but only trusted (signed with the right entitlement) apps can install a root helper in the first place.

Endpoint Security entitlement

As mentioned, backgroundtaskmanagementd itself holds the private entitlement com.apple.private.endpoint-security.submit.btm. This allows it to generate those ES events. No third-party app can have this entitlement (Apple doesn’t distribute private entitlements to others), so only the system’s BTM can issue BTM-specific security events. Security software can listen for them with the appropriate client entitlement (to use ES at all, a third-party needs the com.apple.developer.endpoint-security.client entitlement and to be approved by the user). Apple also runs a user-space BackgroundTaskManagementAgent (the per-user agent) which interestingly does not have a special ES entitlement, meaning the agent itself doesn’t produce ES events. It’s purely for UI; the daemon is the one talking to ES.

XPC and communication entitlements

The BTM framework uses XPC services internally. These XPC connections are protected by requirement rules (likely requiring that the connecting client be code-signed by Apple or have certain entitlements). For instance, System Settings (which is Apple-signed) can communicate with backgroundtaskmanagementd to retrieve the list of items. Third-party apps cannot directly query BTM for the list of all login items (that would be a privacy concern). They can only manage their own by using the APIs Apple provides (which inherently operate within that app’s sandbox limitations).

Temporary exceptions

If a sandboxed helper needs to do something like modify system settings (as in the developer forum example where a helper calls pmset to change power settings), the helper may require temporary exception entitlements to write to certain preference files. These are standard sandbox exceptions (com.apple.security.temporary-exception.*) that developers can request. backgroundtaskmanagementd doesn’t grant these; they must be in the helper’s code signature. The example case showed that a helper needed an exception to write to /Library/Preferences/com.apple.PowerManagement.<UUID>.plist when sandboxed. This underscores that when adopting the new BTM API in a sandbox, developers must consider the sandbox restrictions on their background task and request appropriate entitlements for any system access it needs. Otherwise, the sandbox will block the helper’s functionality (unrelated to BTM, but a general constraint).

ServiceManagement/MDS entitlements

For MDM-managed devices, an MDM profile can auto-approve certain background items via rules matching team ID, bundle ID, or launchd labels. The profile itself must be installed by a device with the Device Management entitlement (i.e., the Mac must be supervised/enrolled). Standard apps cannot create such rules on the fly; it’s purely an admin capability. backgroundtaskmanagementd enforces these rules: if an item matches an MDM rule, it will mark it as “managed” (as seen in logs: type=managed legacy agent in the disposition). Managed items get special treatment: the UI will indicate “managed by your organization” and the toggle is disabled. Under the hood, BTM likely sets a flag in the DB entry indicating management, and the BackgroundTaskManagementAgent posts a different style of notification (one that groups them).

In summary, apps do not need a dedicated “background tasks” entitlement to add login items, but they must adhere to code signing rules: if sandboxed, sandbox your helper; if installing a root daemon, use SMJobBless with the proper entitlements; if wanting to adjust system settings from a helper, include the necessary exceptions. From the daemon’s perspective, backgroundtaskmanagementd uses entitlements exclusively available to Apple to do its job (ES event submission, etc.), and it will not honor requests from processes lacking permission. For example, if a malicious app tried to directly manipulate BTM’s XPC without going through proper channels, it would fail the code signature check. The system is designed such that only trusted pathways (like the user toggling in System Settings or an Apple API call) can tell BTM to change something.