Was ist Prompt Injection? KI Chatbots und Agenten schützen

Was ist Prompt Injection?

Prompt Injection ist ein Angriff, bei dem versteckte Anweisungen im Text, den ein KI Modell liest, dessen Verhalten verändern. Der Angreifer schreibt also keinen Code, sondern ganz normale Sätze, die das Modell für Befehle hält. Dadurch kann das Modell somit Daten preisgeben, falsch antworten oder eine Aktion auslösen, die niemand freigegeben hat.

Das Thema wirkt auf den ersten Blick technisch, ist aber im Kern eine Vertrauensfrage. Ein großes Sprachmodell (LLM, also eine KI, die Text erzeugt) liest jeden Text als mögliche Anweisung. Deshalb können eine Regel Ihres Entwicklers und ein Satz in einer Kunden Mail für das Modell gleich wichtig aussehen.

Deshalb erklären wir in diesem Leitfaden die Arten, die Geschäftsrisiken und die Verteidigungsschichten. Dabei zeigen wir bewusst keinen Angriffscode und keine Angriffsbeispiele. Unser Ziel ist, dass Sie Ihr System verteidigen können, nicht dass jemand lernt, eines zu knacken.

Was ist der Unterschied zwischen direkter und indirekter Prompt Injection?

Es gibt zwei Arten, und sie brauchen unterschiedliche Abwehr. Zunächst trennen wir sie sauber.

Direkte Prompt Injection liegt vor, wenn die Person im Chat versucht, die Vorgaben des Modells zu überschreiben. Zum Beispiel fordert ein Nutzer den Chatbot auf, frühere Regeln zu vergessen oder die versteckte Systemanweisung zu zeigen. In der Praxis nennt man einen Teil dieses Verhaltens auch Jailbreak. Der Angreifer sitzt Ihnen gegenüber und tippt die Eingabe selbst.

Indirekte Prompt Injection ist deutlich heimtückischer. Die Anweisung steckt nicht in der Chatnachricht, sondern in externen Inhalten, die das Modell liest. Das kann eine Webseite sein, eine E-Mail, ein PDF, ein Support Ticket oder eine Produktbewertung. Der Nutzer ist dabei unschuldig. Das Modell liest die versteckte Anweisung einfach mit, während es den Inhalt zusammenfasst oder verarbeitet.

• Zum Beispiel sitzt der Angreifer bei der direkten Art im Chatfenster, bei der indirekten Art außerhalb davon.
• Außerdem lässt sich die direkte Art teilweise über Nutzeridentität und Ratenbegrenzung steuern.
• Dagegen kann bei der indirekten Art der schädliche Text in einer Quelle stehen, der Sie vertrauen.
• Bei Agenten mit Werkzeugen ist die indirekte Art viel gefährlicher, denn das Modell handelt nach dem, was es liest.

Warum kann ein Modell Anweisungen nicht von Daten trennen?

In klassischer Software laufen Befehle und Daten über getrennte Kanäle. Eine Datenbankabfrage und der Kundenname darin sind verschiedene Ebenen, und diese Trennung zu schützen ist seit Jahren die Grundlage der Abwehr. Große Sprachmodelle haben dagegen eine solche Grenze von Natur aus nicht.

Das Modell verarbeitet die Systemanweisung, die Nutzernachricht und das gerade gelesene Dokument in einem einzigen Textstrom. Am Ende ist alles eine Folge von Wörtern, also gibt es keine eingebaute Grenze. Folglich ist die Erwartung unrealistisch, dass das Modell selbst weiß, welcher Satz eine Regel und welcher ein Datum ist. Entwickler ziehen diese Linie auf dem Papier, das Modell antwortet jedoch nach Wahrscheinlichkeit.

Außerdem lernen Modelle, hilfsbereit zu sein. Zudem kann ein selbstsicherer, autoritär klingender Satz kann sie lenken. Deshalb schließt kein einzelner Patch das Problem. Daher sehen Sicherheitsexperten darin ein statistisches Verhalten und verteilen die Abwehr auf mehrere Schichten statt auf einen Filter.

Die praktische Lehre ist einfach: Behandeln Sie die Ausgabe des Modells so, als käme sie aus einer Eingabe, der Sie nicht voll vertrauen. Binden Sie Befugnisse dann an das System um das Modell herum und nicht an das Modell selbst.

