Guardrails im Betrieb
Die Hausordnung im Harness ist die erste Verteidigung - aber der Harness ist Partei: Er führt aus, was das Modell sagt. Im Betrieb steht deshalb eine zweite Kontrollebene außerhalb. Was sie sieht, was sie verhindert, was sie nur beweisen kann.
Basics
Für alle frei: das Konzept, die Analogie, das Warum.
In Guardrails steht die Hausordnung: Eingaben prüfen, Ausgaben filtern, Nutzertext nie in den System-Prompt, die Verteidigungsleiter Stufe für Stufe. Das alles wohnt im Harness - in dem Code, den du selbst geschrieben hast.
Diese Seite fängt dort an, wo diese Annahme endet. Zwei Dinge stimmen im Betrieb nicht mehr:
Der Harness ist Partei. Er führt aus, was das Modell sagt, und seine Filter laufen im selben Prozess, den ein gekaperter Kontext gerade steuert. Ein Agent, der sich an seine eigene Hausordnung halten soll, ist wie ein Kassenbuch, das der Kassierer selbst führt - meistens gut genug, und genau dann nicht, wenn es darauf ankommt.
Nicht alles läuft durch deinen Harness. Der Coding-Agent eines Kollegen, die Browser-KI der Fachabteilung, der eingekaufte Agent im CRM - sie alle rufen Modelle auf, ohne dass deine Hausordnung auch nur in der Nähe ist. Kontrolle, die im Anwendungscode wohnt, gilt genau für eine Anwendung.
Die Antwort des Betriebs ist eine Kontrollebene außerhalb: ein Proxy im Pfad zum Modell, Detektoren davor und dahinter, harte Regeln auf der Aktionsebene, und ein Protokoll, das hinterher beweisen kann, was geschehen ist.
Was passiert, wenn es sie nicht gibt
Jede Zeile dieser Tabelle ist ein dokumentierter Vorfallstyp, kein Gedankenspiel. Und jede hat ein Konzept, das unten ein eigenes Kapitel bekommt:
| Was passiert | Was man dagegen baut |
|---|---|
| Ein abgerufenes Dokument trägt Anweisungen, der Agent führt sie aus | Detektoren, Markierung fremden Texts - und Architektur, die Untrusted von Handlungsmacht trennt |
| Kundendaten wandern in den Prompt, ein Markdown-Bild trägt Geheimnisse hinaus | Maskieren mit Rückweg (Vault), URL-Allowlist im Output |
| Die Antwort klingt sicher und widerspricht den eigenen Quellen | Groundedness-Prüfung zwischen Abruf und Auslieferung |
| Ein Werkzeugaufruf tut mehr, als der Auftrag hergibt | Policy-Engine, Least-Privilege, Freigabe vor irreversiblen Aktionen |
| Ein kurzer Prompt erzeugt zehntausende Token und legt die GPU lahm | Limits, Deckel, Kaskadierung - Betriebsführung statt Vertrauen |
Der Weg durch die Schleuse
Wie die Ebene arbeitet, sieht man am schnellsten, wenn man sie selbst schaltet: Fünf Anfragen, vier Schichten, jede einzeln abschaltbar. Die Latenz zählt mit - denn jede Schicht kostet, und keine ist umsonst:
Fünf Anfragen durch die Schleuse
Schalte die vier Schichten einzeln zu und schick jede Anfrage hindurch. Beobachte, welche Schicht welchen Angriff stoppt - und welche durchkommt. Die Latenz unten rechts zählt mit.
user: "Fasse das angehängte Protokoll zusammen."
abgeschaltet
abgeschaltet
abgeschaltet
abgeschaltet
ausgeliefert
0 ms
Summe der durchlaufenen Schichten - ein früher Block ist billiger.
Die harmlose Anfrage soll durch - und tut es. Eine Schleuse, die hier blockt, ist kein sicheres System, sondern ein kaputtes: Fehlalarme sind der halbe Preis jeder Schicht.
Im aktuellen Zustand kommen 4 der vier Angriffe durch. Nur mit allen vier Schichten - in der richtigen Reihenfolge - ist es keiner.
Geführt in fünf Schritten
Baue die Schleuse Schicht für Schicht auf und sieh nach jedem Schritt, welcher Angriff jetzt geschlossen ist - und welcher noch offen.
Ohne Kontrollebene kommt jeder Angriff durch - auch die harmlose Anfrage, was hier richtig ist. Das ist der Ausgangszustand, gegen den jede Schicht antritt.
Was hier üblicherweise falsch verstanden wird
- Ein guter Detektor reicht als Guardrail.
- →Er fängt eine Angriffsklasse. Exfiltration, erschlichene Aktionen und getarnte Nutzlast brauchen je eine andere Schicht - und die stärksten davon sind gar keine Detektoren.
- Mehr Schichten heißt mehr Wartezeit.
- →Die deterministischen Schichten - Normalisierung, Allowlist, Policy - kosten zusammen ein paar Millisekunden. Teuer ist allein die probabilistische Prüfung. Sicherheit skaliert hier nicht mit Latenz.
- Die Reihenfolge der Prüfungen ist egal.
- →Läuft der Detektor vor der Normalisierung, sieht er getarnten Text und lässt ihn durch. Erst normalisieren, dann prüfen - sonst urteilt der Wächter über einen anderen Text als das Modell.
Die Auflösung jeder Anfrage ist im Code als feste Regel hinterlegt, nicht als Modellurteil - die Fläche zeigt die Mechanik der Schichten, nicht die Trefferquote eines bestimmten Detektors.
Wer die Schichten einmal durchgeschaltet hat, kennt die zwei Befunde dieser Seite schon: Keine Schicht fängt alles, und die getarnte Anfrage rutscht ausgerechnet an der Schicht vorbei, die für sie gebaut wurde. Das ist kein Konfigurationsfehler, sondern der Normalzustand - warum, steht im letzten Kapitel.
Drei Aufgaben, nicht eine
Der häufigste Denkfehler über diese Ebene ist, sie als Mauer zu lesen. Sie ist drei Dinge zugleich, und das schwächste davon ist die Mauer:
- Kostenerhöher. Detektoren und Filter machen Angriffe teurer, nicht unmöglich. Die Forschung ist hier eindeutig: Adaptive Angreifer umgehen jeden veröffentlichten Text-Filter - die Frage ist, wie viele Versuche es kostet und ob jemand die Versuche sieht.
- Schadensbegrenzer. Harte Regeln auf der Aktionsebene - was ein Werkzeug darf, welche Domains ein Output laden darf, welche Aktion eine Freigabe braucht - wirken auch dann noch, wenn der Text-Filter längst überlistet ist. Sie sind deterministisch: keine Trefferquote, sondern eine Regel.
- Nachweisführer. Das Protokoll der Ebene ist der Unterschied zwischen „wir glauben, es ist nichts passiert“ und „hier ist, was passiert ist“. Für ein Audit ist ein Vendor-Versprechen von 99,99 Prozent keine Evidenz - ein Protokoll geblockter und durchgelassener Anfragen ist eine.
Was unten steht
Acht Kapitel, in der Reihenfolge, in der man sie braucht: zuerst der Schadenskatalog als Nachschlagewerk - was ohne Kontrollebene passiert, sortiert und mit Kennungen. Dann die Landkarte: wo jedes Konzept sitzt (Harness, Proxy, Engine, Endpoint), wann es greift (vor, parallel, nach, nachträglich), was es tut (verhindern, verändern, beobachten) und wie es entscheidet (Regel oder Wahrscheinlichkeit). Danach der Bau: Torwächter, Detektoren, Eingangs- und Ausgangsschleuse, die Handbremse auf der Aktionsebene. Am Ende die Grenzen - die Zahlen aus den Angriffs-Challenges, und die Architektur, die übrig bleibt, wenn man ihnen glaubt.
Jedes Konzept kommt mit dem, was es kostet: Latenz, Fehlalarme, Betriebsaufwand. Es gibt auf dieser Seite keinen Wächter, der nur Vorteile hat - die Frage ist nie „sicher oder unsicher“, sondern „welcher Schaden ist teurer als diese Schicht“.
Weiter
Ab hier liegen die Lösungen - 8 Kapitel für Pro-Mitglieder.
- Der Schadenskatalog - Neunzehn Schadensbilder in fünf Klassen, jedes mit Erkennungsmerkmal und Gegenkonzept. Das Register, auf das die folgenden Kapitel verweisen - und die Landkarte auf die OWASP Top 10.
- Die Landkarte: wo, wann, was, wie - Jedes Kontrollkonzept sitzt an einem Ort, greift zu einem Zeitpunkt, hat eine Wirkungsart und eine Entscheidungsart. Wer die vier Achsen kennt, kann jedes Produkt und jedes Paper in zwei Minuten einordnen.
- Der Torwächter: Bauformen und Datenpfad - Sechs Positionen, an denen ein Wächter sitzen kann, die drei Haken im Anfrage-Pfad, das Streaming-Dilemma - und die eine Entscheidung, die vor dem ersten Ausfall getroffen sein muss.
- Die Detektoren: vier Familien und ihre echten Zahlen - Muster, Encoder-Klassifikatoren, Guard-LLMs, Blick ins Modell - was jede Familie kostet, was sie wirklich trifft, und warum die Vendor-Zahl nie die Betriebszahl ist.
- Die Eingangsschleuse: Normalisieren, Maskieren, Markieren - Was mit einer Anfrage passiert, bevor das Modell sie sieht - und warum die Reihenfolge der Schritte selbst Architektur ist: Wer nach dem Detektor normalisiert, hat den Detektor nicht gehabt.
- Die Ausgangsschleuse: der letzte Blick vor der Auslieferung - Der Zero-Click-Abfluss über ein Markdown-Bild, der Kanarienvogel im System-Prompt, die Faktenprüfung mit dem kleinen zweiten Modell - was die Antwort durchlaufen muss, bevor sie jemand liest.
- Die Handbremse: harte Regeln auf der Aktionsebene - Wo die Kontrollebene aufhört zu raten: Policy-Engines, Least-Privilege, Credential-Trennung, Freigaben - und der Werkzeugkanal mit seinen eigenen Angriffen: Tool-Poisoning, Rug Pull, Shadowing.
- Die Grenzen: was die Angriffs-Challenges wirklich zeigen - Zwölf Verteidigungen, über neunzig Prozent durchbrochen. Eine Challenge mit 208 000 Angriffen, jede Defense gefallen. Was von der Kontrollebene bleibt, wenn man den Zahlen glaubt - und welche Architektur trotzdem trägt.
Anmelden, um diesen Inhalt zu sehen
Dieser Bereich ist Mitgliedern vorbehalten. Logge dich ein, um weiterzulesen.
Jetzt anmelden