Ersetzung generativer Richter durch Entscheidungsmodelle zur Abwehr von Prompt-Injection-Angriffen

StackOne hat seinen Defender-Schutz gegen Prompt Injection aktualisiert, indem es ein generatives großes Sprachmodell durch ein spezialisiertes Entscheidungsmodell ersetzte. Diese Änderung, die in einem technischen Beitrag vom 15. Oktober 2026 detailliert beschrieben wird, verlagert die letzte Stufe des Verteidigungssystems von einem textgenerierenden Richter zu einem probabilistischen Klassifikator, der vollständig innerhalb der lokalen Infrastruktur operiert.

Was passiert ist

Defender schützt tool-aufrufende Agenten, indem jedes Ergebnis überprüft wird, das von externen Tools zurückgegeben wird. Das System nutzt einen dreistufigen Ansatz, um Geschwindigkeit und Genauigkeit auszubalancieren. Stufe 1 führt schnelle Musterabgleiche in etwa einer Millisekunde durch. Stufe 2 verwendet einen 22 MB großen Klassifikator, der auf der CPU läuft und Zeichenketten in Zehntelsekunden bewertet. Bisher stützte sich Stufe 3 auf ein kleines generatives LLM, um mehrdeutige Fälle zu prüfen, die von Stufe 2 eskaliert wurden. Obwohl dieser generative Richter effektiv war, um Angriffe zu erkennen, war er teuer und langsam, da er GPU-Ressourcen benötigte und Hunderte von Millisekunden pro Aufruf beanspruchte. Aufgrund dieser Einschränkungen konnte er nur eine Teilmenge der Ergebnisse verarbeiten.

Das Engineering-Team suchte nach einer günstigeren und schnelleren Alternative für Stufe 3, die potenziell jedes Tool-Ergebnis zusammen mit Stufe 2 bewerten könnte, anstatt nur die unsicheren Fälle. Sie ersetzten den generativen Richter durch ein „System One“-Entscheidungsmodell. Dieser Modelltyp, der kürzlich von TypeSafe und Jev populär gemacht wurde, trifft Entscheidungen ohne Textgenerierung. Die neue Implementierung nutzt ein Entscheidungsmodell, das auf einem ModernBERT-Backbone basiert, auf einer einzigen kleinen GPU Platz findet und lokal gehostet werden kann. Diese Umstellung ermöglicht es dem System, die Datensicherheit zu wahren und gleichzeitig Latenz und Kosten zu senken.

Wie es funktioniert

System-One-Modelle sind nach Daniel Kahnemans Konzept des schnellen, intuitiven Denkens benannt. Im Gegensatz zu generativen Modellen, die offenen Text produzieren, akzeptieren diese Modelle einen Zustand, wie z. B. Text oder JSON, sowie eine Reihe typisierter Fragen. Die Ausgabe ist streng auf vordefinierte Optionen beschränkt: Multiple-Choice-Auswahlen, numerische Bewertungen oder binäre Wahrscheinlichkeiten, die als „Nouls“ bezeichnet werden. Da der Ausgaberaum geschlossen ist, kann das Modell nicht dazu gebracht werden, durch Prompt Injection zu schwafeln, sich zu weigern oder fehlerhaften Text zu erzeugen. Es kann lediglich Wahrscheinlichkeiten den von Entwicklern bereitgestellten Optionen zuweisen.

Diese Architektur bietet zwei Hauptvorteile für Sicherheitsprüfungen. Erstens verhindert der geschlossene Ausgaberaum, dass das Model zu unerwarteten Verhaltensweisen gezwungen wird. Zweitens ist die Ausgabe eine rohe Wahrscheinlichkeit statt eines generierten Wortes. Generative Richter verwenden implizit einen Schwellenwert von 0,5 bei der Wahl zwischen Wörtern wie „block“ oder „allow“, aber dieser Schwellenwert verschiebt sich während des Retraining unvorhersehbar. Ein Entscheidungsmodell liefert explizite Wahrscheinlichkeiten, sodass Ingenieure benutzerdefinierte Schwellenwerte basierend auf den gewünschten False-Positive-Raten für jede Bereitstellung festlegen können. StackOne testete gehostete APIs wie Jev, lehnte sie jedoch aufgrund von Bedenken hinsichtlich der Datensicherheit ab, da Tool-Ergebnisse häufig sensible Mitarbeiterdaten enthalten. Stattdessen feinten sie ein Open-Weights-Modell auf ihren eigenen Daten ab.

