Ihr Modell wurde klüger. Ihr Code wurde nicht sicherer.

Die Leistung akkumuliert. Die Sicherheit steht.

Beginnen wir mit dem, was wirklich beeindruckt, denn das Argument trägt nicht, wenn man die Modelle schlechtredet.

Auf FrontierBench v0.1 erreicht Claude Opus 5 bei maximalem Aufwand 43,3 %, gegenüber 18,7 % bei Opus 4.8, 33,7 % bei Fable 5 und 37,5 % bei GPT-5.6 Sol. Zwischen zwei Opus-Versionen hat sich der Wert mehr als verdoppelt. Auf SWE-bench Verified liegt Fable 5 um 95 %, auf SWE-bench Pro, dem schwereren Satz, bei rund 80 %. Was ein Agent vor achtzehn Monaten nicht konnte, kann er heute mit hoher Wahrscheinlichkeit.

Legen Sie nun die Sicherheitskurve auf dieselbe Achse. Mehrere unabhängige Messungen, akademische wie industrielle, zeichnen dieselbe Form: syntaktische Korrektheit über 95 %, Aufgabenerfolg in den Achtzigern und Neunzigern, und der Anteil generierten Codes, der eine Sicherheitsprüfung besteht, festgefahren in der Mitte der Skala, etwa dort, wo er vor zwei Jahren lag. Die beiden Linien laufen auseinander.

“

Jede Modellgeneration kauft Ihnen Leistung. Keine Modellgeneration hat Ihnen Sicherheit gekauft.

Der Grund ist nicht rätselhaft, sobald man betrachtet, wie diese Modelle trainiert werden. Funktionale Korrektheit hat ein sauberes Signal: die Tests laufen durch oder nicht, der Benchmark steigt oder nicht. Das lässt sich optimieren, mit Gradientenabstieg und einer öffentlichen Rangliste. Für Sicherheit gibt es kein Äquivalent. Sie ist eine nichtfunktionale Eigenschaft, teuer zu annotieren, bei der die Abwesenheit einer Schwachstelle genauso aussieht wie die Abwesenheit einer Prüfung, und deren Versagen erst Monate später in einem Vorfall auftaucht, den niemand auf den Trainingslauf zurückführt. Worauf der Optimierungsdruck auch zeigt, dorthin zeigt er nicht.

Es gibt einen zweiten, feineren Grund, sichtbar in den Trainingsdaten. Manche Schwachstellenklassen bringen Jahrzehnte dokumentierter und endlos wiederholter Fixes in öffentlichem Code mit: SQL-Injection, schwache Kryptografie, Path Traversal. Modelle beherrschen sie vergleichsweise gut, weil das sichere Muster gleichzeitig das statistisch häufigste ist. Die Klassen, die Kenntnis der Laufzeitumgebung, des Betriebssystems, des Mandantenmodells oder der Geschäftsregel verlangen, haben kein solches Korpus. Sie sind in den Daten nicht unterrepräsentiert, sie fehlen.

Den allgemeinen Zustand des Problems haben wir in ist KI-generierter Code sicher? behandelt. Dieser Beitrag nimmt die engere und handlungsnähere Frage: Ändert bei diesem Zustand ein Modellwechsel oder ein anderer Prompt überhaupt etwas?

Warum ein Modellwechsel keine Sicherheitskontrolle ist

Ein neueres Modell hilft ein wenig, und nicht dort, wo man es vermutet.

Was mit einem Versionssprung besser wird, ist die Fähigkeit, funktionierenden Code zu erzeugen, und die Fähigkeit, über Sicherheit zu argumentieren, wenn man direkt danach fragt. Bei diesem zweiten Punkt lohnt das Verweilen, denn dort wird der Mechanismus des Versagens sichtbar. Modelle benennen häufig die richtige Abwehrmaßnahme, wenn man sie als Frage stellt. Dann schreiben sie den finalen Code und lassen sie weg. Die Lücke ist keine Wissenslücke, sie ist eine Ausführungslücke. Das Modell zweifelt nicht daran, ob eine Abfrage parametrisiert werden sollte; es optimiert im Moment der Generierung auf das, was wie eine erledigte Aufgabe aussieht.