Warum ist Prompt Injection ein echtes Risiko für Ihr Unternehmen?

Das Risiko wächst also mit den Zugriffen und Befugnissen des Modells. Zum Beispiel schreibt ein Chatbot ohne jeden Zugriff im schlimmsten Fall einen falschen Satz. Ein System mit Anbindung an Kundendaten, Postfächer oder Zahlungswerkzeuge kann dagegen viel größeren Schaden anrichten.

Drei Folgen für Unternehmen stehen im Vordergrund:

• Datenabfluss: Das Modell kann interne Regeln, Kundendaten oder Dokumentinhalte an die falsche Person weitergeben.
• Unbefugte Aktionen: Ein Agent mit Werkzeugen kann einen Datensatz löschen, eine E-Mail senden oder einen Bestellstatus ändern.
• Markenschaden: Schreibt Ihr Chatbot etwas Unpassendes, Falsches oder Verbindliches, verbreitet sich der Screenshot schnell.

Sobald personenbezogene Daten im Spiel sind, kommt außerdem eine rechtliche Ebene hinzu. Zum Beispiel kann ein Abfluss Meldepflichten nach dem Datenschutzrecht auslösen. Die Grundlagen finden Sie in unserem DSGVO Leitfaden für Websites. Dieser Beitrag ist keine Rechtsberatung, deshalb sprechen Sie für Ihren Fall mit einer Juristin oder einem Juristen.

Wie zeigt sich Prompt Injection bei Chatbots?

In der Praxis ist ein Chatbot im Kundenservice oft der erste Kontakt eines Unternehmens mit KI. Solche Bots laufen zum Beispiel meist mit einer Systemanweisung, einer Wissensbasis und manchmal einem kleinen Satz an Werkzeugen, etwa einer Bestellabfrage. Das Risiko entsteht dort, wo diese drei Teile zusammentreffen.

Erstens droht eine durchsickernde Systemanweisung. Konkret schreiben viele Teams Preisregeln, Rabattgrenzen oder interne Prozesshinweise in diesen Text. Überredet ein Nutzer das Modell, ihn anzuzeigen, erfährt ein Wettbewerber oder ein Angreifer diese Informationen.

Zweitens droht das Abdriften vom Thema. Schreibt zum Beispiel der Bot eines Möbelhauses plötzlich lange Antworten zu fremden Themen, steigen die Kosten und der Markenton leidet. Drittens ist die Wissensbasis selbst ein Risiko. Lernt Ihr Bot von öffentlichen Seiten oder von Dokumenten, die Nutzer hochladen, kann eine versteckte Anweisung auf indirektem Weg hineingelangen.

Fragen Sie daher zuerst, worauf der Bot zugreifen darf, und erst danach, was er antworten soll. In dieser Reihenfolge gehen wir bei unserer KI Chatbot Entwicklung vor.

Warum wächst das Risiko bei KI Agenten mit Werkzeugen?

Ein Agent antwortet nicht nur. Stattdessen plant er Schritte und ruft Werkzeuge auf. Zum Beispiel liest er E-Mail Nachrichten, prüft einen Kalender, aktualisiert einen CRM Eintrag oder führt einen Befehl auf einem Server aus. Daher gilt: Je mehr Werkzeuge das Modell erreicht, desto größer ist der Schaden, wenn jemand es in die Irre führt.

In Sicherheitskreisen spricht man oft von einem riskanten Dreiklang: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Möglichkeit, Informationen nach außen zu senden. Vereint ein Agent alle drei, findet eine indirekte Anweisung möglicherweise einen Weg, Daten abzuziehen. Somit senkt schon das Kappen einer der drei Fähigkeiten senkt das Risiko spürbar.

Ein Beispielszenario: Ein Agent fasst ein Postfach zusammen und entwirft Antworten. Dann schickt jemand von außen eine E-Mail mit einem versteckten Satz, der den Agenten bittet, ein anderes Gespräch an eine dritte Adresse weiterzuleiten. Behandelt der Agent die E-Mail als Arbeitsauftrag statt als Inhalt und darf er zudem senden, kann eine unerwünschte Weiterleitung passieren.

Das größere Bild zu Agenten zeigt unser Beitrag KI Agenten im Marketing. Wie Sie einen Agenten auf eigener Infrastruktur betreiben, lesen Sie unter KI Agent selbst hosten. In diesem Artikel behandeln wir die Sicherheitsseite.