Wichtige Details

• Der Musterabgleich der Stufe 1 wird in ungefähr einer Millisekunde abgeschlossen.
• Stufe 2 verwendet einen 22 MB großen Klassifikator, der Zeichenketten auf der CPU in Zehntelsekunden bewertet.
• Das neue Modell der Stufe 3 basiert auf einem ModernBERT-Backbone und passt auf eine einzelne kleine GPU.
• Die Zero-Shot-Leistung des untrainierten Entscheidungsmodells betrug 54,5 % Genauigkeit auf gehaltenen Testdaten.
• Das Modell beantwortet spezifische Fragen zu Anweisungen, Anfragen zur Datenexfiltration und Identitätsbehauptungen.
• Tests mit gehosteten APIs unter Verwendung von Jev kosteten $0,000025 pro Aufruf, generalisierten jedoch schlecht auf Tool-Payloads.

Warum das wichtig ist

Für Ingenieure, die agentische Systeme entwickeln, sind die Kosten und die Latenz von Sicherheitsprüfungen erhebliche Engpässe. Generative Richter sind zwar flexibel, führen aber zu variabler Latenz und hohen Rechenkosten, da sie GPUs benötigen und große Textblöcke parsen müssen. Durch den Wechsel zu einem Entscheidungsmodell zeigt StackOne, dass hochriskante Klassifizierungsaufgaben keine offene Generierung benötigen. Dieser Ansatz ermöglicht eine strengere Kontrolle über das Modellverhalten und vorhersehbare Leistungseigenschaften. Er eröffnet zudem die Möglichkeit, jedes einzelne Tool-Ergebnis zu scannen, anstatt nur eine gestichprobe oder eskalierte Teilmenge, was die allgemeine Sicherheitslage verbessert, ohne dass die Kosten proportional steigen.

Datenschutz bleibt eine kritische Einschränkung für KI-Anwendungen im Unternehmensumfeld. Viele Organisationen können interne Daten, wie CRM-Notizen oder E-Mails, nicht zur Klassifizierung an Drittanbieter-APIs senden. Der Wechsel zu lokalen Open-Weights-Entscheidungsmodellen adressiert dies, indem die gesamte Verarbeitung innerhalb der bestehenden Infrastruktur gehalten wird. Dieses Muster deutet auf einen breiteren Wandel in der KI-Sicherheitswerkzeugkette hin: weg von der Abhängigkeit von Frontier-Modellen für jede Aufgabe und hin zu spezialisierten, kleineren Modellen, die für bestimmte Entscheidungsgrenzen feinabgestimmt sind. Dies reduziert die Abhängigkeit von externen Anbietern und senkt das operative Risiko.

Was Sie tun können

• Überprüfen Sie Ihre aktuellen Schutzmaßnahmen gegen Prompt Injection, um festzustellen, wo generative Modelle für einfache Klassifizierungsaufgaben eingesetzt werden.
• Bewerten Sie System-One- oder Entscheidungsmodelle für alle binären oder Mehrklassen-Sicherheitsentscheidungen in Ihrer Pipeline.
• Definieren Sie spezifische, typisierte Fragen für Ihre Sicherheitsprüfungen, anstatt offene Fragen wie „Ist das sicher?“ zu stellen.
• Testen Sie Open-Weights-Entscheidungsmodelle auf lokaler Hardware, um sicherzustellen, dass sie Ihre Anforderungen an Latenz und Datenschutz erfüllen.
• Legen Sie explizite Wahrscheinlichkeitsschwellenwerte für Blockieraktionen basierend auf Ihrer akzeptablen False-Positive-Rate fest.
• Feinabstimmen Sie Modelle auf Ihren eigenen historischen Daten, um die Genauigkeit über die Zero-Shot-Fähigkeiten hinaus zu verbessern.