Hi Kevin @DTS Engineer, thank you so much for the response! This is indeed a comprehensive answer. I suspected it was missing for similar reasons you mentioned, just wanted to make sure it was intentional. Following the topic of intercepting file access events: could you suggest other technologies that are better suited to achieve this goal? Let's say it does not have to be general purpose software for end users, so anything like kernel module or even a custom kernel build also count. P.S. Thank you for the warning and for the links to other forum threads on this topic; very useful. As someone who came from the kernel driver world, I can imagine the possible performance impact of a subsystem like Endpoint Security, and the responsibility that comes with it. My app is monitoring-only, so hopefully it will be less prone to such errors. Anyway, will use your advice and try to be more careful.

Hello and thank you so much for quick response! The service application running on the host must be able to tell which client has connected to it via vsock. I have working code that runs on Linux (based on a "classic" vsock implementation), and it has to use different port numbers for each client, otherwise it would be impossible for multiple guests to connect to a single host. I tried to reuse the same approach in macOS, but it seems to be impossible. However, I understand it is not even required in macOS, since VM instances run by the Virtualization.framework are already isolated from each other. When the host app receives an incoming connection, it will be able to tell which client has connected just by using different VZVirtioSocketListenerDelegate. I haven't tested it yet, but I feel like this approach should work. Thanks again for clarification!