VPN Works: Gives Each AI Agent Its Own Network and a Record of Every Connection
A coding agent spends its day reading text written by strangers: issues on your issue tracker, snippets pasted into prompts, code from repositories, instructions on web pages. One malicious instruction planted in that text can be enough to make an agent send a deploy token somewhere it shouldn’t. On a machine-wide VPN, that request leaves the same way as everything else, and afterwards nobody can say which program sent it.
VPN Works narrows the network down to one program. Its command, vpnw, seals an agent in a Linux network namespace whose only way out is through vpnw itself. A script that ignores proxy settings finds no route anywhere. Every connection the agent makes is checked against a short policy and written to a record. It leaves by the path you chose: direct, through your office proxy, or nowhere at all.
Day to day it comes down to four commands. run picks the outbound path and runs the program. trace prints every connection the program made, with timestamps and destinations. guard enforces a policy and blocks anything outside it. learn drafts a policy from a traced run.
The learn command is the part teams will like most. Nobody writes an allow list from scratch; you run the agent once and let it do what it normally does, then you read what it actually connected to, strike what it shouldn’t have done, and enforce the rest. Under a default-deny policy, a hostname that isn’t allowed is never even looked up by DNS, so DNS itself can’t be used to leak data. Every connection is logged, so if something does go wrong, you know exactly what happened.
For teams running agents on their own machines or in their own data centers, this is not paranoia. It’s a straightforward defense: an agent that makes a request outside your policy either gets blocked or gets logged, and you know about it before the damage happens. The policy is readable and simple, and you drafted it from watching your agent work normally, so it’s not a guess.
The details matter. The namespace is strict: no DNS out unless you allow it, no route to any IP unless the policy names it, no leaking through environment variables or shared memory. The log is complete: every attempt shows up, even the ones that were blocked. The policy engine runs on the machine where the agent runs, so the policy can be changed without an API call or a restart, and you can test a new policy against old logs to see what would have happened.
There’s a second engine. Scope brings the same idea to the company VPN. It learns from traffic who uses which systems inside your network and drafts least-privilege rules for the gateway, so a stolen login no longer opens the whole office to an attacker. Scope is for the infrastructure team; the agent-level VPN Works is for the team running the agents themselves.
Both tools are Alphas, tested on Linux. The live demo replays real runs of an agent trying to leak a deploy token, and you can edit the policy against the real engine, compiled to WebAssembly, to see what would have been blocked. How It Works covers the sandbox in detail, explaining how the network namespace works and how the policy engine decides what to allow.
For teams running coding agents on their own machines or in their own cloud, knowing exactly which outside connections an agent makes, and being able to block what it shouldn’t do, is the difference between confident adoption and worried caution. VPN Works makes that confidence real.