Endpoint Security: preventing exec after the ES client disconnects or exits

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:

1. An AUTH_EXEC request already pending when the guarding client crashes, disconnects or is destroyed with es_delete_client?
2. 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.

Are you working on the same product as this person and this person?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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?

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 just posted about this here, but es_new_descendants_client was specifically designed with AI constraining in mind.

Notably, on this point:

The proposed policy would authorize the initial exec, then deny subsequent ES_EVENT_TYPE_AUTH_EXEC requests for that worker while collection is active.

...es_new_descendants_client doesn't have any of the deadline requirements a standard ES client has, so you can happily take as long as you want individually auth'ing every single request.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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:

1. What happens to an AUTH_EXEC request already blocked awaiting a response: is it denied, allowed, or left blocked?
2. 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.

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?

When the client goes away, all the restrictions it applied are removed. The team is definitely interested in providing more “persistent" options, but nothing like that exists today.

1. What happens to an AUTH_EXEC request already blocked awaiting a response: is it denied, allowed, or left blocked?

Strictly speaking, there's a bit of a race condition here between the kernel deciding the client is dead vs. missing its deadline. In the second case, whatever es_deadline_miss_mode_t you'd set up would apply. However, I don't think that's actually all that useful, since all future requests would be allowed.

1. What governs later exec attempts by that still-running worker after the client is gone? Does any kernel-enforced restriction remain?

No. Again, this is an area the team is interested in improving, but right now things basically "fail open".

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?

So, I think part of this boils down to how "serious" you want this to be. On the simpler side of things, there are a variety of what you could set things up such that the descendants exit if the guard dies. Depending on the level of risk/concern, that can go all the way up to a system-wide es_client who's primary function is to monitor/protect the descendant clients.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware