v2.0 is shipped. What changed.

We tagged v2.0 today. The build is signed, notarized, stapled, and shipped from the same commit that has been running on my machine for three weeks. 249 of 249 tests green. Soak test ran four detection models in parallel for the duration without a crash, a memory leak, or a chain integrity failure. The DMG is byte-identical across rebuilds.

That last sentence is the one that matters. Most of the rest of this post explains why.

v1 was a demo. v2 is a product.

v1.0 shipped on April 4, 2026, the same date as this post one year prior in our planning calendar. It was 176 tests, end-to-end detection on live ChatGPT and Claude.ai, a Chrome extension with programmatic injection, agency score 0.5 on the transfer test, Stripe live, $23 of MRR, and a notarized DMG. It worked. It was the version that proved the architecture was not vapor.

But v1 was the version where we still had to explain things to ourselves. The five planes were there in the design doc. They were not yet there in the code. The detection ensemble had two models running, two more in development. The defense layer was a single Execution Gate, no Memory Integrity, no Capability Decay. The audit trail was VOAF v0, not yet versioned for the open spec. v1 was the version we used to convince ourselves the architecture was real.

v2 is the version we are willing to put in front of an enterprise security review.

Anyone can ship a demo. Shipping a product means shipping the build pipeline that produces the demo, identically, every time.

The five-plane architecture is now actually five planes

In v1, the planes were a diagram. In v2, they are eleven crates with a strict no-cross-imports rule, all inter-plane traffic crossing the event bus in vigil-core. You can pick any plane out of the codebase, read its public interface, and verify that it cannot reach into another plane's internals.

The planes are Identity, Intercept, Analysis, Policy, and Vault.

Identity holds the authority chain. TAP attestation lives here. VARP revocation lives here. The plane has no knowledge of what is being intercepted or how it is analyzed. It only knows who is allowed to act for whom, and how to revoke that authority across surfaces.

Intercept is the TLS proxy and the Chrome extension. Two entry points. Same internal API. The plane has no knowledge of the policy rules. It captures, normalizes, and emits.

Analysis is the four-model detection ensemble plus the decomposition layer. Statistical only. No enforcement primitives. The plane emits scores and signals. It does not make decisions.

Policy is the deterministic rule engine and the Execution Gate. Decisions live here. No LLMs. No statistical models. The plane reads signals from Analysis and produces enforcement actions.

Vault is the cryptographic audit trail and the local archive. VOAF chain construction lives here. The plane writes; nothing else writes to the chain.

This separation is not aesthetic. It is the audit boundary. An enterprise reviewer can verify that the security-critical paths in Policy never call into the statistical models in Analysis. The architecture is the proof.

The detection ensemble is now four models

v1 had two models running and two in implementation. v2 has all four operational and validated under load.

• Isolation Forest for outlier detection on per-request feature vectors.
• LSTM for sequential pattern recognition across session windows. 222 observations to warm.
• Bayesian for posterior updates on user-specific baselines. 222 observations to warm.
• Multi-Window CUSUM for change-point detection on rolling windows.

The ensemble is not democratic. Each model handles a class of attack the others miss. The Isolation Forest catches single-request anomalies. The LSTM catches multi-turn drift, which is how every agent compromise we have studied actually unfolds. The Bayesian model catches deviation from the user's own baseline, which is how we get the false positive rate down. The CUSUM catches the regime shift that signals a session has been hijacked.

I will write the ensemble post separately. The short version is that no single model handles all attack classes, and any defense product that ships with one model is either underclaiming or wrong.

The defense layer started shipping

v1 had the Execution Gate. That is a real primitive: actions hold pre-execution until classified, latency budget under 50ms for the prevention path. But Execution Gate alone is not a defense layer. It is one piece of a defense layer.

v2 includes Memory Integrity and Capability Decay. Memory Integrity protects long-running agent context against poisoning by external document ingestion. Capability Decay revokes elevated capabilities after a configurable window, so an agent that was authorized to act ten minutes ago does not retain that authorization forever in the absence of a fresh attestation.

Phase 2 of the defense layer (still on a branch) adds three more primitives. Phase 3 adds the rest. The point of a defense layer is that no single primitive carries the load. Every published agent attack we have studied bypassed at least one defense in isolation. The only architecture that survives is the one with overlapping primitives.

The build is reproducible

v1 was signed and notarized. v2 is signed, notarized, and byte-identical across rebuilds.

If you build v2.0 from the tagged commit on a clean machine with the pinned toolchain, you will get a binary whose SHA-256 matches the binary we signed. We can publish the hash. Any third party can verify the binary they downloaded matches the source we published. There is nowhere for a backdoor to hide that does not also break the hash.

This is the discipline that distinguishes security software from software that has security in the name. The provider that cannot reproduce its own build is asking you to trust the build server, the CI pipeline, the developer's laptop, and every dependency in the supply chain. Reproducibility removes most of those from the trust path.

It costs us hours per release. It is not optional.

What is not in v2

The dashboard rebuild to the three-tab spec. The MIRROR feature. The Personal Model layer. Vigil Vault as a standalone product. Windows port. Mobile companion. VOAF-M training-data export.

None of those are abandoned. All of them are sequenced. Vigil_Master_Build_Order.md has the order. v2 was about getting the foundation to a state where the rest of the work does not require renegotiating the architecture every time we ship a feature.

What this means for users

If you are running v1, the auto-update will move you to v2 on next launch. Your VOAF chain remains valid. Your config migrates. Your subscription does not change.

If you are an enterprise prospect waiting on a security review, this is the version. The architecture is documented. The build is reproducible. The audit trail is verifiable by an independent tool. You can have your security team read the code and the spec in a weekend.

If you are a regulator or a researcher and you want to evaluate the system, vigil-verify is open source and the VOAF spec is published. You do not need to install anything to confirm the audit format holds.

If you are a competitor, the gap closes only when you ship reproducible builds, structural separation between detection and enforcement, and an open audit format that does not depend on your continued operation. We have shipped all three. The bar is now publicly set.

Thanks

To the team. To the design partners who ran v1 long enough to surface the failure modes that v2 fixed. To the people in the Singapore building community who have made this venture possible. To the Anthropic, OpenAI, and Google researchers who have been quietly helpful while we figured out the parts of the threat surface they could not publicly comment on.

v3 is already in design. We will publish that timeline separately.

The build is at runvigil.ai. The hash is in the release notes. Verify it.