Die fehlende Sicherheitsgrenze in LLMs: Warum W^X nicht greift

Zusammenfassung

In modernen Betriebssystemen verhindert das W^X-Prinzip (Write XOR Execute), dass Angreifer Daten in ausführbaren Code verwandeln.

Transformer-basierte LLMs, die in modernen KI-Anwendungen zum Einsatz kommen, können W^X nicht durchsetzen, weil sie sämtlichen eingehenden Text als Teil ihres ausführbaren Kontexts behandeln.

Dadurch kann jede Eingabe das Verhalten beeinflussen, als wäre sie eine Anweisung – was adversariale Prompts unvermeidlich macht.

Schutzschichten wie Guardrails, Fine-Tuning oder Sandboxing können das Risiko senken, doch keine davon kann diese grundlegende architektonische Beschränkung beseitigen.

Einleitung

Eine der grundlegendsten Ideen moderner Softwaresicherheit ist das W^X-Prinzip: Speicher darf entweder beschreibbar oder ausführbar sein, aber niemals beides. Diese Trennung verhindert Code-Injection-Angriffe, indem sie sicherstellt, dass in den Speicher gelegte Daten – selbst wenn ein Angreifer sie präpariert hat – nicht als aktive Anweisungen ausgeführt werden können. Das Prinzip ist einfach, wirksam und tief darin verankert, wie Betriebssysteme vor bösartigen Angriffen geschützt werden.

Large Language Models jedoch haben keine solche Grenze. Sie können nicht zwischen Text, der als passive Daten behandelt werden sollte, und Text, auf den das Modell reagieren sollte, unterscheiden. Die Transformer-Architektur verschmilzt System-Prompts, Nutzereingaben und Tool-Anweisungen zu einer einzigen kontinuierlichen Folge von Tokens. Alles, was das Modell liest, wird Teil der internen Berechnung, die entscheidet, was es als Nächstes ausgibt.

Es gibt keinen Begriff von „Read-only-Daten", kein Berechtigungs-Flag für die Ausführung und keine Isolation zwischen Rollen. Von ihrer Konstruktion her behandeln LLMs jede Eingabe als ausführbar.

Wie Transformer-LLMs funktionieren: Jede Eingabe wird ausführbar

Transformer-Modelle arbeiten über einen einfachen Mechanismus. Der gesamte eingehende Text wird in Tokens umgewandelt, und das Modell verarbeitet die vollständige Sequenz auf einmal. Es sagt das nächste Token voraus, indem es gelernte statistische Muster auf jedes vorangegangene Token im Kontextfenster anwendet.

Auch wenn die Anwendungsschicht Teile der Eingabe als „System-Anweisungen", „Tool-Beschreibungen" oder „Nutzernachrichten" kennzeichnet, behandelt das Modell selbst diese Kategorien nicht unterschiedlich. Das Modell sieht nur eine einzige geordnete Liste von Tokens, und jedes davon beeinflusst die Wahrscheinlichkeitsverteilung des nächsten.

Deshalb haben ein System- und ein Nutzer-Prompt innerhalb des Modells keine harte Trennung. Diese Unterscheidungen existieren nur außerhalb des Modells, als Metadaten für Entwickler und Anwendungen. Sobald der Text in den Transformer gelangt, konkurriert alles gleichberechtigt darum, das Verhalten des Modells zu formen.

Wenn ein Nutzer versteckte Anweisungen oder adversariale Formulierungen einschleust, verarbeitet das Modell diese Tokens auf exakt dieselbe Weise wie die eigenen Sicherheitsregeln des Systems. Transformer stützen sich auf statistische Muster, die während des Trainings gelernt wurden, nicht auf strukturelle Grenzen.

Für ein LLM ist jede Eingabe – unabhängig von ihrer Kennzeichnung – Teil seines ausführbaren Kontexts.

Diese architektonische Eigenschaft ist es, die Prompt Injection möglich macht.

Warum Prompt Injection unvermeidlich ist

Das Paper Universal and Transferable Adversarial Attacks on Aligned Language Models zeigt, wie sich diese architektonische Schwäche in der Praxis ausnutzen lässt.

Die Autoren demonstrieren, dass sehr kurze Textsequenzen – manchmal nur wenige Tokens – LLMs zuverlässig dazu zwingen können,

• Sicherheitsbeschränkungen zu ignorieren,
• eingeschränkte oder interne Systeminformationen preiszugeben,
• das Alignment-Training zu umgehen,
• sich auf eine Weise zu verhalten, die der Systemgestalter nicht beabsichtigt hat.

Diese präparierten Sequenzen ähneln keinen Anweisungen. Sie wirken oft zufällig oder bedeutungslos. Werden sie jedoch an eine ansonsten harmlose Anfrage angehängt, bringen sie das Modell dazu, einer versteckten, unbeabsichtigten Logik zu folgen.

