Behandeln Sie Inhalte von Nutzern, aus Dokumenten und aus dem Web als nicht vertrauenswürdige Daten. Legen Sie die Autorität von Anweisungen außerhalb des Modells fest, beschränken Sie Quellen und Werkzeuge, validieren und autorisieren Sie Argumente auf dem Server, lassen Sie sensible Aktionen bestätigen und geben Sie dem Modell überhaupt keine Geheimnisse. Testen Sie fortlaufend direkte und indirekte Angriffe und überwachen Sie ungewöhnliche Aufrufe.
Prompt Injection entsteht, wenn nicht vertrauenswürdige Inhalte versuchen, das Verhalten des Modells zu ändern, Informationen preiszugeben oder eine unzulässige Aktion auszulösen. Eine Anweisung kann direkt vom Benutzer stammen oder in einer Webseite, einem Dokument, einer E-Mail oder einem Werkzeugergebnis versteckt sein. Ein Sprachmodell verarbeitet alles als Text, daher ist der Satz „Ignoriere fremde Anweisungen“ allein kein vollständiger Schutz.
Sicherheit beruht auf der Architektur rund um das Modell. Das System trennt Anweisungen von Daten, minimiert den geladenen Kontext, setzt Berechtigungen serverseitig durch und beschränkt Werkzeuge je nach Risiko. Eine sensible Aktion erfordert Validierung und Bestätigung. Tests umfassen auch die Verkettung mehrerer harmloser Schritte, denn ein Angriff muss nicht mit einem einzigen auffälligen Satz gelingen.
Erfassen Sie direkte und indirekte Einstiegswege
Ein direkter Angriff erfolgt über eine Frage, einen Chat oder ein Formularfeld. Ein indirekter kann sich in einem per RAG geladenen Dokument, im Text einer E-Mail, auf einer HTML-Seite, in einem Dateinamen oder in der Antwort einer externen API befinden. Erfassen Sie alle Stellen, aus denen das Modell Text bezieht, und legen Sie deren Verantwortliche und Vertrauensstufe fest. Ein interner Speicher ist nicht automatisch vor schädlichen Inhalten sicher.
Erfassen Sie anschließend die möglichen Folgen: Offenlegung des System-Prompts, Anzeige einer fremden Quelle, Änderung von Tool-Parametern, Versand von Daten oder Umgehung einer Freigabe. Die bloße Preisgabe einer Anweisung kann weniger schwerwiegend sein als der Zugriff auf ein Geheimnis, das darin nie hätte stehen dürfen. Bestimmen Sie die Schutzpriorität nach der tatsächlichen Fähigkeit und Auswirkung, nicht danach, wie dramatisch ein Text klingt.
Trennen Sie maßgebliche Anweisungen von nicht vertrauenswürdigen Daten
Systemregeln und die Tool-Richtlinie entstehen in der Anwendung, nicht im geladenen Dokument. Kennzeichnen Sie den Quelltext mit Begrenzungszeichen und einer Beschreibung, dass er zur Analyse bestimmt ist. Geben Sie ihm niemals die Möglichkeit, die Rolle oder den Sicherheitsmodus zu überschreiben. Diese Unterscheidung verringert das Risiko, doch das Modell hält sie nicht immer ein, daher darf sie nicht die einzige Schutzschicht sein.
Beschränken Sie den Kontext auf die für die Frage notwendigen Passagen und filtern Sie Inhaltstypen heraus, die das System nicht unterstützt. Verarbeiten Sie HTML ohne aktive Elemente und bewerten Sie verborgene Ebenen und Metadaten gesondert. Die automatische Zusammenfassung einer fremden Website darf anschließend nicht deren Anweisungen ausführen. Behandeln Sie auch die Ausgabe des Modells als nicht vertrauenswürdig, bevor sie dargestellt oder im nächsten Schritt verwendet wird.
- Inventar aller externen und internen Texteingaben
- klare Grenze zwischen Systemregeln und analysierten Daten
- minimierter Kontext ohne Geheimnisse und unnötige Daten
- sichere Verarbeitung der Modellausgabe vor der weiteren Verwendung
Beschränken Sie Tools und setzen Sie Berechtigungen außerhalb des Modells durch
Das Modell hat nur Zugriff auf eng gefasste Tools, die für die aktuelle Aufgabe nötig sind. Argumente werden anhand eines Schemas, fachlicher Regeln und einer Autorisierung auf Basis der verifizierten Nutzeridentität geprüft. Mandant, Rolle oder Zielberechtigung werden nicht durch die Textausgabe bestimmt. Ein Lese-Tool hat keine versteckte Schreibmöglichkeit, und allgemeine Codeausführung oder beliebige URLs werden ohne außergewöhnlichen Grund nicht zugelassen.
Sensible oder schwer umkehrbare Aktionen erfordern eine Vorschau und die Bestätigung konkreter Werte. Begrenzen Sie die Anzahl der Aufrufe, das Datenvolumen, die Zeit und die Verkettung. Fordert ein Dokument dazu auf, Inhalte an eine externe Adresse zu senden, lehnt der Server das Ziel unabhängig von der Begründung des Modells ab. Bewahren Sie Geheimnisse in der Anwendungsschicht auf; das Tool gibt nur das notwendige Minimum an Ergebnissen zurück.
Schützen Sie Retrieval, Zitate und Darstellung
RAG filtert Quellen vor der Suche nach Berechtigungen und bewahrt die Herkunft. Eine schädliche Passage darf weder die Auswahl weiterer Quellen noch die Zitierregeln beeinflussen. Bei der Indexierung lassen sich Typ und Vertrauenswürdigkeit eines Dokuments kennzeichnen, doch ein Erkennungsfilter ist nicht unfehlbar. Trennen Sie sensible Sammlungen ab; bei Fragen außerhalb des Umfangs durchsucht das System sie überhaupt nicht.
Geben Sie generierten Text mit sicherem Escaping aus und erlauben Sie nur einen kontrollierten Satz an Formatierungen. Validieren Sie Links und weisen Sie Nutzer vor dem Verlassen zu einem externen Ziel darauf hin. Das Modell soll keinen ausführbaren Code erzeugen, den die Anwendung automatisch ausführt. Eine Quellenangabe wird anhand der tatsächlichen Quelle überprüft, und die Zugriffsberechtigung wird auch beim Öffnen geprüft.
Angriffe testen und Reaktion vorbereiten
Das Testset enthält direkte Aufforderungen zur Umgehung von Regeln, versteckte Anweisungen in Dokumenten, gefälschte Systemnachrichten, Manipulation von Zitaten, Versuche mit fremden Identifikatoren und die Verkettung von Tools. Testen Sie verschiedene Sprachen und Formate. Erfolg bedeutet nicht nur eine sichere Antwort, sondern auch, dass keine verbotenen Daten geladen und kein Tool aufgerufen wurde.
Überwachen Sie abgelehnte Autorisierungen, ungewöhnliche Kombinationen von Tools, das Ausgabevolumen und den Zugriff auf sensible Sammlungen. Logs dürfen keine offengelegten Secrets enthalten. Bei Verdacht deaktivieren Sie das betroffene Tool, widerrufen Zugangsdaten, sichern Beweise auf sichere Weise und untersuchen das Ausmaß. Jeder Vorfall fließt in einen Test und eine architektonische Korrektur ein, nicht nur in einen längeren Prompt.
Häufige Fragen
Löst ein besserer Systemprompt das Problem der Prompt Injection?
Nicht allein. Der Prompt ist nur eine Ebene. Sie benötigen minimale Berechtigungen, serverseitige Autorisierung, validierte Tools, sicheres Retrieval, die Bestätigung von Aktionen und laufende Tests.
Kann eine schädliche Anweisung auch in einem internen Dokument stehen?
Ja. Das Dokument könnte versehentlich hochgeladen oder kompromittiert worden sein oder zitierten externen Text enthalten. Jeder vom Modell analysierte Inhalt wird als Daten mit einer festgelegten Vertrauensstufe behandelt.
Sollte ein KI-System die API-Schlüssel seiner Tools kennen?
Nein. Geheimnisse verbleiben in der Serverschicht, die die autorisierte Funktion ausführt. Das Modell erhält nur das sichere Ergebnis, das zur Fortsetzung der Aufgabe nötig ist.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
