The National Academies Launders Mythos: “Implications of AI for Cybersecurity”

In April “The Boy That Cried Mythos” caught Anthropic collapsing its own credibility. In June “Mythos dressed up in a coat, should be called Opus with a moat” caught it again.

Anthropic wants to play God, feed on claims only they can verify, which is to say it feeds beliefs based on lies. If that sounds harsh, think about how the God of cycling Lance Armstrong treated anyone who suggested he was doping. He sure got a lot of medals for “livewrong“.

Source: Flickr

Now the Mythos lies have spilled their way into a venue claiming to use a formal review process. A new National Academies document (NASEM) freshly launders vendor marketing without any explanation.

National Academies of Sciences, Engineering, and Medicine. 2026. Implications of AI for Cybersecurity: A Rapid Expert Consultation. Washington, DC: The National Academies Press.

This should help clarify, for those who are wondering if we are dealing with a Lance Armstrong of LLMs.

NASEM Laundry (June 2026) Prior Evidence
Figure 1 plots Mythos at 83.1% on CyberGym as settled capability, sourced to “Wang et al. 2025” The 83.1% has been repeatedly proven false. It’s a self-reported number by Anthropic. AISLE proved detection reproduced in 8 of 8 open-weight models, even at $0.11 per million tokens, Cisco proved outcome is model-independent
Restricted Glasswing access presented as responsible handling of uniquely capable model The danger warnings are self-serving FUD marketing. Model uniqueness repeatedly disproven. Mythos emailed out of its sandbox only after being instructed to try, showed no sign of altering its weights, and Opus 4.6 finds the same or better flaws
Vulnerability discovery framed as a breakthrough enabling novel risk The flagship FreeBSD CVE-2026-4747 is a 2007 patch in training data, opposite of novel. It was a curated recovery from a backlog of delayed fixes, which any model does.
Benchmark score offered as capability evidence Of 23,019 reported findings, 1,752 were human-checked and 75 had fixes shown. The 90.6% accuracy applies to humans doing the work, not the machine output
Concedes open models approach frontier, advantage short-lived GLM 5.1 reproduced findings on the IronCurtain harness, and clearbluejar recovered CVE-2026-4747 on two open-weight models on a single consumer GPU. Discovery is provable as an orchestration problem, making the frontier-model unnecessary.
Expansion to roughly 150 organizations across more than 15 countries, including NATO and ENISA, read as demand Manufactured scarcity is a vendor marketing trick. The June 2 expansion followed a June 1 confidential IPO filing near a one-trillion-dollar valuation, committing access and capital ahead of the promised verification, and several trialing firms are Anthropic investors
Field evidence in the figure The curl maintainers reported no change to their workflow, and Mozilla’s headline of 271 Firefox vulnerabilities reconciles to just three versus the advisory
Mythos claims rest on anthropic.com/glasswing, the FT relay, and a benchmark the cited authors never ran on Mythos No reproduction steps accompanied the launch blog, the system card, or the Glasswing update, and a result validated only against the system that produced it is not independent confirmation
Published June 2026, capability stated as established Anthropic’s own promised report is due around July 6, 2026, and the prudent posture is to treat the unproven vendor capability as unproven

Still No Evidence Mythos Better at Security Than Self-hosted LLMs

Anthropic allegedly built Mythos so good at finding vulnerabilities that it was too dangerous to release. Then it was handed to only a few dozen very wealthy organizations under Project Glasswing. One of them ran it against curl and sent the project a report claiming five confirmed security vulnerabilities. The curl security team dug in. Three were false positives flagging behavior already documented in the API docs. The fourth was just a bug. One survived: a low-severity CVE shipping with 8.21.0. The most dangerous code-analysis model in the world, pointed at one of the most audited C codebases in existence, found… a single low.

Whomp whomp, sad trombone for Mythos.

The project lead publicly wrote that the Mythos hype was primarily marketing, given no evidence Mythos finds issues to a higher or more advanced degree than tools that came before it. He also said he is not anti-AI-SAST. He reiterated that AI-powered code analyzers are significantly better at finding flaws than traditional analyzers ever were.

I agree with all of that 100%.

