Supply-chain security for pull requests and packages

Run untrusted code somewhere it can't hurt you, and catch what it tries to steal.

Airlock tests a new pull request, npm package or PyPI package in a throwaway virtual machine full of fake passwords. Whatever the code tries to send out is captured as evidence, an AI agent explains it, and nothing merges until a person approves.

The problem

In CI, install scripts and test hooks run with real tokens and full internet access. A postinstall that reads ~/.npmrc and posts it somewhere still leaves the tests green, and reviewers rarely read a lockfile change. Passing tests don't tell you what the install did.

How Airlock works

1. Detonate. Each run gets a fresh microVM with its own kernel on a Vultr server. The install and tests run as an unprivileged user beside fake credentials, each carrying a token unique to the run, while a root watcher records programs, file reads, DNS lookups and connections.
2. Capture. Only the package registries are reachable. Every other address is answered by a fake server on the host, so stolen credentials are caught in the request itself: the theft is proven by the payload, not guessed from a connection. For a pull request, the code before the change runs too, and only new behaviour is flagged.
3. Investigate. An AI agent on Vultr Serverless Inference reads the code and the evidence. If something only misbehaves when called, it asks Airlock to run it from a clean copy, so that theft counts as proof as well. Every claim it makes cites a recorded event.
4. Gate. A required GitHub check holds the pull request at pending. Proven theft is rejected automatically; anything else waits for a person, and only a person can approve.

See it on real pull requests in the public demo repo, or verify a signed receipt.