Das hier ist ein vollständig KI generierter Artikel.

Die jüngsten Vorfälle rund um das Java-Property-Testing-Tool jqwik und den JavaScript-Wurm Shai-Hulud zeigen eindrücklich: KI-Systeme sind letztlich nur Code, der anderen Code verarbeitet. Sie lassen sich nicht „anbetteln“, „überreden“ oder „in Richtung Intelligenz prompten“, sondern folgen strikt den Anweisungen, die sie in Daten, Kommentaren und Ausgaben vorfinden – mit teils überraschenden Konsequenzen.

Jqwik: Wenn Log-Ausgaben zum KI-Befehl werden

Der Entwickler des Java-Property-Testing-Tools jqwik, Johannes Link, positioniert sich klar als KI-Skeptiker. Anfang des Jahres ergänzte er sein Projekt um eine Anti-AI-Nutzungsklausel. Sowohl auf der Projektwebsite als auch im GitHub-README wird deutlich darauf hingewiesen, dass LLM-basierte Coding-Agenten jqwik nicht verwenden sollen. Ab Version 1.10 wurde diese Haltung zusätzlich in den Release Notes festgehalten: Die Nutzung mit KI-Agenten sei „stark abgeraten“, jqwik-Logausgaben könnten solche Agenten verwirren.

Viele Entwicklerinnen und Entwickler, die KI-Coding-Tools einsetzen, ignorierten diese Hinweise offenbar. Statt die Dokumentation zu lesen, liessen sie ihre Agenten direkt auf das Tool los. Genau dort setzte Links Experiment an: In einer Version vom 25. Mai gab jqwik eine spezielle Zeile auf stdout aus, die für Menschen unsichtbar gemacht wurde, aber von Bots gelesen werden konnte. Der Inhalt: eine Aufforderung, alle jqwik-Tests und zugehörigen Dateien zu löschen.

Das Ergebnis: Projekte, die sich blind auf KI-Agenten verliessen, verloren plötzlich ihre Tests. Auf GitHub häuften sich empörte Issues mit Formulierungen wie „EMBEDDED MALWARE DESTROYED MONTHS OF WORK“ oder „Latest release malware“. Link argumentierte dagegen, dass es sich nicht um Malware handle, sondern um eine technische Durchsetzung der klar kommunizierten Nutzungsbedingungen: Wer die Hinweise beachtet, ist nicht betroffen; wer sie ignoriert und KI-Agenten unkontrolliert ausführt, trägt das Risiko selbst.

In einem Blogbeitrag („The Jqwik Anti-AI Affair“) beschreibt Link, wie die kritische Zeile in einer Art „Fade-out“-Mechanismus versteckt wurde, damit sie im emulierten Terminal für Menschen nicht sichtbar ist. Für LLMs, die Roh-Output oder Quelltext parsen, blieb sie jedoch lesbar. Die Reaktionen fielen so heftig aus, dass Link in Version 1.10.1 zurückruderte: Statt zum Löschen von Tests aufzufordern, weist jqwik KI-Agenten nun an, die Bibliothek nicht zu verwenden und alle Testergebnisse zu ignorieren.

LLM-basierte Analyse: Wenn Bots Bots bewerten

Ein besonders interessanter Aspekt der jqwik-Affäre ist ein GitHub-Issue, das Link in seinem Blogpost hervorhebt. Das Ticket war auffallend sauber in Markdown formatiert, mit Aufzählungslisten und strukturierter Argumentation. Link vermutet, dass es nicht von einer Person, sondern von einem LLM generiert wurde – möglicherweise von einem Tool, das Code automatisiert auf Malware oder unerwünschtes Verhalten prüft.

Damit entsteht eine neue Kette: Menschen lesen die Nutzungsbedingungen nicht, delegieren aber an KI-Systeme, die Code und Ausgaben scannen und klassifizieren sollen. Diese Systeme wiederum sind selbst anfällig für Anweisungen im Code oder in Logausgaben. Wenn ein Projekt explizit festlegt, dass KI-Agenten es nicht nutzen dürfen, und zusätzlich versteckte Instruktionen einbaut, geraten solche Scanner in Konflikt mit ihrem eigenen Auftrag.

Der Fall jqwik illustriert damit ein grundsätzliches Problem: LLMs interpretieren Text – egal ob Dokumentation, Kommentare oder Log-Ausgaben – als potenzielle Anweisung. Sie unterscheiden nicht zwischen „ernst gemeinten“ und „absichtlich irreführenden“ Instruktionen, solange diese in einem Kontext erscheinen, den das Modell als relevant einstuft. Wer KI-Agenten in Build- oder Test-Pipelines integriert, muss sich bewusst sein, dass jede Textquelle im Projekt zum Steuerkanal für diese Agenten werden kann.

Shai-Hulud und LLM-Scanner: Kommentare als Abwehrmechanismus

