We're seeing this same behavior in our enterprise environment and have been able to isolate it to a specific mechanism in SecurityAgent's launch sequence.
Environment:
- macOS Tahoe 26.3
- MDM-managed Macs (Jamf Pro)
- Non-admin user accounts
- Admin By Request 5.2.0 (authorization plugin: AbrAuth)
What we found:
We built a lightweight detection tool using NSWorkspace activation notifications and a CGEvent tap to catch the moment focus shifts, then captured unified logs (±5 seconds around each event) filtered to the authorization subsystem, process lifecycle, and WindowServer.
The logs show a consistent chain:
- A LaunchDaemon (mdmclient, JamfDaemon, or AssetSonar in our case) requests
system.privilege.admin authd evaluates the right and walks the authorization plugin chain- SecurityAgent spawns to host the plugin evaluation (AbrAuth:invoke)
- SecurityAgent registers with WindowServer
(SLSSetFrontProcessWithInfo with window=0) - Focus transfers to SecurityAgent — despite no window being displayed
- The authorization succeeds, SecurityAgent exits, but the focus damage is done
Key detail: We also reproduced this with a minimal LaunchDaemon running as root (UID 0). The daemon requests system.privilege.admin with only kAuthorizationFlagExtendRights (flags 0x00000002) — no kAuthorizationFlagInteractionAllowed. authd grants the right immediately (SUCCESS, since the caller is root), but SecurityAgent still spawns, still registers with WindowServer, and still calls SLSSetFrontProcessWithInfo(window=0), stealing focus.
The unified logs also show SecurityAgent emitting an analytics event — com.apple.appkit.application.stoleKeyFocus — which it then drops as unused. Apple appears to have telemetry for this exact class of event.
Our question:
Is SecurityAgent expected to spawn and register with WindowServer for non-interactive authorization evaluations from root LaunchDaemons? The right is granted immediately, no UI is needed, yet SecurityAgent's AppKit initialization calls SetFrontProcess unconditionally. This seems like SecurityAgent should either (a) not spawn when no UI is required, or (b) not call SetFrontProcess when it has no window to present.
Workarounds we've confirmed:
- Admin By Request shipped a fix in v5.1.2 that avoids triggering the chain from their side
- An active ABR admin session prevents the steals (AbrAuth handles the authorization differently)
- The issue does not occur on non-MDM Macs where the user is a local admin (authd resolves the right directly without spawning SecurityAgent)
