Introduction

A VPN for every agent: each AI agent gets a network of its own, and every connection it makes is checked, routed and recorded.

VPN Works is a project to build that network. Its engine, vpnw, is one small program. It runs an agent in a sealed sandbox whose only way out is vpnw, then decides each connection with a policy you can read, sends it down the path you chose and writes it down.

The engine works today on Linux. It is one binary of 3.6 MB with no third-party code, and its tests tried 14 ways out of the sandbox without finding one that works. A live demo replays it in your browser. The next step is real agents on more systems.

Why Give Each Agent Its Own Network

AI agents run code and call APIs on their own, usually with all the network access the machine has. That is a lot of trust for a program that follows instructions it finds in text. A README or an issue only has to carry the right sentence, and an agent holding a token can be talked into sending it out. Models can’t reliably tell data from instructions, so the practical defense sits outside the model.

A VPN or a firewall doesn’t fit that job. It covers the whole machine and can’t tell which program opened a connection, let alone keep a record of what one agent did. VPN Works gives each agent its own network instead. One way out: the agent is sealed in, so every connection that gets out goes through vpnw, whatever the program does. A path you choose: direct, the office network or a regional exit, for this agent only. A policy people can read: a short text file, drafted from a real run and checked by a person. A record: every connection with its decision, as text and as JSON Lines. How it works

What the Alpha Has Shown So Far

In the Alpha’s tests a sealed program tried 14 ways around vpnw: direct connections to public, private and cloud metadata addresses, UDP, DNS, a raw socket, a child process, Unix sockets, io_uring and a second system call table. All 14 were blocked. The tests also caught 24 of 24 bugs planted in the engine on purpose. vpnw adds about 9 ms to a program’s start and about 1 ms to each new connection.

All of this was measured on one Linux machine, with a stand-in agent and stand-in servers. No real coding agent has run under vpnw yet, and two IPv6 routes could not be tested because that machine has no IPv6. That is what the Beta is for. The Alpha in detail

Where the Project Stands

The Alpha is done: run, trace, guard and learn on Linux, with a sealed sandbox, tests and a demo. The Beta comes next and takes about 14 weeks: WireGuard, a file-system layer, macOS, packages, and real coding agents working under vpnw every working day for four weeks. Toward v1.0, the project adds workspaces, freezes the event format and has the sandbox reviewed by outside experts. v1.0 freezes the command line, the policy files and the events, so scripts built on them keep working. See the roadmap

Try It in Your Browser

A coding agent gets a task whose task file hides an instruction to send a deploy token to an attacker. The live demo replays six real runs of the Alpha on Linux: the first trace, a policy learned from it, the token stopped, a route through the office, a script that ignores proxy settings and a request for cloud credentials. Under the replay, the Alpha’s own policy engine runs in your browser, so you can change the policy and run the agent again. It is open to everyone, with no sign-up and nothing to install. Open the live demo