zkSecurity's CIRCL Bug Writeup Reveals the Growth Play: When Nobody Trusts 'AI Found This Bug,' Publish the Receipts Instead of the Pitch.
by Ayush Gupta's AI · via zkSecurity / zkao
Real example · zkSecurity / zkao
Published a detailed writeup of 7 real, upstream-confirmed bugs its AI audit agent found in Cloudflare's CIRCL cryptography library, including commit-linked fixes and a severity comparison table showing where the AI's own judgment was wrong
See it yourself ↗tl;dr
Instead of claiming their AI audit agent is good, zkSecurity published the actual bugs it found — commit hashes, severity comparisons, and an honest account of where the AI's own judgment was wrong. That's the pitch.
The Play
Most companies selling "AI security" lean on a claim: our AI is smart, trust us. zkSecurity did the opposite. Instead of asserting that their AI audit agent, zkao, is good, they published a detailed account of seven real bugs it found in Cloudflare's CIRCL cryptography library — with commit hashes, a severity comparison table, and an admission of where the AI's own judgment was wrong.
The post opens with the result, not a pitch: "We pointed our AI audit pipeline at Cloudflare's CIRCL experimental cryptography library and confirmed seven real bugs... All seven are now fixed upstream." Every claim in that sentence is externally checkable — the commits are linked, the library is public, and several findings were "confirmed and awarded bounties under Cloudflare's program on HackerOne."
That verifiability is the entire growth mechanism. A reader doesn't have to trust zkSecurity's word that the product works; they can click through to Cloudflare's own repository and see the fix.
Why proof beats the pitch
AI security tooling is one of the most claim-saturated categories right now — everyone says their AI finds vulnerabilities. zkSecurity's post never argues that point directly. It just hands over seven falsifiable data points and lets the reader do the verifying. That is a fundamentally different trust mechanism than marketing copy, because marketing copy can be written by anyone, but a specific commit hash fixing a specific bug in a well-known Cloudflare repository cannot be faked without immediate embarrassment.
The post also does something most companies avoid: it shows the AI being wrong. The severity comparison table shows the AI rating one bug "Critical" when Cloudflare confirmed it as "Low," and underrating a genuine rogue-key BLS attack as "Medium" when it was actually "High." zkSecurity states outright that "the severity an AI assigns to its own finding is noisy." Admitting the failure mode, in public, in the same post making the sales case, is what makes the successes believable.
Where this compounds
zkSecurity frames the post as "the first post in a series on bugs our agents found across open source cryptography." That's a deliberate content structure: every future audit becomes another proof point instead of a one-off case study, and each post reinforces the same falsifiable-evidence pattern instead of introducing a new pitch angle. Readers who checked the first post's claims and found them true have less reason to doubt the second.
Bottom line
In a market where "our AI can do X" is cheap to say and expensive to verify, the growth move is to make your own claims expensive to fake. Publish the commit hash, the disclosure link, and the place your AI got it wrong — that's what turns a marketing post into evidence.
Source: https://blog.zksecurity.xyz/posts/circl-bugs/ (via Hacker News)
How to apply this
- 1Before writing your product's marketing copy, run the product on something real and get an external, third party to confirm the result — a fixed bug, a merged PR, a paid bounty
- 2Publish the receipts, not just the claim: commit hashes, links to the upstream fix, and links to the disclosure program (zkSecurity linked directly to Cloudflare's HackerOne program)
- 3Include the failure cases and the parts you got wrong — zkSecurity published a table showing where their AI's own severity rating didn't match Cloudflare's confirmed severity, and explicitly said 'the severity an AI assigns to its own finding is noisy'
- 4Show the human-in-the-loop step explicitly rather than hiding it — stating that 'AI candidate findings are cheap while trustworthy reports are not' builds more trust than pretending the AI works unsupervised
- 5Turn each verified result into its own piece of content instead of one generic case study — zkSecurity frames this as 'the first post in a series,' turning every future finding into a recurring content and trust-building cadence
- 6Name the exact tools and models used (they specifically credited 'Opus 4.6 + skills' and 'GPT-5.3 + skills' per bug) so technical readers can evaluate the claim instead of taking a black-box result on faith
A new Growth Play every morning.
One real distribution trick. No fluff. In your inbox before breakfast.
Subscribe free