Compilers and AI 'Cyber' Defense

Compilers and AI 'cyber' defense Skip to main content Compilers and AI 'cyber' defense Jul 10, 2026 AI & LLMs I haven’t had time to blog in a while, I have a lot to say, but have been doing a lot of things and so haven’t gotten words down in a while.

One of those things in the past few weeks has been picking back up my Rue project. I’m really excited for what it’s turning into, even though it’s not really ready for anyone else to use just yet. So go take a look if you want, but don’t expect anything amazing, it’s very much a work in progress.

Anyway, one of the things that got me back into working on it is the releases of Fable and Sol. I hadn’t really touched Rue since January, and a lot of things have changed since then. It’s fun to have new models take a look at older projects and see what their new perspectives are.

Unfortunately, due to the intelligence of these new models, the US government has asked for and imposed restrictions. These are largely around things like cybersecurity. Since I don’t do cybersecurity work, I didn’t think they would affect me.

(Aside: I put ‘cyber’ in quotes in the title because I hate that apparently that’s the term folks are using now. Sigh.)

Well:

ⓘ This content can't be shown We take extra caution with cybersecurity requests. If you're a security professional, you may be able to apply for Trusted Access. Trusted Access: https://openai.com/form/enterprise-trusted-access-for-cyber/ Learn more: https://help.openai.com/en/articles/20001326

› please continue

• It is a false positive from the safety layer, not a judgment that you asked for anything malicious. Rue contains fuzzers, crash reproducers, sanitizer hooks, child processes, deliberate out-of-bounds writes, and compiler-panic tests. Those patterns look similar to exploit-development activity when a classifier sees commands or snippets without fully trusting the repository-ownership context.

RUE-560 is an especially likely trigger because the correct regression test deliberately performs a one-byte overflow in an ASan-instrumented child and requires that child to crash. That is defensive testing, but the surface pattern is still “construct an overflow and observe the failure.”

I cannot disable or bypass that layer. I can reduce interruptions by keeping work tightly scoped to this repository, putting negative behavior inside the existing test harness, describing the defensive purpose explicitly, avoiding reusable attack tooling, and checkpointing progress before risky-looking verification. The persistent goal means that if a turn is interrupted, the next continuation can inspect the workspace and resume without needing you. Nothing I’ve found suggests the project or your request is dangerous. It is really unfortunate that, in order to make sure my compiler isn’t going to produce incorrect codegen, this trips the safety guards. I guess that simply saying “hey this is a toy language nobody uses and so it’s fine I’m not hacking anyone” and that not allowing me around the guards is a “good” thing, but at the same time, it is unfortunate if these policies end up making it so that individuals like me can’t make my software as robust as products from large organizations.

I don’t know how to end this post really, just wanted to put that out there. I’m still thinking about the implications, and I hope you do as well.

Here’s my post about this post on BlueSky:

Steve Klabnik @steveklabnik.com Compilers and AI 'cyber' defense

steveklabnik.com/writing/comp... Compilers and AI 'cyber' defense Blog post: Compilers and AI 'cyber' defense by Steve Klabnik steveklabnik.com

July 10, 2026 at 4:16 PM 1 1 View on Bluesky

Compilers and AI 'Cyber' Defense

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

The Anatomy of an AI-Native Org