The above should read "via an assassin shell script" - not sure why Apple replaced it with "*".

Thanks for the response. The word I was trying to write was a-s-s-a-s-s-i-n. I.e. a process whose job is to kill another process. I'm not interested in running a GUI as root per se. What I want to do is have a GUI that takes over the screen (or screens) and prevents access to the user's desktop unless they perform certain authentication steps. This doesn't need to be a root process, it simply needs to be unkillable by the logged in user. If there were some way to run setuid(X) where X is not the logged in user, that could work.

OK. And what triggers that situation? Could be a number of different events. Could be an unlock event (com.apple.screenIsUnlocked). For context, I usually see folks implement this sort of thing in terms of screen unlock, and you can do that using an authorisation plug-in. However, that’s not something you can reliably trigger on demand. We are specifically not interested in using an Auth Plugin because we want more flexibility than is offered by the Auth Plugin API (e.g. no biometrics, very prescribed UI). So the first nut we are trying to crack is this issue of "unkillability" by the logged in user. I'm hoping to get an idea if this is even possible. If macOS 15.* and onward simply do not allow a GUI to be launched by anyone other than the logged in user then I am probably out of luck. Thanks for your help!

I'm wondering if this could be accomplished in conjunction with an Endpoint Security agent. So my GUI would just run normally as the logged in user, but would be "protected" by an Endpoint Security agent that would trap "kill -9" calls. Could that work?

Thanks very much for the quick reply - it is very helpful!

To follow-up, am I correct in that the problem is that we are storing the raw representation in the system - and thus a file system-based - keychain? In another post, you directed someone to a post on storing CryptoKit keys. That post discusses storing the raw representation in the keychain, so I'm inferring that the problem with our approach is the choice of keychain. In digging through the code, I see that the raw representation is stored using kSecUseDataProtectionKeychain: true, Since we are storing in the system keychain, we obviously don't use the Data Protection Keychain. Thus, what I'm taking away from your response is that the fact that we are not using the DPK is the fundamental problem with our approach? And the fact that we don't use the DPK compromises the security of our approach? Or are there other problems as well? Thanks in advance for your help on this!