X posts — 2026 (curated)

In the spirit of @gwern's "Writing for LLMs so They Listen", I've mirrored all my X posts on my website: https://tchauvin.com/x/. In addition to LLM discoverability, I've found that looking back over my posts helps me develop my thinking.

I want to take back my "not very consequential" take. I wrote that because the number of exposed secrets was low, and I thought that this couldn't have been used for distillation, because doing so would require sending tens or hundreds of thousands of queries to decrypt the traces, which would surely have been noticed and blocked.

But I would have also assigned a very small probability that AI companies were essentially not monitoring their hacking evaluations for Internet access. I was also certain that at the time of publication, the issue was fully patched, yet traces could apparently still be decrypted on OpenAI until about 2h ago (https://x.com/wunderwuzzi23/status/2087371066020868164)! OpenAI and Anthropic had also been informed of the issue in May and didn't patch it (https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/, https://x.com/matthew_d_green/status/2087165493677293953).

So the attack may be consequential if it was used for distillation. I don't know enough about the evidence, and what is going on in AI companies is sufficiently outside of standard expectations, that I don't have a confident assessment of how likely this could have been.

We are all in the dark and left speculating. I respect AI companies for recently voluntarily disclosing embarrassing failures. The EU AI Office (which has enforcement power since Aug 2nd) could just ask them directly, and publish (maybe anonymized) findings to inform the world. Transparency about failures is an important component of security.

A new paper shows that encryption of chain-of-thought was done really poorly across Anthropic, OpenAI, Google. It's not very consequential, but is another example imo of them going so fast that they fail at basic security stuff.

https://arxiv.org/abs/2608.09867

This isn't too far from what needs to happen though: massive compute dedicated to cyberdefense for all orgs, asap. Like Glasswing, let orgs use the model internally, not as an unannounced pentest. But this raises the question of what to do with the hospitals where the IT employee is anti-AI...

Learning from past mistakes is very important (especially when they are still ongoing). Highly recommend reading.

Excited to read the rest of the sequence.

Under extreme pressure to ship + AI progress, securing codebases is easy (e.g. AI review of each PR), but securing organizations is not on track.

If you look at the recent eval environment escapes, the most striking thing to me is that preventing them would have been very easy (most prominently monitoring the logs). A good example that going too fast can defeat world-class talent and the best intentions.

Slowing down progress seems much better than a pause to me, if possible at all. Do you have thoughts on how this could realistically work?

Some guesses, anything goes:
(1) compute throttling
(2) bureaucracy-type slowdown similar to FDA / nuclear
(3) laws forbidding market release AND internal possession of models that:
(3a) are broadly too good / too good at AI research, increasing the allowed capability ceiling every year
(3b) lack safety properties: good interpretability, not too good at cyberattacks, no neuralese etc. Btw the mandatory 30-day review period of the June 2 EO already incentivizes labs to deliberately kneecap cyberattack capabilities, Opus 5 being a great example of this.

I prefer 3b (adding a bit of "not too good at AI research" but seems hard to define?).

@NeelNanda5 per AI 2040 Plan A:
(4) enforce a cap on the fraction of compute that can be spent on AI R&D
(5) enforce total research transparency, disincentivizing finding algorithmic improvements

In the past, there's been a few cases of "benevolent worms" that hacked into systems in order to patch them. This is illegal, risky, and takes a lot of effort to do right.

2026-2027 will bring an explosion of CVEs, and a vast number of devices will be left unpatched. I wouldn't be too surprised to see benevolent worms taking off in the next few years.

Anthropic isn't revealing Project Glasswing SHA-3 reports anymore. The 135-day responsible disclosure window ends in 22 days. They probably will reveal everything in bulk only at that time.
This probably invalidates Berkeley Vulnerability Initiative's leaderboard.

@corban_villa @ralucaadapopa @daryakaviani what do you think?

The potential of AI for censorship and surveillance are widely discussed (and real). However, privacy-preserving systems and services are bottlenecked primarily on SWE. I hope to see these things flourish and become default digital infrastructure, similar to Signal

With coding capabilities making very fast progress, now is a time to defer coding projects as much as possible, and spend more time on reading, learning, thinking...

see also @gwern emphasizing project proposals as part of a strategy of writing for LLMs. I forget the link

@gwern some coding projects relating to augmenting myself and that i don't intend to defer:
* ai newsletter
* something about turning all the podcasts i listen to into notes and anki cards

When should a frontier-in-cybersecurity model be released to everyone?

Assuming that open-weight models are 6 months behind, I believe that access should be gradually expanded (defenders first, but with an increasingly loose definition) over the course of 6 months.

I think companies should publish the number of orgs and people on the "trusted access" list so we can check we are on track.

I suspect that the current rollout is too slow, and I'm afraid that the June 2 EO, and lack of cyber literacy that resulted in Fable 5 being suspended, will make this way worse.

@logangraham @chrisrohlf @newton_cheng

the fact that 3 months after the start of Project Glasswing, Huggingface (!) had to rely on GLM-5.2 for Incident Response is damning evidence of this. Rollout must be much faster

You can't judge a bug-finding agent only on its recall, false positives must be reported too! Ideally, also report the amount of human labor necessary to tell true positive from false positive.

this is the same criticism I made of an AISLE blog post in April

I'm at ICML 2026 this week in Seoul, hit me up if you'd like to say hi!
I'll be presenting our work "Token-Efficient Change Detection in LLM APIs" in the Wednesday morning poster session, Hall A #3201, along with @clement_lalanne and Erwan Le Merrer.

CyberGym is the least informative of the recent ones. It's close to saturation and much easier than ExploitGym (scores: see below) and ExploitBench (GPT-5.5 34%, GPT‑5.5‑Cyber unreported, Mythos 5 78%). In fact it's so much easier than ExploitBench where Mythos 5 scores 78%, that it's almost certainly saturated at the current level (~85%).

As we wrote about CyberGym in our Epoch AI post "Are Mythos’ cyber capabilities overhyped?" (https://x.com/EpochAIResearch/status/2065181455937056813):

"Successes are only counted if the crash also does not occur on a patched version of the code that is supposed to have addressed the vulnerability. We found approx 5% of the vulnerabilities don’t have specific enough descriptions, and so scale the results to cap at 95% instead of 100%.

We suspect this is insufficient and that the benchmark is essentially saturated, as the prompt is not very clear that models must only use the given vulnerability, and as reported by Anthropic frontier models achieve crashes 95%+ of the time without the restriction of targeting the correct vulnerability."

However I'm confused about OpenAI reporting a score of 26% for GPT-5.5 on ExploitGym: in the ExploitGym blog post, the authors report 120/898 = 13.4% for GPT-5.5. @dawnsongtweets @AlexBarry4 thoughts? Maybe they dropped the constraint of using the given vulnerability?

@joshua_saxe in the most recent GTIG report (May), they document fairly complex pipelines that attackers set up to get access to models like Gemini, which shows how valuable this access is to them. Seeing this practice vanish would be interesting evidence

https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access/

New blog post: "Vulnerabilities and exploits: where are we headed?"

In Are Mythos’ cyber capabilities overhyped?, co-authored with Epoch AI, we looked at the public evidence on how good Mythos Preview was at vulnerability discovery and exploit development. In this post, I consider the implications. For vulnerability discovery: moving from sparse sampling to dense sampling, AI vs fuzzing, long-term defense dominant but bumpy ride in 2026-2027 due to slow patch rollouts; offline vs online exploitation and why both are offense-dominant, except for one defensive use case of exploit development.

I've been thinking more about this idea lately: an "auto mode for scams". I think the need is very real, both in vulnerable people (who won't pay for solutions and are therefore ignored by the market) and companies. Probably what I would do if I started a company today.

I expected deep fake phishing & scamming to come sooner than vulnerability detection, but I was (fortunately) wrong.

You mention "same capability", "Mythos-like hacking", but there's no direct comparison to Mythos. Is this just based on the observation that GPT-5.5 is much better than non-Mythos models?

I'll be at ICLR 2026 (Rio de Janeiro) next week, let me know if you'd like to say hi!

Your points are valid about the prominent claim of "can detect previously known vulns". But the important result from the blog post is that cheap models can detect vulns without an overwhelming number of true positives. And for this, focusing on only a few CWEs is fine.

I didn't like the first blog post because it ignored the issue of false positives. But after reading this one, I now believe that there's something real and interesting here. The important takeaway is that they were apparently able to detect real bugs and possibly vulns without drawning in false positives.

Some people are commenting that the few-shot examples specifically prompt for the kinds of vulnerabilities we are looking for. It is indeed an issue for the blog post's prominent claims that the models can find some known vulnerabilities. But it's not an issue for the other result (more important and less emphasized) that false positives can be manageable. It's fine to only focus on a subset of vulnerabilities: that's also what fuzzers, SAST, etc do!

There aren't that many important CWEs for C/C++ code, so I think it's fine to focus on those only. This would be bad if the goal was to catch all vulns, but the goal is to catch true vulns without an overwhelming number of false positives. I think the blog post does a much better job demonstrating this than the previous one, and I now believe there is something real and interesting here.

I switched to coding on a server I own (capable laptop) and highly recommend it:

1) coding agents can run 24/7, always connected to the Internet. perfect for travel
2) mitigation against supply chain attacks and the risks of the occasional --yolo or --dangerously-skip-permissions run
3) initial setup is easy with coding agents...
4) ... including good security defaults (firewall, tunneling ssh through wireguard so the server doesn't have any open port on the Internet...)
5) requiring Internet access to code would have been a downside in the past but isn't one anymore

