Thanks Kevin. The lack of authorization deadlines makes the descendants client a useful direction to explore. Could you clarify its behavior specifically when the client is lost? For a worker covered by es_new_descendants_client, if the client process crashes, disconnects, or calls es_delete_client: What happens to an AUTH_EXEC request already blocked awaiting a response: is it denied, allowed, or left blocked? What governs later exec attempts by that still-running worker after the client is gone? Does any kernel-enforced restriction remain? The case I need to cover is a separate evidence collector with a read or associated copy/storage operation already in flight when the guarding client disappears. Is there a supported way to keep exec replacement prevented until that operation finishes, including if it fails, while still allowing shutdown within a finite bound? If the descendants client does not provide that guarantee, confirmation would help me redesign the collection boundary. A reference to the applicable public contract and supported OS/SDK versions would be appreciated. This remains a proposed design; I have not run a guard-loss experiment.

No, I’m not associated with either poster. I’m working independently with AI assistance on a local assistant that performs authorized project tasks and verifies their saved outputs. The supervised worker and separate evidence collector are still a proposed design. The underlying goal is trustworthy verification of an approved worker’s output. I’m open to changing the architecture if the execution-blocking requirement is unsupported. What supported approach would Apple recommend for that goal?

I have narrowed the question using the current Endpoint Security documentation. es_set_deadline_miss_mode with ES_DEADLINE_MISS_MODE_FAIL_CLOSED documents denial for missed AUTH deadlines and for AUTH messages dropped because the queue was full. Does this policy have any documented effect when the client is destroyed or disconnects, rather than remaining alive and missing its deadline? Specifically, what happens to: An AUTH_EXEC request already pending when the guarding client crashes, disconnects or is destroyed with es_delete_client? A later exec attempt after that client is gone, while the separate collector still has an in-flight read or associated copy/storage operation? I also reviewed es_new_descendants_client and es_sync_client. The sync documentation says its callbacks also run on client destruction, so I am not treating a callback alone as proof of a live guard or a successful initial exec. Is there a supported public mechanism that establishes the initial successful executable image before the first collector read, excludes subsequent exec replacement until all collector effects finish (including failed operations), survives the relevant client/owner-loss cases, and permits finite shutdown? The current documentation metadata lists macOS 27.0 for these newer functions; I have not validated a deployment or SDK combination. A public contract with the supported versions, entitlements and release conditions—or confirmation that Endpoint Security cannot provide this guarantee—would help determine the design. This remains an API-contract question, not a reproduced operating-system bug.