I'm evaluating Endpoint Security for a supervised macOS worker and a separate evidence collector. This is a question about supported API guarantees; I don't have a reproduced macOS bug. Before collection starts, I need to identify the worker's successful initial executable image. That image must remain current until every collector read and its resulting copy or storage operation has finished, including operations that ultimately report failure. Here, "remain current" means preventing replacement by a later successful exec, not preventing ordinary memory changes within the running program. The proposed policy would authorize the initial exec, then deny subsequent ES_EVENT_TYPE_AUTH_EXEC requests for that worker while collection is active. This is a design under consideration, not an implemented or tested guard. The unresolved case is loss of the ES client while a collector operation is already in flight. If the client crashes, is deleted, or disconnects: What happens to an exec authorization request already pending at that point? What governs later exec attempts after the client is gone? Can a supported mechanism keep exec replacement blocked until the collector's in-flight operations finish, while allowing shutdown within a finite bound? A later health check would not cover an interval in which replacement was already allowed. I reviewed Apple's WWDC20 Endpoint Security session, but haven't established a documented client-loss guarantee for this requirement. I'm asking about client loss separately from an authorization-response deadline expiring. Please point me to the applicable public API contract, including macOS/SDK availability and entitlement requirements. If Endpoint Security cannot provide this guarantee, that limitation would help me reconsider the design. Any supported ordering requirement for establishing the initial successful exec before the first collector read would also be useful.