I asked claude to log everything we did as we were going through the setup, and to create an ansible playbook out of it at the end. So future installs on new machines should be much faster

The biggest flaw in the AISLE blogpost is that vulnerability detection with LLMs is all about false positives. They should have reported on applying the same technique on all snippets of FreeBSD and how much human time was needed to dismiss the at least thousands of false positives.

(the blog post's section on false positives studies *one* cherry-picked, synthetic, very out-of-distribution example, to support the false conclusion of "inverse scaling"...)

Hmm I'd say:
- reduce the attack surface: uninstall unnecessary browser extensions, IDE extensions, etc. Minimize interactions with shady parts of the Internet
- password manager
- keep software more up-to-date than usual
- MFA I guess?

I think it's a good policy to act as if everything you write down on a computer will be leaked some day. (I already had that policy before)

But if you're not the type of person who believes phishing emails, and don't have many Internet-exposed servers, you're already in a good place I'd say

I was planning to write a blog post titled "Stay away from the Internet in 2026". The period of turmoil will be this year, perhaps next year too. Then it'll get better I think.

New research: cheaply detecting changes in LLM APIs.

We published two papers on the topic:
- Log Probability Tracking of LLM APIs (ICLR 2026)
- Token-Efficient Change Detection in LLM APIs

Both papers request a single token of output from APIs, enabling unprecedently cheap monitoring.

I'm interested in UIs + models that have minimal latency, please share suggestions!

The latency of LLMs is annoying when you use them often.

I tested a few LLMs, plus google search, on a simple question: "how do i reverse a string in python?". Results, from fastest to slowest:
- Google search, featured snippet: 1.5s
- the default Mistral model on http://chat.mistral.ai, logged out: 4.4s. Congratulations to the Mistral team!
- Google search + stack overflow: 5.2s
- Gemini 3 Fast on http://gemini.google.com (Pro plan): 6s
- Claude Haiku 4.5 on http://claude.ai (Pro plan): 10.4s
- Claude Opus 4.5 on http://claude.ai (Pro plan): 12.3s
- Gemini 3 Pro on http://gemini.google.com (Pro plan): 14.3s

Claude models on http://claude.ai take a hit from an annoying bug where they reload the page after the initial load, making me lose the cursor and forcing me to use the mouse, as you can see in the video. @AnthropicAI @claudeai please fix

Link to the video on youtube: https://www.youtube.com/watch?v=ftRZMIlATac