Prompt-Injection: Risiken des Datenabflusses bei KI-Assistenten

Was ist eine Prompt-Injection?

Die Prompt-Injection ist ein Cyberangriff auf große Sprachmodelle (LLM): Der Angreifer tarnt bösartige Eingaben als legitime Eingaben [10]. Sie richtet sich gegen Dienste, die auf KI setzen [11]. Ziel ist, das Modell dazu zu bringen, seine ursprünglichen Anweisungen zu ignorieren [13] und stattdessen die des Angreifers zu befolgen [27].

Die drei Elemente der Definition

• Eine scheinbar legitime Eingabe: Der präparierte Text ähnelt einer Anfrage oder einem gewöhnlichen Inhalt [10].
• Eine Wirkung auf die Anweisungen: Das Modell gibt die Vorgaben auf, die sein Verhalten bestimmten [27].
• Ein Nutznießer: Befolgt werden nun die Befehle des Angreifers und nicht mehr die des Konzeptors oder des legitimen Nutzers [27].

Eine Quelle beschreibt sie als Möglichkeit, eine KI umzulenken, ohne eine Schwachstelle im klassischen Sinne auszunutzen [28]. Für einen CISO verändert das die Art des Problems: Die Manipulation läuft über den normalen Nutzungskanal des Modells und nicht über einen Codefehler, den ein Patch schließen könnte.

Zwei gängige Analogien, mit Vorsicht zu verwenden

In der Literatur der Anbieter tauchen zwei Vergleiche immer wieder auf:

• SQL-Injection: Flutteris beschreibt die Prompt-Injection als „das KI-Äquivalent der SQL-Injection“ [27].
• Social Engineering: OpenAI bezeichnet sie als eine für konversationelle KI spezifische Form des Social Engineering [16].

Beide Quellen sind kommerzielle Akteure. Ihre Vergleiche dienen der Veranschaulichung: Sie helfen, das Risiko im Verhältnis zu bekannten Angriffen einzuordnen, belegen aber keine technische Gleichwertigkeit. Der erste Vergleich betont die präparierte Eingabe, die ein System umlenkt, der zweite die Überzeugung eines Gesprächspartners. Die Prompt-Injection entlehnt von beidem etwas, ohne mit einem von beiden identisch zu sein.

Bleibt zu klären, warum ein Modell sich so umlenken lässt und auf welchen Wegen die bösartige Eingabe es erreicht. Dies ist Gegenstand der folgenden Abschnitte.

Warum lassen sich LLM manipulieren?

LLM lassen sich manipulieren, weil sie die Anweisungen, die man ihnen gibt, nicht von den Daten trennen, die sie lesen: Das Modell verarbeitet alle Eingaben als einen fortlaufenden Prompt [34].

Eine Grenze, die verschwimmt

Erhält ein Agent die Aufforderung „Analysiere diesen Vertrag“, „Fasse diese E-Mail zusammen“ oder „Formuliere diesen Absatz um“, führt er die Anweisung aus. Um die Aufgabe zu erfüllen, liest er jedoch ein Dokument, und dessen Inhalt hat für ihn nicht einen anderen Status als die ursprüngliche Anweisung [34]. Ein im Dokument eingeschmuggelter Text kann daher als Befehl verstanden werden. Die KI wird so zum Angriffsvektor, weil sie die Grenze zwischen Daten und Anweisungen auflöst [21].

Die Folgen zeigen sich im indirekten Fall: Die KI führt die versteckten Befehle dann aus, als kämen sie vom legitimen Nutzer [36]. Eine Analyse von Palo Alto Networks zu Coding-Assistenten geht in dieselbe Richtung: Das Modell unterscheidet nicht zuverlässig zwischen Systemanweisungen und Nutzeranfragen [33].

Ein Angriff, der keine Schwachstelle ausnutzt

Die Prompt-Injection lenkt eine KI um, ohne eine Schwachstelle im traditionellen Sinne auszunutzen [28]. Sie beruht nicht auf einem Implementierungsfehler. Sie nutzt die normale Funktionsweise des Modells, um sie gegen seine Konzeptoren zu wenden [24]. Das Modell tut, wofür es konzipiert wurde: Es befolgt die Anweisungen, die es liest.