Wie sieht indirekte Prompt Injection im echten Leben aus?

Wir zeigen hier daher keinen Code, sondern beschreiben die Abläufe in einfachen Worten. Die folgenden Szenarien sind Beispielszenarien und verweisen auf keinen konkreten Vorfall.

1. Webseite zusammenfassen: Ein Recherche Agent liest für eine Wettbewerbsanalyse eine Seite. Dann steht in einem unsichtbaren Bereich ein Satz, der den Agenten bittet, ein bestimmtes Produkt zu empfehlen. Der Agent hält ihn für Seiteninhalt und übernimmt ihn in den Bericht.
2. Dokumente verarbeiten: Ein HR Assistent bewertet Lebensläufe. Zum Beispiel hat ein Bewerber einen Satz eingebettet, der die KI anweist, die Bestnote zu vergeben. Der Assistent hält diese Zeile womöglich für seine eigene Regel.
3. Support Ticket: Ein Kunde formuliert ein Ticket so, dass ein interner Abfrage Agent zu den Daten anderer Kunden gelenkt werden soll.
4. Produktbewertung: Ein Werkzeug, das Bewertungen zusammenfasst, liefert eine falsche Zusammenfassung, weil eine Bewertung eine Anweisung versteckt.

Allen Fällen ist also gemeinsam, dass der schädliche Text als vertrauenswürdiger Inhalt getarnt in Ihr System gelangt. Die erste Frage der Abwehr lautet deshalb nicht, wer es geschrieben hat. Fragen Sie stattdessen, welche Befugnis das Modell besitzt, während es diesen Inhalt liest.

Was sagt die OWASP Liste für LLM Anwendungen zu Prompt Injection?

OWASP ist eine gemeinnützige Sicherheitsgemeinschaft, bekannt durch die Top 10 Liste für Webrisiken. Außerdem veröffentlicht dieselbe Gemeinschaft eine eigene Risikoliste für LLM Anwendungen. Prompt Injection steht dort an erster Stelle, und die offizielle Seite erklärt sie ausführlich.

Laut der offiziellen Seite des OWASP Gen AI Security Project entsteht Prompt Injection, wenn Nutzereingaben das Verhalten oder die Ausgabe eines Modells auf unbeabsichtigte Weise verändern. Zudem unterscheidet die Seite direkte und indirekte Formen. Zu den genannten Folgen zählen die Offenlegung sensibler Daten, das Preisgeben der Systemanweisung, unbefugter Zugriff auf Funktionen und verfälschte Entscheidungen.

Vor allem lautet die wichtigste Botschaft, dass es wahrscheinlich keine narrensichere Methode gibt. Weil Modelle nach Wahrscheinlichkeit arbeiten, sollten Sie die Abwehr in Schichten aufbauen. Zu den Maßnahmen auf der Seite gehören: Verhalten über Systemanweisungen eingrenzen, das erwartete Ausgabeformat prüfen, Eingabe und Ausgabe filtern, minimale Rechte vergeben, bei riskanten Aktionen eine menschliche Freigabe verlangen, externe Inhalte trennen und Angriffe simulieren.

Die Liste wird mit der Zeit aktualisiert, daher können Version und Rangfolge abweichen. Deshalb prüfen Sie bitte den aktuellen Stand auf der offiziellen Seite. Die klassische Webliste haben wir in einem eigenen Beitrag behandelt: OWASP Top 10 Sicherheitslücken und Maßnahmen.

Was ist das Grundprinzip der Abwehr gegen Prompt Injection?

Das Grundprinzip lautet: Gehen Sie davon aus, dass ein Angriff gelingt, und begrenzen Sie den Schaden. Statt zu versuchen, das Modell unüberredbar zu machen, verkleinern Sie, was es tun kann, selbst wenn es überredet wurde. Somit wird aus einer Filterfrage eine Architekturfrage.

In der Praxis sprechen wir von sieben Schichten:

