Eine Million Token gehen hinein, nur viertausend werden geprüft

Die drei Lücken, die in fast jeder KI-Architektur offenstehen

Ein kurzer Prompt wird geprüft. Derselbe Prompt, viertausend Wörter länger, geht ungeprüft durch. Das ist kein Einzelfall, sondern eine Eigenschaft der üblichen Bauweise.

Drei Lücken stehen in fast jeder Architektur offen: Der Wächter sieht weniger als das Modell, er liest nur Text, und der Weg um ihn herum ist ab Werk eingebaut. Zu jeder stehen hier die veröffentlichten Messwerte, und zur dritten die Dokumentation eines großen Anbieters, die das Überspringen des Filters ausdrücklich beschreibt.

Die Schicht, die zuletzt gebaut und zuerst gestrichen wird

In fast jeder KI-Architektur ist dieselbe Schicht die dünnste: die Schutzschicht. Das liegt selten an Nachlässigkeit. Es liegt daran, dass sie in der Projektlogik an der falschen Stelle steht. Modellauswahl, Datenanbindung, Retrieval, Oberfläche und Betrieb erzeugen sichtbaren Fortschritt. Die Schutzschicht nicht. Sie verhindert Ereignisse, die noch gar nicht eingetreten sind. Also wandert sie ans Ende der Liste, und am Ende der Liste steht der Termin.

Was dann eingebaut wird, ist meist eines von drei Dingen: eine Anweisung im Systemprompt („Du darfst niemals …“), ein Aufruf einer Moderations-API auf den Eingabetext, oder ein kleines Klassifikationsmodell vor dem eigentlichen Sprachmodell. Alle drei sind besser als nichts. Keine der drei hält dem stand, was heute an Eingaben auf ein produktives System trifft.

Der Grund ist nicht die Qualität der eingesetzten Modelle. Der Grund ist eine strukturelle Lücke zwischen dem, was der Wächter sieht, und dem, was das Sprachmodell verarbeitet. „Wächter“ steht hier durchgehend für das, was in der Literatur Guard-Modell heißt: ein Modell, dessen einzige Aufgabe die Bewertung von Eingaben und Ausgaben ist. Sie hat drei Ausprägungen: die Länge der Eingabe, die Art der Eingabe, und die Umgehungspfade der eigenen Architektur.

Wie sich Prompt Injection in die größere Bedrohungslage einordnet, zeigt unser Überblick zu den OWASP LLM Top 10.

Lücke 1: Der Wächter sieht weniger als das Modell

Der Wächter sieht einen Ausschnitt, das Modell das Ganze

Schutzmodelle werden bewusst klein gehalten, damit sie schnell und günstig antworten. Klein heißt aber auch: kurzes Kontextfenster.

Prüfkomponente Fenster Bei Überschreitung Verbreiteter Injektionsdetektor (86M Parameter) 512 Token, rund 350 Wörter Sache des Aufrufers Toxizitätsklassifikator (125M Parameter) 512 Token Sache des Aufrufers Gehosteter Moderationsdienst A 10.000 Zeichen Fehler, kein Abschneiden Gehosteter Moderationsdienst B Einheiten zu 1.000 Zeichen zerlegt, rechnet je Einheit ab Gehosteter Moderationsdienst C 10.000 Token für Injektionserkennung überspringt den Filter Bestes offenes Wächtermodell, August 2026 32.768 Token trainiert (256k rechnerisch) zerlegen Dasselbe Modell auf einer 16-GB-Karte 4.096 Token zerlegen Dasselbe Modell auf einer 48-GB-Karte volle 32.768 Token selten nötig Sprachmodell dahinter 128.000 bis über 1.000.000 Token —

Die Zeile zum Wächtermodell ist neu. Seit dem 4. August 2026 gibt es ein offenes Guard-Modell, das auf Sequenzen bis 32.768 Token trainiert ist. Das ist das größte trainierte Kontextfenster, das für ein offen verfügbares Modell dieser Art belegt ist. Es ändert die Lage, aber nicht so weit, wie es zunächst aussieht: Gegen eine Million Token Eingabe bleibt Faktor 30.