curl is one of the most fuzzed and audited C codebases in existence (OSS-Fuzz, Coverity, CodeQL, multiple paid audits), and finding anything is a good challenge. That’s why what happened next is so interesting.

The curl blog post about Mythos unleashed a wave of non-Mythos AI hunting as researchers piled onto curl with their own tooling. AISLE was hunting curl in fall 2025, before Mythos. When the blog post stirred the field, they were already deep in the codebase and just claimed 6 of 18 discovered. Compare those 18 to the single low-severity one that Mythos was credited with. The AISLE blog post makes it clear their AI method has been the most successful and yet it’s the least cost model, opposite of Mythos marketing.

Papers, Please: Wem gehört eigentlich die Browser-Engine?

Schnauzer | Deutsche | English

Wer in Berlin einen Reisepass beantragt, seine Steuer über ELSTER abgibt, sich einen Termin im Bürgeramt erkämpft oder sich bei seiner Krankenkasse einloggt, tut das alles in einer Rendering-Engine, die er nicht kontrolliert, nicht prüfen kann und die sich über Nacht von einem Server an der amerikanischen Westküste neu schreibt. Die Browser-Engine ist das meistverbreitete Stück ausländische Software im gesamten öffentlichen Leben Deutschlands. Und auf keiner einzigen Liste für kritische Infrastruktur steht sie drauf.

Das Ding, das niemand auf die Liste setzt

KRITIS, das deutsche Regelwerk für kritische Infrastruktur, das das BSI beaufsichtigt, zählt alles auf: Strom, Wasser, Lebensmittel, Telekommunikation, Gesundheit, Finanzen und Verkehr. NIS2 hat den Perimeter europaweit noch weiter gezogen. Und die Browser-Engine? Sie ist der Türöffner zu jedem dieser Sektoren — die Schicht, über die der Bürger an die Dienste überhaupt erst herankommt — und sie steht außerhalb von allem, was wir je eingestuft haben.

Drei Engines fahren das offene Web. Googles Blink trägt rund drei Viertel des gesamten Verkehrs, über Chrome, Edge und fast den ganzen Rest. Apples WebKit hat iOS fest in der Hand. Mozillas Gecko, das Herz von Firefox, dümpelt inzwischen unter fünf Prozent. Alle drei werden aus den USA gesteuert. Das Tech-Souveränitätspaket der EU-Kommission vom Juni 2026 gibt es selbst zu: Bei den wichtigen digitalen Technologien hängt die Union zu über achtzig Prozent an Quellen außerhalb Europas. Das ist keine Abhängigkeit mehr, das ist ein Verhältnis.

Und jetzt kommt der Punkt: Das ist keine Eigentumsangst. Das ist ein offenes Scheunentor in der Governance. Eine Engine, die sich selbst aktualisiert, ist ein ferngesteuerter Schreibkanal in jeden öffentlichen Rechner, der sie laufen lässt: Wer den Update-Server kontrolliert, entscheidet, was heute Nacht auf die Geräte gespielt wird. Beim Stromzähler oder der Telefonvermittlung würden wir das nie und nimmer dulden. Aber bei der Schicht, über die der ganze Staat seinen Bürgern begegnet, drücken wir beide Augen zu — weil es ja „läuft”. Genau so sieht jede vereinnahmte Infrastruktur aus. Bis zu dem Tag, an dem sie nicht mehr läuft.

Drei Engines — zwei baust du nie selbst

Nimm die Romantik aus dem Wort heraus, dann ist eine Engine ein Verbund aus sieben Teilen in einer Schleife: Netzwerk, HTML-Parsing, das DOM, die CSS-Kaskade samt Style-Berechnung, das Layout, Rendering und Compositing, und die Bindings, die JavaScript an den Baum koppeln. Der Trick ist zu begreifen: Die tiefsten und teuersten dieser Teile sind Massenware. Eine JavaScript-Engine, ein Stack für Textshaping und Font-Rasterung und die GPU-Primitiven unter dem Rendering — das sind jeweils Mannjahrtausende an Arbeit, und sie nachzubauen bringt dir exakt null Souveränität. Niemand kontrolliert das Web, bloß weil er einen Font-Rasterizer besitzt.

