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.