Security model

Everything that manages VMs (the app, the mvz CLI, the control service, and every VM runner) runs as the logged-in user. One small component runs as root, and it does four things.

Privileges

The helper, shown as Network Helper during setup, exists for the four things that need root: loading firewall rules into pf, creating 802.1Q VLAN interfaces, linking /usr/local/bin/mvz and macvisor, and writing /etc/resolver/mvz and /etc/resolver/macvisor so <vm>.mvz and <vm>.macvisor lookups reach the service. It is a launch daemon, approved once with one administrator password. It installs only from a copy of MacVisor that only an administrator can change, such as one in /Applications, so a standard account can't swap the code it runs.

It answers only MacVisor's app and background service, which it checks by code signature, and it checks who is asking:

The links point only into a copy of MacVisor that only an administrator can change, and go only into a /usr/local/bin that is a real folder under administrator control. The helper never replaces a file there that isn't a MacVisor link.

It accepts policy, never packet-filter text, and compiles the rules itself. The background service sends each network's policy, whether or not the app is open, and the helper checks each subnet again: rules apply only to a subnet inside 192.168.0.0/16, from /20 to /30, that doesn't overlap one of the Mac's own networks. A compromised user-level process can therefore only ask for what the interface already expresses, not for arbitrary root control of host networking. Uninstalling MacVisor clears the firewall rules it holds and unregisters it.

The guest boundary

A VM is isolated by design. Every feature that crosses that isolation is opt-in and visible:

• Shared folders expose chosen host directories over VirtioFS. Share only what the guest needs, read-only where possible.
• Clipboard synchronisation goes both ways by default. Per VM, limit it to Mac to VM only, so the guest can't change your clipboard, or VM to Mac only, so the guest never sees it, or turn it off. The Mac's clipboard is sent only while the VM's window is active. See Guest tools.
• Guest-initiated requests (files, URLs, and automatic port forwards asked for by software in the guest) always need approval on the host.
• USB passthrough gives a guest a real host device; the guest driver then talks to your hardware directly.
• Rosetta sharing and nested virtualization are per-VM and visible in the VM's settings.
• Imported bundles are treated as data, not trusted settings. Importing a .macvisor bundle from elsewhere removes its shared folders and external disk images, clears USB auto-capture, turns start at login off, pins port forwards and remote access to 127.0.0.1, and fixes invalid guest account names; MacVisor lists what it changed. A bundle whose configuration names disk files outside the bundle is refused. See Storage and sharing.

Inside a macOS guest the agent is an ordinary user login item named MacVisor Agent, switchable in the guest's own Login Items & Extensions. It runs as the signed-in guest user, with no elevated rights.

Two provisioning paths cross the boundary on purpose, once:

• Linux cloud-image VMs are configured by cloud-init with your user name and UID, the public SSH keys from ~/.ssh and your agents (or only those you pass with --ssh-key), and, only if you ask (--home, or Share my home folder (read-only) in the New VM form), your home folder read-only at the same path. Nothing private leaves the Mac, but a read-only share of your home folder is still your home folder: leave it off for guests you don't trust. The form remembers your last choice, so make sure it is unchecked before you create such a VM.
• macOS 27 guests with automatic setup and Remote Login are signed into once by MacVisor, over SSH with the account's password, to authorise your SSH keys and install the agent. MacVisor then turns SSH password logins off, so the guest takes keys only. Later agent updates go over SSH with MacVisor's own key, ~/.macvisor/ssh/id_ed25519. The default account (mac / macvisor) is public knowledge and still works at the guest's login window; change it on any VM others can reach.

Network isolation

Host-only networks keep guests off external networks entirely. A custom network's firewall adds inbound and outbound control enforced on the host, where the guest cannot disable it; its limits are listed in Network firewall. Bridged mode is the opposite choice: the VM is a device on your LAN, subject only to what your network already enforces.

macOS permissions MacVisor asks for

• Background item approval for the control service, and one administrator password for the network helper, at first-run setup.
• Files and Folders access when VMs live on a removable, network, or otherwise protected volume: once for the background service when it scans the library, once for the VM runner when it first starts a VM stored there.
• Local Network access, for the app and for the VM runner. VMs live on a local network of their own, and since macOS 15 nothing may talk to it without consent: mvz shell and exec over SSH, the <vm>.mvz names, guest address discovery, and the agent install into a macOS 27 guest all connect from the Mac to a guest's address. Managed under Settings → Setup; see Install and activate.
• Microphone access, only for a VM configured to receive host microphone input.

What leaves your Mac

• VM data never does. Bundles, disks, snapshots, and guest traffic stay local.
• License checks go from MacVisorService to Polar (api.polar.sh, port 443): at activation, once after an update, about once a week, at the end of an Enterprise term, to confirm a licensing record this Mac couldn't verify, and to finish a deactivation made offline. They carry the key, this Mac's hardware UUID, and, at activation, its computer name. Nothing about your VMs goes with them. Apart from these and the app's update check, MacVisor makes no routine traffic of its own; the image catalogue ships inside the app and is never fetched. See Activate your license.
• Update checks download a signed release feed from scaleninja.com once a day when enabled; updates are verified against MacVisor's signing key and never installed without asking. Running VMs are not interrupted.
• Image and installer downloads go to the vendors named in the catalogue, the distributions' servers and Apple's CDN, over HTTPS, only when you ask for an image, and are verified against the vendor's checksum before use.
• Problem reports are created only when you ask, saved to a file you choose, and sent by you.

Protecting VM data at rest

A .macvisor bundle holds the guest's whole disk and, with macOS automatic setup, the account password in its configuration until the guest agent first connects, or for the first 30 minutes the VM runs when there is no agent to install. The New VM form doesn't remember the password, and exported snapshots, and exports of a VM that has booted, leave it out. FileVault is the right protection for that, at the cost of unattended reboots; see Always-on host. Snapshots and templates are convenience, not backup; back the host up independently.