Should I install this dependency? Developers answer that question every day, and the honest answer is usually "I hope so". Supply-chain attacks hide in install scripts and load-time code: here the package itself is the attacker, and running it on your laptop, with your tokens around, is exactly the risk. Quarantine Package runs that first install on Vultr instead. You type name@version and get a decision, install, review or do-not-install, plus a public receipt you can link in a pull request. On one Vultr Cloud Compute VM, the dependency tree is downloaded with scripts disabled. A model on Vultr Serverless Inference reads the package, predicts what it will do (network, files outside its folder, child processes) and writes a harness that exercises its main API. A fresh container then installs and loads it: read-only root, no capabilities, non-root, no secrets, resource limits and a hard time limit, with its file, process and network syscalls traced. Most sandboxes simply cut the network. We let the package try: its only route ends at a logging sinkhole, so the receipt shows where it wanted to send data, and how much, while nothing leaves the VM. Fixed rules, not the model, decide the verdict; a README that prompt-injects the model can change the explanation, never the outcome. After the run the model explains what happened, and a guard rejects any text that contradicts the verdict. The receipt puts the prediction next to what really happened, proves every container, network and volume was destroyed, and exports as Markdown for a pull request, JSON and SARIF; the CLI exit code can gate CI. Tested on real packages, not only demos: express and fastify (from the author's own payments project) get install; esbuild, which keeps a native binary running, gets review because we fail closed; a hostile package that writes to /etc, reaches for docker.sock and posts data out gets do-not-install while the site keeps answering.
Category tags: