Ledger
Ledger is the fourth engine of VPN Works. It keeps a record of every connection that can’t be changed without it showing. Consumer VPNs promise to keep no logs. A company running AI agents needs the opposite: after an incident or in an audit, “where did this agent send data?” needs an answer people believe, and an ordinary log file can be edited by anyone who can reach it.
VPN Works keeps network access narrow and on the record. The Agent gives each AI agent a network of its own. Scope gives each person on a company VPN only the systems they use. Lab checks that VPN apps keep traffic inside the tunnel when things go wrong. Ledger makes every record tamper-evident. Exit checks the policy again at the far end.
Ledger seals a log as it is. The records stay in their own file, one to a line, untouched. A second file next to it, the ledger, holds a hash for every line and, at intervals, a checkpoint signed with Ed25519. From then on, if a line is changed, deleted, inserted or moved, or the end is cut off, the check names the line. Anyone with the public key can check the whole log offline, or check that one connection is in it without seeing the others.
Ledger 0.1.0 is an Alpha: a working engine, tested on one Linux machine. It has sealed a real trace of the Agent and real flows from Scope’s recorder as they were written, and generated logs of a million records. No auditor has used it yet.

Try It
The demo below is the Agent’s recorded run from its own demo: a coding agent whose task file told it to send a deploy token to evil.example, and which did. The page seals that record with a key it makes in your browser. Then try to hide the connection. Change a byte, delete a line or swap two, and the check names the line. The page runs Ledger’s own Go code, compiled to WebAssembly, and the key never leaves your browser.
The demo has more room on its own: open it full screen.
What the Demo Shows
| Step | What happens |
|---|---|
| The record | The 28 events of a run recorded on September 29, 2026. Lines 22 to 26 are the connection to evil.example, which sent 865 bytes |
| Seal it | A key made in the page, and the record sealed with a checkpoint every 8 records: 4 checkpoints, and the text the last one signs |
| Change it | Change a byte, delete a line or swap two, and the check names line 25. Delete the whole connection or cut off the end, and it names line 22 |
| Every kind of change | The twelve cases of the tamper matrix, all caught at the lines the tests expect |
| Prove one connection | A proof of line 25: 4 hashes in 1,087 bytes, checked with the public key alone. A changed record, or another key, fails |
| Cut at a checkpoint | Both files cut back to checkpoint 3 check out on their own. Checkpoint 4, kept elsewhere as a witness, catches the cut |
The sealed record case study walks through it step by step.
How It Works
- Two files. The records stay in their own JSON Lines file, exactly as they were written. Ledger writes the ledger next to it, also JSON Lines and readable by eye.
- Hashes. Each record gets a SHA-256 hash, the hashes form a Merkle tree as in RFC 6962, and a chain links each record to everything before it.
- Checkpoints. Every 1,000 records by default, and at the end of every seal, Ledger signs the tree’s root, the chain and the hash of the checkpoint before with Ed25519. None can be dropped, replayed or moved without the check seeing it.
- Verify. It recomputes everything from the records and the public key, and names the first bad line with what happened to it: changed, deleted, inserted, swapped or moved.
- Proofs. A small file shows that one record is in the log, and the public key is all it takes to check it. At a million records a proof holds 20 hashes.
- Follow. Ledger can seal a log while it grows, like
tail -f, so an agent’s trace is sealed as it is written. - Witnesses. Seal prints every checkpoint it signs. A copy kept elsewhere, such as a remote system log, catches a log cut back to an earlier checkpoint, the one change the two files can’t show on their own.
What Was Measured
| Figure | What it means |
|---|---|
| 12 of 12 | Ways of changing a sealed log, each one named by the check at the exact line the tests expect |
| 32 of 32 | Deliberately planted bugs caught by the tests |
| 640,120 and 982,065 | Records sealed per second, for a million Agent events and for a million Scope flows. Verifying them ran at 646,182 and 814,813 a second |
| 2,215 bytes | A proof that one record is in a log of a million records, the record included |
| 1,280 | Lines of Ledger’s own Go that verify and check-proof run, file formats included, besides the configuration reader the engines share: what an auditor would read |
All figures come from one machine with two CPUs, Linux 6.18 on x86-64. Ledger is written in Go with the standard library only, and its Linux program is 2.7 MB.
Limits
- The key. Whoever holds the private key can sign a new history. It should belong to an account the agent doesn’t run as, and witnesses limit the damage to checkpoints not yet sent out.
- Witnesses by hand. Any file of checkpoint lines works as a witness, but Ledger has no built-in way to send checkpoints out yet.
- Keys are files on the sealing machine. No hardware keys, rotation or revocation yet.
- Size. The ledger adds about 87 bytes a record, and verify holds every hash in memory: it peaked at 156 MB to 163 MB for a million records. A million records is the largest log measured.
- Rotation and crashes. Log rotation isn’t followed, and after a crash in the middle of a write the ledger has to be cut back to its last checkpoint by hand.
The Code
VPN Works is open source under the Apache License 2.0. Copyright VPNW.com 2026. The code is at https://github.com/VPNWorks/vpnw. The Ledger Alpha report has every test and figure, and the commands that reproduce them.
What Comes Next
Sealing built into vpnw and vpnw-scope as they write, a way to send checkpoints to a witness with consistency proofs, key rotation and revocation, recovery after a crash mid-write, and a verifier that streams very large logs. Then a pilot, where a team seals its agents’ records for some weeks and an auditor checks them. The roadmap has the plan for every engine. Teams who would like to try it on their own agents’ records are welcome to write.