Was dir wirklich gehört — das souveräne Tafelsilber — das ist die Layout-Engine, die Rendering-Pipeline und die Sicherheitsgrenze drumherum. Das ist der Teil, für den sich Geld lohnt, und den baust du nicht auf der grünen Wiese neu. Servo gibt es nämlich schon: eine speichersichere Engine in Rust, verwaltet von der Linux Foundation Europe, von einem fünfköpfigen Team bei Igalia von 41 auf 62 Prozent in den Web Platform Tests gehievt, mit ihrem ersten getaggten Release 2026. Eine deutsche Engine ist also ein Problem des Forkens und Finanzierens — auf europäischem Fundament, nicht auf dem leeren Blatt. Die ganze Rechnung, inklusive der Kosten weiter unten, steht in diesem ausgezeichneten Realitätscheck zu Browsern und Souveränität.

Die Einkaufsliste, alles in Rust

Hier ist der Stack, den ein Geldgeber wirklich bezahlen soll — ausgewählt nach einer einzigen Regel: kein amerikanischer Plattform-Gatekeeper in irgendeinem tragenden Teil.

Teilsystem Souveräne Wahl Was es ersetzt
Sprache Rust Speichersicherheit als Basis — und das ganze Ökosystem darunter
JavaScript-Engine Boa V8 (Google), JavaScriptCore (Apple), SpiderMonkey (USA)
GPU-Rendering und Compositing WebRender + wgpu Skia und plattformeigene Grafik-Stacks
TLS rustls Googles BoringSSL, OpenSSL
Layout selbst gebaut, auf dem Taffy-Gerüst für Flexbox/Grid das eine Teil, das einem niemand verkauft
Text und i18n rustybuzz, fontations, ICU4X HarfBuzz, FreeType, ICU (die alten C-Bibliotheken)
Barrierefreiheit AccessKit die Accessibility-APIs der Plattform
Basis-Codebasis Servo eine Neuentwicklung von Grund auf

Die eine Komponente, die entscheidet, ob das Wort „souverän” den Realitätscheck übersteht, ist die JavaScript-Engine. Bettest du Googles V8 oder Apples JavaScriptCore ein, dann hast du die Abhängigkeit bloß mit einem netteren Logo neu aufgebaut. Mozillas SpiderMonkey ist die ehrliche Brücke — offen, einbettbar, der schnellste Weg zu einem laufenden Browser —, aber es bleibt Code aus den USA. Boa ist das Ziel: eine einbettbare Engine in Rust, MIT-lizenziert, von einer Community gepflegt, und schon bei rund 94 Prozent Konformität in Test262, der offiziellen ECMAScript-Suite. Sie ist weiter, als ihr irgendjemand zutraut — ihre Temporal-Bibliothek für Datum und Zeit ist so gut, dass V8 sie inzwischen selbst verwendet. Der Abstand zu V8 und SpiderMonkey ist real, aber er liegt in der reinen Geschwindigkeit und in den tausend Sonderfällen, nicht in der Korrektheit. Und genau so ein Abstand ist die Art Arbeit, die eine staatliche Initiative gut hinbekommt: begrenzt, bezahlbar, kein Hexenwerk. Finanziere Boa auf Web-Niveau hoch, und die JavaScript-Schicht des europäischen Stacks enthält überhaupt keinen fremdgesteuerten Code mehr.

Wo das Geld wirklich hingeht

Das ehrliche Bild vom Engineering ist das Gegenteil von beängstigend. Fast alles auf der Liste ist entweder Massenware, die du einmal einbaust, oder ein begrenztes Problem, das du einmal löst. Es gibt genau eine Hürde, die sich nur langsam mit Geld abbauen lässt, und das ist die Web-Kompatibilität — konkret: es muss laufen wie Chrome. Layout ist an den Rändern schlampig spezifiziert, und so heißt „korrekt” in der Praxis: „verhält sich wie Blink, auch dort, wo Blink von der Norm abweicht” — weil die Websites der ganzen Welt gegen Chrome getestet werden und nicht gegen die Spezifikation. Da gibt es keine elegante Abkürzung. Das ist langes, sturem Gegentesten gegen die Web Platform Tests, und darin wird auf Dauer der Löwenanteil der Arbeit stecken.

