Not all all, the distance is in whatever layer’s activation space you are, where ±middle layers work the best. It’s also not e.g. L2, because we were using a “learned” covariance matrix and getting something like a Mahalanobis distance.
Stanislav Fort
Karma: 482
Interesting! I used a similar technique for a very particular application, namely detecting harmful inputs into LLMs in Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback Section 5.4 (Applying Out-of-Distribution Detection to Reject Strange or Harmful Requests).
Quick thought: I wonder if you could still be overestimating parameter counts for models that would be made by distilling a larger teacher down to a smaller student. Any OSS ones you could test this hypothesis on?
Thanks for flagging this, Rasool. I’ve been following the Anthropic announcement closely. It’s genuinely exciting to see a frontier lab validate that AI can find real vulnerabilities in real software at scale. The more serious players in this space, the better, since it is a genuinely large problem ⇒ far larger than any single team.
We’ve been doing this work operationally since mid/late-2025, and our experience has been that the hardest part isn’t finding some bugs but rather the hardest bugs in the most audited codebases. Earning the trust of maintainers and closing the full loop from discovery through patch acceptance is also very challenging. That’s where most of the difficulty (and most of the value) lives.
I wrote up a practitioner’s perspective on what we’ve learned, how our results compare, and what the real challenges ahead look like from our vantage point: What AI Security Research Looks Like When It Works
i don’t know for sure that there is zero “formal methods” in the pipeline
in discovering the 12 OpenSSL zero-day vulnerabilities, we haven’t used any formal methods. since then, we incorporated some. the (discovery --> CVE assigned --> CVE made public) pipeline is a very lagging indicator and the OpenSSL results are reflective of the state of the AISLE system approximately mid-fall 2025, prior to our use of formal methods
Short answer: these aren’t Heartbleed-class, but they’re absolutely worth patching.
Two signals: (i) OpenSSL itself minted CVEs for them. This is non-trivial given its conservative posture, and (ii) fixes were backported across supported branches (3.5.4 / 3.4.3 / 3.3.5 / 3.2.6, with distro backports).
For context, per OpenSSL’s own vulnerability index as of today (3 Nov 2025), there were 4 CVEs in 2025 YTD (CVE-2025-), 9 in 2024 (CVE-2024-), 18 in 2023 (CVE-2023-), 15 in 2022 (CVE-2022-). Getting any CVE there is hard. “Low/Medium” here mostly reflects narrow preconditions and prevalence within typical OpenSSL usage, not that the primitives themselves are trivial. The score (called CVSS) compresses likelihood and impact into one scalar.
Appreciate the pushback and your perspective. Two anchoring facts:
-
OpenSSL minted and published these CVEs (not us). They’re very conservative. Getting any CVE through their process is non-trivial. In 2025 we reported several issues. Some received CVEs, others were fixed without CVEs, which is normal under OpenSSL’s security posture.
-
On your “AI vs human experts” point: the findings came from a fully autonomous analysis pipeline. We then manually verified and coordinated disclosure with maintainers. The takeaway: our stack surfaced previously unknown, CVE-worthy bugs in OpenSSL’s hardened codebase. That’s hard to do by hand at scale.
-
I think you might be conflating AISLE’s toy experiments with tiny models vs our actual zero-day detection performance on some of the most hardened codebases out there (e.g. curl, FreeBSD, OpenSSL). On publicly available zero-day discovery evidence, AISLE matches and sometimes even surpasses Mythos. I compiled some of the CVE-level evidence here: https://stanislavfort.substack.com/p/mythos-at-home-and-its-called-aisle