Das funktioniert, weil adversariale Suffixe die Wahrscheinlichkeitslandschaft, die das Modell für die Vorhersage des nächsten Tokens nutzt, subtil verschieben und so die Wahrscheinlichkeit erhöhen, dass das Modell dem vom Angreifer beabsichtigten Verhalten folgt. Das Modell „entscheidet" sich nicht, Regeln zu brechen; es setzt lediglich sein statistisches Muster-Matching auf einer Sequenz fort, die gezielt manipuliert wurde.

Ein Beispiel im Paper zeigt ein Modell, das eine schädliche Frage konsequent verweigert – bis ein adversariales Suffix angehängt wird. Mit dem Suffix beantwortet das Modell die Frage nicht nur, sondern legt auch internes Reasoning offen, das es zuvor zurückgehalten hatte. Ein weiteres Beispiel zeigt, wie ein Suffix das Modell dazu bringen kann, System-Anweisungen wiederzugeben, die der Nutzer niemals sehen sollte.

Der beunruhigendste Aspekt ist die Übertragbarkeit. Ein bösartiges Suffix, das für ein LLM gefunden wurde, funktioniert häufig auch bei anderen – selbst bei anderen Modellanbietern. Das deutet stark darauf hin, dass die Schwachstelle aus der gemeinsamen Transformer-Architektur stammt und nicht aus einer spezifischen Implementierung oder Trainingsmethode.

Das ist faktisch Code-Injection ohne Code. Der Angriff verbirgt sich in dem, was eigentlich „Daten" sein sollten, und das Modell führt ihn aus, weil Transformer keine Grenze durchsetzen können, die W^X ähnelt.

Warum Abwehrmaßnahmen das Risiko nur senken, nicht beseitigen können

Viele Fachleute hoffen, dass Guardrails, Fine-Tuning, Eingabefilterung oder spezielle Wrapper-Systeme dieses Problem beheben. Diese Methoden können helfen, doch keine von ihnen verändert den Kernmechanismus des Modells. Sie wirken, als brächte man zusätzliche Schlösser an einer Tür an, die sich nicht vollständig schließen lässt. Die Tür lässt sich vielleicht schwerer versehentlich öffnen, doch wenn jemand auf die richtige Weise drückt, bleibt der Spalt bestehen.

Guardrails funktionieren als weitere LLM-Schicht, was bedeutet, dass sie sich durch dieselben Arten adversarialer Prompts umgehen lassen. Das Fine-Tuning von Modellen anhand bösartiger Prompt-Beispiele verbessert die Widerstandsfähigkeit, doch kein Datensatz kann ein Modell auf die unendlichen Variationen vorbereiten, die ein Angreifer erzeugen kann. Eingabefilterung hilft – bis eine adversariale Zeichenfolge auftaucht, die den Filter nicht auslöst. Sandboxing kann begrenzen, was das System tun kann, aber es kann nicht verändern, wie das Modell Eingaben interpretiert.

Die Transformer-Architektur unterscheidet schlicht nicht zwischen dem, was gespeichert werden soll, und dem, was ausgeführt werden kann. Kein externer Wrapper kann Sicherheit vollständig garantieren. Alle Abwehrmaßnahmen wirken um die Architektur herum, nicht in ihr.

Das ist kein Fehler, den sich patchen lässt. Es ist eine strukturelle Eigenschaft der Funktionsweise Transformer-basierter LLMs.

Fazit

Das W^X-Prinzip schützt Softwaresysteme seit Jahrzehnten, indem es sicherstellt, dass beschreibbare Daten nicht zu ausführbarem Code werden können. Large Language Models verletzen dieses Prinzip nicht – sie können schlicht nichts Vergleichbares umsetzen. Transformer behandeln jedes Token im Kontextfenster als Teil eines einzigen kontinuierlichen Rechenprozesses. Sie können nicht unterscheiden, was gelesen, und was befolgt werden soll, weil die Architektur keinen Mechanismus bietet, um Daten von Anweisung zu trennen.

Diese inhärente Konstruktionseigenschaft macht LLMs grundlegend anfällig für Prompt-Injection-Techniken. Die Forschung zeigt durchgängig, dass adversariale Eingaben Guardrails aushebeln, interne Logik offenlegen und das Modellverhalten auf unbeabsichtigte Weise beeinflussen können. Schutzschichten können die Auswirkungen mindern, aber sie können die Grundursache nicht beseitigen: Jede Eingabe bleibt standardmäßig ausführbar.

Solange LLMs eine starke, W^X-ähnliche Grenze fehlt – eine interne Trennung zwischen „zu verarbeitenden Informationen" und „auszuführenden Anweisungen" –, bleiben Injection-Angriffe unvermeidlich. Und da Tool-Nutzung und Multi-Agenten-Orchestrierung die Fähigkeiten und die Entscheidungsbefugnis des Modells erweitern, wächst die potenzielle Tragweite solcher Angriffe zusätzlich.

Bis diese architektonische Beschränkung behoben ist, werden LLMs in Unternehmensumgebungen weiterhin ein inhärentes Risiko tragen. Sie können ungeheuer leistungsstark sein, aber sie können noch nicht dieselben grundlegenden Sicherheitsgarantien bieten, auf die sich moderne Betriebssysteme verlassen.