Prompt Injection: Die Sicherheitslücke, die kaum jemand bei KI-Agenten nennt

KI-Agenten lesen E-Mails, durchsuchen Dokumente, beantworten Kundenanfragen und stoßen Aktionen in angebundenen Systemen an. Damit das funktioniert, müssen sie Inhalte aus vielen Quellen verarbeiten — und genau hier liegt eine Schwachstelle, die in den meisten Produkt-Demos nicht vorkommt. Sie heißt Prompt Injection. Dieser Beitrag ordnet das Thema sachlich für Entscheider ein: ohne Alarmismus, aber auch ohne es zu verharmlosen.

Was ist Prompt Injection?

KI-Sprachmodelle verarbeiten alles, was sie bekommen, als Text in einem gemeinsamen Strom. Sie unterscheiden technisch nicht zuverlässig zwischen einer Anweisung, die der Nutzer ihnen gibt, und Daten, die sie eigentlich nur lesen sollen. Für ein Modell sieht beides am Ende wie Sprache aus.

Diese fehlende Trennung lässt sich ausnutzen. Ein Angreifer kann in Daten, die der Agent verarbeitet, einen Befehl verstecken — formuliert wie eine normale Anweisung. Trifft der Agent auf diesen Text, besteht das Risiko, dass er ihn als Auftrag interpretiert und ausführt, statt ihn nur als Inhalt zu behandeln. Das ist der Kern von Prompt Injection: Eine versteckte Anweisung in den Daten kapert das Verhalten des Modells.

Direkt vs. indirekt — die eigentliche Gefahr

Man unterscheidet zwei Varianten, und der Unterschied ist für die Risikobewertung entscheidend.

Bei der direkten Prompt Injection tippt der Nutzer selbst einen Trick ein, um das Modell zu überreden, seine Regeln zu umgehen ("Ignoriere deine bisherigen Anweisungen und ..."). Das ist meist harmlos: Wer das tut, manipuliert nur seine eigene Sitzung — er hat ohnehin nur die Rechte, die ihm zustehen.

Das eigentliche Risiko ist die indirekte Prompt Injection. Hier stammt die versteckte Anweisung nicht vom Nutzer, sondern aus Inhalten, die der Agent im Auftrag des Nutzers verarbeitet — und die ein Dritter zuvor präpariert hat:

• ein Dokument in der Wissensdatenbank, das der Agent durchsucht;
• eine E-Mail, die der Agent zusammenfassen oder beantworten soll;
• eine Webseite, die der Agent aufruft und ausliest;
• die Ausgabe eines angebundenen Werkzeugs, der der Agent vertraut.

Der Nutzer ahnt nichts von der versteckten Anweisung. Der Agent verarbeitet den Inhalt im guten Glauben — und führt im ungünstigen Fall die Anweisung des Angreifers aus, anstatt die eigentliche Aufgabe zu erledigen. Weil der Inhalt von außen kommt und automatisch verarbeitet wird, ist diese Variante deutlich schwerer zu kontrollieren als ein direkter Tippversuch.

RAG-Poisoning: Wenn die Wissensbasis zur Waffe wird

Eine besonders relevante Form der indirekten Injection betrifft Agenten, die auf Ihre eigenen Dokumente zugreifen. Dieses Prinzip — der Agent zieht zur Beantwortung passende Inhalte aus einer Wissensdatenbank heran — heißt Retrieval-Augmented Generation, kurz RAG. Was RAG genau ist, erklären wir hier im Detail.

Beim RAG-Poisoning schleust ein Angreifer gezielt vergiftete Inhalte in diese Dokumentensammlung ein. Greift der Agent darauf zu, kann der präparierte Inhalt sein Verhalten kapern. Sicherheitsforscher haben gezeigt — und solche Zahlen sind als Größenordnung, nicht als feste Konstante zu lesen —, dass bereits rund fünf präparierte Dokumente ausreichen können, um Antworten in der Größenordnung von rund 90 Prozent der Fälle zu manipulieren. In Demonstrationen genügte sogar ein einzelnes PDF mit unsichtbarem Text (etwa weiße Schrift auf weißem Grund oder kleinste Schriftgröße), damit der Agent die versteckte Angreifer-Anweisung statt der eigentlichen Aufgabe ausführte.

