Thanks, Quinn. I reviewed the recent discussions, particularly Kevin Elliott’s replies here: https://developer.apple.com/forums/thread/850253 https://developer.apple.com/forums/thread/852760 My understanding is that Endpoint Security restrictions disappear when the client goes away. FAIL_CLOSED covers missed authorization deadlines and queue-full drops; it does not preserve the restrictions through client loss. I will not treat it as a policy that survives the process enforcing it. That answers most of my original questions. The one remaining clarification is whether I should apply that same limitation to pending AUTH_RENAME/AUTH_UNLINK requests and later file moves or deletions after the last matching client disappears or unsubscribes. The collector’s specific requirement is to stop accessing a file if that file or an ancestor moves outside its fixed approved roots, including during a read or write. Another process may perform the move. A later notification or restart would leave an unprotected interval. If the client-loss guidance already covers those namespace operations too, confirmation is enough. I will treat Endpoint Security alone as insufficient for that requirement rather than repeat the full question list. I am not asking for a guarantee that an allowed operation will succeed. This remains a design inquiry; no Endpoint Security client has been created for this candidate.

Thanks, Quinn. The concern is the service sending a delayed reply after the recipient no longer matches its authorization decision. The proposed sequence is: A local client sends a request. The service checks that message’s sender identity and separately decides what that client is allowed to receive. The service retains the message while it prepares a reply. Before delivery, the client may exec a different executable, or the reply right may have moved to another process. I agree that an authorized client can copy or leak information after receiving it. This design cannot prevent that. The narrower goal is to avoid delivering information to a different executable or process that was never authorized to receive it. Your sender-identity clarification answers the first part. I also read Conforming to Mach IPC security restrictions. It recommends XPC to mitigate reply interception, but I could not establish the delayed-delivery boundary above from that article alone. For supported C XPC, does retaining the received message’s reply context keep delivery bound to the original authorized process and executable occurrence? If it does not, is there a supported way to check the actual recipient before sending, or should the design avoid putting sensitive data in a delayed reply when that identity cannot be established? This remains a design question. I am not claiming a reproduced vulnerability.

Thanks, Quinn. That clarifies the kernel-supplied audit token and the PID-version change across exec. Two points remain unclear: For a retained received dictionary M, does SecCodeCreateWithXPCMessage(M, …) use identity fixed to that message’s original sender, even after concurrent receives or sender exec? The cited implementation’s connection-token lookup is what prompted this question. Does retaining M’s reply context bind delivery to that original sending occurrence, or could a later executable or another rights holder receive the reply? If it doesn’t provide that guarantee, what supported public API and ownership pattern should validate the eventual recipient before sensitive data is sent? Please identify any supported-version limits.

Thank you for the referral and the disk-image release guidance for macOS 27 and later. Could you clarify the corresponding supported contracts for VZEFIVariableStore and VZSharedDirectory? This is a source-design question targeting macOS 27.0.1, build 26A434, on Apple silicon. I have not run a reproducer or established exact-build behavior. EFI variable store: After guestDidStop(_:) or a successful stop(completionHandler:), is the framework finished accessing and modifying the variable-store file, including outstanding operations and access held by framework helper processes? At what documented boundary may the host safely reuse, replace or remove that file? Shared directories: At either successful stop boundary, are all framework operations involving the shared directory and its descendants complete? Does that boundary cover files already opened through the share and references retained by framework helpers? Removing a share while running: What does setting VZVirtioFileSystemDevice.share to nil guarantee about in-flight operations and already-open guest files? Is there a supported completion notification establishing that the framework has finished accessing the formerly shared resources? Failure paths: How do these guarantees differ after an internal VM error or termination of the process hosting the VM? If neither stop notification establishes complete release, what public API or ownership pattern provides that boundary? Please distinguish backing-resource release from persistent-data synchronization. Does any applicable release boundary also guarantee that pending EFI-store and shared-file writes have completed, or is separate synchronization required? I am not assuming that releasing application references, observing object destruction, or reaping the hosting process proves that all framework-held access has ended. Host-side competing writers and application authorization are separate concerns. Documentation references and supported-version limits would help. If the guarantees or exact-build applicability cannot be established publicly, an explicit statement of that limitation would also be useful.