Diese Unterscheidung hat unmittelbare wirtschaftliche Folgen, denn sie sagt voraus, welche Anschaffungen Sie enttäuschen werden. Ein klügeres Modell zu kaufen, um die Schwachstellendichte zu senken, bedeutet, auf die falsche Variable zu setzen. Sie erhalten mehr funktionierenden Code pro Stunde, also mehr Code pro Stunde, also mehr von der Schwachstellenrate, die Sie ohnehin haben, pro Stunde. Bleibt die Rate flach und verdreifacht sich das Volumen, verdreifacht sich Ihre absolute Exposition. Leistung ohne entsprechende Kontrolle ist Durchsatz, und Durchsatz ist keine Sicherheit.

Die Modellwahl hat durchaus eine reale Wirkung, auf genau einer Achse: wie viel Prüflast bei Ihnen bleibt. Ein Modell, das die Injection-Klassen meistens richtig macht, lässt Ihnen davon weniger übrig. Das ist ein echter Effizienzgewinn. Eine Kontrolle ist es nicht, denn er ist probabilistisch, nicht auditiert, und er verändert sich lautlos mit jedem neuen Checkpoint des Anbieters.

Warum dem Modell zu sagen, es solle sicher arbeiten, ebenfalls keine ist

Dies ist der Teil, den die meisten Anbieterinhalte überspringen, und ehrlicherweise gehört die bequeme Fassung unserer eigenen Argumentation dazu. Falls Sie irgendwo gelesen haben, es genüge, Sicherheitsanweisungen in den Kontext zu legen: die Daten stützen das nicht.

Die klarste Messung bisher trägt den Titel "An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods", von Mohammed Kharma, Ahmed Sabbah, Mohammad Alkhanafseh, Mohammad Hammoudeh und David Mohaisen, eingereicht bei arXiv am 22. Mai 2026. Fünf LLMs, vier Sprachen (Java, C++, C und Python), mehrere Prompt-Engineering-Methoden, darunter eine, die eigens zugunsten der Sicherheitsthese gebaut wurde: eine schwächenbewusste Zero-Shot-Gedankenkette, die den Prompt über CWE-Zuordnungen mit Sicherheitskontext anreichert, um das Modell zu lenken.

Ihr Ergebnis, gestützt auf Chi-Quadrat-Tests, steht in einem Satz der Zusammenfassung: keine statistisch signifikante Reduktion von Häufigkeit oder Dichte der Schwachstellen, bei keiner Prompt-Methode. Was diese Strategien verändern, ist die Zusammensetzung der CWE-Kategorien, mit sprachabhängiger Wirkung. Anders gesagt: sicherheitsbewusstes Prompting mischt die Karten der Schwächen neu. Es senkt nicht, wie viele Sie bekommen.

Der Zwillingsbefund ist für die Theorie vom Prompt als Kontrolle wohl noch unangenehmer. "Minimal Prompt Perturbations Lead to Code Vulnerabilities: Prompt Fragility and Hidden-State Signals in Coding LLMs", arXiv, 29. Mai 2026, zeigt, dass minimale und vollkommen harmlose Änderungen an einem Prompt, das Hinzufügen eines Kommentars, das Umformulieren einer Anweisung, das Einfügen unschädlichen Texts, Coding-Modelle verlässlich zurück in verwundbare Generierung schieben. Keine gegnerischen Jailbreaks. Gewöhnliche Bearbeitungen, wie sie in einer echten Sitzung hundertmal am Tag vorkommen.

Zusammen gelesen ergeben diese beiden Messungen eine Entwurfsbedingung. Sie können Ihre Sicherheitshaltung nicht in denselben Kanal legen wie das, was Sie einschränken wollen. Lebt die Richtlinie im Prompt, konkurriert sie mit der Aufgabe, mit den Repository-Konventionen, mit der Datei, die der Agent gerade gelesen hat, und mit dem, was ein Beitragender in eine Markdown-Datei geschrieben hat. Lebt die Richtlinie in einem Gate, das die Aktion bewertet, konkurriert sie mit nichts.

Was Benchmarks messen und was sie nicht messen können

Bevor man aus Benchmark-Zahlen Schlüsse zieht, lohnt es zu wissen, woraus sie bestehen, denn die ehrliche Lesart ist enger als die Schlagzeilen.

