Prompt Injection eindämmen, wenn ein Agent fremde Inhalte liest

Mit einer erfolgreichen Injection planen

Der OWASP-Eintrag von 2025 zu Prompt Injection beschreibt indirekte Injection als Inhalte aus externen Quellen wie Websites oder Dateien, die das Verhalten des Modells verändern, und hält fest, dass die Anweisung für Menschen nicht sichtbar sein muss. Er stellt außerdem fest, dass unklar ist, ob es eine narrensichere Verhinderung gibt. Zu den genannten Gegenmaßnahmen gehören minimale Rechte, menschliche Freigabe riskanter Aktionen, die Trennung externer Inhalte und Angriffstests. Daraus folgt unsere Planungsannahme: Entscheidend ist, was der Agent tun kann, nachdem er getäuscht wurde.

Unser Leitfaden zur Sicherheit von Coding-Agenten behandelt Agenten in Repositories. Dieser Beitrag geht um Agenten in Fachprozessen, die E-Mails, Dokumente, Tickets, Webseiten und Tool-Ergebnisse lesen.

Sicherheit von Coding-Agenten in Engineering-Teams

Nicht vertrauenswürdige Eingaben und Aktionen gegenüberstellen

Nehmen wir einen hypothetischen Agenten in der Kreditorenbuchhaltung. Er liest Lieferanten-E-Mails mit PDF-Rechnungen, sucht Bestellungen heraus und könnte im ersten Entwurf Zahlungsvorschläge anlegen, Lieferanten antworten und Bankverbindungen von Lieferanten ändern. Seine Übersicht sieht so aus:

• E-Mail-Texte und Anhänge: nicht vertrauenswürdig, geschrieben von jedem, der an das Postfach schreiben kann
• Bestellungen: vertrauenswürdig bei Beträgen, aber Freitextfelder können vom Lieferanten stammenden Text enthalten
• Antworten an Lieferanten: ein Kanal nach außen, über den alles abfließen kann, was im Kontext des Agenten steht
• Änderung der Bankverbindung: ein folgenreicher Schreibvorgang, auf den eine eingeschleuste Nachricht über ein geändertes Konto zielen würde

Die gefährliche Kombination liegt offen: nicht vertrauenswürdiger Text im Kontext, ein Schreibvorgang, der Geld bewegt, und ein Weg, Daten nach außen zu senden. Zu entscheiden ist, welche Verbindung gekappt wird. Hier würden wir die Änderung von Bankverbindungen ganz aus dem Agenten nehmen, Antworten auf feste Vorlagen ohne Freitext beschränken und den Agenten nur Zahlungen vorschlagen lassen, die eine Person im ERP-System freigibt.

Entwurfsmuster, die den Weg entfernen

Ein Paper von Beurer-Kellner und Kollegen aus dem Jahr 2025 beschreibt Entwurfsmuster, die auf einem Prinzip beruhen: Hat ein Agent nicht vertrauenswürdige Eingaben gelesen, muss er so eingeschränkt sein, dass diese Eingaben keine folgenreichen Aktionen auslösen können. Vier der Muster, die zu Fachprozessen passen:

• Action Selector: Das Modell wählt eine von festen Aktionen und sieht deren Ergebnisse nie, sodass keine Tool-Ausgabe es lenken kann
• Plan then Execute: Das Modell legt seine Tool-Aufrufe fest, bevor es nicht vertrauenswürdige Daten liest. Eingeschleuster Text kann Argumente ändern, aber keine Aufrufe hinzufügen
• Map-Reduce: Jedes nicht vertrauenswürdige Dokument wird isoliert verarbeitet, sodass eine bösartige Datei die Behandlung der anderen nicht beeinflusst
• Dual LLM: Ein privilegiertes Modell mit Tools liest nie nicht vertrauenswürdigen Text, ein abgeschottetes Modell ohne Tools liest ihn und gibt Werte per Referenz zurück

