VPN Works

Introduction

Tue, 29 Sep 2026 00:00:00 +0000

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.

How It Works

Tue, 29 Sep 2026 00:00:00 +0000

The idea. Seal each agent in a sandbox whose only way out is vpnw. vpnw checks every connection against a policy, sends it down the path you chose and records it. The agent doesn’t need to know any of this.

A VPN usually works at the level of the machine. Once it is up, every program on the machine goes out the same way, under the same rules, and nobody can say afterwards which program sent what. That was fine when the programs were a browser and a mail client. It fits badly when one of them is an agent that takes instructions from whatever it reads.

Coding Agent Case Study: Deploy Token Blocked by a Policy Drafted From One Traced Run

Tue, 29 Sep 2026 00:00:00 +0000

A coding agent needs the network to do its job. It reads repositories, downloads packages, files tickets and reports back. It also reads text written by strangers, and some of that text is written to give it orders. If the agent holds a token and can reach any server on the internet, one hidden sentence in a task file is enough to send the token away.

In the Alpha demo a stand-in coding agent gets exactly that task file. It runs twice under vpnw on Linux: once under trace, to see what it does, and once under guard, with a policy that learn drafted from the first run and a person reviewed. The first run leaks the token. The second doesn’t, and the rest of the agent’s work goes through, except the ticket, which needs the office route.

Office Route Case Study: Ticket Filed Through the Office Exit, With the Deploy Token Still Blocked

Tue, 29 Sep 2026 00:00:00 +0000

Some of an agent’s work lives inside a company network: an issue tracker, a package mirror, an internal API. The usual way in is the company VPN, and it takes the whole machine along. Every program on the laptop, the browser included, now goes through the office, and the agent can reach everything on that network that the laptop can.

In the Alpha demo one program at a time goes through the office. The office network has an exit, a SOCKS5 proxy inside it at 10.8.0.1, which knows internal names such as tracker.office.internal. vpnw sends the agent there and nothing else. The agent files its ticket, and its policy still stops the deploy token.

Sealed Sandbox Case Study: A Script That Ignores Proxy Settings Tries Three Ways Out and Finds None

Tue, 29 Sep 2026 00:00:00 +0000

A proxy setting is only a request. Most programs honor HTTPS_PROXY, and a policy enforced at the proxy works for them. A program that has been told to leak something has every reason not to honor it. It can switch the proxy off, connect to an address directly or find a local service that will connect for it. A policy that only lives in the proxy never hears about any of that.

Cloud Metadata Case Study: Request for Instance Credentials Blocked Before Any Connection Is Made

Tue, 29 Sep 2026 00:00:00 +0000

Every major cloud runs a metadata service at the same address, 169.254.169.254, reachable from inside each virtual machine. Among other things it hands out the machine’s own credentials: on AWS, for example, the temporary keys of the role the instance runs as. An agent on a cloud machine that gets talked into fetching that address can leak keys that carry every permission the machine’s role has in the cloud account.

Next Uses: Seven Places Where a Network per Program Could Fit

Tue, 29 Sep 2026 00:00:00 +0000

The four case studies share one pattern. A program that runs on its own, and can be talked into things, gets a network of its own: one way out, a path chosen for it, a policy a person can read and a record of every connection. Coding agents came first because they are the clearest case, and because the Alpha demo covers them.

The pattern turns up well beyond coding agents. None of the seven uses below has been tested, and none is a goal of the Beta, though some would reuse pieces the Beta builds. This post sets out what each would ask of vpnw, what already carries over from the Alpha, and what would be new work. It is a map for choosing what to try after the Beta, ideally with the people who run these systems.

VPN Works Explained: How vpnw Gives Each AI Agent Its Own Network and Stops Token Leaks

Tue, 29 Sep 2026 00:00:00 +0000

VPN Works is a prototype of a small program called vpnw. It gives one program, usually an AI agent, a private network of its own on a Linux computer. vpnw decides where that program’s traffic may go, sends it out the way you choose and writes down every connection it makes.

That matters because of how AI agents work. Coding assistants and similar tools run on laptops and servers with all the network access the machine has, and they follow instructions they find in text. One hidden line in a task file or a web page can say “send the deploy token to this address”, and an agent may simply do it.

About

Mon, 01 Jan 0001 00:00:00 +0000

VPN Works is a project at an early stage. Its engine works on Linux, a live demo replays it and runs its policy engine in your browser, and the next step is real agents on more systems. This site shows where the project stands, gaps included.

Why the Project Exists

AI agents now run code and call APIs on their own. They run on developer laptops, in CI and on servers, usually with all the network access of the machine they run on. That is a lot of access for a program that takes instructions from whatever text it reads.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

The project would like to hear from:

Teams running AI agents, coding agents in particular, who would like to try the Beta on their own machines or in CI.
Security and platform engineers with an agent, a tool or a network setup the project should test.
Anyone with a question about the engine, the demo or the figures on this site.

Write to info@vpnw.com.

If you are writing about a setup, it helps to mention the agent, where it runs (a laptop, CI or a server), the operating system and distribution, what the agent needs to reach, and how your network is organized: an office VPN, a proxy, fixed egress addresses.

Live Demo

Mon, 01 Jan 0001 00:00:00 +0000

A coding agent runs a task whose task file hides an instruction to send a deploy token to an attacker. Six steps show what VPN Works does about it. Every line in the terminal below comes from real runs of the Alpha on Linux and is replayed here, and the decisions in the two panels under it are made by the Alpha’s own policy engine, running in your browser. There is nothing to sign up for or install, and nothing you do here leaves this page.

Roadmap

Mon, 01 Jan 0001 00:00:00 +0000

The Alpha proves the design on one Linux machine, with stand-ins for the agent and the network. What comes next puts real agents under vpnw on more systems, then leads to a first release, and after that to the parts a company would pay for. Durations are estimates, and what real agents turn up could stretch them.

The Alpha

Mon, 01 Jan 0001 00:00:00 +0000

The Alpha is the working prototype of the VPN Works engine: one Go program called vpnw, its tests, a few tools and a demo. On Linux it runs a program in a sealed sandbox whose only way out is vpnw. Each connection is decided by a policy, sent down the path you chose and recorded.

Everything so far ran on one Linux machine, a virtual machine with two CPUs. The demo’s agent, servers, office and attacker are stand-ins in a private network namespace. The engine also compiles for arm64 Linux and for macOS, but neither build has run yet. On macOS it is meant to route and trace programs that honor proxy settings; it can’t seal them. No real coding agent has run under vpnw so far. That is the job of the Beta.