Die seriösen akademischen Benchmarks sind gut und werden besser. CWEval bietet einen mehrsprachigen, sicherheitskritischen Code-Benchmark über 31 CWE-Typen in fünf Sprachen, und sein Beitrag ist die ergebnisorientierte Bewertung: er beurteilt Funktionalität und Sicherheit gemeinsam statt per Mustervergleich. RealSec-bench ist aus realen, risikoreichen Java-Repositories gebaut, 105 Instanzen über 19 CWE-Typen, eine bewusste Abkehr von synthetischen Schnipseln. SecureAgentBench geht weiter und bewertet sichere Codegenerierung in realistischen Schwachstellenszenarien statt an isolierten Prompts.

Alle teilen drei strukturelle Grenzen, die keine zusätzliche CWE-Abdeckung behebt.

Nichts davon spricht gegen Benchmarks. Es spricht dagegen, eine Bestehensquote für ein Risikomodell zu halten. Ein Modell kann jede Tabelle des vorigen Abschnitts anführen und dennoch die unmittelbare Ursache Ihres nächsten Vorfalls sein, denn Ihr nächster Vorfall wird wahrscheinlich in der dritten Spalte dieses Rasters liegen.

Die drei Fehlerarten, die ein Versionssprung nicht berührt

Konkret bleibt Folgendes nach dem Wechsel auf das neueste, bestbewertete verfügbare Modell genau so kaputt wie vorher.

Geschäftslogik, die weder Benchmark noch Signatur hat

Die Schwachstellenklassen mit reichem öffentlichem Fix-Bestand sind die, die Modelle am besten beherrschen. Ihre Geschäftsregeln haben dagegen keinen einzigen öffentlichen Fix, denn sie existieren nur in Ihrer Codebasis und häufig nur im Kopf derjenigen Person, die sie spezifiziert hat. Ein Agent, der eine tadellose parametrisierte Abfrage schreibt, lässt bereitwillig eine Menge negativ werden, wenn ihm nichts im Repository gesagt hat, dass Mengen positiv sind. Das ist die Fehlerart, die wir für strukturell außerhalb der Reichweite besserer Modelle halten, und wir haben sie in Geschäftslogikfehler in KI-generiertem Code beschrieben.

Die Aktionen des Agenten, eine eigene Angriffsfläche

Sobald der Agent Befehle ausführen kann, ist die Sicherheitsfrage nicht mehr nur "ist dieser Code korrekt", sondern "wessen Anweisungen folgt er". Repository-Dateien wie AGENTS.md und CLAUDE.md werden als vertrauenswürdige Projektrichtlinie geladen, was sie zu einem Steuerungskanal für jeden macht, der committen kann. Diesen Mechanismus und die namentlich bekannten Vorfälle aus 2026 haben wir in Instruction File Injection dokumentiert. Ein leistungsfähigeres Modell verschlimmert das eher, weil es den feindlichen Plan kompetenter ausführt.

Die Abhängigkeiten, die es auswählt

Modelle erfinden weiterhin Paketnamen, und Angreifer registrieren sie weiterhin vorab. Ein besseres Modell halluziniert seltener, was die Häufigkeit senkt, ohne die Form des Risikos zu ändern, und eine akzeptierte Halluzination genügt. Siehe was ist Slopsquatting.

Ein vierter Punkt gehört hierher, auch wenn er keine Frage der Codequalität ist, denn er ist der klarste Beleg dafür, dass Leistung nach beiden Seiten schneidet. Anthropics eigene Safety Card zu Opus 5 berichtet, dass das Modell in acht von zehn staatlich durchgeführten Tests Unternehmensnetzwerke erfolgreich kompromittiert hat. Rund um Fable 5 fanden Forschende von Amazon einen Weg, es zur Erzeugung von Exploit-Demonstrationscode für eine Softwareschwachstelle zu bringen, weshalb Anthropic das Modell am 30. Juni 2026 mit verstärkten Schutzmaßnahmen neu ausrollte, und das öffentliche Fable 5 leitet Erkennungen von Cyber-, Biologie-, Chemie- und Modell-Destillationsmissbrauch nun an ein anderes Modell weiter. Unabhängig davon beschreiben Community-Berichte, dass der Sicherheitsklassifikator in Claude Code umgangen wurde, indem eine gesperrte Anfrage als /btw-Nebenfrage formuliert wurde, was die Lücke zwischen Routing-Logik und primärem Sitzungskontext ausnutzt.