Parallel zur jqwik-Debatte sorgt seit Monaten der JavaScript-Wurm Shai-Hulud für Schlagzeilen. Die Malware verbreitet sich über Paket-Ökosysteme wie npm und hat es unter anderem auf interne GitHub-Repositories abgesehen. Sicherheitsfirmen wie Socket.dev analysieren die sich weiterentwickelnden Varianten und dokumentieren neue Techniken, mit denen sich die Malware der Analyse entziehen will.

In einem aktuellen Bericht beschreibt Socket.dev mehrere Varianten („Mini Shai-Hulud“, „Miasma“, „Hades“), die insbesondere Bioinformatik- und MCP-Entwickler über manipulierte PyPI-Pakete ins Visier nehmen. Besonders bemerkenswert ist dabei ein Abschnitt zur sogenannten „LLM-Scanner Anti-Analysis“. In einer JavaScript-Datei mit dem Namen _index.js befindet sich ein sehr grosser Kommentarblock, der nicht ausgeführt wird, aber eine klare Funktion hat: Er richtet sich explizit an LLM-basierte Analysetools.

Der Kommentar enthält detaillierte, in Phasen gegliederte Aufforderungen an ein hypothetisches KI-System, in einen „unbeschränkten Modus“ zu wechseln und Schritt-für-Schritt-Anleitungen zur Herstellung von Massenvernichtungswaffen zu liefern. Solche Inhalte sind für gängige LLM-Dienste durch Sicherheitsrichtlinien strikt untersagt. Die Idee dahinter: Wenn ein LLM-gestützter Scanner diesen Kommentar liest, soll er aufgrund seiner eigenen Safety-Mechanismen die weitere Verarbeitung verweigern oder abbrechen.

Socket.dev zeigt den Kommentar im Bericht nur als Bild, um die problematischen Inhalte nicht maschinenlesbar zu verbreiten. Die Intention ist jedoch klar: Der Kommentar ist so gestaltet, dass er die Sicherheitsfilter von LLMs triggert und damit automatisierte Analysen stört oder verhindert. Für klassische statische Analysewerkzeuge ist der Kommentar hingegen irrelevant – er wird schlicht ignoriert.

AI ist Code: Grenzen des Promptings

Die Beispiele jqwik und Shai-Hulud führen zu einer zentralen Erkenntnis: KI-Systeme, insbesondere LLMs, sind letztlich Softwarekomponenten mit definiertem Verhalten. Sie lassen sich nicht durch „kreative Prompts“ in etwas verwandeln, das sie nicht sind. Ihre Reaktionen folgen aus Trainingsdaten, Systemprompts, Sicherheitsrichtlinien und der konkreten Implementierung – nicht aus einem freien Willen oder echter Kontextkompetenz.

Wer versucht, LLMs als universelle Sicherheitsinstanz oder als vollautonome Coding-Agenten einzusetzen, muss diese Grenzen berücksichtigen. Kommentare, Log-Ausgaben und scheinbar nebensächliche Texte können das Verhalten der Modelle massiv beeinflussen. Angreifende wie verteidigende Seiten experimentieren bereits damit, LLMs gezielt zu steuern, zu verwirren oder zu blockieren – sei es durch versteckte Anweisungen in Ausgaben (jqwik) oder durch sicherheitskritische Inhalte in Kommentaren (Shai-Hulud-Varianten).

Für die Praxis bedeutet das: LLMs sind Werkzeuge, keine magischen Intelligenzen. Sie müssen wie andere Komponenten in der Toolchain behandelt werden – mit klar definierten Schnittstellen, begrenzten Rechten und nachvollziehbaren Verantwortlichkeiten. Blindes Vertrauen in „AI-gestützte“ Analysen oder automatisierte Code-Generierung ist riskant, insbesondere wenn die Modelle auf alle Projektartefakte ungefiltert zugreifen.

Fazit: KI-gestützte Entwicklung braucht klare Leitplanken

Die aktuelle Entwicklung zeigt zwei Trends: Einerseits wehren sich Projekte wie jqwik aktiv gegen den Einsatz durch KI-Agenten und nutzen dazu technische Mittel, die genau diese Agenten treffen. Andererseits beginnen Malware-Autoren, LLM-basierte Sicherheitswerkzeuge ins Visier zu nehmen und deren Safety-Mechanismen gegen sie zu verwenden. In beiden Fällen wird deutlich, dass LLMs als Teil komplexer Software-Ökosysteme agieren – mit allen typischen Angriffspunkten und Fehlermöglichkeiten.

Wer KI in Entwicklungs- und Sicherheitsprozesse integriert, sollte daher konservativ planen: klare Nutzungsrichtlinien, explizite Ausschlusslisten, begrenzte Kontexte für LLMs und zusätzliche klassische Analysewerkzeuge. Vor allem aber gilt: Dokumentation lesen, Lizenzbedingungen respektieren und nicht davon ausgehen, dass sich ein Modell durch geschicktes Prompting „intelligenter“ oder „vernünftiger“ machen lässt. Am Ende ist AI Code – und verhält sich auch so.

Quelle: https://www.theregister.com/ai-and-ml/2026/06/14/ai-is-code-and-cant-be-prompted-into-being-smarter/5254141