Zwei andere Probleme sind wirklich knifflig, und beide sind Sicherheitsprobleme, bei denen eine Rust-Engine besser sein kann als die etablierten Dinger, statt nur hinterherzulaufen: die Renderer-Sandbox und die Vertrauensgrenze zwischen ihr und dem privilegierten Prozess — und die Lebensdauer der DOM-Objekte, die der JavaScript-Garbage-Collector verfolgt, die klassische Quelle ausnutzbarer Use-after-free-Fehler, gegen die Speichersicherheit überhaupt erst erfunden wurde.

Das Geld für den ganzen Spaß? Wird auf grob 50 bis 70 Millionen Euro im Jahr geschätzt — für Entwickler, Tests, Sicherheitsaudits und Standardarbeit. Stell das neben das 7,8-Milliarden-Budget der Europäischen Weltraumorganisation oder die 300 Milliarden, die das EuroStack-Vorhaben in digitale Infrastruktur stecken will — dann ist eine Browser-Engine ein Rundungsfehler. Am Geld hat es nie gelegen. Es liegt an der Dauerhaftigkeit: eine Engine ist kein Projekt, das fertig wird, sondern eine Verpflichtung, die das Ministerium überleben muss, das sie bezahlt hat.

In die öffentliche Hand — und zwar föderal

Deutschland baut schon souveräne öffentliche Software, und zwar schon föderal. ZenDiS, das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung — eine bundeseigene Gesellschaft, Ende 2022 gegründet und ausdrücklich auf dem Weg zu einer gemeinsamen Bund-Länder-Körperschaft — betreibt openCode, die Code-Schmiede des öffentlichen Sektors, und openDesk, die souveräne Alternative zu Microsoft 365. Als die Regierungschefs aller sechzehn Länder zur Ministerpräsidentenkonferenz zusammenkamen, nutzten sie openDesk — eine Woche nach dem Start. Und auf EU-Ebene formt sich der Apparat ebenfalls schon: ein EU-Konsortium für digitale Infrastruktur und digitale Gemeingüter, in dem ZenDiS und die deutsche Sovereign Tech Agency die ersten Projekte stemmen sollen. Das Chassis, das eine Browser-Engine bräuchte, ist halb gebaut, bevor jemand eine Zeile Layout-Code geschrieben hat.

Also stell die Engine dahin, wo der Rest des souveränen Stacks ohnehin wohnt: ein Upstream, sechzehn Verwalter. Eine einzige föderale Browser-Behörde würde genau das wiederherstellen, wovor man wegrennt — einen einzigen Punkt für den politischen Zugriff und einen einzigen Explosionsradius für jede Sicherheitslücke. Ein föderales Modell, auf Länderebene gepflegt, verteilt die Sicherheitsprüfung, passt zur Subsidiarität, auf der der deutsche Staat gebaut ist, und sorgt dafür, dass kein einzelnes Ministerium und kein einzelnes Unternehmen die Schlüssel hält. Engines sammeln sich nicht bei Google, weil es für alle anderen unmöglich wäre. Sondern weil sonst niemand bereit war, für Dauerhaftigkeit zu zahlen. Ein föderaler öffentlicher Auftrag ist die eine Struktur, die Dauerhaftigkeit finanzieren kann, ohne ein neues Monopol unter europäischer Flagge hochzuziehen.

Und jetzt Butter bei die Fische, was das wahre Risiko angeht: Es ist nicht technisch. Deutschlands eigene Open-Source-Versuche sind schon ausgebremst worden, weil Bundesressorts ihre alten Verträge geschützt haben — netzpolitik hat dokumentiert, wie genau dieser Behörde der Rotstift angesetzt wurde. Die Gefahr für eine deutsche Engine ist die Vergabepolitik im eigenen Laden. Rust war es nie.

Eine Republik, die ihre eigene Regierung nicht in einem Browser darstellen kann, den sie selbst kontrolliert, hat den Vordereingang längst einem anderen in die Hand gedrückt. Die Standards sind offen, die Sprache ist Rust, das Fundament ist Servo, die JavaScript-Engine ist Boa, und das Chassis zum Verwalten steht ebenfalls schon da. Forkt es. Finanziert es. Stuft es als KRITIS ein. Und die Schlüssel — die bekommen die Länder.

