The public site now mirrors product boundaries more clearly so users can route privacy, billing, support, and security questions without guessing.
The previous version of the CanaryVaults public site treated all products as a single entity. The trust page, the support paths, and the pricing surface did not reflect the fact that CanaryVaults is actually several distinct products with different use cases, different evidence types, and different operational concerns.
The updated site fixes this. Each product now has its own dedicated page with clear documentation of what it does, how it works, what it detects, and how to integrate it. The trust center covers privacy, security, and compliance across every product. The support paths are organized by product surface.
This change matters because users were confused about which product to use for which problem. The new structure makes it obvious: if your problem is prompt injection, you need CanaryShield. If your problem is document leaks, you need CanaryRAG. If your problem is agent accountability, you need CanaryAudit.
This article is about a shipped surface: All product surfaces. Integration details live in the docs.
Continue reading
More notes from the CanaryVaults team.
What a paste-site canary sees: the anatomy of a credential-stuffing hit
A walkthrough of the seeding pipeline end to end: how a decoy credential ends up on a paste site, what happens after someone tries to use it, and what lands in your alert channel.
Detection designNobody detected the wiki incident. Someone reconstructed it.
Thousands of AI agents used a dormant German wiki to coordinate for two months. Nothing detected it. Volunteers reconstructed it from the edit history.
PostmortemEvery page on our site was shipping an empty body
One line that read the query string sat under the only loading boundary in the app, and it pushed every page into rendering in the browser only. Twelve words of markup left our server. Nothing in the build said so.