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

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.

What They Would Share

Every use below relies on the same parts of the Alpha: the sealed sandbox, so a program can’t go around vpnw; the policy, with deny_private as a floor; paths chosen per run; and the record, as text and JSON Lines. What changes from one use to the next is who writes the policy, how strict it can be, and who reads the record.

CI Jobs and Package Installs

A build job installs hundreds of packages, and installing a package can run its code. Hijacked packages that steal tokens during installation have become a regular event on npm and PyPI, and a CI job is full of tokens. Under vpnw guard, an install step would reach the package registries and nothing else. Anything more would be denied, and the job would fail with exit code 120 where everyone can see it.

• Carries over: guard, learn from a clean build, exit codes that CI understands, JSON traces kept as build artifacts.
• New work: ready-made CI steps (the Beta plans one for GitHub Actions and one for GitLab), a policy per build step, and support for the caching proxies many companies already put in front of their registries.
• The limit: a policy works on names. If the registry and the attacker’s upload share a host, as they do when a stolen token is pushed to a public code host, vpnw can’t tell the two requests apart without reading them, and it doesn’t read traffic.

MCP and Tool Servers

Agents call tools through MCP servers, and many of those are small local programs written by third parties, running with the full network access of the machine. A weather tool needs one API. A database tool needs one database. Each could run under its own vpnw policy, started by the agent’s client with vpnw guard --policy weather.toml -- weather-server instead of the server’s own command.

• Carries over: everything. A tool server that talks over standard input and output is an ordinary program to vpnw, and the Alpha’s tests check that standard input passes through unchanged.
• New work: policies for popular servers, and a check that each one honors proxy settings. A server that doesn’t will fail under guard instead of leaking, which is safe but not useful.

Browser Agents

Agents that drive a browser need the open web, so an allow list is out of the question. What remains useful is the floor and the record: deny_private with a default of allow keeps the agent away from the machine’s own network, the office and the cloud’s metadata service, and the trace shows every site it touched.

• Carries over: deny_private, default allow, the record, HTTP and SOCKS5 proxying.
• New work: browsers open many connections at once, and in the Alpha’s parallel test vpnw handled a little over a third of the requests per second a bare run did. HTTP/3 runs over UDP, which vpnw refuses, so a browser has to fall back to HTTP/2 over TCP, and that needs checking. Whether a browser runs at all with the Unix-socket filter on is untested.

Crawlers That Need a Regional Exit

A price-comparison crawler, a localization test or a research agent often needs its traffic to leave from a particular country. Today that usually means a proxy setting in the program, or a whole machine on a VPN. With vpnw, vpnw run --config exits.toml --via germany -- python crawler.py would send that one program through a German exit while other programs on the same machine use other exits, or none.

• Carries over: named paths, one per run, several runs at once on one machine.
• New work: WireGuard paths (in the Beta), health checks that pick another exit when one is down, and a record of which exit each connection used, which the Alpha already keeps per run.

Platforms That Host Other People’s Agents

A company that runs agents for its customers wants each customer’s agent on its own exit address, so the customer’s own systems can recognize it, and each with its own policy and record. That is the Alpha’s model repeated a thousand times on one server.

• Carries over: a path, a policy and a record per run; about 9 ms to start a sealed run and about 4 MB of memory for vpnw and 4 MB for its helper.
• New work: the parts companies would pay for: exits run for them, policies and paths pushed to every machine, and records kept and searchable for as long as their contracts say. Load tests with hundreds of runs at once.

Audit Trails in Regulated Teams

Banks, insurers, health providers and law firms trying agents need to answer a simple question afterwards: where did the agent send data? The record answers it per run, with every destination, decision and byte count, and without keeping the data itself.

• Carries over: the record, which never keeps payloads, URL paths, headers, environment variables or passwords.
• New work: records that can’t be edited afterwards without it showing, a frozen event format, export to the security tools these teams already use, and retention rules.

Everyday Developer Tools

Plenty of command-line tools phone home: telemetry, update checks, crash reports. vpnw trace shows what a tool contacts, and guard keeps it to what it needs. This is the smallest use, and the one a developer can try alone in five minutes.

• Carries over: trace, learn and guard, as they are.
• New work: packages that make vpnw easy to install, which the Beta brings.

What the Engine Would Need

How a New Use Would Be Tried

The same way as coding agents. First a demo with stand-ins, recorded on Linux and replayed like the Alpha’s. Then a real program under guard for weeks, with a policy learned from a clean run and reviewed, a planted attempt to leak a canary token, and the numbers measured again. A use counts as covered only when that attempt is blocked and the real work goes through.

Which Come First

MCP and tool servers, and everyday developer tools, need almost nothing new, so they are the natural first tries after the Beta. CI jobs follow closely, because the Beta builds the CI steps anyway. Browser agents and crawlers wait for the Beta’s WireGuard path and more speed. Hosting platforms and audit trails need the paid layer that comes after v1.0. The roadmap has the order, and anyone running one of these systems is welcome to get in touch.