Die beiden mittleren Zeilen sind die unangenehmen: Das trainierte Fenster ist nicht das Fenster, das man einstellt — es hängt am Speicher der Karte, und zwischen 16 und 48 Gigabyte liegt Faktor acht im nutzbaren Kontextfenster. Warum, steht in Teil 3 – die zugrunde liegenden GPU-Speicherklassen erklärt unser Dimensionierungs-Guide.

Bemerkenswert ist die rechte Spalte, und besonders ihre letzte Zeile. Dass eine zu lange Eingabe die Prüfung nicht ablehnt, sondern den Filter überspringt, ist keine Eigenart einer selbstgebauten Anbindung. Es steht so in der Dokumentation eines großen Anbieters: Überschreitet die Eingabe das Limit, meldet der Filter „Ausführung übersprungen“ und die Anfrage läuft weiter. Wer diesen Rückgabewert nicht auswertet, hat den Ersatzpfad aus Lücke 3 eingekauft, ohne eine Zeile Code dafür geschrieben zu haben.

Alles jenseits des nutzbaren Kontextfensters wird in Stücke zerlegt. Oder gar nicht geprüft.

Genau hier setzt der wirksamste bekannte Angriff an. Eine Untersuchung aus dem Jahr 2026 verteilt eine schädliche Anweisung gezielt so über eine lange Eingabe, dass jeder einzelne Prüfabschnitt für sich harmlos aussieht. Das Sprachmodell sieht die Eingabe vollständig, setzt die Bruchstücke zusammen und führt sie aus. Die gemessenen Umgehungsquoten:

Die letzte Zeile ist aufschlussreich: Zufälliges Füllmaterial fällt auf, natürlichsprachiges nicht. Ein Angreifer nimmt natürlichsprachiges.

Warum die übliche Gegenmaßnahme nicht greift

Wer einen langen Text prüfen will, zerlegt ihn in Blöcke, bewertet jeden Block und nimmt den höchsten Wert. Diese Aggregation über max() verstärkt eine Entscheidung nur dann, wenn mindestens ein Abschnitt ein starkes Signal zeigt. Wer die schädliche Anweisung bewusst über viele Abschnitte streut, sorgt dafür, dass jeder Abschnitt schwach bleibt. Das Maximum von lauter kleinen Werten ist ein kleiner Wert. Die Prüfung meldet „unauffällig“ und hat dabei formal korrekt gearbeitet.

Was hilft, ist keine größere Prüfkomponente, sondern eine zustandsbehaftete Bewertung über alle Fenster hinweg:

GRUNDPEGEL = 0.1093 # an eigenen, unauffälligen Daten kalibriert
SCHWELLE = 0.50

def bewerte_lang(text, detektor):
werte = [detektor.score(f) for f in zerlege(text, 512, 256)]
summe, lauf, vorheriger = 0.0, 0, 0.0
for wert in werte:
ueberschuss = max(0.0, wert - GRUNDPEGEL)
if ueberschuss > 0:
lauf += 1
if lauf == 2: # Serie beginnt: erstes Fenster nachtragen
summe += vorheriger + ueberschuss
elif lauf > 2:
summe += ueberschuss
vorheriger = ueberschuss
else:
lauf, vorheriger = 0, 0.0
return summe >= SCHWELLE or max(werte) >= 0.9

Zwei Bausteine greifen hier ineinander. Summiert wird nur der Anteil oberhalb eines kalibrierten Grundrauschens, so ergeben viele leicht erhöhte Fenster gemeinsam ein Signal. Und summiert wird nur, wenn mindestens zwei aufeinanderfolgende Fenster erhöht sind, was vereinzelte Ausreißer harmloser Texte unterdrückt.