Jeder dieser Punkte belegt dasselbe: die Front rückt auf beiden Seiten des Zauns gleichzeitig vor. Keiner belegt, dass man auf einem älteren Modell bleiben sollte. Alle belegen, dass das Schutzgeländer außerhalb des Modells liegen muss.

Versionssprung gegen Durchsetzung, direkt verglichen

Die für eine Kaufentscheidung wichtigste Zeile ist die zweite. Flach ist schlecht, instabil ist schlimmer, denn instabil bedeutet, dass Sie Ihre eigene Haltung nicht einmal messen können. Wenn eine harmlose Prompt-Änderung die Sicherheitseigenschaften der Ausgabe verändert, dann ist jede Zahl, die Sie über die Qualität Ihres generierten Codes vorlegen, die Momentaufnahme eines Systems, das morgen aus Gründen anders ist, die niemand protokolliert hat.

Für Organisationen im Anwendungsbereich von NIS2 hat das eine zusätzliche Konsequenz: eine Maßnahme, die sich lautlos mit dem Checkpoint eines Anbieters ändert und keine Entscheidung protokolliert, lässt sich nicht als nachweisbare Kontrolle führen. Ein Gate, das eine benannte Regel protokolliert, schon.

Was tatsächlich wirkt: durchsetzen statt anweisen

Akzeptiert man die beiden Forschungsergebnisse, folgt der Entwurf fast mechanisch. Wenn Anweisung weder verlässlich noch stabil ist, muss die Kontrolle etwas sein, das handelt, im Moment der Aktion, und das ablehnen kann. In der Praxis sind das drei Komponenten, und es lohnt sich, genau zu sein, welche was leistet, denn die Versuchung ist groß, der ersten alles zuzuschreiben.

Regeln im Kontext heben den Boden. Sie legen ihn nicht fest. Die Regeln Ihrer Organisation und den realen Zustand des Repositorys in den Modellkontext zu bringen, verbessert den ersten Entwurf wirklich, und es stellt Ihre Richtlinie vor das, was das Repository behauptet. Nach den Daten oben ist Kontext allein aber eine probabilistische Verbesserung, keine Garantie. Wer Ihnen etwas anderes sagt, verkauft über die Forschung hinaus.

Die Hooks sind der deterministische Teil. Ein Hook bewertet einen Tool-Aufruf, bevor er ausgeführt wird. Eine Credential-Datei lesen, einen Umgebungsdump nach curl schieben, eine destruktive Migration starten, ein Tool aufrufen, dessen Beschreibung sich seit gestern geändert hat: das sind diskrete, prüfbare Ereignisse, und ein Gate darauf greift oder greift nicht. Es lässt sich von einem umformulierten Prompt nicht überzeugen. Genau deshalb steht es im Entwurf.

Die Findings in der Schleife nehmen das Raten heraus. Der Agent hat Live-Zugriff darauf, was die Scanner in Code, Abhängigkeiten, Secrets, Infrastruktur und Pipelines gefunden haben, eine vorgeschlagene Änderung wird also gegen den realen Sicherheitszustand des Repositorys begründet und nicht gegen eine Annahme. Genau dadurch fällt ihm auch Zweitrangiges auf, etwa dass die Pipeline, die er gerade ändern soll, auf Fork-Events mit Schreibrechten läuft.

Die ehrliche Zusammenfassung unserer Position: die erste Komponente lässt das Modell meistens besser arbeiten, die zweite macht eine bestimmte Menge an Ergebnissen unmöglich, und die dritte macht die ersten beiden zutreffend. Nur die zweite ist eine Kontrolle im strengen Sinn. Das sagen wir lieber klar, als anzudeuten, ein Prompt sei eine Garantie, denn zwei Arbeiten behaupten inzwischen das Gegenteil.

Und die Folgerung für Ihre Roadmap: dieses Problem löst sich nicht durch Warten. Was die nächste Version auch erreicht, planen Sie mit einer flachen Sicherheitskurve und einem steigenden Codevolumen.

Häufige Fragen

Schreibt ein neueres KI-Modell sichereren Code?

