Warum ein Modell falsch antwortet und dabei sicherer klingt als richtig
Erfundene Bibliotheken, erfundene Paragraphen, erfundene Zitate - vorgetragen ohne den kleinsten Zweifel. Das ist kein Aussetzer, sondern die direkte Folge davon, worauf das Modell trainiert wurde.
30. Juli 2026halluzination · vertrauen · training
Ein Modell nennt eine Funktion, die es nicht gibt. Es zitiert einen Paragraphen, den niemand je geschrieben hat. Und es tut das nicht zögernd, sondern im selben festen Ton wie bei allem anderen. Ärgerlich ist selten der Fehler - ärgerlich ist, dass er nicht anders klingt als das Richtige.
Flüssigkeit ist das Ziel, Wahrheit ein Nebeneffekt
Ein Sprachmodell wird darauf trainiert, das nächste Token vorherzusagen. Sein gesamtes Können ist die Antwort auf die Frage: Was steht in einem Text dieser Art üblicherweise an dieser Stelle? Wahrheit ist in dieser Aufgabe nirgends vorgesehen. Sie kommt nur mit, weil in den Trainingsdaten meistens Zutreffendes steht.
Damit liegt der Fehlermodus fest. Fehlt dem Modell eine Tatsache, entsteht keine Lücke - denn eine Lücke wäre unwahrscheinlich. Es entsteht das, was an dieser Stelle plausibel ist: ein Funktionsname, der genau so gebaut ist wie die echten Funktionsnamen dieser Bibliothek. Eine Paragrafennummer im richtigen Format. Eine Quelle mit passendem Autor, passendem Jahr, passendem Verlag. Die Erfindung ist kein Ausrutscher, sondern das gewissenhafte Ergebnis derselben Maschinerie, die sonst richtig liegt.
Der Ton ist ein Stil, kein Messwert
Dazu kommt, dass Sicherheit im Ausdruck selbst ein gelerntes Muster ist. Wenn ein Modell schreibt „Das ist definitiv der Fall", dann hat es nicht in sich hineingehorcht, sondern die Formulierung gewählt, die zu einem Text dieser Sorte passt. Erklärungen in Handbüchern, Antworten auf Fachfragen, Dokumentation - die Vorlagen in den Trainingsdaten sind fast durchweg selbstbewusst geschrieben. Zögern kommt darin kaum vor.
Die anschließende Feinabstimmung auf Hilfsbereitschaft verstärkt das eher, als dass sie es dämpft: Bewertet wurde die Antwort, die weiterhilft, und eine klar formulierte Antwort wirkt hilfreicher als eine mit drei Vorbehalten. Wer also aus dem Tonfall auf Verlässlichkeit schließt, liest ein Stilmerkmal als Messwert.
Guardrails
Die Hausordnung des Agenten: was er nie tun darf, wie Fehler abgefangen werden - und warum Grenzen kein Misstrauen sind, sondern Architektur.
Ein Agent, der handeln kann, braucht Grenzen: Eingaben prüfen, Ausgaben filtern, gefährliche Aktionen stoppen, Fehler sauber behandeln. Guardrails machen aus einem Experiment ein System, dem man Arbeit anvertrauen kann.
Ein produktiver Agent kann Geld bewegen, Daten löschen, Mails an Kunden schreiben. Was er nicht darf, ist genauso wichtig wie das, was er kann.
Guardrails greifen auf mehreren Ebenen: Prompt-Constraints, Tool-Whitelists, Output-Filter, Rate-Limits, sandboxed execution. Und der wichtigste Guardrail: Threat Modeling, bevor das System live geht.
Die Verteidigungsleiter
Der häufigste Angriff auf einen Agenten ist auch der billigste: man redet mit ihm. Prompt Injection heißt, Anweisungen dorthin zu schmuggeln, wo das Modell Daten erwartet - in eine Kundennachricht, in ein Dokument, in eine Webseite, die ein Tool gerade abruft. Das Modell unterscheidet nicht zwischen „das ist mein Auftrag" und „das ist der Text, über den ich reden soll". Beides ist für es dasselbe: Zeichen im Kontext.
Verteidigung dagegen ist keine Entscheidung, sondern eine Leiter. Jede Stufe fügt genau eine Schicht hinzu, und jede Schicht hat einen Angriff, an dem sie zerbricht:
| Stufe | Verteidigung | Was sie bricht |
|---|---|---|
| 0 | keine | direkt fragen |
| 1 | System-Prompt-Härtung | Rollenspiel, Umdeutung |
| 2 | Ausgabefilter, fest verdrahtet | Kodierung, Akrostichon, buchstabenweise |
| 3 | Ausgabefilter, modellbasiert | Umschreibung, Verteilung über eine Geschichte |
| 4 | Eingabefilter, fest verdrahtet | Synonyme, Fremdsprache |
| 5 | Eingabefilter, modellbasiert | harmlose Aufträge mit versteckter Nutzlast |
| 6 | alles zusammen + Domänen-Einschränkung | fast nur noch narrativ |
Die Leiter hat eine Achse, die man beim ersten Lesen leicht übersieht: Eingabe gegen Ausgabe und fest verdrahtet gegen modellbasiert. Ein fest verdrahteter Filter sucht Zeichen - er ist schnell, kostenlos und blind für Bedeutung, deshalb rutscht Base64 durch. Ein modellbasierter Wächter versteht Bedeutung - er ist langsam, kostet einen zweiten Modellaufruf und lässt sich selbst überreden, denn er ist ja auch nur ein Modell mit einem Prompt.
Und: Eingabefilter greifen zu früh, um zu wissen, was passieren wird, Ausgabefilter zu spät, um zu verhindern, dass es passiert ist. Deshalb steht am Ende der Leiter nicht eine bessere Schicht, sondern alle zusammen.
Was 279 000 echte Angriffe zeigen
Über die Wirksamkeit dieser Schichten muss man nicht spekulieren. Lakera hat in Gandalf the Red die Angriffe auf ein öffentliches Prompt-Injection-Spiel ausgewertet - 279 000 echte Versuche von echten Menschen, gegen abgestuft verteidigte Systeme. Drei Befunde daraus sind der Unterschied zwischen Spielwissen und Berufswissen:
- Schichtung wirkt, Einzelschichten nicht. Keine der Schichten hält allein stand; jede hat ihren Angriff. Erst die Kombination senkt die Erfolgsquote deutlich - nicht weil eine der Schichten besser würde, sondern weil ein Angriff plötzlich alle gleichzeitig überlisten muss.
- Domänen-Einschränkung ist die stärkste Einzelmaßnahme. Ein Bot, der nur über ein Thema reden darf, ist weit schwerer zu kapern als ein Alleskönner. Nicht, weil er besser bewacht wäre - sondern weil es fast keinen Weg gibt, ihn außerhalb seines Themas überhaupt anzusprechen.
- Verteidigung im System-Prompt kostet Nutzbarkeit, auch wenn sie nichts blockt. Jeder Satz „tu dies niemals" macht das Modell vorsichtiger, wortkarger, misstrauischer gegenüber harmlosen Fragen. Sicherheit und Brauchbarkeit sind eine gemeinsame Zielgröße, keine zwei getrennten. Deshalb taugt ein Spiel, in dem nur die Sicherheit zählt, nicht als Vorlage für Produktions-Guardrails.
Die OWASP Top 10 für LLM-Anwendungen führt Prompt Injection seit ihrer ersten Fassung als LLM01 - die erste Position, und in der Ausgabe 2025 unverändert dort. Ihre Empfehlungen lesen sich wie die Leiter oben, mit einer ausdrücklichen Einschränkung: Keine Einzelmaßnahme löst die Klasse. OWASP spricht von Risikominderung, nicht von Behebung.
Ein Beispiel aus dem eigenen Haus
Die wirksamste Maßnahme steht in keiner Filterliste, weil sie keine ist: Nutzertext gehört nicht in den System-Prompt. Genau das macht der Kommentar-Agent dieser Seite in src/lib/comments/agent.ts - der System-Prompt ist eine feste Zeichenkette, der Kommentar geht als User-Message hinterher:
/**
* System-Prompt des Kommentar-Agenten. Der Kommentar selbst geht als
* User-Message ins Modell, NIE hier hinein - das dämpft Prompt-Injection:
* Anweisungen im Kommentar bleiben Daten.
*/
export function buildCommentAgentPrompt(candidates: SearchDoc[]): string {
Der Unterschied ist strukturell, nicht kosmetisch. Würde der Kommentartext in den System-Prompt interpoliert, stünde ein „Ignoriere alle vorherigen Anweisungen" auf derselben Ebene wie die Anweisungen des Betreibers - sie wären dieselbe Ebene. So bleibt er eine Rolle tiefer. Das ist keine Garantie: Modelle folgen auch Anweisungen aus User-Messages. Aber es ist der Unterschied zwischen einem Angriff, der über die Rollenhierarchie hinweg überzeugen muss, und einem, der einfach mitgeschrieben wird.
Dazu kommt im selben Modul die zweite Hälfte: Der Prompt sagt dem Modell ausdrücklich, dass der Kommentar untrusted user data ist, und die Antwort ist auf ein enges Schema festgelegt. Ein gekaperter Agent kann so bestenfalls das Falsche in ein Feld schreiben, das ohnehin nur drei Werte annehmen darf - Schadensbegrenzung durch Form, nicht durch Wachsamkeit.
Der unbequeme Schluss
Prompt Injection ist nicht gelöst. Es gibt keine Bibliothek, kein Modell und keinen Anbieter, der die Klasse schließt; es gibt nur Systeme, bei denen sie seltener trifft und weniger anrichtet. Beides ist erreichbar, und beides ist Ingenieursarbeit: Trefferquote senken durch Schichtung und Domänen-Einschränkung, Schaden begrenzen durch enge Tool-Rechte, Bestätigungen vor irreversiblen Aktionen und Protokolle, die zeigen, was passiert ist.
Wer stattdessen auf den einen richtigen System-Prompt wartet, baut sein System auf ein Versprechen, das niemand gegeben hat.
Es gibt ein Signal - nur nicht im Text
Das Modell ist nicht völlig ahnungslos über die eigene Unsicherheit. Bei jedem Token liefert es eine Wahrscheinlichkeitsverteilung mit, und wenn es rät, ist diese Verteilung flacher: Fünf Kandidaten liegen dicht beieinander, statt dass einer klar führt. Diese Zahlen (die Logprobs) kommen aber nicht in der Ausgabe an - der Text ist die gezogene Stichprobe, nicht das Maß ihrer Wackeligkeit. Und die Sprache, in der ein Mensch Unsicherheit ausdrücken würde („ich glaube", „womöglich"), ist selbst nur wieder Text, der genauso vorhergesagt wird wie alles andere.
Anders gesagt: Der Kanal, auf dem das Modell Zweifel hätte, und der Kanal, auf dem wir sie ablesen, sind zwei verschiedene Kanäle.
Was beim Bauen daraus folgt
Wer Agenten baut, kann die Neigung nicht wegprompten - „erfinde nichts" ist ein Wunsch, keine Sperre. Was hilft, ist Bauweise:
Nachprüfbarkeit statt Beteuerung. Die Antwort soll nicht behaupten, sondern belegen: Dateipfad und Zeile, Quelle mit Fundstelle, das rohe Werkzeugergebnis daneben. Ein Beleg lässt sich prüfen, ein Ton nicht.
Nachschlagen schlägt Erinnern. Ein Werkzeug, das die tatsächliche Bibliotheksschnittstelle liest, verschiebt die Frage vom Gedächtnis in die Gegenwart. Genau darum geht es beim Werkzeuggebrauch und bei RAG - nicht darum, mehr zu wissen, sondern darum, weniger zu raten.
Ausführen ist das ehrlichste Urteil. Erfundener Code fällt beim Übersetzen auf, erfundene Endpunkte beim Aufruf. Ein Agent mit einem Rückkanal aus der Wirklichkeit korrigiert sich selbst; einer ohne bleibt bei seiner ersten, wohlklingenden Version.
Unsicherheit erzwingen, wo sie zählt. Ein „unbekannt" als ausdrücklich erlaubter Ausgabewert in einem strukturierten Schema wird deutlich häufiger genutzt als ein „sag Bescheid, wenn du es nicht weißt" im Fließtext. Was angeboten wird, wird auch gewählt.
Die nützlichste Gewohnheit ist am Ende die einfachste: Vom Ton auf gar nichts schließen. Er ist ein Merkmal des Textes, nicht seines Wahrheitsgehalts.