I am evaluating a hypothetical file collector that uses fixed approved directory roots. Its requirement includes rename-after-open: if another process moves an opened file or an ancestor outside the approved namespace, the collector must not continue accessing it there. This concerns input reads, directory enumeration, preview reacquisition, and writes to exclusively created output files. Retaining a previously approved descriptor or detecting a move after access does not meet the requirement.
I am considering whether Endpoint Security can prevent the relevant namespace mutations before they occur for the complete access interval. No Endpoint Security client has been created or exercised for this candidate. This is a request for a documented, versioned contract, not permission to deploy a client, obtain an entitlement, or change the system.
The deadline-mode documentation describes the response to an unanswered authorization within its deadline. The mode values describe deny without killing the client, allow without killing the client, and killing the client as the default. The setter documentation also describes denial of a queue-full AUTH drop under FAIL_CLOSED. I have not found, in the specific pages listed below, an explicit contract for the separate case of client loss. I am not assuming that deadline policy covers disappearance of a client.
Could you clarify the following?
Pending authorization at client loss
For a relevant authorization such as ES_EVENT_TYPE_AUTH_RENAME or ES_EVENT_TYPE_AUTH_UNLINK that is already pending, what exact verdict applies if the matching client crashes, disconnects, is deleted with es_delete_client, or unsubscribes before responding? Please distinguish each case, including when it was the last matching client and when other matching clients remain. Does a configured FAIL_CLOSED deadline policy remain attached to that pending request after client loss?
Operations after the last matching client is gone
What controls a later rename, reparenting, exchange, unlink, or other relevant namespace mutation after the last matching client has disappeared or unsubscribed? Is there a supported policy that remains effective independently of that client's lifetime? Please distinguish new operations from an authorization that was already pending, including cached decisions and any interval before a replacement client is ready.
A supported complete protection interval
Is there a supported way, through Endpoint Security or another supported kernel-enforced mechanism, to keep the necessary namespace mutations denied from before the collector's first access until its final read/write ends, despite authorization-client loss, partial setup, or owner death? The mutating actor may be outside the collector's process subtree. A later watchdog termination, restart, or notification of a completed operation would not establish denial during the intervening interval. If protection must end before that interval is complete, please identify the exact limitation.
Client types and failure cases
Which guarantees differ between es_new_client and es_new_descendants_client? Beyond the unanswered-deadline and full-queue cases, does any deadline mode affect the cases in questions 1 and 2? Please identify any self-process, muting, caching, scope, or actor limitations that prevent the proposed all-relevant-mutator coverage. I am not assuming a descendant-scoped client can authorize operations by unrelated processes.
Versioned support and prerequisites
For any supported contract, please cite the public documentation or other authoritative reference, applicable released macOS versions, exact API and deployment configuration, and required entitlements, privilege, consent, or system-extension conditions. API introduction metadata alone is not being treated as evidence about an installed target, and an upgrade or privilege change is not assumed. If no public supported mechanism provides the requested interval, an explicit statement of the missing guarantee or required independent enforcement boundary would be useful.
Public references reviewed
https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::)
https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_t
https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed
https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_open
https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_kill
https://developer.apple.com/documentation/endpointsecurity/client
https://developer.apple.com/documentation/endpointsecurity/es_client_t
https://developer.apple.com/documentation/endpointsecurity/es_new_client(::)
https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::)
https://developer.apple.com/documentation/endpointsecurity/es_delete_client(:)
https://developer.apple.com/documentation/endpointsecurity/es_unsubscribe_all(:)
The scoped document reviews did not establish the two client-loss cases above; this is not a claim that every relevant Apple document or mechanism has been exhausted. No real data, credentials, private artifacts, logs, or host identifiers are needed for this clarification.