Ein Detail daran entscheidet über die Wirksamkeit und wird beim Nachbauen regelmäßig übersehen: Wenn die Serie beim zweiten Fenster anerkannt wird, muss das erste nachgetragen werden. Wer erst ab dem zweiten summiert, verwirft bei jeder Serie genau das Fenster, mit dem der Angriff begonnen hat — und bei einer Serie der Länge zwei die Hälfte des gesamten Signals. Der Grundpegel ist dabei kein universeller Wert. Er muss an den eigenen unauffälligen Produktionsdaten bestimmt und bei jedem Modellwechsel neu gemessen werden.

Lücke 2: Der Wächter liest, aber sieht und hört nicht

Systeme nehmen längst nicht mehr nur Text entgegen. Es kommen Dokumentenscans, Fotos, Bildschirmaufnahmen, Sprachnachrichten, Telefonate und Videoclips. Die Schutzschicht dagegen ist in der überwiegenden Zahl der Installationen rein textbasiert.

Bei Bildern brechen gleich drei Wege die Textprüfung. Eine Anweisung, die als Text blockiert würde, passiert die Prüfung, sobald sie als Schrift in einem Bild steht. Das Sprachmodell liest sie, der Textfilter nicht. Hinzu kommt die semantische Lücke: Die Sicherheitsausrichtung der Modelle wurde überwiegend auf Text trainiert, visuell transportierte Absicht löst die entsprechenden internen Konzepte oft nicht aus. Eine Untersuchung aus 2026 misst für einen visuell kodierten Angriff gegen ein aktuelles Modell 40,9 Prozent Erfolg gegenüber 10,7 Prozent für dieselbe Aussage in Textform. Drittens gibt es berechnete Störmuster, die für Menschen unauffällig sind und die interne Darstellung verschieben.

Bei Sprache ist die Lage schlechter und bei Video am schlechtesten. Für offene Audiomodelle ohne Schutzmechanismus werden Erfolgsquoten um 69 Prozent für schädliche Spracheingaben gemessen, der stärkste audiospezifische Angriff eines Prüfstands erreicht 96,2 Prozent. Video bringt zusätzlich die Zeitachse mit: Ein Ablauf kann Bild für Bild unauffällig sein und erst in der Reihenfolge schädlich werden.

Alle drei Modalitäten sind abzudecken, jede auf eigene Weise. Wie, steht in Teil 7.

Lücke 3: Der Umgehungspfad ist eingebaut

Der Ersatzpfad, der die Schutzschicht aufhebt

Die dritte Lücke kommt nicht von außen, sondern aus der eigenen Architektur. Gemeint ist der Fallback: der Zweig, der greift, wenn die Prüfung nicht antwortet. Nahezu jede Einbindung eines Prüfdienstes sieht im Kern so aus:

async def pruefe_eingabe(text: str) -> bool:
try:
ergebnis = await wächter.check(text, timeout=0.4)
return ergebnis.sicher
except Exception:
logger.warning("Wächter nicht erreichbar, fahre fort")
return True # <-- die gesamte Schutzschicht, aufgehoben

Die Zahl im Beispiel ist dabei mit Bedacht gewählt: 400 Millisekunden liegen unter dem später gemessenen Median von 431 Millisekunden für ein volles Prüfstück, also einen Chunk in der üblichen Bezeichnung. Wer so einstellt, hat den Ersatzpfad nicht als Ausnahme gebaut, sondern als Regelfall, und die Schutzschicht ist im Normalbetrieb abgeschaltet. Das Zeitlimit gehört an der gemessenen Verteilung ausgerichtet, nicht an einer runden Zahl.

Aus Sicht der Verfügbarkeit ist der Zweig darüber die naheliegende Entscheidung. Der Dienst soll nicht ausfallen, nur weil ein Nebenaggregat klemmt. Aus Sicht der Sicherheit hebt dieser eine Zweig die gesamte Schutzschicht auf. Denn er ist von außen adressierbar, und zwar auf vier Wegen:

• Überlänge. Der Prüfdienst lehnt wegen Größenüberschreitung ab. Ein Angreifer erzeugt das durch bloße Textmenge.
• Zeitüberschreitung. Unter Last antwortet der Prüfer langsamer als das Zeitlimit. Auch das lässt sich provozieren.
• Unbekannter Typ. Eine Sprachnachricht, ein Video, ein unbekanntes Format: Der Zweig „kann ich nicht prüfen“ mündet in denselben return True.
• Modellwechsel. Fällt das primäre Modell aus und die Anwendung schaltet auf ein Ersatzmodell oder einen Ersatzanbieter um, läuft dieser Pfad in vielen Aufstellungen an der Prüfkette vorbei. Grund ist, dass die Prüfung an den Aufruf des primären Modells gebunden wurde statt an die Ausgangsschnittstelle.

Was solche autonom handelnden Systeme im Unternehmenseinsatz ausmacht, erklärt unser Enterprise-Guide zu KI-Agenten.

Drei Ersatzpfade, die keine Ausnahme auslösen

Die vier oben genannten Wege haben eine Gemeinsamkeit: Sie erzeugen wenigstens einen Eintrag im Protokoll. Es gibt drei weitere, die das nicht tun, und über die man in Bestandsaufnahmen regelmäßig stolpert.

Der erste sitzt in der Auswertung der Antwort, nicht im Aufruf. Der Wächter antwortet in einem Format, das der aufrufende Dienst nicht kennt — weil das Modell gewechselt wurde, weil eine Version das Format erweitert hat, weil ein Feld umbenannt wurde. Der Prüfaufruf war erfolgreich, die Antwort liegt vor, und die Auswertung liefert nichts. Wie sich das auswirkt, hängt an einer einzigen Zeile: Wird ein unlesbarer Befund als „nicht sicher“ behandelt, sperrt das System jeden Dialogschritt. Wird er als leer behandelt, läuft ein erkannter Angriff still durch. Verbreitet ist die zweite Variante, und sie ist die gefährlichere: Der Wächter findet den Angriff, und niemand erfährt davon.

Der zweite sitzt in der Verzeichnisabfrage des Vermittlungsdienstes. Gateways fragen ihre Prüfdienste ab, welche Modelle sie bedienen. Antwortet ein Dienst darauf nicht, sieht er aus wie einer ohne Modelle — und wird übersprungen. Keine einzige Prüfung schlägt fehl, keine Zeitüberschreitung, keine Ausnahme. Der Wächter ist einfach nicht mehr in der Kette.

Der dritte ist eine Bereitschaftssonde, die auf den falschen Port zeigt. Das Muster ist in Bestandsaufnahmen leicht zu erkennen: dreistellige Zahlen von Fehlschlägen in Folge, während der richtige Endpunkt in wenigen Millisekunden mit „in Ordnung“ antwortet. Eine Sonde, die immer rot ist, wird nach dem dritten Tag ignoriert, und genau dann fällt der echte Ausfall nicht mehr auf.

Die Zahl, die fast niemand erhebt

In Bestandsaufnahmen stellen wir regelmäßig dieselbe Frage: Wie oft hat der Prüfdienst im letzten Monat nicht geantwortet? Die Antwort steht in jedem Protokoll und wird fast nie gelesen. Wo wir sie erheben, ist sie regelmäßig dreistellig, und in einer untersuchten Aufstellung machten diese Einträge 58 Prozent aller Protokolleinträge der Schutzschicht aus. Der Rest, die echten Funde, war die Minderheit.

Was daraus folgt, hängt an einer einzigen Einstellung, und beide Antworten sind unangenehm. Wer im Zweifel sperrt, weist im Monat dreistellig viele legitime Anfragen ab. Wer im Zweifel durchlässt, hat ebenso viele ungeprüfte Anfragen und merkt nichts davon. Zwei entgegengesetzte Fehler, derselbe blinde Fleck.

Das verschiebt die Prioritäten, und zwar bevor über Angriffstechniken geredet wird. Am meisten bringt an dieser Stelle die Verfügbarkeit — zwei Instanzen mit Lastverteilung statt einer je Umgebung —, und erst danach das bessere Modell. So bauen wir es, und wir weisen es nach statt es zu behaupten: aktive Instanz gestoppt, acht Anfragen über die Kette, achtmal beantwortet.

