Live Demo

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.

Stand-in network, real Alpha engine. The agent, the servers, the office and the attacker ran as small programs in a private network namespace. vpnw and everything it printed are real.

How to Run It

  1. Press Play. The six steps play in about a minute, each ending with a short conclusion. Pause at any time, or pick a step.
  2. Watch the diagram. Each connection goes from the agent to vpnw, then down a path to a server. Green opened, red was denied by the policy, amber could not be reached.
  3. Read the record. The table under each step is vpnw’s own trace of that run.
  4. Try your own policy. Below the replay, edit the policy, pick a path and run the agent’s five requests again, or ask the engine about any destination.

On a wide screen the demo shows the terminal and the diagram side by side: open it full screen.

The Controls

Control What it does
Play, Pause, Resume Plays the six steps in order, pauses and carries on. The whole replay takes about a minute
Back, Next Moves to the previous or next step and plays it
Restart Goes back to step 1 and plays from there
Step 1 to Step 6 Jumps to that step and plays it
Compute the draft in this page In step 2: runs the Alpha’s learn code on the step 1 trace, in your browser

The Six Steps

  1. See what the agent does. vpnw trace runs the agent with no policy. It reaches the code host, the package index and a telemetry endpoint, the office tracker is not found on the public internet, and the token goes to evil.example. Now there is a record of all five.
  2. Learn a policy from the trace. vpnw learn writes a draft that allows what the agent reached, evil.example included, and notes the tracker it could not reach. A person removes evil.example and adds the tracker.
  3. Guard: enforce the policy. The same agent under vpnw guard. The token is denied and logged, the rest of the work goes on, and vpnw exits with 120.
  4. Route: this agent, through the office. vpnw run --config office.toml --via office reaches the internal tracker through the office exit. Then the agent again with the route, the policy and the record together: every allowed step works, and the token still goes nowhere.
  5. Sealed: an agent that ignores proxy settings. A script tries three ways out: by name, by address, and through a local service’s Unix socket. Outside vpnw the first one works. Inside, all three fail and vpnw never sees a connection.
  6. Private addresses. curl asks for the cloud metadata service at 169.254.169.254. deny_private blocks it before any connection is made, even with a default of allow.

Reading the Diagram

  • The sealed sandbox holds the program. Its one door leads to vpnw.
  • vpnw shows the command it is running and, at the end, how many connections it saw and denied.
  • The public internet and the office network hold the stand-in servers, with their addresses. Each server shows what happened to it: open, the bytes sent and received, DENY with the rule, or not found on this path.
  • The counters always add up: every connection is opened, denied or failed. The deploy token says whether the token left, was blocked by vpnw, or had no way out at all.

The Two Panels

  • Run the agent under your own policy. Edit the policy file, choose the direct path or the office exit, and run the agent’s five requests again. Each decision comes from the Alpha’s policy engine; whether a server then answers comes from the recorded demo network. The presets include the learned draft, which lets the token out, and a deny list, which vpnw refuses on the office path because it would weaken deny_private.
  • Test one destination. Ask the engine about any host and port, optionally with what the name resolves to. The examples include the usual tricks: the metadata address in NAT64 form, 127.0.0.1 written as a number, and a DNS answer that points inside the network.

Things to Try

  1. Let it play once. Then compare the table in step 1 with the one in step 3: the same five requests, one of them denied.
  2. Run the learned draft. In the first panel pick “The draft from learn” and run it. The token reaches evil.example, which is why learn’s output is only a draft.
  3. Switch paths. Run the reviewed policy on the direct path, then through the office exit. The ticket step only works through the office.
  4. Break the policy. Type allow = ["*"] and run it. vpnw refuses to start, with the same message its command line prints.
  5. Try the tricks. In the second panel, try 2130706433, 64:ff9b::a9fe:a9fe, or api.github.com resolving to 10.0.0.7.

If It Does Not Start

The demo works in any current Chrome, Edge, Firefox or Safari, on a computer or a phone, with JavaScript switched on. The replay needs nothing else. The two panels need WebAssembly: the engine comes with the page, about 1.1 MB (about 400 KB compressed), and runs inside it. If a panel says the engine could not start, try another browser, or allow scripts on this page if an extension blocks them.

What Is Real Here

Real:

  • Every line in the terminal: recorded from real runs of the Alpha on Linux on September 29, 2026 with the demo kit, vpnw’s lines and the stand-ins’ alike, and replayed exactly.
  • The table under each step: vpnw’s own trace of that run, in its JSON Lines format.
  • The decisions in the two panels and the draft computed in step 2: the Alpha’s Go code (the policy engine, the request plan and learn), compiled to WebAssembly with TinyGo. A test compares the request plan with the running broker in 119 cases, and the browser build gives the same answers as the standard Go build on 471 calls.

Stand-ins:

  • The agent, its poisoned task file, the servers, the office exit, the local service and the attacker. They ran as small Python programs in a private network namespace, at addresses that exist only there.
  • The pace: each run took under a tenth of a second and is replayed slowly enough to read.
  • In the panels, whether a server answers: that comes from the recorded demo network, not a live connection.

The Linux Demo Kit

The same demo runs offline, in about a minute, on a Linux machine that allows unprivileged user namespaces: ./run-demo.sh. So far it has run on one x86-64 test machine. It builds its own private network with the stand-in servers, needs no root and changes nothing on the machine. The kit holds the vpnw binary and the demo, without source code, and is available on request.

Next, in the Beta, real coding agents run under vpnw, with WireGuard, macOS and packages. The roadmap has the plan.