I’m designing a least-privilege system LaunchDaemon registered with SMAppService, and I’d like to clarify whether the following architecture is supported by public macOS contracts. The LaunchDaemon declares a MachServices entry. Its steady-state service must run as a dedicated non-root account and later creates an NSXPCListener for that Mach service. We currently launch the daemon directly using UserName, GroupName, and InitGroups=false. However, InitGroups=false does not appear to guarantee that the resulting process supplementary-group list is limited to the service’s intended group. In testing, the daemon received a supplementary group outside our accepted set. We therefore do not want to depend on incidental inherited launch-time group state. We are considering this alternative: launchd starts a small, fixed, code-signed bootstrap executable as root. The bootstrap reads the target UID/GID from an existing protected root-owned binding record. It establishes an exact credential state using public BSD APIs, conceptually: setgroups(...) setgid(...) setuid(...) It verifies the resulting non-root credentials. It creates no XPC listener or storage connection while privileged. Without forking, it permanently replaces itself using execve() (or possibly POSIX_SPAWN_SETEXEC) with another fixed, separately signed executable in the same bundle. That non-root executable independently validates its security state and then creates NSXPCListener(machServiceName:) for the Mach service declared by the original LaunchDaemon job. The bootstrap would not remain as a privileged parent or supervisor. My main questions are: Is a same-PID exec after permanent UID/GID/supplementary-group reduction supported for an SMAppService system LaunchDaemon before it checks in to its declared Mach service? Does the exec-replaced process retain the launchd/bootstrap context required for NSXPCListener(machServiceName:) to check in to that Mach service? If so, what execution context must be preserved across exec (for example bootstrap context, environment, file descriptors, or Mach rights)? Is there a documented way to preserve only the context required for the LaunchDaemon/Mach-service relationship without carrying unintended root-derived capabilities into the non-root executable? Would SMAppService.unregister() / normal launchd termination continue to treat the exec-replaced process as the same LaunchDaemon job? If this topology is not supported, is there an Apple-supported way to establish an exact supplementary-group set before a non-root SMAppService LaunchDaemon begins handling its Mach service? The goal is to avoid relying on undocumented launchd behavior, incidental supplementary groups, private APIs, or a long-lived privileged helper. I’m specifically looking for the supported contract here rather than whether this happens to work on a particular macOS release.