Für Unternehmen ist das besonders heikel, weil die Wissensbasis oft aus Quellen gespeist wird, die nicht vollständig kontrolliert sind: hochgeladene Kundendokumente, eingehende E-Mails, importierte Web-Inhalte, geteilte Laufwerke. Jede dieser Quellen kann theoretisch zum Einfallstor werden.

Warum KI-Agenten und MCP die Angriffsfläche vergrößern

Ein einfacher Chatbot ohne Systemzugriff kann wenig Schaden anrichten. Sobald ein Agent jedoch Werkzeuge nutzt und auf mehrere Datenquellen zugreift, wächst die Angriffsfläche mit jeder Anbindung. Mehr angebundene Werkzeuge und Datenquellen bedeuten schlicht mehr Einfallstore. Anweisungen können sich verstecken in:

• Tool-Beschreibungen — der Text, der dem Agenten erklärt, was ein Werkzeug kann;
• Tool-Ausgaben — den Daten, die ein Werkzeug zurückliefert;
• Memory — gespeicherten Inhalten aus früheren Sitzungen;
• Retrieval-Treffern — den Dokumenten, die der Agent aus der Wissensbasis zieht.

Das Model Context Protocol (MCP) ist hier kein Sonderfall, sondern macht das Muster sichtbar: Es ist der Standard, über den agentische KI-Systeme strukturiert an Geschäftssysteme angebunden werden. Jede zusätzliche Anbindung ist Nutzen und potenzielles Einfallstor zugleich. Wichtig ist die richtige Lesart: MCP macht KI nicht per se unsicherer — entscheidend ist, wie die Anbindung abgesichert wird. Wie das technisch sauber gelingt, behandeln wir ausführlich im Beitrag zur MCP-Server-Sicherheit und DSGVO.

Die unbequeme Wahrheit

Es gibt nach heutigem Stand keinen vollständigen, garantierten Schutz vor Prompt Injection. Auch führende KI-Modelle bleiben grundsätzlich verwundbar — die Schwachstelle steckt in der Funktionsweise heutiger Sprachmodelle selbst, nicht in einem einzelnen Produktfehler.

Sicherheitsberichte aus 2025/2026 beschreiben — wieder als Größenordnung zu verstehen — Erfolgsraten von Angriffen, die je nach Aufbau und Testszenario in einem Bereich von rund 50 bis 84 Prozent liegen. Auch große, etablierte Anbieter waren von solchen Tests betroffen. Diese Zahlen sind keine Untergangsprognose, sondern eine nüchterne Einordnung: Wer eine einzelne "Wunderlösung" sucht, sucht etwas, das es nicht gibt.

Defense in Depth — so schützen sich Unternehmen

Diese Schutzschichten greifen ineinander. Keine einzelne ist allein ausreichend — in Kombination senken sie Eintrittswahrscheinlichkeit und möglichen Schaden jedoch erheblich.