Die Vergleiche der Quellen spiegeln diese Besonderheit wider. Manche setzen den Angriff mit der SQL-Injection gleich, da der Angreifer das Modell dazu bringt, seine ursprünglichen Anweisungen aufzugeben und seine eigenen zu befolgen [27]. Andere sehen darin einen für konversationelle KI typischen Social-Engineering-Angriff [16]. Die zweite Parallele ist anschaulicher: Man erzwingt keinen Schutzmechanismus, man überzeugt das Modell.

Diese grundlegende Ursache wiegt umso schwerer, je mehr Assistenten sich internen Daten und dem Web öffnen. Diese Erweiterung ihrer Fähigkeiten bringt eine Form von Risiko mit sich, die noch wenig eingegrenzt ist [28]. Je mehr Quellen der Agent liest, die er nicht kontrolliert, desto mehr Gelegenheiten gibt es, dort eine Anweisung unterzubringen. Daher die Auffassung mancher Quellen, dass Sicherheit auf der Reduzierung der Angriffsfläche, dem Least-Privilege-Prinzip und Kontrollen auf jeder Stufe beruht und nicht auf einer einzigen Abwehrmaßnahme [39].

Worin unterscheiden sich direkte und indirekte Injection?

Die direkte Injection wird vom Angreifer in die Anfrage eingegeben, die er an das Modell richtet. Die indirekte Injection ist in einer Quelle versteckt, die der Assistent verarbeitet, und der legitime Nutzer bemerkt sie oft nicht. Eine Quelle definiert sie als das Einfügen bösartiger Anweisungen in eine Anfrage oder in eine Datenquelle, um das Verhalten des Modells zu beeinflussen [23].

Wo sich die Anweisungen verbergen

• Direkt: Die Anweisung kommt über den Kanal der Konversation, in Form einer Anfrage.
• Indirekt: Die Anweisung läuft über die Daten, die die KI verarbeitet, häufig ohne Wissen des Nutzers [18]. Es kann sich um ein Dokument, eine Webseite oder eine andere Datenquelle handeln.

Der zweite Fall funktioniert, weil die KI alle Eingaben als einen fortlaufenden Prompt verarbeitet. Sie trennt die Anweisungen, die der Nutzer ihr gegeben hat („Analysiere diesen Vertrag“, „Fasse diese E-Mail zusammen“), nicht von den Daten, die sie gerade liest [34].

Eine Webseite, die einen Assistenten in die Falle lockt

Eine Webseite kann ausreichen, um einen Assistenten umzulenken. Ein Artikel über Claude beschreibt dieses Szenario: Der Inhalt der Seite enthält versteckte Befehle, und die KI führt sie aus, als kämen sie vom legitimen Nutzer. Mögliche Folgen sind Datenabflüsse, nicht autorisierte Aktionen oder verzerrte Antworten [36]. Der Nutzer hat lediglich gebeten, eine Seite einzusehen oder zusammenzufassen. Der Angreifer hatte dagegen nie Zugriff auf die Konversation.

Ein Punkt der Aufmerksamkeit für Agenten

Die wissenschaftlichen Quellen des Dossiers behandeln die indirekte Injection als eigenständiges Risiko. Ein Aufsatz über die Delegation einer Absicht an einen KI-Agenten nennt die Prompt-Injection, „einschließlich der indirekten“, als erstes Risiko und den Datenabfluss als zweites [8]. Ein Werk über die Verantwortung, wenn Maschinen handeln, behandelt ebenfalls ausdrücklich die indirekte Prompt-Injection [5]. Bei einem Agenten, der externe Quellen liest und danach handelt, beschränkt sich die Angriffsfläche also nicht auf das, was der Nutzer eingibt. Sie umfasst alles, was der Agent öffnet, liest oder abfragt.

Wie führt eine Prompt-Injection zu einem Datenabfluss?

Eine Prompt-Injection führt auf drei dokumentierten Wegen zu einem Datenabfluss: über unerwünschte Aktionen des Agenten, über die Ausgaben des Modells und über die Offenlegung des Systemprompts. Diese durch einen Angreifer verursachten Abflüsse sind von solchen zu unterscheiden, die aus alltäglicher Nutzung entstehen.

Drei durch den Angriff ausgelöste Abflusswege

