Verify it yourself
Download a real, signed Vloex audit bundle and re-derive the chain offline with the verifier we ship inside it. Keys are resolved from a public JWKS; roots are signed checkpoints you can archive yourself. Signed events from both surfaces — the coding-agent gateway and the browser extension — form one Merkle chain an auditor can rebuild without an account and without trusting us. Change a single byte and the proof breaks.
Real export · 12 signed events across the coding-agent gateway AND the browser extension · single-file verifier, one dependency (cryptography)
Run it yourself
The verifier is one auditable Python file with a single dependency (pip install cryptography). Read it before you run it if you like — it's in the zip as vloex-verify.py.
$ unzip vloex-audit-sample.zip -d vloex-sample $ cd vloex-sample $ pip install cryptography $ python vloex-verify.py . --jwks jwks.json $ echo $? 0
That output is the real report from the committed bundle, not marketing copy: the checkpoint's Ed25519 signature verifies against the key set, the device-key manifest (keys.jws) verifies against the log key, all 12 per-event device signatures verify offline, and every leaf walks its Merkle proof to the signed root. Exit 0 means full independent verification.
# flip a single hex digit of any payload_hash in events.jsonl, then: $ python vloex-verify.py . --jwks jwks.json FAIL(device_sig): event 0d0ce3b8-149b-4faa-a3d4-f15da181079a v2 device signature does not verify (mismatch) FAIL(leaf): leaf re-derivation MISMATCH for event 0d0ce3b8-149b-4faa-a3d4-f15da181079a — payload_hash / key_id / signature bytes were altered RESULT: FAIL — 2 check(s) failed (device_sig, leaf) $ echo $? 1
Three different links in the chain, three distinct failure modes: alter a payload_hash in events.jsonl → FAIL(leaf); change one character inside keys.jws → FAIL(manifest_sig); edit a root line in checkpoints.txt → FAIL(checkpoint_sig). The verifier names the broken link and exits non-zero. There is no byte you can change that still verifies.
Trust anchors
Keys are resolved from a public JWKS; roots are signed checkpoints you can archive yourself. Every bundle's trust.json says where both live.
https://api.vloex.com/.well-known/jwks.json
The deployment's log key signs every checkpoint and the device-key manifest. Once published, a key is never removed from the JWKS, so old checkpoints keep verifying forever. This demo bundle mints fresh sample keys each time it is regenerated, so its key set ships in-bundle (jwks.json) — a customer bundle's trust.json points at the live public URL instead.
Origin, day + sequence, the Merkle root, the previous root (prev chains days together), the leaf count, and a keys line that pins the exact device-key manifest — then an Ed25519 signature over the verbatim body. Anyone holding a copy of this note can later prove the history it commits to was never rewritten.
$ curl -fsS https://api.vloex.com/.well-known/jwks.json -o jwks.json $ python vloex-verify.py vloex-audit-sample.zip --jwks https://api.vloex.com/.well-known/jwks.json
On a customer bundle, the verifying key material comes from the public JWKS URL in its trust.json — not from the bundle, not from a dashboard session. Add --checkpoint-cross-check to byte-compare the bundle's checkpoints against the live public log.
Honest limit: a log-key signature proves a checkpoint came from this deployment — it does not prove history was never re-signed. What prevents rewrite is checkpoint copies outside Vloex's reach: your S3 Object-Lock bucket, any archived copy of the public checkpoint URL, and this witness kit — a ~20-line GitHub Action you commit to your own repository. Daily, it fetches your public checkpoint, verifies the note signature against the pinned JWKS, and commits it. One honestly-archived checkpoint transitively pins all prior history and the key registry.
What just happened
Each event becomes a signed leaf hash.
The device signs the event's payload hash with a private key that never leaves it. The bundle ships the hash, the key id, and the signature — not the prompt text. The verifier checks the device signature against the signed key manifest and re-hashes those fields into the exact leaf the backend recorded.
Leaves fold into one Merkle root.
Every leaf for the day is combined pairwise (RFC 6962) into a single root. The bundle includes each event's sibling path, so the verifier walks any leaf up to the root on its own.
The root is published as a signed checkpoint.
The deployment's log key signs a plain-text checkpoint note over the root, the previous root, and a hash pinning the device-key registry. The verifying keys resolve from a public JWKS — the backend holds only public device keys, so it cannot forge a device signature.
Copies you keep make it rewrite-proof.
A log-key signature proves origin, not that history was never re-signed. Rewrite protection comes from checkpoint copies outside Vloex's reach — your Object-Lock bucket, an archived public URL, a witness repo. One archived checkpoint pins everything before it.
What's in the bundle
Gateway — in the signed chain
9 events
Coding-agent gateway events — Claude Code and Cursor calling MCP tools, some blocked at the choke point. Signed per-event at the proxy with Ed25519, folded into the Merkle root.
Browser — in the signed chain
3 events
Browser AI sessions (ChatGPT, Claude.ai, Gemini). Signed in the Chrome MV3 service worker with ECDSA-P256 — the same canonicalize contract as the gateway — and verified + anchored into the same Merkle root.
What we do NOT claim. Not “every event, everywhere, is signed.” Device-signing is live on both the coding-agent gateway and the browser extension, and the backend verifies + anchors either the same way — but shadow-AI / OAuth-discovery events from workspace connectors are captured and governed without device signatures, and an unenrolled or WebCrypto-less browser degrades gracefully to unsigned. The verifier transparently skips any such row (there are none in this sample). Events recorded before signature v2 are labeled v1 legacy: signature-verified at ingest, but NOT independently verifiable offline — the verifier says so instead of pretending. And the bundle ships only hashes of each event, never the prompt or response text — contents are encrypted at rest, so the chain proves integrity over the hash, not the text; binding a hash to the original text is only possible for a party holding the original content (e.g. your SIEM export). No SOC 2 claim here; this page is about one thing: math you can re-run yourself.
This is the record your auditor gets to keep — verifiable without us in the room. See how the gateway blocks a leak before it happens.