1. Least-Privilege — minimale Rechte Der Agent erhält nur exakt die Rechte, die er für seine Aufgabe braucht — nicht mehr. Ein Agent, der Berichte erstellt, braucht keinen Schreibzugriff auf Kundendaten und keine Lösch-Rechte. Je weniger ein gekaperter Agent darf, desto kleiner der maximal mögliche Schaden.
2. Mensch-Bestätigung bei folgenreichen Aktionen Aktionen mit echten Konsequenzen — eine E-Mail versenden, eine Buchung auslösen, Daten löschen oder überschreiben — werden nicht automatisch ausgeführt, sondern erst nach einer ausdrücklichen menschlichen Freigabe. So bleibt ein manipulierter Agent ohne direkten Außenwirkungs-Schaden.
3. Trennung von Anweisung und Daten / Input-Filterung Eingehende Inhalte werden klar als Daten gekennzeichnet und vorgefiltert, bevor der Agent sie verarbeitet. Auffällige Muster (versteckter Text, eingebettete Anweisungen, ungewöhnliche Formatierungen) lassen sich erkennen und neutralisieren, statt sie ungeprüft an das Modell durchzureichen.
4. Output-Prüfung vor Weiterverarbeitung Bevor die Ausgabe des Agenten weiterverarbeitet wird oder eine Aktion auslöst, wird sie auf Plausibilität und unerwartete Anweisungen geprüft. Ein Ergebnis, das plötzlich zu einer ungeplanten Aktion auffordert, wird abgefangen.
5. Mandanten- und Rollentrennung Daten verschiedener Kunden, Abteilungen oder Rollen bleiben sauber getrennt. Selbst wenn ein Agent in einem Bereich kompromittiert wird, kann er nicht auf fremde Datenbestände übergreifen.
6. Revisionssichere Audit-Logs Jede Aktion des Agenten wird nachvollziehbar protokolliert. So lässt sich im Ernstfall rekonstruieren, was passiert ist, der Schaden eingrenzen — und die Lücke gezielt schließen.
7. EU-Hosting & DSGVO Datenverarbeitung in der EU und eine saubere datenschutzrechtliche Grundlage sind kein Selbstzweck: Sie begrenzen, welche Daten überhaupt im Spiel sind, und sind Voraussetzung für einen verantwortbaren Betrieb im deutschen Mittelstand.

Die technische Umsetzung dieser Schichten — insbesondere Rechte-Minimierung, Mandantentrennung und Audit-Logs — gehört in die Architektur der Systemanbindung. Im Detail zeigen wir das im Beitrag zur MCP-Server-Sicherheit und DSGVO.

Checkliste für Ihr KI-Projekt

Diese Punkte sollten vor dem Produktivbetrieb eines KI-Agenten geklärt sein:

• check_circle
  Datenflüsse kartiert: Welche externen Inhalte verarbeitet der Agent (E-Mails, Dokumente, Webseiten, Tool-Ausgaben)? Jede Quelle ist ein potenzielles Einfallstor und sollte bewusst bewertet sein.
• check_circle
  Rechte minimiert: Hat der Agent nur die Rechte, die er wirklich braucht? Schreib- und Lösch-Rechte sind auf das Nötigste reduziert.
• check_circle
  Freigaben definiert: Für welche folgenreichen Aktionen ist eine menschliche Bestätigung vorgeschrieben — und wer erteilt sie?
• check_circle
  Eingaben gefiltert: Werden eingehende Inhalte als Daten gekennzeichnet und auf versteckte Anweisungen vorgeprüft, bevor der Agent sie verarbeitet?
• check_circle
  Trennung sichergestellt: Sind Mandanten, Rollen und Datenbestände sauber voneinander isoliert?
• check_circle
  Protokollierung aktiv: Werden alle Agenten-Aktionen revisionssicher geloggt, sodass sich ein Vorfall rekonstruieren lässt?
• check_circle
  Datenschutz geklärt: Liegen EU-Hosting, Rechtsgrundlage und ein AVV mit dem KI-Anbieter vor? Mehr dazu im Beitrag zu DSGVO-konformer KI.

Einordnung für Entscheider

Prompt Injection ist kein Grund, auf KI-Agenten zu verzichten — der Nutzen für strukturierte, wiederholbare Prozesse bleibt erheblich. Es ist aber ein klarer Grund, Governance vor den Produktivbetrieb zu stellen statt danach. Wer minimale Rechte, menschliche Freigaben, saubere Trennung und Protokollierung von Anfang an mitdenkt, betreibt KI-Agenten verantwortbar.