• Unerwünschte Aktionen des Agenten. Laut Bruno Lussato, zitiert von franceinfo, kann ein Angreifer Prompts entwerfen, die den KI-Agenten dazu bringen, gegen seine Rolle zu handeln: Datenabfluss, Ausführung von Code oder Erzeugung schädlicher Inhalte [26]. Der Abfluss sensibler Daten zählt außerdem zu den wichtigsten erfassten Risiken, neben der teilweisen Übernahme von Systemen und dem Reputationsschaden [25].
• Abfluss über die Ausgaben des Modells. Unter den häufigen Bedrohungen nennt eine Quelle „von der Prompt-Injection bis zum Abfluss über die Ausgaben“ [2]. Was das Modell antwortet, kann also selbst zum Ausgangskanal für Informationen werden.
• Abfluss des Systemprompts. Er ist technisch mit der Prompt-Injection und dem Jailbreak verwandt [30]. API-Schlüssel und Zugangsdaten zählen zu den offengelegten Elementen [30]. Daraus lässt sich ableiten, dass ein Systemprompt keine Geheimnisse enthalten sollte.

Abflüsse durch alltägliche Nutzung: ein anderer Mechanismus

In diesem zweiten Fall ist kein Angreifer beteiligt. Vertrauliche Informationen werden unbeabsichtigt an externe Dienste weitergegeben, über KI-Oberflächen, die Mitarbeitende nutzen [20]. Die Ursache ist ein Nutzungsverhalten und keine Manipulation des Modells.

Beide Familien treffen sich bei der Frage, welche Daten in Prompts eingegeben werden. Eine Analyse zur Shadow AI empfiehlt, sich zu fragen, welche Daten ein Tool in seine Prompts einbezieht [3]. Informationen, die an einen nicht kontrollierten Dienst übermittelt werden, sind offengelegt, ob eine Injection stattfindet oder nicht.

Diese Unterscheidung ist für einen CISO wichtig: Die beiden Abflüsse erfordern nicht dieselben Maßnahmen. Laut einer der Quellen gilt bei diesem Assistenten-Typ: „Das eigentliche Sicherheitsthema ist die Governance“ [2].

Welche weiteren Schäden entstehen bei Agenten, Speicher und Code?

Das Risiko der Prompt-Injection beschränkt sich nicht auf den Datenabfluss: Sobald ein Assistent über Werkzeuge, ein Gedächtnis oder Zugriff auf Code verfügt, kann eine umgelenkte Anweisung Handlungen auslösen und nicht nur Offenlegungen.

Unvorhergesehene Aktionen und Weiterverbreitung

Laut Bruno Lussato, zitiert von franceinfo, kann ein Angreifer Prompts entwerfen, die unerwünschte Aktionen des Agenten auslösen: Datenabfluss, Ausführung von Code oder Erzeugung schädlicher Inhalte [26]. IBM beschreibt außerdem ein Szenario der Weiterverbreitung. Die bösartige Anweisung fordert den Assistenten auf, sie an weitere Kontakte zu übermitteln [10]. Der Angriff bleibt somit nicht auf das erste Opfer beschränkt.

Vergiftung des Speichers

Versteckte Anweisungen können unauffällig in den Speicher verbreiteter Consumer-Assistenten eingeschleust werden: Microsoft Copilot, ChatGPT, Claude, Perplexity und Grok [29]. Das Ziel ist nicht mehr eine isolierte Konversation, sondern das Gedächtnis des Assistenten.

Gekaperte Coding-Assistenten

Das Team Unit 42 von Palo Alto Networks hat festgestellt, dass diese Assistenten von Nutzern oder böswilligen Akteuren über den Chat, die Autovervollständigung oder die Generierung von Unit-Tests manipuliert werden können. Die festgestellten Folgen sind das Einschleusen von Hintertüren, der Abfluss sensibler Informationen und die Erzeugung schädlicher Inhalte [33]. Secure Code Warrior berichtet seinerseits von einem Coding-Agenten, der so manipuliert wurde, dass er Code mit SQL-Injection-Anfälligkeiten schreibt und Systemwerkzeuge installiert [17].

Was diese Quellen wert sind

