Alpha Demo on VPN Works

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.