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 five things.

Privileges

The helper, shown as Network Helper during setup, does five things: 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, which all need root; and, because it serves the whole Mac, holding the MacVisor license for every account on it, in /Library/Application Support/MacVisor/Licensing, which only root can read (a marker beside it, licensing-device-key, which any account can read, holds only a hash of the device key's public half). See Licenses on a Mac with several accounts. 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 from an administrator account clears the firewall rules it holds and unregisters it; from a standard account, only that account's rules are cleared and the helper stays.

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.
• Files sent from the guest to the Mac always need approval on the host.
• Automatic port forwarding, on by default for VMs made from cloud images (--no-forward turns it off), has no approval step: ports the guest listens on appear on the Mac's 127.0.0.1 only, never on its other interfaces, and ports where the Mac's own services usually listen are held back. See What automatic forwarding leaves out.
• 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. On a VM automatic setup set up from 27.0.0 beta 4, setup also adds /etc/sudoers.d/macvisor-shutdown, which lets that account run shutdown -h now, and nothing else, without a password, so MacVisor can stop the VM cleanly when the agent isn't connected; delete it in the guest to undo.

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 no app may talk to it without consent. MacVisor needs it for its own connections to a guest's address, such as the account and agent setup in a macOS 27 guest. mvz shell, exec, Docker contexts and port forwards go through the guest agent instead; commands you run in a terminal against a guest's address (curl http://dev.mvz:8080) use the terminal app's own permission. To check its permission and make macOS ask, the app and the runner send a one-byte datagram to the local multicast DNS group (224.0.0.251:5353), which never leaves the local network. Shown in the Setup Assistant (Assistant -> Setup Assistant...); 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 to ScaleNinja's licensing server (keys.scaleninja.com, port 443): when you click Start Free Trial or run mvz license trial, activate, refresh, deactivate, or move a license; about once a week, during a trial too; after a license or trial ends, to look for a renewal; to confirm a licensing record this Mac couldn't verify, and to finish a deactivation made offline; after a check that got no answer, again after 5 minutes and then at growing intervals up to every 6 hours; and when you try a licensed action while MacVisor waits for the server's answer (at most every 30 seconds). They carry a SHA-256 hash of this Mac's hardware UUID and one of its serial number (never the raw values), its model (never its computer name), the MacVisor and macOS versions, a random one-time value, with the Network Helper on the public half of a device key that proves later checks come from the same Mac, and, for activating, refreshing, and deactivating, the key. Never your email. The answers are signed, and MacVisor checks them on the Mac. Nothing about your VMs goes with them; Polar receives nothing from MacVisor, and to check a key the licensing server sends Polar only the key. What the licensing server keeps, and for how long, is in the privacy policy. 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 sources named in the catalogue, the distributions' download servers and Apple's CDN, only when you ask for an image. Some distributions' servers redirect to third-party mirrors. Each file is checked before use against a checksum pinned in the signed catalogue or read over HTTPS from the distribution's checksum list; only a file with such a checksum may arrive over plain HTTP, which a mirror sometimes redirects to. The exception is macos-latest when Apple offers a newer build than the catalogue lists: it is downloaded over HTTPS from the address Apple gives, with no checksum to check. Name a catalogue installer (macos-27) to have it checked.
• Inside the guest, cloud-init installs the runtime you chose from the distribution's repositories, download.docker.com (Docker on the RHEL family), GitHub (nerdctl when the Mac's cached copy isn't there yet; k3s and its installer), and, for k3s on some SELinux distributions, Rancher's package repository. That is the guest's own traffic.
• Problem reports are created only when you ask, saved to a file you choose, and sent by you. They hold MacVisor's logs, its task history, recent MacVisor crash reports, and a summary of your VMs (names, ids, settings, package paths) and networks.

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.