Diese Fälle stammen von einem Massenmedium (franceinfo) und von kommerziellen Akteuren: IBM, Palo Alto Networks, Secure Code Warrior. Auch der Artikel, der die Speichervergiftung beschreibt, stammt von einer kommerziellen Website, und der verfügbare Auszug erlaubt es nicht, die Autoren der zitierten Studie zu identifizieren [29]. Keines dieser Elemente ist eine hier geprüfte Primärstudie. Sie veranschaulichen plausible und dokumentierte Szenarien, messen aber weder deren Häufigkeit noch deren Erfolgsquote. Ein CISO wird sie daher nutzen, um eine Liste von Szenarien zu erstellen, die zu testen sind, nicht um ein Risiko zu beziffern.

Was sagt die OWASP, und welche DSGVO-Pflichten bestehen?

Die Prompt-Injection wird von mehreren Quellen als Schwachstelle Nr. 1 laut OWASP dargestellt. Laut einer kommerziellen Quelle unterliegt ein durch Prompt-Injection verursachter Datenabfluss denselben DSGVO-Regeln wie ein klassischer Hackerangriff.

Ihr Platz im OWASP-Referenzrahmen

Die OWASP wird als internationale Referenzorganisation für Cybersicherheit beschrieben. Eine spezialisierte Website gibt an, dass sie die Prompt-Injection als Schwachstelle Nr. 1 einstuft [24]. Ein anderer Dienstleister für Cybersicherheit spricht von der „Gefahr Nummer eins für LLMs laut OWASP“ [37]. Beide Quellen sind Fachbeiträge und nicht das Referenzwerk selbst. Für eine verbindliche Einstufung muss das Dokument der OWASP direkt konsultiert werden.

Ein Artikel zum „OWASP Top 10 LLM 2026“ erwähnt einen Schwerpunkt auf agentischen Risiken, den „Unbounded Consumption“, die Prompt-Injection und die OWASP ASI [40]. Das Dossier erlaubt es nicht, die Einstufung für 2026 im Detail darzustellen, und auch nicht zu sagen, welchen Platz die Prompt-Injection dort einnimmt. Wir behaupten dies daher nicht.

DSGVO-Pflichten im Falle eines Abflusses

Laut core.security, einer kommerziellen Quelle, sieht sich der Verantwortliche, der einen durch Prompt-Injection verursachten Abfluss von Kundendaten erleidet, denselben gesetzlichen Pflichten gegenüber wie bei einem klassischen Hackerangriff [32]. Die Quelle nennt:

• die Meldung an die CNIL innerhalb von 72 Stunden;
• finanzielle Sanktionen von bis zu 4 % des weltweiten Jahresumsatzes [32].

Dieser Quelle zufolge ändert die Angriffstechnik also nicht die rechtliche Einordnung des Vorfalls. Für einen CISO ist die Prompt-Injection damit eine mögliche Ursache für eine Datenschutzverletzung, die – wie ein Einbruch – in die Verfahren zum Vorfallmanagement aufzunehmen ist.

Das Dossier enthält weder den Wortlaut der DSGVO noch eine Veröffentlichung der CNIL. Diese Angaben stammen von einem kommerziellen Akteur, und der Datenschutzbeauftragte muss sie anhand der amtlichen Texte bestätigen.

Wie lässt sich das Risiko in der Praxis verringern?

Keine einzelne Abwehrmaßnahme genügt: Die Verteidigung in der Tiefe kombiniert Reduzierung der Angriffsfläche, Least-Privilege-Prinzip und Kontrollen auf jeder Stufe. [39] Jede Schicht begrenzt Schäden, die die anderen nicht verhindert haben.

Die Hebel, die das Dossier belegen kann

• Begrenzen, was der Agent erreichen kann. Die Prompt-Injection ist weniger bedenklich, wenn der Agent keinen Zugriff auf sensible Daten hat [15]. Databricks, ein Anbieter von Datenplattformen, empfiehlt daher, die Fähigkeiten des Agenten einzuschränken, insbesondere seinen Zugriff auf sensible Systeme und private Daten [15].
• Den Menschen und die Rechte an der richtigen Stelle platzieren. Eine spezialisierte Quelle nennt die menschliche Validierung und granulare Zugriffskontrollen, insbesondere im Finanzsektor [35]. Die Idee: Eine sensible Aktion beruht nicht allein auf der Entscheidung des Modells.
• Vor dem Einsatz absichern. Laut Flowpi, einem kommerziellen Anbieter, müssen Chatbots und Copilots vor dem Produktiveinsatz geschützt werden. Ohne Leitplanken bedrohen Prompt-Injection und Datenabflüsse die Marke, die Kunden und den Return on Investment [22].
• Das Thema als Governance-Frage behandeln. Für einen Unternehmensassistenten gilt: „Das eigentliche Sicherheitsthema ist die Governance“. Dies setzt eine eigene Datensicherheitsstrategie für KI voraus [2].