Für meinen Großonkel Lutz und seine Familie, 1941 – die wir nicht mehr aus Berlin herausholen konnten, bevor sie wegen der Angaben in ihren Papieren getötet wurden.

Papers, Please: Who Does Your Browser Engine Actually Belong To?

Schnauzer | Deutsche | English

Every German who renews a passport, files taxes through ELSTER, fights for a Bürgeramt appointment, or signs into a statutory health insurer does all of it inside a rendering engine they do not control, cannot audit, and that rewrites itself overnight from a server on the American west coast. The browser engine is the most widely deployed piece of foreign software in the whole of German public life. And I don’t see it on a single critical-infrastructure list.

The thing about things not on the list

KRITIS, the German critical-infrastructure regime overseen by the BSI, names everything: energy, water, food, telecommunications, health, finance, and transport. NIS2 widened the perimeter across the EU. And the client-side browser engine? It is the door into every one of those sectors — the layer through which the citizen actually reaches their critical services — outside everything being designated.

Three engines run the open web today. Google’s Blink carries roughly three-quarters of all traffic, through Chrome, Edge, and nearly all the rest. Mozilla’s Gecko, the heart of Firefox, now languishes below five percent. Apple’s WebKit has iOS locked down. All three are inside and steered from the United States. The European Commission’s June 2026 tech-sovereignty package admits it outright: for the important digital technologies, the Union depends on sources outside Europe for over eighty percent. That goes beyond dependency; it is a relationship.

This is not idle ownership desire or anxiety. It is an open barn door in the governance conversation everyone is having. An engine that updates itself is a remotely controlled write channel into every public machine that runs it: whoever controls the update server decides what gets pushed onto those devices tonight, tomorrow and the day after. We never tolerate that for an electricity meter or a telephone exchange. Chinese toys have been banned for less. But for the layer through which the entire state meets its citizens, we stare like deer in headlights while it “works.” That is exactly what every captured piece of infrastructure looks like. Right up to the day it stops working.

Three engines, two you’ll never build yourself

Take the romance out of the word engine and it’s just assembly of seven parts in a loop: networking, HTML parsing, the DOM, the CSS cascade together with style computation, layout, rendering and compositing, and the bindings that couple JavaScript to the tree.

The deepest and most expensive of those parts are the commodities. A JavaScript engine, a stack for text shaping and font rasterization, and the GPU primitives beneath rendering — each is person-millennia of work, and rebuilding them buys you exactly zero sovereignty. Nobody will control the web when they own a font rasterizer.

What actually belongs to you is the layout engine, the rendering pipeline, and the security boundary around them. That is the part time is worth spending on, and greenfield isn’t necessary. Servo already exists: a memory-safe engine in Rust, stewarded by the Linux Foundation Europe, taken by a five-person team at Igalia from 41 to 62 percent on the Web Platform Tests, with its first tagged release in 2026. A German engine is therefore a problem of forking and funding the low hanging fruit. The full accounting, including the costs below, is already laid out in an excellent reality check on browsers and sovereignty.

The shopping list, all in Rust

Here is the stack a funder should actually pay for — selected by a single rule: no American platform gatekeeper for critical browser parts.

Subsystem Sovereign choice What it replaces
Language Rust memory safety as the foundation — and the whole ecosystem beneath it
JavaScript engine Boa V8 (Google), JavaScriptCore (Apple), SpiderMonkey (US)
GPU rendering and compositing WebRender + wgpu Skia and platform-native graphics stacks
TLS rustls Google’s BoringSSL, OpenSSL
Layout built in-house, on the Taffy framework for Flexbox/Grid a part you can’t buy
Text and i18n rustybuzz, fontations, ICU4X HarfBuzz, FreeType, ICU (the old C libraries)
Accessibility AccessKit the platform’s accessibility APIs
Base codebase Servo a from-scratch rewrite

