I had an interview repository to look at, and I knew I should review it before running anything. So I cloned it and ran npm install.

That was the part where I ran something.

In my head, installing dependencies belonged to getting ready. Running the application would come later, after I’d checked it. npm made no such distinction.

The repository I’d installed had a prepare script that sent the process’s environment variables to a hidden address and executed the response. Environment variables can hold API tokens. Executing the response lets the person at the other end decide what your computer does next.

The application didn’t need to start. The installation was enough.

If this has already happened to you, disconnect the machine. From a different device, change the passwords, keys, and tokens that were on it. Then wipe it and reinstall the operating system: once somebody else’s code has run, you can’t know what it left behind. If a crypto wallet was on it, move the funds to a new wallet; a stolen seed phrase can’t be changed.

The horse only needs you to follow the instructions

An interview assignment makes a good Trojan horse because running unfamiliar code is part of the expected work. You want to understand the project, fix the bug, and get on with the conversation. The README tells you how to begin.

That same opening works for a game or a useful-looking tool. Most of the repository can be perfectly ordinary. A small script or dependency can fetch the malicious part later. Microsoft has documented fake interview campaigns that use repositories and dependency installation to steal credentials and install backdoors. In some of those campaigns, trusting the repository in VS Code is enough: the editor runs the project’s task file, which fetches the backdoor.

Once code runs on your account, it can often read the same files you can: private keys, .env files, cloud credentials. It doesn’t need administrator rights to steal a file you already have permission to open. Being hosted on GitHub doesn’t make the code any safer.

npm was where my review turned into running the code. Its install lifecycle includes scripts such as postinstall and prepare, which can execute arbitrary commands. The broader problem applies to any language: at some point, you let somebody else’s code act with your permissions.

I wanted a place where making that mistake again would have less of an impact.

Naturally, I started building a laboratory

My first response involved a gateway, packet sniffers, and filesystem monitoring. After a day, I caught myself. I was building quite a lot of machinery to answer a fairly small question: what is this repository trying to do? I cut it down to a disposable virtual machine, an SSH connection, and an AI agent reading the code.

On a Mac, UTM gives you a straightforward way to build that extra computer. It runs a separate operating system inside a window. I’d use Ubuntu Server LTS; a desktop isn’t needed when the work happens through a terminal.

The important part is what this computer doesn’t have. No personal files, existing private keys, wallet, or signed-in accounts. No shared home directory or clipboard. Those conveniences would give the VM access to things I was trying to keep out of reach.

The agent can help with the setup, guiding you through UTM’s interface where needed. It stays on your Mac, where it can reach its AI service, and reads the isolated VM through SSH. The prompt below creates a reusable base.

SSH lets you stay in your Mac’s terminal while issuing commands inside Ubuntu. The saved connection should look like this, with the key path you chose:

ssh -F none -a -x -o IdentitiesOnly=yes -i ~/.ssh/repo-review -p 2222 review@127.0.0.1

Once isolation is on, the VM can’t reach your Mac or the internet, but that one SSH connection still works, so the agent can keep interacting with the VM.

On Linux, QEMU can provide a similar setup, though I haven’t tested that version of these instructions.

Solitary confinement for untrusted code

For each repository, make a fresh copy of the powered-off base. Temporarily reconnect the copy to download the repository. It can reach your Mac during this step, so don’t install dependencies or run the project yet. A public GitHub repository can be cloned over HTTPS without bringing a personal token along.

Then shut the VM down, restore isolation, and hand the investigation to the agent: following install scripts, checking what they call, and explaining suspicious behavior with references to the actual code.

The agent needs boundaries too. A README can contain instructions aimed at it. Keep the agent asking permission before it runs commands on your Mac, and read what it proposes; if the tool can restrict the agent to the VM connection, use that. A prompt won’t contain an agent that still has unrestricted access to your Mac.

If you later need to run something, run it in the isolated copy, under the review account without admin rights. If it needs missing dependencies or an online service, record that limitation. Reconnecting a VM after running suspicious code opens the network back up to whatever may now be inside it.

None of this proves a repository is safe. An LLM can miss something; malware can behave differently in a VM or on another operating system. Keep UTM and Ubuntu patched, keep the clean base, and delete the review copy when you’re finished.

I still want to understand the code before I run it. I just prefer a setup where getting the order wrong doesn’t immediately put my everyday files and keys in reach.