Guardrails

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:

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-AnwendungenExtern - Öffnet in neuem Tab 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.