Hinzu kommt der regulatorische Rahmen: Der EU AI Act wird ab August 2026 weitgehend voll wirksam, und die DSGVO gilt ohnehin. Beides verlangt nachvollziehbare, kontrollierte Datenverarbeitung — genau das, was eine saubere Defense-in-Depth-Architektur ohnehin liefert. Sicherheit und Compliance ziehen hier am selben Strang. Wie sich KI-Einsatz datenschutzkonform aufsetzen lässt, behandeln wir im Beitrag zu DSGVO-konformer KI; die Grundlagen produktiver Agenten erklärt der Beitrag zu KI-Agenten für Unternehmen.

Häufige Fragen zu Prompt Injection

Was ist Prompt Injection einfach erklärt?

Prompt Injection ist ein Angriff, bei dem versteckte Anweisungen in Daten geschmuggelt werden, die ein KI-Modell verarbeiten soll. Da KI-Modelle technisch nicht zuverlässig zwischen einer echten Anweisung und Inhalten, die sie nur lesen sollen, unterscheiden, kann ein Angreifer in einem Dokument, einer E-Mail oder einer Webseite einen Befehl verstecken — und der KI-Agent führt diesen Befehl im ungünstigen Fall aus, statt seine eigentliche Aufgabe zu erledigen.

Kann man sich vollständig vor Prompt Injection schützen?

Nein, einen vollständigen, garantierten Schutz gibt es nach heutigem Stand nicht — auch führende KI-Modelle bleiben grundsätzlich verwundbar. Sicherheitsberichte aus 2025/2026 beschreiben je nach Aufbau Angriffs-Erfolgsraten in einer Größenordnung von rund 50 bis 84 Prozent. Der praktikable Weg ist deshalb nicht eine einzelne Wunderlösung, sondern Defense in Depth: mehrere ineinandergreifende Schutzschichten, die Risiko und möglichen Schaden deutlich reduzieren.

Ist mein Unternehmen mit KI-Agenten gefährdet?

Ein gewisses Risiko besteht überall dort, wo ein KI-Agent externe Inhalte verarbeitet — also Dokumente, E-Mails, Webseiten oder Tool-Ausgaben — und gleichzeitig folgenreiche Aktionen ausführen darf, etwa E-Mails versenden, Daten ändern oder löschen. Kein Grund zur Panik, aber ein klarer Grund, Governance, minimale Rechte und menschliche Bestätigung bei kritischen Schritten vor dem Produktivbetrieb zu definieren.

Was ist RAG-Poisoning?

RAG-Poisoning ist eine Form der indirekten Prompt Injection. Wenn ein KI-Agent auf eine Wissensdatenbank oder Dokumentensammlung zugreift (Retrieval-Augmented Generation, kurz RAG), können dort gezielt vergiftete Inhalte hinterlegt werden. Sicherheitsforscher zeigten, dass bereits eine Größenordnung von rund fünf präparierten Dokumenten Antworten in rund 90 Prozent der Fälle manipulieren kann — und ein einzelnes PDF mit unsichtbarem Text kann ausreichen, damit der Agent die Angreifer-Anweisung statt seiner eigentlichen Aufgabe ausführt.

Macht MCP KI-Agenten unsicherer?

MCP an sich macht KI nicht unsicherer, aber jede zusätzlich angebundene Datenquelle oder jedes Werkzeug vergrößert die Angriffsfläche — etwa über Tool-Beschreibungen, Tool-Ausgaben, Memory oder Retrieval-Treffer. Entscheidend ist die saubere Absicherung der MCP-Anbindung: minimale Rechte, klare Trennung von Anweisung und Daten, Audit-Logs und EU-Hosting. Richtig umgesetzt schafft MCP sogar mehr Kontrolle, weil exakt definiert wird, worauf ein Agent zugreifen darf.