How are these reports verified to be valid? If there are too many some could be hallucinations too.
At least, that’s what most of the high-visibility users in Project Glasswing are doing.
There are bad apples everywhere, and this initiative is no exception.
If it makes you feel any better, many of us regularly meet to stay calibrated and hold each other accountable, so I’m confident in the quality of the work produced by this particular group of employees across some of the partner companies mentioned in the article.
That said, I know several people who blindly report everything Mythos finds, which is foolish, especially since the harness is a critical part of the project's quality metrics. Some of the harnesses I’ve tested are quite weak, which leads to poor results.
For example, yesterday morning I was pulled into an ad hoc meeting where a CVP was grilling me about several supposedly critical bugs that my team had reported against one of the core components of iCloud. I was genuinely surprised because we’re very strict about validation. We often even downgrade the severity of bugs when our harness can’t prove what Mythos found. After reading the reports, I realized they weren’t ours. They came from another team that had recently been given access to Mythos. They built their own harness and were using different vulnerability criteria. Fortunately, they had only started earlier this week, so I was able to stop that work.
That incident showed that not everyone involved in Project Glasswing follows the same standards. Most people do their best, but priorities differ, so it’s expected that you’ll find a few bad apples.
I wish AI labs would stop the theatrics and release their models without restrictions, but I also recognize that’s not the world we live in. For every person who wants to use these technologies for good, there are many others who would use them for harm.
In any case, while I agree that some experiments contain genuine noise, the CVE count is real.
>That incident showed that not everyone involved in Project Glasswing follows the same standards.
It genuinely felt like the aladin scene in The Dictator reading this comment.
> Its very hard to understand what you're saying with the comment
Yes, fair enough. I’m simply trying to shed some light on what goes on behind the scenes without disclosing too much information to avoid breaching the NDA(s) that all Project Glasswing users have signed. There’s a lot of speculation about the usefulness of Mythos as a security tool, so much so that even the US government got involved. Honestly, it’s so absurd that I can’t even express it in words. I thought that sharing a bit about how frustrating it is to work within this project, trying to secure software that literally millions of people around the planet use on a daily basis, while virtually everyone outside of it criticizes every move you make, would be helpful.
Many people I work with recognize the power of Mythos, just like any other model with a similar number of parameters, but most of the people I interact with agree that it’s not the ultimate panacea. I believe that it’s just vocal minorities scaring everyone into thinking that the model is some kind of cybernetic weapon.
And I didn’t even have to deal with a jumpy national government.
Wait, you guys had a RCE in Claude Code for nearly a year and didn't even release a disclosure about it and secretly patched it and swept it under the rug?
Well... It's okay, I still trust you."
So in your opinion, what would be the best off the shelf options? And secondly, how much better you’d say a purpose built one is compared to a general purpose one with a good system prompt?
Or it functionally does not exist.
(No, long hashes with an equally mythic promise of reproducibility don’t count)
This gives Anthropic a staggering amount of power. Oh it came from Mythos? We will just lose time trying to analyze it, better apply the fix ASAP
Do people maintaining serious software do this, though?
The actual, underlying problem is that software is buggy and current programming languages aren't fit for writing reliable software. There's a wide gap between the state of art in formal verification, and what is actually practiced in the industry. It's because of this general unreliability that AI has a large supply of vulnerabilities to find. The situation will only get better if software becomes reliable and written in solid foundations.
My guess is that AI will be even more useful to verify software (something like, write Lean or Coq proofs that the software is not vulnerable, things like that), rather than finding vulnerabilities piecemeal but still letting software be written in unsuitable languages, with no formal verification to prevent bugs from sneaking through.
To make it worse? AI and even Fable can make things +50% and then -50% in different places. You can trade 1 bug for another.
So just "rubber stamp" doesn't make it better.
In theory, this should be very straightforward to prove correct with many of the current tools. In practice, no one has shown us how to do it. We could even rewrite the code from a macro/#include maze to proper function calls if that's a prerequisite for analysis. At this point, I would even take a one-off analysis.