Thank you, Quinn. You're right — “assigned domain” was my own imprecise terminology, not a macOS API concept. Apologies for the ambiguity. By it, I mean the complete execution scope originating from an untrusted worker: the worker process itself, any child or descendant processes it starts, and any additional execution it can cause to run on its behalf through supported delegation mechanisms. I am not assuming macOS provides an existing process-grouping or security-domain abstraction covering all of these. The requirement is to establish one of two guarantees: Prevent the worker from creating or delegating additional execution in the first place, leaving only the original sandboxed worker and its narrowly authorised communication channel; or Provide a supported, OS-enforced way for an independent supervisor to identify, terminate and positively verify the end of all worker-originated execution before a replacement worker is allowed to run. The critical failure case is loss of the worker's controller. A mechanism requiring that controller or an Endpoint Security client to remain operational would not independently satisfy the requirement. I'm asking whether macOS exposes a supported mechanism for either guarantee, rather than proposing that such an execution domain already exists. If neither is available, confirmation of that limitation would be equally helpful. Thank you again for your guidance.

Thank you, Quinn. I've reviewed the descendant-scoped Endpoint Security mechanism and the related DTS discussion: https://developer.apple.com/forums/thread/852760 That discussion confirms that Endpoint Security cannot preserve required authorisation denials throughout client loss and recovery using its APIs, including for descendant-scoped clients. My remaining question is therefore specifically about supported containment independent of the enforcement client's continued operation. Does macOS provide a public, supported mechanism that either: Restricts a sandboxed worker from creating or delegating execution outside its assigned domain, with those restrictions surviving controller failure; or Allows a surviving supervisor to positively establish termination of the complete predecessor execution domain, including descendants and delegated execution, before starting a replacement? If neither guarantee is currently available through supported APIs, confirmation of that limitation would also be helpful. I'm keeping network transmission and transport fencing as separate requirements. Thank you for your guidance.

Hi Quinn, Thank you for clarifying the difference between Virtualization.framework and Hypervisor.framework, and for confirming that another userspace process cannot retain or acquire the original vCPU execution resources after their owner terminates. I understand that QEMU-specific thread and process management is our responsibility, and we're examining that separately. I have one remaining question about Hypervisor.framework itself, independent of QEMU's implementation: When the process owning a Hypervisor.framework VM has actually terminated, and its supervising parent obtains terminal status through waitpid() (WIFEXITED or WIFSIGNALED), is it a supported guarantee that every vCPU executed by that process has already ceased executing guest instructions and cannot resume? This includes abnormal process termination while a thread was executing hv_vcpu_run(). I'm deliberately distinguishing irreversible cessation of guest execution from complete VM resource reclamation. I am not asking whether sending SIGKILL guarantees immediate termination, only what is established once actual process termination has been confirmed. If Hypervisor.framework provides no documented guarantee for that ordering, confirmation of that limitation would also be helpful. Thanks again for your guidance. Gary

Hi Quinn, Thank you for the detailed clarification. That's extremely helpful. The behaviour you've described addresses several of our concerns about provider crashes. There are three remaining questions concerning a fail-closed design: Provider suspension: If an NEFilterDataProvider remains alive but stops processing callbacks, is there a documented timeout or system-enforced mechanism that prevents unresolved flows from proceeding? Outstanding permissions: If the provider has previously issued a partial flow allowance using passBytes and subsequently crashes or becomes unresponsive, can already-authorised bytes continue to pass? Existing connections: You've confirmed that previously allowed flows continue after a provider crash. Is there a supported mechanism for an independent process to terminate or fence those existing flows, and positively verify that transmission has stopped? Our objective is to establish a security boundary that remains effective following failure of the application or its monitoring components. We're particularly interested in distinguishing guaranteed, documented system behaviour from behaviour that requires application-level integration testing. Thanks again for your help. Gary

Hi Quinn, Thank you for the detailed explanation and for suggesting an enhancement request. I've now submitted Feedback Assistant request FB25189315, covering persistent VM identity, independently verifiable teardown completion following host-application failure, and supported external termination where appropriate. Your clarification about the absence of a guaranteed cleanup timeline and a successor-process verification API was particularly helpful in identifying the limitation. Thanks again for your assistance.

Thank you, Quinn. That's very helpful. I have one follow-up regarding the completion of that cleanup. On an Apple Silicon Mac running macOS 26.6, if a Virtualization.framework application's termination has been independently confirmed, is there a supported lifecycle event or ordering guarantee that establishes when its guest has actually ceased executing? Specifically, is there any externally observable condition that another process can rely upon before starting a replacement VM? Or should developers treat guest cleanup completion after unexpected application termination as unobservable through the public APIs? I'm trying to distinguish confirmed application termination from confirmed guest teardown, without relying on private helper-process identities or the absence of guest telemetry. Thanks again for your guidance.