Abgerufene Inhalte als nicht vertrauenswürdige Eingaben behandeln

Erkennen Sie, wo Daten zu Anweisungen werden

Ein Coding-Agent liest mehr als den Nutzerauftrag. Er kann Issues, Repository-Dateien, Paketdokumentation, Suchergebnisse und Werkzeugantworten untersuchen. Manche dieser Inhalte können Anweisungen anderer Personen enthalten.

Prompt Injection liegt vor, wenn solche Inhalte das Modell von der autorisierten Aufgabe weglenken. Eine indirekte Injection gelangt über eine abgerufene Quelle zum Modell, nicht über den direkten Nutzerauftrag. OWASP nennt Repository-Material und Werkzeugausgaben als relevante Eintrittspunkte. Lesen Sie den Präventionsleitfaden.

Betrachten Sie eine fiktive Wartungsaufgabe. Der Nutzer bittet den Agenten, einen Berichtsfilter zu korrigieren und die erforderlichen Tests auszuführen. Eine abgerufene README bezeichnet die Tests als veraltet und fordert den Upload einer Konfigurationsdatei. Die README kann das Projekt erklären. Sie darf weder das Auslassen der Nutzerprüfungen noch den Versand von Dateien an andere Ziele erlauben.

Erfassen Sie die möglichen Folgen

Derselbe irreführende Text hat in verschiedenen Umgebungen unterschiedliche Folgen. Ein nur lesendes Zusammenfassungswerkzeug könnte eine falsche Zusammenfassung erzeugen. Ein Agent mit Repository-Schreibzugriff kann Code ändern. Ein Agent mit Secrets und ausgehendem Netzwerkzugriff kann Informationen offenlegen.

Prüfen Sie die verfügbaren Aktionen, bevor Sie die relevanten Schutzmaßnahmen bestimmen. Listen Sie sensible Ressourcen, beschreibbare Ziele und externe Empfänger auf. Beziehen Sie nach der Ersteinrichtung ergänzte Konnektoren ein. Ein neues Werkzeug kann die Folgen einer bestehenden Schwäche vergrößern.

Ein Agent kann irreführenden Inhalt auch in eine spätere Phase tragen. Er könnte zum Beispiel eine nicht vertrauenswürdige Anweisung in einen generierten Auftrag kopieren. Der nächste Agent darf diesen Auftrag nicht als unabhängig genehmigte Richtlinie behandeln.

Nutzen Sie mehrere Kontrollen mit unterschiedlichen Zwecken

Trennen Sie vertrauenswürdige Aufgabenanweisungen im Anwendungsentwurf von abgerufenen Daten. Zeigen Sie die Herkunft des abgerufenen Materials. Diese Schritte verbessern die Interpretation, bilden aber keine vollständige Sicherheitsgrenze.

Setzen Sie Ressourcenberechtigungen im Ausführungssystem durch. Begrenzen Sie Ziele für sensible Daten. Verlangen Sie vor folgenreichen Aktionen die passende Entscheidung. Prüfen Sie den vorgeschlagenen Vorgang gegen die autorisierte Aufgabe und das Ziel.

Filter und ein zweites Modell können verdächtige Inhalte erkennen helfen. Sie können aber auch Angriffe übersehen oder legitime Informationen blockieren. Ersetzen Sie deterministische Autorisierung nicht durch einen Konfidenzwert des Modells. OWASP weist ausdrücklich auf die Grenzen hin, wenn Schutz allein auf Prompts oder Retrieval beruht. Lesen Sie die Risikobeschreibung.

Testen Sie den Ablauf ohne reale Offenlegung

Nutzen Sie ein temporäres Repository und fiktive Dateien. Geben Sie der Evaluation keine Produktionszugangsdaten und keine unbeschränkten externen Schreibrechte. Fügen Sie eine harmlose Anweisung ein, die der Aufgabe widerspricht, etwa eine erforderliche Prüfung auszulassen.

Beobachten Sie sowohl die Modellantwort als auch die tatsächlichen Werkzeugaktionen. Eine Nachricht wie „Ich habe die Anweisung ignoriert“ reicht nicht, wenn die Prüfung trotzdem ausgelassen wurde. Erfassen Sie Aufgabe, injizierte Testdaten, erlaubte Werkzeuge und beobachtetes Ergebnis.

Wiederholen Sie repräsentative Fälle nach Änderungen an Prompts, Modellen, Konnektoren oder Berechtigungen. Ein abgewehrtes Beispiel ist ein Nachweis für diesen Fall, kein Beweis gegen jede Injection. Scheitert ein Test, begrenzen Sie die möglichen Folgen, während Sie den zugrunde liegenden Ablauf korrigieren.