Das von Debenedetti und Kollegen beschriebene System CaMeL leitet Kontroll- und Datenfluss aus der vertrauenswürdigen Anfrage ab und setzt beim Aufruf von Tools Richtlinien über Capabilities durch. Seine Garantien gelten innerhalb des Bedrohungsmodells der Autoren, das die Anfrage des Nutzers als vertrauenswürdig annimmt, und hängen von den Sicherheitsrichtlinien ab, die für jedes Tool festgelegt sind. Die Autoren berichten, dass es 77 % der Aufgaben im Benchmark AgentDojo mit beweisbarer Sicherheit löst, gegenüber 84 % für ein System ohne Schutz. Diese Lücke ist ein gemessener Nutzenverlust in ihrem Benchmark, keine Vorhersage für Ihren Prozess.

Kontrollen, die das Modell nicht umstimmen kann

• Tool-Berechtigungen, die auf die Aufgabe zugeschnitten sind und vom Server oder Fachsystem durchgesetzt werden
• Freigaben, die an genau diese Aktion und diesen Inhalt gebunden sind und von vertrauenswürdigem Code geprüft werden, für alles, was Geld bewegt, Zugriffe ändert oder Daten nach außen sendet
• Begrenzter ausgehender Netzwerkverkehr der Agentenumgebung und eine Darstellung der Ausgabe, die Bilder und Links nicht automatisch lädt, denn OWASP beschreibt Datenabfluss über eine eingefügte Bild-URL
• Deterministische Prüfungen der Ausgaben gegen erwartete Werte, etwa Beträge, die zur Bestellung passen, und Empfänger auf einer Allowlist
• Tool-Ergebnisse als nicht vertrauenswürdige Eingabe behandeln, was die MCP-Spezifikation für Tools aufgreift, wenn sie Clients empfiehlt, Ergebnisse vor der Weitergabe an das Modell zu prüfen

Externe Inhalte im Prompt klar zu kennzeichnen, lohnt sich trotzdem. Es senkt die Erfolgsquote von Injections, doch das Modell kann sich darüber weiterhin hinwegsetzen lassen.

Prüfungen vor und nach dem Go-live

Bauen Sie ein Testset für Angriffe aus Ihren eigenen Eingangskanälen: weißer Text in PDFs, Anweisungen in E-Mail-Signaturen, Text in anderen Sprachen oder Kodierungen und Anweisungen in Tool-Ergebnissen. Prüfen Sie in jedem Fall das Ergebnis an der Grenze, nicht die Formulierung des Modells: kein Schreibvorgang ohne Freigabe, nichts nach außen jenseits der Vorlagen, ein ausgelöster Alarm. Wiederholen Sie das Set bei jeder Änderung an Modell, Prompt oder Tools. Protokollieren Sie nach dem Start jeden Tool-Aufruf mit Kennungen und Quellen der vorher gelesenen Eingaben und der getroffenen Entscheidung. Rohinhalte erfassen Sie nur über eine freigegebene, zugriffsbeschränkte und geschwärzte Erfassung mit eigener Aufbewahrungsfrist. Prüfen Sie abgelehnte Aktionen und werten Sie einen blockierten Versuch als Zeichen, dass jemand testet.

Was die Grenzen kosten

Jedes Muster kostet Flexibilität. Ein Action Selector kann keine Anfrage außerhalb seiner Liste bearbeiten, Plan then Execute kann sich nicht an das anpassen, was es vorfindet, und Freigaben kosten bei jedem betroffenen Fall Zeit einer Person. Richten Sie die Stärke der Grenze an der schlimmsten Aktion aus, die der Agent erreichen kann. Ein Agent, der Dokumente für die Person zusammenfasst, die sie hochgeladen hat, braucht vielleicht wenig Kontrolle. Einer, der zahlen, versenden oder Zugriffe vergeben kann, sollte mit gekappten Wegen starten, und Fähigkeiten kommen erst nach Tests einzeln zurück.

Ein praktischer nächster Schritt: Zeichnen Sie für einen Agenten die Übersicht aus Eingaben und Aktionen und markieren Sie jeden Weg von nicht vertrauenswürdigem Text zu einem Schreibvorgang oder einem Kanal nach außen.

KI-Engineering und -Architektur