• Geben Sie dem Modell und seinen Werkzeugen nur die minimal nötigen Rechte.
• Binden Sie schwer umkehrbare Aktionen an eine menschliche Freigabe.
• Prüfen Sie Eingabe und Ausgabe, aber sehen Sie darin nie die einzige Abwehr.
• Halten Sie geheime Daten ganz aus dem Kontext des Modells heraus.
• Trennen Sie externe Inhalte und markieren Sie sie als nicht vertrauenswürdig.
• Protokollieren Sie jeden Werkzeugaufruf und überwachen Sie die Logs.
• Testen Sie regelmäßig aus der Sicht eines Angreifers.

Jede Schicht kann allein versagen, denn keine Kontrolle ist perfekt. Zusammen zwingen sie den Angreifer jedoch, alle gleichzeitig zu überwinden. Kurz gesagt: Sie bauen mehrere Türen statt eines einzigen Schlosses. In den nächsten Abschnitten gehen wir jede Schicht einzeln durch.

Wie macht das Prinzip der minimalen Rechte einen KI Agenten sicherer?

Kurz gesagt bedeuten minimale Rechte, einem System genau so viel Zugriff zu geben, wie es für seine Aufgabe braucht. Gegen Prompt Injection ist das die stärkste Verteidigung, denn sie legt direkt fest, was ein Angreifer erreicht, wenn das Modell übernommen wird.

Listen Sie zunächst die Werkzeuge auf, die der Agent wirklich braucht. Zum Beispiel muss ein Terminbot einen Kalender lesen und Termine anlegen. Das Recht, die Kundendatenbank zu löschen, braucht er nicht. Trennen Sie danach für jedes Werkzeug Lese und Schreibrechte. Ein Werkzeug mit Lesezugriff birgt viel weniger Risiko als eines mit Schreibzugriff.

• Legen Sie für den Agenten ein eigenes Dienstkonto an und teilen Sie nie ein volles Administratorkonto.
• Begrenzen Sie den Datenzugriff pro Nutzer, damit der Agent nur die Daten der Person in dieser Sitzung sieht.
• Schränken Sie Werkzeuge ein, die Verbindungen nach außen aufbauen können.
• Halten Sie Zugangsdaten aus dem Prompt heraus und bewahren Sie sie in der Werkzeugebene auf.
• Prüfen Sie die Rechte in festen Abständen und schalten Sie ungenutzte ab.

Dieser Ansatz verringert außerdem schlichte Fehler. In der Praxis gilt: Trifft das Modell von selbst eine falsche Entscheidung, entsteht kein Schaden, wenn ihm die Macht fehlt, sie auszuführen.

Wann ist bei Werkzeugaufrufen eine menschliche Freigabe nötig?

Eine menschliche Freigabe bremst die Automatisierung ein wenig. Dafür bietet sie das verlässlichste Sicherheitsventil. Würden Sie bei jedem Schritt um Freigabe bitten, wäre der Agent sinnlos, deshalb staffeln Sie die Freigabe nach dem Risiko.

Zunächst können Aktionen mit geringem Risiko automatisch laufen. Dazu gehören das Lesen von Informationen, das Entwerfen eines Textes oder die Antwort auf eine allgemeine Frage. Bei mittlerem Risiko zeigen Sie dem Nutzer eine kurze Zusammenfassung und holen eine Bestätigung ein. Bei hohem Risiko verlangen Sie die ausdrückliche Zustimmung einer befugten Mitarbeiterin oder eines befugten Mitarbeiters.

• Jede Aktion mit Geld, Rechnungen, Erstattungen oder Preisänderungen.
• Löschen von Datensätzen, Massenänderungen und Datenexporte.
• Versand von E-Mail Nachrichten oder Nachrichten außerhalb des Unternehmens.
• Rechtevergabe, Passwortzurücksetzung und Kontoänderungen.
• Aufbau einer neuen Verbindung zu einem anderen System.

Außerdem sollten Sie den Freigabedialog klar und schlicht halten. Der Nutzer muss genau sehen, was der Agent tun will und mit welchen Daten. Eine vage Frage wie "Bestätigen Sie?" verleitet dagegen zum gedankenlosen Zustimmen.

Reichen Eingabe und Ausgabefilter gegen Prompt Injection aus?

Nein, allein reichen sie nicht aus, aber sie sind eine wertvolle Schicht. Konkret fangen Eingabefilter verdächtige Muster ab. Ausgabefilter stoppen Informationen, die das Modell nicht preisgeben darf, oder ein unerwartetes Format. Ein Angreifer kann Stichwortfilter dennoch umgehen, indem er einen Satz umformuliert oder eine andere Sprache nutzt.

