Eine wichtige Schutzmaßnahme ist ein kontrollierter Daten- und Aktionsfluss: Externe Inhalte werden als unzuverlässige Daten behandelt, Zugriffe technisch begrenzt und sensible Aktionen anhand unabhängiger Regeln geprüft. Eine einzelne Prompt-Anweisung oder ein Filter kann Prompt Injection nicht zuverlässig vollständig verhindern.
Wie lässt sich das im Alltag umsetzen? Wir betrachten einen fiktiven E-Mail-Prozess, die wichtigsten Schutzschichten und konkrete Testfälle für ein Pilotprojekt.
Was ist Prompt Injection bei KI-Agenten?
Prompt Injection bezeichnet den Versuch, das Verhalten eines KI-Systems durch eingeschleuste Anweisungen zu beeinflussen. Bei einer indirekten Prompt Injection stehen diese Anweisungen in Inhalten, die der Agent für seine eigentliche Aufgabe liest: etwa in einer Kunden-E-Mail, einem PDF-Anhang, einem Support-Ticket oder einer Webseite.
Die Herausforderung: Ein großes Sprachmodell, auch Large Language Model (LLM) genannt, verarbeitet sowohl die Arbeitsanweisung als auch fremde Inhalte in natürlicher Sprache. Diese gemeinsame Verarbeitung schafft eine mögliche Schwachstelle: Das Modell kann eine fremde Anweisung für einen Teil des eigentlichen Auftrags halten. Bösartige Anweisungen in externen Inhalten können die Anwendung so zu einer unerwünschten Antwort oder Handlung verleiten. Ein geschickt formulierter Text kann versuchen, die ursprüngliche Aufgabe zu verändern, vertrauliche Informationen in eine Antwort einzubauen oder eine Aktion auszulösen. Das Risiko betrifft auch interne Zusammenfassungen, selbst wenn der Agent keine E-Mail versenden darf. Prompt-Injection-Angriffe können so Antworten verfälschen oder einen Datenabfluss vorbereiten.
MITRE beschreibt indirekte Prompt Injection als Angriff über externe Datenquellen. Welche Folgen tatsächlich möglich sind, hängt davon ab, welche Daten und Werkzeuge dem Agenten zur Verfügung stehen. Solche Werkzeuge werden auch Tools genannt; über sie kann ein Agent beispielsweise Informationen abfragen oder eine Nachricht vorbereiten. Die E-Mail ist dabei ein möglicher Angriffsvektor: Sie bringt Inhalte von außen in den Kontext der KI.
Direkte und indirekte Prompt Injection unterscheiden
Eine direkte Prompt Injection erfolgt über eine Eingabe an die Anwendung, etwa wenn jemand einen Chatbot gezielt zu einer unerlaubten Antwort verleiten will. Bei der indirekten Variante liegt die fremde Anweisung in einer Quelle, die ein System später für einen legitimen Auftrag liest – zum Beispiel in einer E-Mail, einem Dokument oder einem Support-Ticket. Die Anweisung kann die KI dazu bringen, Inhalte falsch einzuordnen oder eine nicht vorgesehene Aktion vorzuschlagen.
In der Sicherheitsanalyse wird der eingeschleuste Inhalt auch als Payload bezeichnet. Er kann Anweisungen in natürlicher Sprache enthalten, aber ebenso aus anderen für das Modell verarbeitbaren Inhalten bestehen.
Für die praktische IT-Sicherheit lohnt sich die Frage: Wer kann Inhalte in diese Quelle einbringen? Ein offenes Support-Postfach ist anders zu bewerten als eine intern gepflegte Wissensquelle. Auch interne Dokumente können manipuliert oder versehentlich verändert werden; ihre Herkunft allein garantiert keine Sicherheit. OWASP erläutert beide Varianten.
Prompt Injection und Phishing: Wo liegt der Unterschied?
Beim klassischen Phishing versucht ein Angreifer häufig, eine Person durch eine täuschende Nachricht zu einer Handlung zu bewegen – etwa zur Preisgabe von Zugangsdaten. Bei Prompt Injection sollen eingeschleuste Anweisungen ein KI-System beeinflussen. Cyberkriminelle können beide Angriffsmethoden in einer Nachricht kombinieren. Ein etablierter Mailfilter bleibt daher Teil der IT-Sicherheit; er kann allein nicht sicher beurteilen, wie ein Sprachmodell einen Inhalt verarbeitet.
Bestehende E-Mail- und Security-Filter bleiben wichtig. Selbst eine korrekt zugestellte Nachricht eines bekannten Absenders kann jedoch problematische Inhalte enthalten, etwa wenn dessen Konto kompromittiert wurde. Abwehrmaßnahmen müssen daher auch berücksichtigen, was der Agent nach dem Lesen ausführen darf.
Indirekte Prompt Injection: Beispiel einer Kundenanfrage
Stellen wir uns einen mittelständischen Betrieb vor. Ein AI Agent liest Anfragen aus einem gemeinsamen Postfach und erstellt Antwortentwürfe für den Kundenservice. Eine Nachricht enthält eine normale Frage zu Lieferzeiten. Zusätzlich fordert ein manipulativer Absatz das System auf, seine ursprüngliche Aufgabe zu ignorieren, eine interne Preisliste abzurufen und an eine weitere Adresse zu senden.
Der Zusatz kann offen im Text stehen oder in einem Anhang vorkommen. Eine versteckte Anweisung kann für einen Benutzer schwer zu sehen sein und dennoch vom Modell verarbeitet werden. Auch eine Nachricht, die auf den ersten Blick harmlos wirkt, kann eine Anweisung enthalten, die potenziell schädlich ist. Das fiktive Szenario dient der Erklärung; es beschreibt keinen dokumentierten Vorfall bei einem AI-Cowork-Kunden.
| Schritt | Gewünschter Ablauf | Mögliche Abweichung |
|---|---|---|
| Eingang | Kundenanfrage aus dem freigegebenen Postfach abrufen | Der Agent verarbeitet zusätzlich eine fremde Handlungsanweisung. |
| Bearbeitung | Lieferfrage erkennen und relevante Informationen suchen | Die Nachricht beeinflusst, welche internen Informationen abgerufen werden. |
| Entwurf | Antwort für die zuständige Person vorbereiten | Ein Entwurf enthält vertrauliche Daten oder einen manipulierten Empfänger. |
| Versand | Eine berechtigte Person prüft und bestätigt den Entwurf. | Eine unzureichend kontrollierte Funktion versendet Inhalte extern. |
Schon beim Erstellen eines Entwurfs können Daten an ein anderes System übertragen oder für weitere Personen sichtbar werden. Deshalb sollten Unternehmen auch den Speicherort, die Zugriffsrechte und mögliche Folgeaktionen eines Entwurfs prüfen.
Abwehr von Prompt Injection: Warum reicht eine Anweisung allein nicht aus?
Eine klare Systemanweisung kann dem Modell helfen, seine Aufgabe und die Herkunft von Informationen einzuordnen. Sinnvoll ist etwa der Hinweis, dass E-Mails und Anhänge als externe Inhalte behandelt werden. Die übergeordnete Arbeitsanweisung wird häufig System Prompt genannt. Sie ist eine wichtige Grundlage für KI-Anwendungen, bietet allein jedoch keine technische Zugriffssperre: Bösartige Anweisungen können KI-Systeme trotz sorgfältig formulierter Prompts beeinflussen. Ein Modell kann externe Informationen falsch interpretieren oder eine manipulative Anweisung übernehmen.
Ein vorgeschalteter Filter kann Inhalte semantisch anhand ihrer Bedeutung untersuchen und verdächtige Formulierungen erkennen. Dabei sind sowohl Fehlalarme als auch übersehene Angriffe möglich. Bei KI-Systemen, die externe Inhalte verarbeiten, sollte die Erkennung deshalb durch unabhängige technische Regeln ergänzt werden. OWASP empfiehlt deshalb mehrere Schutzmaßnahmen, darunter begrenzte Rechte, unabhängige Kontrollen für Aktionen und regelmäßige Sicherheitstests.
Für Unternehmen ist entscheidend, welche Auswirkungen ein Fehler im schlimmsten Fall haben kann. Darf der Agent nur eine begrenzte Auswahl an Nachrichten zusammenfassen? Kann er zusätzlich Dokumente durchsuchen, Empfänger ändern oder Nachrichten versenden? Welche Befehle dürfen seine Tools ausführen? Je größer die Rechte, desto sorgfältiger müssen die einzelnen Übergänge abgesichert werden.
Erkennung und Abwehr von Prompt Injection im E-Mail-Prozess
Die Erkennung sollte mehrere Stellen im Ablauf einbeziehen: Nachricht und Anhang, angeforderte Tool-Aufrufe und den vorbereiteten Entwurf. Eine verdächtige E-Mail kann zum Beispiel versuchen, den Empfänger zu ändern oder zusätzliche Daten aus einer internen Quelle anzufordern. Prüfen Sie dabei auch versteckte Inhalte, soweit sie vom verwendeten Parser oder Modell verarbeitet werden. Verdächtige Merkmale sind Hinweise für die Prüfung; eine sichere Erkennung jedes Angriffs lässt sich daraus nicht ableiten.
Für die Abwehr von Prompt Injection ist entscheidend, welche Aktion technisch möglich ist. Eine Anwendung kann etwa nur eine Zusammenfassung erzeugen und den Versand in einem gesonderten Schritt mit eigener Berechtigung und Freigabe vorsehen. Auch Inhalte, die aus KI-Systemen zurückkommen, sollten vor ihrer Weitergabe auf Empfänger, Berechtigung und den beabsichtigten Zweck geprüft werden. Das begrenzt mögliche Auswirkungen, garantiert aber keine fehlerfreie Antwort.
KI-Agenten und E-Mail: Sechs Schutzmechanismen für den Workflow
1. Aufgabe und erlaubte Daten eingrenzen
Definieren Sie zunächst den Geschäftsprozess: Welche Postfächer, Nachrichtentypen und Dokumente braucht der Agent tatsächlich? Ein Agent für Lieferanfragen benötigt beispielsweise nicht automatisch Zugriff auf Personalakten oder das gesamte Unternehmensarchiv.
Die Auswahl sollte technisch durch Postfach-, Dokumenten- und Schnittstellenrechte umgesetzt werden. So lassen sich Kundendaten auf den für den Auftrag erforderlichen Umfang begrenzen. Welche Quellen als vertrauenswürdig gelten, muss das Unternehmen festlegen und regelmäßig überprüfen. Zusätzlich lohnt sich eine klare Kennzeichnung von Nachrichtentexten und Anhängen als externe Inhalte. Die Kennzeichnung kann die Einordnung durch das Modell unterstützen, ersetzt aber keine Zugriffskontrolle.
2. Lese- und Aktionsrechte getrennt vergeben
Lesen, Entwürfe erstellen, Nachrichten versenden und Daten in anderen Anwendungen verändern sind unterschiedliche Funktionen. Prüfen Sie für jede Funktion, ob sie im Prozess gebraucht wird und welche Identität sie ausführt. Ein Agent, der Antworten vorbereitet, braucht in einem Pilotprojekt häufig zunächst keinen direkten Versandzugriff.
Auch ein reiner Lesezugriff kann vertrauliche Informationen offenlegen. Einschränkungen müssen daher sowohl für den Abruf als auch für die Weitergabe und Speicherung von Inhalten gelten. Mehr zu technischen Identitäten und begrenzten Rechten im Beitrag KI-Agenten: Identität und Zugriffsrechte.
3. Versand und andere sensible Aktionen unabhängig prüfen
Für den Einstieg empfiehlt sich eine menschliche Prüfung, bevor eine externe Nachricht versendet oder eine folgenreiche Änderung ausgeführt wird. Die zuständige Person sollte Empfänger, Inhalt, Anhänge und den Anlass der Aktion sehen können.
Für diesen Schritt braucht die Anwendung einen eindeutigen Freigabestatus. Die technische Freigabe muss an die konkret geprüfte Fassung gebunden sein. Ändert sich nach der Prüfung beispielsweise der Empfänger oder der Anhang, sollte die Freigabe erneut erforderlich sein. Das ausführende System prüft vor dem Versand Berechtigung und Freigabestatus. Ob und wann später eine weitergehende Automatisierung sinnvoll ist, hängt vom Risiko, den Tests und den internen Regeln ab.
4. Empfänger, Ausgaben und Folgeaktionen begrenzen
Ein Freigabedialog hilft nur, wenn die prüfende Person sehen kann, was tatsächlich passiert. Ergänzend können technische Regeln etwa externe Empfänger einschränken, bestimmte Anhänge blockieren oder Datenübertragungen auf ausdrücklich zugelassene Ziele begrenzen. Auch Links, Werkzeugaufrufe und Weiterleitungen gehören in die Betrachtung. Für die Cybersicherheit ist zudem wichtig, welche externen Ziele das System technisch erreichen kann. Ein erlaubter Systemzugriff auf das Postfach sollte beispielsweise nicht automatisch den Zugriff auf fremde Webdienste einschließen. Eine Prüfung darf sich nicht allein auf den für Menschen sichtbaren Text verlassen.
Prüfen Sie dabei jeweils die konkreten Funktionen des verwendeten Systems. Eine pauschale Empfängerliste erkennt nicht jede Manipulation; auch interne Empfänger können Inhalte erhalten, für die sie nicht berechtigt sind.
5. Fehler und verdächtige Anfragen behandeln
Was geschieht, wenn eine Nachricht die Aufgabe ändern will, der Empfänger unklar ist oder eine Berechtigungsprüfung fehlschlägt? Legen Sie einen sicheren Ablauf fest: Aktion stoppen, den Fall für eine zuständige Person sichtbar machen und gegebenenfalls manuell bearbeiten.
Die Anomalieerkennung kann Sicherheitsteams zusätzlich auf ungewöhnliche Werkzeugaufrufe oder viele fehlgeschlagene Berechtigungsprüfungen aufmerksam machen. Sie erkennt jedoch weder jeden Angriff noch beweist jede Auffälligkeit einen Missbrauch. Protokolle können helfen, einen Vorfall nachzuvollziehen. Sie sollten selbst auf das notwendige Maß begrenzt und geschützt werden: E-Mails, personenbezogene Angaben und vollständige Modellantworten gehören nicht automatisch unbeschränkt in Logdateien.
6. Wiederholt testen und Zuständigkeiten festlegen
Ein einmaliger Test zeigt nur, wie sich eine bestimmte Konfiguration in diesen Fällen verhält. Neue Modelle, Werkzeuge, Datenquellen oder geänderte Berechtigungen können die Ergebnisse verändern. Legen Sie fest, wer Tests verantwortet, Abweichungen bewertet und nach relevanten Änderungen erneut prüft. Fachbereich und Sicherheitsteams können dafür gemeinsam Testfälle aktualisieren und die Ergebnisse bewerten.
Datenschutz: Welche Daten sieht das Modell?
E-Mails enthalten häufig Namen, Kontaktdaten oder Informationen zu konkreten Vorgängen. Klären Sie vor dem Einsatz, welche Daten für die Aufgabe erforderlich sind, welche Dienste sie verarbeiten und wer auf Eingaben, Ausgaben und Protokolle zugreifen darf.
Bei AI Cowork ersetzen wir erkannte personenbezogene Angaben vor der Modellverarbeitung durch Platzhalter. Enthält das Ergebnis diese Platzhalter, ordnen wir sie anschließend wieder den ursprünglichen Angaben zu. Diese zusätzliche Pseudonymisierung setzen wir bei lokalen Modellen sowie beim Einsatz von Azure und Amazon Bedrock ein. Für Azure und Bedrock nutzen wir Server in Deutschland; wenn diese für den vorgesehenen Einsatz dort nicht verfügbar sind, wählen wir alternativ einen Standort in der EU.
Da eine Zuordnung zu den Originaldaten möglich bleibt, sprechen wir von Pseudonymisierung. Sie vermindert Risiken, ersetzt aber weder die Prüfung der Datenflüsse und Zugriffsrechte noch eine Bewertung des konkreten Projekts. Für den E-Mail-Anwendungsfall sollten Unternehmen auch testen, welche Angaben und Anhänge tatsächlich erfasst werden und wie mit nicht erkannten Daten umgegangen wird. Der Europäische Datenschutzausschuss erläutert den Unterschied zur Anonymisierung.
Wichtig für das Sicherheitskonzept: Pseudonymisierung allein verhindert keine Prompt Injection. Ein manipulativer Text kann auch ohne personenbezogene Angaben versuchen, einen Agenten zu einer unerwünschten Aktion zu bewegen.
Prompt-Injection-Angriffe erkennen: Testfälle für den Pilotbetrieb
Die folgende Tabelle zeigt vorgeschlagene Testfälle für die Abnahme einer konkreten Anwendung und ihrer Schnittstellen. Sie dokumentiert keine bereits durchgeführten AI-Cowork-Tests.
| Testfall | Was sollte geprüft werden? |
|---|---|
| E-Mail verlangt Zugriff auf Personalunterlagen | Der Zugriff wird durch die technische Berechtigung verweigert; das Verhalten wird protokolliert, soweit vorgesehen. |
| Nachricht fordert Versand an eine neue externe Adresse | Eine unabhängige Regel blockiert oder verlangt eine passende Prüfung; der vollständige Empfänger ist sichtbar. |
| Manipulative Anweisung steht in einem Anhang | Das System verarbeitet den Anhang nur im vorgesehenen Umfang; unzulässige Aktionen bleiben gesperrt. |
| Antwortentwurf enthält vertrauliche Informationen | Prüfen, ob die vorgesehenen Zugriffs- und Ausgaberegeln sowie die menschliche Prüfung den Fall erfassen und der Versand bis zur Klärung ausgesetzt bleibt. |
| Empfänger oder Anhang wird nach Freigabe geändert | Die ursprüngliche Freigabe gilt für die geänderte Fassung nicht weiter. |
| Prüfdienst oder Berechtigungsprüfung ist nicht erreichbar | Die sensible Aktion wird angehalten und ein definierter Ausnahmeprozess gestartet. |
| Inhalt enthält Namen und Kontaktangaben | An repräsentativen Testdaten prüfen, was vor dem Modellaufruf ersetzt wird und wie mit nicht erkannten Angaben umzugehen ist. |
| Modell oder Connector wird geändert | Die relevanten Sicherheits- und Funktionstests werden vor erneutem Einsatz wiederholt. |
Ein guter Workflow dokumentiert den Testfall, die Konfiguration und das tatsächliche Ergebnis. Er umfasst auch gewöhnliche, zulässige Kundenanfragen und überprüft die Schutzmechanismen nach Änderungen an Tools oder Datenquellen. Ein System, das zu viele harmlose Nachrichten blockiert, führt sonst zu unnötiger manueller Nacharbeit. Beobachten Sie deshalb sowohl übersehene Angriffe als auch falsche Alarme.
Wie starten Unternehmen mit einem E-Mail-Agenten?
Für einen ersten Pilot empfehlen wir vier überschaubare Schritte:
- Einen Prozess wählen: zum Beispiel allgemeine Lieferanfragen aus einem abgegrenzten Postfach.
- Rechte und Daten festlegen: definieren, was der Agent lesen darf, wo Entwürfe liegen und welche Daten an das Modell gehen.
- Prüfung und Ausnahmen einrichten: eine verantwortliche Person prüft externe Antworten; unklare Fälle werden manuell bearbeitet.
- Ergebnisse auswerten: Qualität, Bearbeitungsaufwand, Fehlalarme und Sicherheitsfälle anhand geeigneter Testdaten gemeinsam betrachten.
So können Teams Geschäftsprozesse schrittweise automatisieren und mehrere Aufgaben koordinieren, während die Verantwortung und die Grenzen der Anwendung nachvollziehbar bleiben. Wie sich eine konkrete Freigabe an eine Angebotsfassung binden lässt, erläutern wir im Beitrag KI-Agenten: Angebote erstellen und freigeben.
Was tun, wenn ein Verdacht auf Prompt Injection besteht?
Stoppen Sie die betroffene automatisierte Aktion und informieren Sie die für den Prozess und die IT-Sicherheit zuständigen Personen. Prüfen Sie, welche Werkzeuge aufgerufen wurden, ob sensible Daten in einen Entwurf gelangt sind und ob eine Nachricht tatsächlich versendet wurde. Die nötigen Protokolle und die verdächtige E-Mail sollten entsprechend den internen Regeln gesichert werden.
Bis der Sachverhalt geklärt ist, kann das Team den Workflow begrenzen und betroffene Berechtigungen überprüfen. Anschließend hilft ein zusätzlicher Testfall, dieselbe Situation nach einer Änderung erneut zu prüfen. Maßnahmen und Meldepflichten hängen vom Vorfall und den geltenden Vorgaben ab.
Häufige Fragen
Kann ein KI-Agent eine Prompt Injection in einer E-Mail immer erkennen?
Nein. Modelle und Erkennungsfilter können Angriffe übersehen oder harmlose Inhalte falsch einstufen. Schutz entsteht aus mehreren Maßnahmen, insbesondere begrenzten Rechten, unabhängigen Aktionsprüfungen und regelmäßigen Tests.
Sind lokale KI-Modelle vor Prompt Injection geschützt?
Ein lokales Modell kann den Datenstandort beeinflussen, verhindert aber nicht automatisch, dass manipulative Anweisungen in einer E-Mail verarbeitet werden. Auch lokal sind passende Berechtigungen und Kontrollen erforderlich.
Darf ein KI-Agent E-Mails autonom beantworten?
Das hängt von der technischen Umsetzung, dem Inhalt, dem Risiko und den internen Vorgaben ab. Für einen neuen Prozess ist ein Pilot mit geprüften Antwortentwürfen häufig ein sinnvoller Einstieg. Für spätere autonome Schritte sollten Unternehmen klare Grenzen und geeignete Tests festlegen.
Betrifft Prompt Injection auch KI-Chatbots?
Ja. Auch Chatbots mit generativer KI können fremde Inhalte verarbeiten und dadurch beeinflusst werden. Bei Anwendungen wie ChatGPT oder Gemini hängt das Risiko von der jeweiligen Funktion, den verbundenen Datenquellen und den erteilten Rechten ab. Ein Chatbot mit Systemzugriff benötigt deshalb ebenso begrenzte Rechte und geeignete Kontrollen.
Reicht die Pseudonymisierung personenbezogener Daten als Schutz?
Nein. Pseudonymisierung adressiert einen Teil des Datenschutzrisikos. Gegen unzulässige Werkzeugaufrufe, manipulierte Antworten und ungewollten Versand braucht es ergänzende Kontrollen.
Fazit: E-Mail-Automatisierung mit klaren Grenzen
Intelligente KI-Agenten können Kundenanfragen vorsortieren, Informationen aufbereiten und Antwortentwürfe erstellen. Damit diese Unterstützung im Alltag verlässlich bleibt, sollten Unternehmen Rechte, Datenflüsse und Freigaben für jede Funktion bewusst gestalten und regelmäßig überprüfen.
Möchten Sie prüfen, wie ein sicherer E-Mail-Agent für Ihren Prozess aussehen kann? Sprechen Sie mit uns über eine AI-Cowork-Demo.