Trying unknown Mac software without trusting it: a disposable macOS VM on Apple Silicon

At some point you want to try a Mac app you don't fully trust: a menu bar utility from a one-person shop, an installer someone linked in a forum, a CLI that wants sudo. Installing it on the machine that holds your SSH keys and browser profile is the fast option, and also the one with the worst cleanup story.

A macOS virtual machine on Apple Silicon is a better boundary. It is not magic, and I'll say where it stops working. But for "I want to see what this thing does before I decide," it is the right size of tool.

What a VM does and doesn't give you

A VM gives you a separate macOS with its own user account, its own ~/Library, its own Login Items and launch agents. The app you test can write wherever it likes, and none of that touches your host unless you open a door on purpose.

It does not make an app safe. It won't help you analyze real malware, and it is not a hardened lab. If the sample is likely hostile, legally sensitive, or built to escape basic containment, use a proper analysis environment. The scope here is cautious testing of software that is probably fine but unproven.

Requirements

• An Apple Silicon Mac on macOS 14 (Sonoma) or later.
• Free disk space for the macOS restore image, the VM disk, and any copies. A comfortable macOS guest is around 4 vCPUs, 8 GB of RAM and 128 GB of disk.
• A VM app. This guide uses a native VM manager for Apple Silicon, which builds macOS and Linux guests directly on Apple's Virtualization framework. Any tool that can create a macOS arm64 guest works for the workflow below.

Step 1: build a boring baseline

Create a new macOS guest, name it something obvious like software-test-macos, and leave Shared Folders empty. The first macOS VM takes a while because the restore image is large; keep the Mac awake and the storage path with enough room for both the image and the installed VM.

When Setup Assistant appears, make a local account that has nothing to do with your real identity. Don't sign into your Apple ID, iCloud, Messages, a password manager, browser sync, or a developer account unless the test genuinely needs it.

Then make the guest boring and repeatable:

1. Install the macOS updates you want.
2. Look at the default privacy and security state in System Settings.
3. Create a plain folder such as ~/Test-Downloads.
4. Shut the VM down.

Now clone it and keep the original as your clean baseline. Test on the clone. If something goes sideways you throw the clone away instead of rebuilding macOS from scratch.

Step 2: get the software in with the smallest bridge

The cleanest path is to download the installer from inside the VM. The file, the browser history, the quarantine flag and the Gatekeeper decision all stay in the guest.

If the file is already on your host, share a temporary exchange folder, not your home directory, and prefer read-only. Copy the installer, then remove the share. Shared folders are applied when the VM boots, so stop the VM before you change them.

Things not to share: ~/Documents, ~/Desktop, ~/Downloads, ~/.ssh, browser profiles, password-manager exports, client project folders. If the test needs real project files, share a small copy and treat anything the guest writes back as untrusted until you've looked at it.

Step 3: watch what changes

Run the install as if the VM were a separate Mac you're going to delete. Pay attention to:

• Gatekeeper prompts and notarization warnings.
• Permission requests: Accessibility, Screen Recording, Full Disk Access, Files and Folders, Camera, Microphone, Location.
• New Login Items, launch agents and daemons, browser extensions, network or system extensions.
• Processes that keep running after you quit the app.
• Network access for activation, updates or telemetry.
• Files created outside the app's obvious support folder.

Activity Monitor, Console and System Settings → Login Items cover most of it. For persistence, a few ls commands inside the guest are enough to see what an installer left behind:

ls -la ~/Library/LaunchAgents
ls -la /Library/LaunchAgents
ls -la /Library/LaunchDaemons
find ~/Library/Application\ Support -maxdepth 2 -iname "*app-name*"

Replace app-name with a distinctive piece of the product name. None of this proves the software is safe; it tells you what changed, which is what you need to decide whether to put it on your real machine.

A permission prompt you didn't expect is the moment to pause. If a calculator wants Full Disk Access, the answer is no, and you've just learned something without it costing you anything.

Step 4: keep the host boring

The boundary only works if you don't poke holes in it. In practice that means:

• Shared folders off unless the test needs them.
• Separate accounts and browser profiles inside the guest.
• Throwaway licenses or least-privilege API keys when the app wants credentials.
• Don't approve host-side prompts just because the guest app asked for something.
• Shut the VM down when you're done.

Step 5: clean up

If the test went well, keep the VM as a reference environment. If the app misbehaved, stop it and delete it.

One thing worth knowing: deleting a VM from the app's library removes it from the list, but the disk image can stay on disk. If you want the space back, remove the VM folder under the storage path yourself, once you're sure you won't need it. Check the storage path in the app's settings before you start so you know where it lives.

Where this falls short

• x86 guests. Apple Silicon virtualization runs arm64 guests. If the software only exists for x86 macOS, a VM like this won't run it.
• Nested virtualization and GPU passthrough aren't available, so anything that needs them is out.
• Windows guests are a different story: no 3D acceleration, no shared folders, no audio and no USB passthrough in the current release of the app used here, so this workflow is macOS-only.
• It's risk reduction, not a guarantee. A local VM is one layer. If you wouldn't run it near anything you care about, don't treat the VM as permission to.

The short version

1. Build a clean macOS guest with a throwaway local account.
2. Clone it; test on the clone.
3. Bring files in through the narrowest possible door.
4. Watch permissions, Login Items and launch agents.
5. Delete the clone and reclaim the disk space.

It costs a few minutes of setup per test and makes "do I trust this app?" a question you can answer before it has touched anything you care about.