I’m designing a macOS privileged-service boundary and I’d like to clarify whether a process-occurrence authentication pattern previously described by Apple DTS is a supported shipping security contract, rather than just behaviour that happens to work on current macOS. Target: current macOS 26.x, using public APIs only. Threat model An arbitrary hostile process may run as the same ordinary, non-admin login user as the application. The attacker can launch an exact second copy of the legitimately signed requester binary. The attacker cannot obtain administrator / Touch ID authorization and does not control root, SIP, Recovery, the kernel, or the code-signing infrastructure. Desired property After a fresh Human-authorized operation, a root LaunchDaemon should grant authority to one specific requester process occurrence, not to every process having the same code-signing identity. Apple DTS thread 842442 describes a pattern based on: launching the requester suspended with posix_spawn(..., POSIX_SPAWN_START_SUSPENDED); obtaining a name/task port for that process; reading its TASK_AUDIT_TOKEN; resuming the process; and accepting only Mach messages whose kernel audit trailer identifies that same process occurrence. Thread 842442 also describes this area as being on “thin compatibility ice”, which is why I do not want to build a security boundary on behaviour that Apple does not intend applications to rely on. My core question is: Can a shipping macOS application rely on a pre-bound audit_token_t obtained from a suspended child and compare it against the audit token in subsequent raw Mach message trailers as a supported security boundary for that exact process occurrence? In particular, I need to know whether the supported contract covers: distinguishing another process with the exact same signed executable; PID reuse after the original process exits; messages queued before or around sender termination; a Mach send right transferred to another process — does the receiver see the audit token of the process that actually sends each message?; later exec by the original process; and whether full audit_token_t equality is an appropriate supported comparison for this purpose. If that is not a supported shipping contract, is there a current public XPC API that provides the equivalent property: binding one privileged-service session to one exact process occurrence rather than merely to its code-signing identity? I’m specifically trying to distinguish: code identity = this is an approved executable from mission authority = this one particular authorized process occurrence I’m happy with a negative answer if macOS does not expose a stable public contract for the latter. Related Apple DTS discussion: https://developer.apple.com/forums/thread/842442