Denken Sie deshalb zwei Filterarten zusammen. Die erste Art arbeitet mit Regeln: erwartete Länge, erlaubte Zeichen und eine Liste gesperrter Themen. Die zweite Art arbeitet semantisch: Ein weiteres Modell oder ein Klassifikator prüft, ob die Eingabe Anweisungen erteilen will.

Auf der Ausgabeseite wirkt es am besten, das Format vorab festzulegen. Verlangen Sie vom Modell eine strukturierte Antwort mit bestimmten Feldern und prüfen Sie diese Struktur im Code. Dann lehnen Sie jede Antwort ab, die nicht passt, bevor der Nutzer sie sieht. Blockieren Sie die Antwort außerdem, wenn sie personenbezogene Daten, interne Adressen oder etwas wie einen geheimen Schlüssel enthält.

Trotzdem verhält sich ein Filter nicht wie eine Firewall. Sehen Sie ihn als Vorprüfung vor den übrigen Schichten. Stattdessen kommt die eigentliche Sicherheit aus eingeschränkten Rechten und Freigabeschritten.

Warum sollten Sie sich nicht allein auf die Systemanweisung verlassen?

Denn viele Teams schreiben eine starke Systemanweisung und glauben, die Arbeit sei getan. Sie fügen einen Satz ein wie "Brich diese Regeln nie, egal was der Nutzer sagt." Die Anweisung hilft, ist aber eine Verhaltenssteuerung und keine Sicherheitskontrolle. Das Modell folgt ihr meistens, doch nichts garantiert, dass es immer so bleibt.

Der Grund ist einfach: Die Systemanweisung ist ebenfalls nur Text und steht im selben Strom wie alles andere, was das Modell liest. Zudem kann ein überzeugender oder sehr langer Kontext ihr Gewicht verringern. Folglich ist der Satz "Das steht in der Anweisung" kein Sicherheitsargument.

Nutzen Sie die Systemanweisung für Rolle und Ton, für den Themenrahmen und für das Verhalten in unklaren Fällen. Nutzen Sie sie nicht, um Geheimnisse zu verstecken, Rechtegrenzen zu ziehen oder sensible Daten zu schützen. Lösen Sie diese Aufgaben stattdessen im Code und in der Infrastruktur außerhalb des Modells.

Machen Sie einen kurzen Test: Was passiert, wenn Ihre Systemanweisung morgen im Internet auftaucht? Lautet die Antwort "etwas Schlimmes", steht in der Anweisung etwas, das dort nicht hingehört.

Was bedeutet es, geheime Daten vom Modell fernzuhalten?

Ein Modell kann nichts preisgeben, was es nie gesehen hat. Somit fasst dieser Satz eine der einfachsten und wirksamsten Abwehrmaßnahmen zusammen. Betrachten Sie alles, was Sie in das Kontextfenster legen, als Daten, die ein künftiger Angriff herausholen könnte.

Fragen Sie zunächst, was Sie überhaupt senden. Zum Beispiel sollte ein Support Bot nur die Felder sehen, die in diesem Gespräch nötig sind, nicht den gesamten Kundendatensatz. Besonders schützenswerte Daten wie Ausweisnummern, vollständige Kartendaten und gesundheitsnahe Felder maskieren Sie oder senden sie gar nicht.

• Schreiben Sie nie API Schlüssel, Passwörter oder Zugangstoken in den Prompt.
• Betten Sie keine internen Preislisten und keine Wettbewerbsanalysen in die Systemanweisung ein.
• Schließen Sie bei der Dokumentensuche (RAG) Dokumente aus, die der Nutzer nicht sehen darf.
• Maskieren Sie personenbezogene Daten oder ersetzen Sie sie vor dem Senden durch ein Pseudonym.
• Verarbeiten Sie die Daten bei Bedarf mit einem Modell auf Ihrem eigenen Server.

Vor allem bei dokumentenbasierten Systemen ist die Zugriffskontrolle entscheidend. Wir erklären das im Beitrag Was ist RAG. Wie Sie dort sehen, muss die Suchebene und nicht das Modell entscheiden, welches Dokument gefunden werden darf.

Wie trennen Sie externe Inhalte und markieren sie als nicht vertrauenswürdig?

