Blog — AI security insights
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 in the moments after someone tries to use it, and what lands in your alert channel.
Product thinking and operating lessons
Short writing on AI security decisions, release changes, and what the team is learning while building the platform.
Every page on our site was shipping an empty body
One call to useSearchParams() sat inside the root layout's only Suspense boundary, and deopted the entire application to client-side rendering. Twelve words of markup left our server. Nothing in the build said so.
EngineeringIt worked, it said so, and nothing happened
A contact form returned 201 and showed a green confirmation every time. Nobody was ever notified. We went looking for more of these and found about thirty, all with the same shape.
PostmortemWe were selling a proof that had never run
Several pages described CanaryAudit records as anchored on-chain. Not one record ever had been, and the code that would have done it was not in the deployed image. Here is what happened, and what we decided instead.
OperationsYour alert email probably has one leg holding it up
We read our own DMARC report properly and found every message passing on a single mechanism. If that one DNS record ever breaks, every alert we send lands silently in spam.
OperationsWe audited our own documentation against the source
Five parallel passes read every page under /docs and checked each concrete claim against the code that implements it. A third of the load-bearing ones were wrong, and every error ran in the same direction.
PostmortemOur security address had no mailbox
We published a security contact in a dozen places and nothing was behind any of them. Nothing was broken, either — every individual step had been done correctly, into a void.
Launch notesIntroducing enterprise inquiries — the honest version
The pricing page now has an Enterprise column. Here is exactly what it buys, what it doesn't, and what happens when you email us — written plainly, because the audience for this plan can smell filler.
Alert designWhy AI security alerts need evidence attached from the start
A useful security alert does more than say that something suspicious happened. It explains what fired, which surface was involved, and what proof is available before the incident review even begins.
Product thinkingWhy prompt injection needs its own firewall
Prompt safety breaks when it is treated like generic moderation. Inspection has to sit before execution, not after.
Leak detectionProof beats suspicion when private documents leak through AI
CanaryRAG is designed around planted facts and reproducible signals so operators can distinguish real leakage from vague answer drift.
Agent accountabilityAudit trails matter when AI agents can take action
If an agent writes files, calls APIs, or changes customer state, you need a record that survives dispute resolution and compliance review.
Detection designA believable decoy teaches you more than a blocked request
Honeypots are useful because they observe attacker behavior directly. The quality of the trap determines the quality of the signal.
OperationsOne platform, six product surfaces, fewer blind spots
Why CanaryVaults keeps modules distinct while still sharing auth, routing, and alerting across the full platform.
Launch notesWhat changed in the new trust and support surface
The public site now mirrors product boundaries more clearly so users can route privacy, billing, support, and security questions without guessing.
What the team is writing about
Each topic maps directly to a product surface or operating area inside CanaryVaults.