Thanks Kevin. I’ve filed the enhancement request for a dedicated/self-service entitlement for es_new_descendants_client as you suggested. Feedback ID: FB24830531 I’ll treat the descendants client as descendant-action control while the client is alive, rather than as persistent custody of an IPC capability or a fail-closed authority boundary after client loss. I’ll keep the broader privileged-service / delegated-capability problem separate rather than trying to stretch this API beyond its intended boundary. Thanks again — this clarified the architecture considerably.

Thanks Kevin, your guidance materially changed the direction I’m looking at. I’ve now done a bounded pass over the public es_new_descendants_client semantics and I think the descendant-scoped model is the right supported foundation to explore. Before I prototype it, there are four details I’d like to clarify because they determine whether this can become a real authority boundary rather than just subtree policy: If a descendants client has a pending AUTH event and the ES client crashes, disconnects, or calls es_delete_client, what exact disposition applies to that blocked operation? Does FAIL_CLOSED cover client loss, or only deadline expiry / queue overflow? What exact operations generate AUTH_XPC_CONNECT? Is it limited to named Mach-service connections, or can it also cover connections established through transferred / anonymous XPC endpoints? From the XPC service side, is there a supported way to obtain sender identity or audit-token evidence per connection or per message, so the service could reject a transferred endpoint/connection originating from outside the approved descendant subtree? On distribution: is the descendants-client entitlement still expected to become self-service, and is a normal Developer ID app/helper using the currently managed Endpoint Security entitlement considered an intended production packaging model today? I’m deliberately treating delegation outside the descendant subtree as a separate problem set, as you suggested, rather than trying to stretch the descendants API into solving everything. If these points line up, my next step would be a very narrow PoC: one Human-authorized operation, one descendant worker, and one harmless XPC connection gated through the descendants client with explicit Allow/Deny. Thanks again, this has been extremely helpful in narrowing the problem to a supported path.

Thanks Kevin, this is extremely helpful and materially changes the direction I was considering. It sounds like the descendants client is much closer to the supported boundary I actually need than the suspended-spawn / raw Mach approach, especially given the lack of the standard ES deadline constraint. I’ll treat delegation outside the descendant subtree as a separate threat/problem rather than trying to stretch this API into solving it. My next step will be to prototype the narrower model: one Human-authorized operation, one descendant execution subtree, and descendant-scoped authorization of the sensitive actions that subtree can perform. I’ll also verify the macOS 27 deployment and entitlement requirements before treating this as a shippable architecture. Thanks again, this gives me a much clearer supported direction.

Thanks Quinn. I hadn’t evaluated es_new_descendants_client as the primary architecture yet, mainly because the original target was macOS 26.x and I had been looking at the older Endpoint Security / process-identity mechanisms rather than treating the new descendants client as the authority boundary. Having now looked at it more closely, it does seem much closer to the actual requirement. I can structure the product so that, after the Human authorizes an operation, Anvil launches a dedicated per-operation worker as a descendant of a process that owns a descendants-scoped ES client. I do not need arbitrary independently launched processes to acquire this authority. If the intended pattern is that the descendants client can authorize only that subtree’s access to a privileged service, for example by governing BOOTSTRAP_LOOK_UP / XPC_CONNECT, that may let me avoid raw Mach messaging and the suspended-spawn/audit-token composition entirely, which would be preferable. Before I pursue that architecture, I have four points I’d like to clarify: Is that essentially the use case you had in mind when pointing me to es_new_descendants_client? Can it be used to ensure that only a selected descendant subtree may obtain/connect to a particular privileged XPC/Mach service, while another same-UID process running identical signed code outside that subtree cannot? After an allowed descendant obtains the endpoint/send right, is delegation of that endpoint/right to a non-descendant something this mechanism prevents or detects, or would I still need another boundary for that? Finally, would the Endpoint Security client entitlement be considered appropriate for a broadly shipped developer tool whose use of ES is specifically to enforce this per-operation authority boundary, rather than for a traditional endpoint-security product? The macOS 27 minimum-version issue is something I can evaluate separately. If this is the supported architectural direction going forward, I would much rather design around it than ship the kernel-coupled Mach/audit-token approach.

Thanks Quinn. The product is a local macOS application that coordinates AI-assisted software-development work. Some operations may ultimately cause privileged or otherwise security-sensitive effects, so we need to preserve a very specific authority boundary between a Human-approved operation and the process that is allowed to exercise that authority. The high-level requirement is: A user explicitly authorizes one operation. After that authorization, we want a privileged service to accept security-sensitive requests only from the exact requester process occurrence that was created for that operation. Another process running as the same login user must not be able to inherit or replay that authority merely by launching the same signed executable or by obtaining access to a reusable IPC endpoint. We are not trying to protect against root, kernel compromise, SIP bypass, or an attacker who can obtain a new administrator / Touch ID authorization. The attacker we care about is another arbitrary process running as the same ordinary user. The reason I was exploring the suspended-spawn / audit-token / Mach-message approach was to bind the Human authorization to that one process occurrence rather than to code identity alone. If macOS does not expose a supported public way to make that distinction, that is useful information too. In that case I would rather redesign the product boundary than build a shipping security property on unsupported behaviour. So the architectural question is really: what is the supported macOS pattern, if any, for granting a freshly authorized capability to one exact requester occurrence while excluding another same-UID process running identical signed code?

Yes, it’s the same product and the same underlying security requirement. I opened this new thread because the earlier answer established that suspended posix_spawn + TASK_AUDIT_TOKEN + Mach audit trailers is technically possible, but also described that approach as being on “very thin compatibility ice”. For a security boundary in a product intended to ship to users, I don’t think I can treat that as a sufficiently stable platform contract. What I’m trying to determine now is whether macOS offers a supported public architecture for granting authority to one exact requester process occurrence, even when another same-UID process can launch an identical signed copy. If the audit-token composition is not suitable as a supported shipping boundary, is there another public mechanism or architecture Apple recommends for this threat model? If macOS simply does not provide that guarantee today, confirmation of that would also be extremely useful. es_new_descendants_client is interesting, but my requirement is not primarily descendant tracking; it is authenticating the exact requester occurrence that was freshly authorized.