Die wichtigste Gewohnheit gegen indirekte Angriffe ist, externe Inhalte immer als Daten zu behandeln. Text aus einer Webseite, E-Mail oder einem Dokument darf nie zur Quelle werden, die die Aufgabe des Agenten ändert. Deshalb müssen Sie das in der Architektur sichtbar machen.

Teilen Sie zunächst den Kontext, den Sie dem Modell geben, in Bereiche: Anweisungen des Unternehmens, Anfrage des Nutzers und externer Inhalt. Fassen Sie den externen Inhalt in klare Grenzen und sagen Sie dem Modell, dass er nur Material zur Prüfung ist. Allerdings ist diese Methode nicht perfekt, sie verkleinert aber die Angriffsfläche.

Trennen Sie zweitens Lesen und Handeln. Sie können den Agenten, der externe Inhalte liest, vom Agenten trennen, der Aktionen ausführt. Dabei liefert der Leser nur eine Zusammenfassung oder strukturierte Daten. Der Ausführende sieht den Rohtext nie. Somit kann ein versteckter Satz die Aktionsebene nicht erreichen.

Stufen Sie drittens die Quellen nach Vertrauen ein. Denn Ihre eigene Wissensbasis und eine beliebige Webseite verdienen nicht dasselbe Vertrauen. Setzen Sie Berechtigungen nach Quellentyp. Schalten Sie zum Beispiel in einer Sitzung, die offene Webinhalte liest, das Werkzeug zum Versand von Nachrichten nach außen ganz ab.

Wie fangen Logging und Monitoring Prompt Injection ab?

Vorbeugen ist wichtig, aber ebenso wichtig ist zu sehen, was passiert ist. Denn ein KI System ohne Protokolle kann einen Vorfall nicht erklären. Deshalb muss jedes Gespräch und jeder Werkzeugaufruf nachvollziehbar sein.

Zu den wichtigsten Angaben gehören die Nutzereingabe, die vom Modell gelesenen externen Quellen, das aufgerufene Werkzeug samt Parametern, das zurückgelieferte Ergebnis und die endgültige Antwort. Allerdings können Logs personenbezogene Daten enthalten. Legen Sie Speicherdauer und Zugriffsrechte daher von Anfang an fest.

• Markieren Sie unerwartete Werkzeugaufrufe, etwa wenn ein Support Bot plötzlich einen Export startet.
• Zudem sollten Sie ungewöhnlich lange Eingaben und wiederholte Testmuster beobachten.
• Richten Sie eine Alarmregel für Ausgaben ein, die der Systemanweisung ähneln.
• Prüfen Sie regelmäßig die Aktionen, die im Freigabedialog abgelehnt wurden.
• Speichern Sie genug Details, um ein Gespräch nach einem Vorfall von Anfang bis Ende nachzuspielen.

Wenn Sie ohnehin Serverlogs lesen, können Sie mit unserer Logfile Analyse auch Muster im Webverkehr prüfen. Für KI Protokolle brauchen Sie allerdings ein eigenes Monitoring Dashboard.

Wie testen Sie mit Red Teaming auf Prompt Injection?

Red Teaming heißt, das eigene System wie ein Angreifer anzugehen, um Schwachstellen früh zu finden. Das Ziel ist also nicht, Schaden anzurichten, sondern Ihr System vor dem Livegang zu prüfen. Arbeiten Sie nur in Ihrer eigenen Umgebung und an Systemen, für die Sie eine Erlaubnis haben.

Bauen Sie zunächst eine Testumgebung auf. Bereiten Sie eine Kopie mit erfundenen Datensätzen und ohne echte Kundendaten vor. Schreiben Sie dann einen Testplan: Welche Werkzeuge, welche Daten und welche Ergebnisse sind inakzeptabel? Anders gesagt bildet diese Liste die Bestehenskriterien Ihres Tests.

1. Führen Sie direkte Versuche durch: Versuchen Sie, den Bot aus seinem Themenrahmen zu locken, seine Regeln zu zeigen und seine Rolle zu wechseln.
2. Führen Sie indirekte Versuche durch: Legen Sie harmlose eigene Anweisungen in erfundene Dokumente, die der Agent liest, und beobachten Sie, ob er gehorcht.
3. Testen Sie die Werkzeuggrenzen: Prüfen Sie, ob der Agent etwas tun kann, wofür ihm die Erlaubnis fehlt.
4. Halten Sie die Ergebnisse fest, ordnen Sie sie nach Schwere und beheben Sie sie.
5. Wiederholen Sie die Tests nach jeder Änderung von Modell, Prompt oder Werkzeug.

