Prompt Injection bei Agenten

Ein Agent liest für seine Aufgabe Nachrichten, Webseiten oder Dokumente. In diesem Inhalt kann eine Anweisung stehen, die mit der eigentlichen Aufgabe nichts zu tun hat. Wird sie als neue Vorgabe übernommen, erhält ein fremder Text Einfluss auf den Ablauf. Bei indirekter Prompt Injection kommt diese Anweisung über eine gelesene Quelle hinein.

Das BSI beschreibt diese Klasse als grundlegende Schwachstelle anwendungsintegrierter Sprachmodelle. Entscheidend ist nicht, ob der Text auffällig aussieht. Auch ein höflich formulierter vermeintlicher Arbeitshinweis kann einen anderen Empfänger, eine neue Werkzeugwahl oder eine unzulässige Datenweitergabe verlangen. Seine Herkunft entscheidet über seine Autorität.

Kennzeichnen Sie Quellen als Inhalt mit begrenztem Vertrauen. Ein Dokument darf Tatsachen für eine Recherche liefern, aber nicht die Rechte des Agenten ändern. Trennen Sie verbindliche Auftragsregeln, Werkzeugbeschreibungen und importierte Daten. Diese Trennung erleichtert die Verarbeitung, ist für ein Sprachmodell allein aber keine harte Sicherheitsgrenze.

Ein Textfilter kann bekannte Muster finden. Er kann nicht beweisen, dass der verbleibende Inhalt ungefährlich ist. Versteckte, kodierte oder mehrsprachige Anweisungen können anders aussehen als die Testfälle. Deshalb muss ein entfernter Filtertreffer nicht die einzige Verteidigung sein. Die Wirkung des Systems bleibt auch hinter dem Filter begrenzt.

Ein Agent soll ein Dokument zusammenfassen. Im Dokument steht die Aufforderung, alle Objekte an ein anderes Ziel zu übertragen. Ein reines Lesewerkzeug ohne Versandfunktion begrenzt diesen Angriff bereits technisch. Ein universelles Werkzeug mit weitreichenden Rechten vergrößert dagegen die mögliche Wirkung.

Prüfen Sie Ziel, Ressource und Datenumfang jedes Schreibaufrufs unabhängig von der Begründung des Modells. Eine Behauptung wie für die Sicherheit erforderlich ist keine Erlaubnis. Sensible Operationen brauchen eine passende Handlungserlaubnis und gegebenenfalls eine konkrete Freigabe. Das Zielsystem muss unerlaubte Aufrufe ablehnen können.

Bauen Sie einen Testsatz aus typischen Arbeitsquellen und gezielten Gegenbeispielen. Ein Fall enthält eine Aufgabe, eine präparierte Quelle, erlaubte Werkzeuge und ein beobachtbares unerwünschtes Ergebnis. Prüfen Sie sowohl die Antwort als auch die tatsächlich aufgerufenen Werkzeuge und die Veränderungen im Zielzustand.

Ein guter sicherer Ausgang kann lauten: Quelle wurde gelesen, fremde Anweisung wurde nicht ausgeführt, Aufgabe blieb innerhalb des Auftrags. Ein anderer Fall muss mit einer klaren Übergabe enden. Dokumentieren Sie verbleibende Lücken. Ein bestandener Testsatz belegt Verhalten unter diesen Bedingungen, keine vollständige Abwehr aller späteren Angriffe.

SnapSite plant den Zusammenhang aus FORGE für Kontext, AXON für begrenzte Arbeit und KALKÜL für kontrollierte Handlungen. Die vorhandene Freigabemechanik zeigt, wie eine konkrete Erlaubnis unabhängig vom Modell geprüft werden kann. Sie ist damit ein Baustein zur Begrenzung von Folgen.

Ein allgemeiner Schutz gegen Prompt Injection ist dadurch nicht nachgewiesen. Der Prototyp beweist weder sichere Quellenverarbeitung noch vollständige Abschottung aller Werkzeuge. Eine solche Aussage bräuchte einen eigenen Angriffstestsatz für einen konkreten Agenten mit echten Verbindungen und bekannten Rechten. Die Dokumentation benennt deshalb Entwurfsprinzip und Nachweisgrenze getrennt.