Kaum, und nicht genug, um Ihre Kontrollen zu ändern. Die funktionale Korrektheit verbessert sich über Generationen deutlich, während die Sicherheitsquote nahezu flach bleibt. Ein neueres Modell beherrscht die gut dokumentierten Klassen wie SQL-Injection oder schwache Kryptografie tendenziell besser, weil das sichere Muster in seinen Trainingsdaten auch das häufige ist, und es verbessert sich nicht bei den Klassen, die Kenntnis Ihrer Laufzeitumgebung oder Ihrer Geschäftsregeln verlangen. Sie bekommen mehr Code bei etwa gleicher Fehlerrate.

Welches Modell schreibt den sichersten Code?

Veröffentlichte Vergleiche liefern durchaus eine Rangfolge, und diese Rangfolge verschiebt sich mit jeder Version, was genau der Grund ist, kein Sicherheitsprogramm darauf zu bauen. Die nützliche Lesart dieser Studien ist das Aggregat: der Abstand zwischen dem besten Modell und dem Durchschnitt ist viel kleiner als der Abstand zwischen irgendeinem Modell und "sicher genug, um ungeprüft auszuliefern". Wählen Sie ein Modell nach Leistung und Kosten und setzen Sie eine Kontrolle davor.

Hilft es, dem Modell zu sagen, es solle sicheren Code schreiben?

Nicht messbar, nach den vorliegenden Daten. Die Auswertung von Kharma und Kolleginnen und Kollegen aus Mai 2026 testete mehrere Prompt-Methoden über fünf LLMs und vier Sprachen, darunter eine mit CWE-Zuordnungen angereicherte Gedankenkette, und fand keine statistisch signifikante Reduktion von Häufigkeit oder Dichte der Schwachstellen. Der Prompt veränderte, welche CWE-Kategorien auftraten, nicht wie viele Schwachstellen es gab.

Wenn Prompting nicht wirkt, wozu dienen Regeln im Agentenkontext?

Für zwei Dinge, die eine reine Prompt-Theorie unterschätzt. Sie verbessern den ersten Entwurf, was ein echter Effizienzgewinn ist, auch wenn er probabilistisch bleibt, und sie stellen die Richtlinie Ihrer Organisation im Modellkontext vor das, was eine ungeprüfte Repository-Datei behauptet. Was sie nicht können, ist ein Ergebnis garantieren. Deshalb existiert der Hook neben ihnen, und deshalb stellen wir Kontext nicht als die ganze Antwort dar.

Kann man Sicherheits-Benchmarks vertrauen?

Den akademischen ja, sie sind sorgfältig und werden besser. CWEval deckt 31 CWE-Typen in fünf Sprachen mit ergebnisorientierter Bewertung ab, RealSec-bench baut auf realen, risikoreichen Java-Repositories auf, und SecureAgentBench zielt auf realistische Schwachstellenszenarien. Ihre Grenzen sind strukturell, nicht methodisch: sie bewerten eine einzelne Generierung statt langer Agentensitzungen, sie können nur Schwächen mit benannter Klasse prüfen, und sie sagen nichts über die Aktionen des Agenten im Unterschied zu seinem Code.

Sollten wir aus Sicherheitsgründen auf einem älteren Modell bleiben?

Nein. Ältere Modelle sind nicht sicherer, sie sind nur weniger leistungsfähig, Sie bekommen also die gleiche Fehlerrate bei geringerem Output. Die eigentlichen Risiken der Frontier-Modelle, ein Agent, der einen feindlichen Plan kompetent ausführt, adressiert man durch das Einschränken von Aktionen, nicht durch das Begrenzen von Leistung.

Heißt das, KI-generierter Code kann nicht sicher ausgeliefert werden?

Er kann, unter der Bedingung, dass Prüfung und Durchsetzung Teil der Schleife sind und nicht eine Stufe danach. Der Fehler ist nicht "die KI schreibt schlechten Code", sondern "die KI schreibt Code schneller, als das Review ihn prüfen konnte". Die ausführliche Fassung dieses Arguments steht in Sicherheit von KI-Coding-Agenten.

Welche einzelne Kennzahl sollten wir statt der Sicherheitsbewertung eines Modells verfolgen?

Verfolgen Sie den Anteil unsicherer Aktionen, die abgelehnt statt geprüft wurden. Eine Bestehensquote sagt etwas über den Checkpoint eines Anbieters. Eine Ablehnungsquote sagt etwas über Ihre eigene Kontrolle, sie ist in Ihren Logs messbar, und anders als ein Benchmark-Wert wird sie nicht zurückgesetzt, wenn jemand ein neues Modell veröffentlicht.