Schreiben Sie den Testsatz nicht einmal und lassen ihn dann liegen. Aktualisieren Sie ihn dann, sobald neue Angriffsideen auftauchen. Somit bleibt Ihr System unter einer lebendigen Sicherheitskontrolle.

Welche Abwehr senkt welches Risiko?

Die folgende Tabelle stellt jede Abwehrschicht mit ihrer Wirkung und ihrer Grenze nebeneinander. Sie ist ein allgemeiner Rahmen aus der Praxis, und die Gewichte können in jedem System anders ausfallen.

Zusammengefasst ist das Fazit klar: Keine einzelne Zeile genügt allein. Das größte Gewicht tragen minimale Rechte, menschliche Freigabe und zurückgehaltene Daten, denn sie stützen sich auf Struktur und nicht auf das Verhalten des Modells.

Was gehört in eine schnelle Checkliste gegen Prompt Injection?

Beantworten Sie diese Fragen im Team, bevor Sie eine KI Funktion live schalten. Lautet eine Antwort "wissen wir nicht", klären Sie diesen Punkt vor dem Start.

• Auf welche Werkzeuge und Daten kann das Modell zugreifen, und braucht es jedes davon wirklich?
• Liest es externe Inhalte wie Webseiten, E-Mail Nachrichten, Dokumente oder Bewertungen und kann es in derselben Sitzung Informationen nach außen senden?
• Gibt es für schwer umkehrbare Aktionen eine menschliche Freigabe?
• Enthält die Systemanweisung Geheimnisse, Schlüssel oder interne Preise?
• Prüft der Code das Format der Ausgabe?
• Protokolliert jemand jeden Werkzeugaufruf und sieht die Logs regelmäßig durch?
• Haben Sie nach der letzten Änderung von Modell oder Prompt getestet?
• Gibt es einen Schalter, mit dem Sie den Agenten bei Problemen schnell abschalten?

Allerdings vergessen viele den letzten Punkt. In der Praxis erlaubt ein Notaus es Ihnen, das System abzuschalten, bevor ein Problem wächst. Halten Sie außerdem vorab schriftlich fest, wer nach einem Vorfall was in welcher Reihenfolge tut.

Wo sollte ein kleines Unternehmen bei der Abwehr von Prompt Injection anfangen?

Dennoch können Sie auch ohne großes Sicherheitsteam wichtige Schritte gehen. Die ersten drei Maßnahmen bringen den größten Nutzen und kosten meist kein Budget: Rechte einschränken, sensible Daten aus dem Kontext nehmen und riskante Aktionen an eine Freigabe binden.

Listen Sie zunächst die KI Werkzeuge auf, die Sie nutzen. Zum Beispiel finden die meisten Unternehmen mehr Einstiegspunkte als erwartet, wenn sie die Chat Werkzeuge der Mitarbeitenden, den Bot auf der Website und die Automatisierungsdienste zählen. Schreiben Sie danach für jedes den schlimmsten denkbaren Fall auf.

Schulen Sie dann Ihr Team kurz. Erklären Sie das Risiko, Dokumente und Links aus unbekannten Quellen in einen KI Assistenten zu laden. Halten Sie außerdem schriftlich fest, welches Werkzeug Unternehmensdaten erhalten darf. Zu verwandten Gefahren wie Deepfakes und geklonten Stimmen lesen Sie unseren Beitrag zum Deepfake und Stimmklon Betrug.

Wenn Sie ein eigenes System aufbauen wollen, planen Sie die KI Agenten Entwicklung gemeinsam mit den Sicherheitsanforderungen. Zu Techniken für gute Eingaben finden Sie mehr unter Was ist Prompt Engineering. Bedenken Sie aber, dass ein guter Prompt eine Sicherheitskontrolle nie ersetzt.

Dieser Beitrag ersetzt keine Rechtsberatung. Zum Beispiel bei Fragen zu Datenschutz, Urheberrecht oder Betrug wenden Sie sich an eine qualifizierte Fachperson.