Thank you Quinn for the insights! It's quite a coincidence indeed, I hadn't seen that other thread yet! I think I found that "ancient Q&A" while searching the Documentation Archive for "Authorization" information (or maybe on a comment you left in an older thread). Before filing a bug report, I'd like to clarify whether this is actually a bug or simply a missing feature. What puzzles me specifically is the behavior of Activity Monitor.app: Even when I use rights that are explicitly configured as non-shared (like authenticate-admin-nonshared), Activity Monitor still appears to inherit the credentials. I also tried to configure com.apple.activitymonitor.kill with a timeout of 0, but that didn't help. The only way I've found to prevent this behavior is when the original application explicitly calls AuthorizationFree() with the .destroyRights flag. However, newer versions of System Settings don't have the lock icon you mentioned, so they appear to not be destroying these rights (even if I close the window!). Either way, it strikes me as a weird decision to delegate the proper lifecycle management of an authorization reference exclusively to the application that acquires it. I was hoping there was something to be done at the Authorization Plug-In level to enforce more strict boundaries. What's particularly strange to me is that if I try to access different System Settings panels, I'm always prompted for credentials again. Yet Activity Monitor continues to have access to privileged operations without re-authentication. Is there something special about Activity Monitor's authorization implementation that causes this behavior? Is it possibly using a different authentication mechanism or accessing the cached credentials in a way that bypasses the standard authorization checks?

Thanks Quinn, I'll probably just do that! However, just to be sure, could you please confirm that authorization plug-ins are indeed a good approach to this kind of "advanced" privilege management in macOS?