The one component that decides whether the word “sovereign” applies is the JavaScript engine. Embed Google’s V8 or Apple’s JavaScriptCore and the dependency is still there with a nicer logo. Mozilla’s SpiderMonkey is the honest bridge — open, embeddable, the fastest path to a running browser — but it is still code from the US.

Boa is the ideal target: an embeddable engine in Rust, MIT-licensed, community-maintained, and already at roughly 94 percent conformance on Test262, the official ECMAScript suite. It is further along than anyone gives it credit for — its Temporal library for dates and times is good enough that V8 itself now uses it. The gap to V8 and SpiderMonkey is real, but it lies in raw speed and in the thousand edge cases, not in correctness. And a gap of exactly that kind is the sort of work a state initiative should be working on: bounded, affordable, no vague or fuzzy bits.

Fund Boa up to web grade, and the JavaScript layer of the European stack contains no foreign-controlled code at all.

Where money actually helps

The actual engineering picture is that this is doable, and the time is right. Almost everything on the list is either a commodity you connect once, or a defined problem you solve once. There is exactly one barrier that money buys, and that is the web compatibility. It has to behave like Chrome. Layout is loosely specified at the edges, so “correct” in practice means “behaves like Blink, including where Blink departs from the spec” — because the world’s websites are tested against Chrome and not against the specification. There is no shortcut to this part. It is the long, stubborn cycles against the Web Platform Tests, and that is where the lion’s share of the work will sit over time.

Two other problems are genuinely hard, and both are security problems where a Rust engine can be better than the incumbents rather than merely catching up: the renderer sandbox and the trust boundary between it and the privileged process — and the lifetimes of the DOM objects the JavaScript garbage collector tracks, the classic source of exploitable use-after-free bugs, the very thing memory safety was invented to kill.

The total money for all of it?

Estimated at roughly 50 to 70 million euros a year — for developers, testing, security audits, and standards work. Set that next to the European Space Agency’s 7.8-billion budget, or the 300 billion the EuroStack initiative wants to pour into digital infrastructure, and a proper sovereign browser engine for everyone is a rounding error.

It was never really about the money. It is about permanence and ease of the commitment: an engine is not a project that finishes, it has to outlive the politician’s handshake and ministry that paid for it.

In public hands, federally speaking

Germany already builds sovereign public software, and already does it federally. ZenDiS, the Center for Digital Sovereignty of Public Administration — a federally owned company founded in late 2022 and explicitly on its way to becoming a joint federal-state body — runs openCode, the public sector’s code forge, and openDesk, the sovereign alternative to Microsoft 365. When the heads of government of all sixteen states gathered for the Minister-Presidents’ Conference, they used openDesk — a week after launch. And at EU level the apparatus is taking shape too: an EU consortium for digital infrastructure and digital commons, with ZenDiS and Germany’s Sovereign Tech Agency set to carry the first projects. The chassis a browser engine would need is half-built before anyone has written a line of layout code.

So put the engine where the rest of the sovereign stack already lives: one upstream, sixteen stewards. A single federal browser authority would recreate the very thing you are running from — one point for political capture and one blast radius for every vulnerability. A federated model, maintained at the state level, distributes the security review, fits the subsidiarity the German state is built on, and ensures no single ministry and no single company holds the keys. Engines do not pool at Google because it would be impossible for everyone else. They pool there because no one else was willing to pay for permanence. A federated public mandate is the one structure that can fund permanence without raising a fresh monopoly under a European flag.

And now the plain truth about the real risk: it is not technical. Germany’s own open-source efforts have already been throttled because federal departments protected their legacy contracts — netzpolitik documented exactly how this agency got the red pencil. The threat to a German engine is procurement politics at home. Rust has been ready and waiting for the go signal (pun intended).

A republic that cannot render its own government in a browser it controls has already handed critical information infrastructure to someone else. The standards are open, the language is Rust, the foundation is Servo, the JavaScript engine is Boa, and the chassis to govern it is already standing. Fork it. Fund it. Put it in KRITIS. And the keys for it all go to the trusted states.

Für meinen Großonkel Lutz und seine Familie, 1941 – die wir nicht mehr aus Berlin herausholen konnten, bevor sie wegen der Angaben in ihren Papieren getötet wurden.