Eine Grenze, die man anerkennen muss

Diese Maßnahmen verringern das Risiko, ohne es zu beseitigen. Ein Test mit 2000 Hackern gegen einen KI-Assistenten kommt zu dem Schluss, dass Prompt-Injection ein reales Sicherheitsproblem bleibt [35]. Die Quellen des Dossiers nennen keine unfehlbare technische Maßnahme, und diejenigen, die Maßnahmen im Detail beschreiben, sind überwiegend Anbieter oder Berater. Für einen CISO folgt daraus eine praktische Konsequenz: Die Architektur muss so konzipiert werden, dass eine Injection irgendwann durchkommt, und man muss sich fragen, was der Agent dann lesen, ausführen oder weitergeben könnte.

Wie begrenzt Oupi die Aktionen seines Agenten?

Oupi begrenzt die Aktionen seines Agenten nach zwei Grundsätzen: Sensible Handlungen unterliegen einer menschlichen Validierung, und die Ausführung des Agenten ist isoliert. Dieser Abschnitt beschreibt diese Grundsätze, ohne ihre Umsetzung im Detail darzustellen.

Zwei Grundsätze

• Menschliche Validierung sensibler Handlungen. Der Agent führt eine Handlung mit Folgen nicht allein zu Ende. Eine Person validiert sie, bevor sie ausgeführt wird.
• Isolierte Ausführung. Der Agent arbeitet in einem getrennten Bereich, was begrenzt, was eine umgelenkte Handlung erreichen könnte.

Der Bezug zu den allgemeinen Empfehlungen

Diese beiden Grundsätze entsprechen den Maßnahmen, die im übrigen Dossier empfohlen werden.

• Die Fähigkeiten des Agenten begrenzen. Databricks, ein Anbieter von Datenplattformen, gibt an, dass die Prompt-Injection weniger bedenklich ist, wenn der Agent keinen Zugriff auf sensible Daten hat. Das Unternehmen empfiehlt, den Zugriff auf sensible Systeme und private Daten einzuschränken [15]. Die Isolierung der Ausführung geht in diese Richtung: Sie verringert, worauf ein manipulierter Agent zugreifen kann.
• Menschliche Aufsicht aufrechterhalten. Ein Artikel von Roboto, einem kommerziellen Akteur, nennt die menschliche Validierung in Verbindung mit granularen Zugriffskontrollen als Antwort, die im Finanzsektor eingesetzt wird [35]. Die Validierung sensibler Handlungen folgt dieser Logik: Eine eingeschleuste Anweisung reicht nicht aus, um allein eine kritische Aktion auszulösen.
• Die Angriffsfläche reduzieren. Laut einem technischen Leitfaden zur Absicherung von LLM-Anwendungen beruht Sicherheit auf der Reduzierung der Angriffsfläche, dem Least-Privilege-Prinzip und Kontrollen auf jeder Stufe und nicht auf einer einzigen Abwehrmaßnahme [39]. Die menschliche Validierung und die Isolierung sind zwei dieser Kontrollen.

Die Grenzen dieses Konzepts

Diese Maßnahmen verringern das Risiko, sie beseitigen es nicht. Ein Test mit 2 000 Teilnehmenden an einem KI-Assistenten kommt zu dem Schluss, dass Prompt-Injection ein reales Sicherheitsproblem bleibt [35]. Die menschliche Validierung setzt außerdem voraus, dass die Person versteht, was sie genehmigt. Sie ergänzt die übrigen Schutzmechanismen (Kontrolle der Ausgaben, Erkennung, Überwachung), ersetzt sie aber nicht, entsprechend dem Ansatz der Verteidigung in der Tiefe [39].

Die Vertrauenszusagen von Oupi sind auf der Seite Vertrauen dargelegt.