Das Muster in seiner reinsten Form: Kurze Anfrage, Prüfung greift, Ablehnung. Dieselbe Anfrage mit 4.000 Wörtern harmlosem Vorspann, Prüfung überschreitet ihr Fenster, Ersatzpfad greift, Anfrage geht ungeprüft an das Sprachmodell. Der Angreifer muss den Schutz also gar nicht brechen. Es reicht, ihn zu überfüllen.

Eine tragfähige Antwort hat fünf Eigenschaften. Das Rückfallverhalten ist konfiguriert und je Anwendungsfall dokumentiert, statt im Ausnahmezweig versteckt zu sein. Jeder Rückfall wird gezählt und ist alarmierbar. Zwischen Durchlassen und Ablehnen gibt es einen dritten Ausgang, die entschärfte Weiterverarbeitung ohne Werkzeugzugriff. Die Prüfung hängt an der gemeinsamen Ausgangsschnittstelle, nicht am Aufruf eines bestimmten Anbieters. Und eine Antwort, die nicht ausgewertet werden kann, gilt als Fehler und nicht als Freispruch.

Die Schutzschicht gehört an die Stelle, die jeder Pfad passieren muss. Wird sie an einen Anbieter, ein Modell oder einen Anwendungszweig gebunden, entsteht mit dem nächsten Ersatzpfad automatisch ein Loch. Praktisch heißt das: Sie sitzt im Gateway, nicht in der Anwendung.

Genau nach diesem Prinzip ist Fugi Guardrails gebaut: eine Prüfung im Gateway, die jeden Aufruf zu 100 Prozent abdeckt – den vollen Kontext ohne Kürzung, Text und Bild, ohne Fail-open-Pfad.

Wie sich Guard- und Sprachmodelle abgesichert in eigener Infrastruktur betreiben lassen, beschreibt unser Praxis-Guide zum lokalen KI-Betrieb.

Weiter in Teil 2: Ein größeres Modell schließt die Lücke nicht

Die naheliegende Antwort auf eine zu kleine Prüfung ist ein größeres Prüfmodell. Teil 2 rechnet vor, warum das die Lücke nicht schließt, sondern verschiebt.

Quellen

1. Prompt Overflow: What the Guardrail Inspects Is Not What the Model Infers, arXiv 2605.23196
2. JALMBench: Benchmarking Jailbreak Vulnerabilities in Audio Language Models, arXiv 2505.17568; Audio Is the Achilles' Heel: Red Teaming Audio Large Multimodal Models, arXiv 2410.23861
3. SafeLens: Deliberate and Efficient Video Guardrails with Fast-and-Slow Screening, arXiv 2605.17610; GuardReasoner-Omni, arXiv 2602.03328
4. Dokumentation der gehosteten Moderationsdienste, abgerufen im August 2026: Zeichengrenze je Anfrage, Abrechnung in Einheiten zu 1.000 Zeichen, sowie die Token-Grenze der Injektionserkennung samt dokumentiertem Überspringen des Filters bei Überschreitung.
5. Eigene Messungen an einer produktiven KI-Suite, Juli und August 2026: Modellvergleich an 387 entdoppelten Protokolleinträgen, Latenz- und Durchsatzmessung auf einer 16-GB- und einer 48-GB-Karte, Bildpfadprüfung an zehn nachgebauten Geschäftsanhängen, sowie Befunde aus Bestandsaufnahmen bei Kunden. Zahlen anonymisiert wiedergegeben.

Die Reihe im Überblick

1. Eine Million Token gehen hinein, viertausend werden geprüft — Sie lesen diesen Teil
   
   Coming soon:
2. Ein größeres Modell schließt die Lücke nicht
3. Was die Hardware ändert, und was nicht
4. An den Eintrittsstellen prüfen, nicht am Kontext
5. Der Wächter als Angriffsziel
6. Maskieren statt sperren
7. Bild, Sprache und Video
8. Der europäische Sonderfall und die Modellwahl
9. Die Referenzarchitektur und die Muster, die sie verhindert
10. Was zuerst zu tun ist