Große Sprachmodelle sind darauf trainiert, Anweisungen in natürlicher Sprache zu befolgen. Genau diese Stärke ist zugleich ihre Achillesferse: Aus Sicht des Modells ist eine Anweisung, die in einem verarbeiteten Dokument steht, kaum von einer legitimen Anweisung der Anwendung zu unterscheiden. Prompt Injection nutzt diese fehlende Trennung aus. Ein Angreifer bringt Text in die Verarbeitung ein, der vom Modell fälschlich als verbindliche Instruktion interpretiert wird – etwa um die vorgesehene Aufgabe zu unterlaufen, unerwünschte Ausgaben zu erzeugen oder nachgelagerte Systeme zu missbrauchen.
Wichtig ist die Abgrenzung zum Begriff Jailbreak. Beide Phänomene überschneiden sich, meinen aber nicht dasselbe. Ein Jailbreak zielt darauf, die Sicherheits- und Richtlinienvorgaben eines Modells auszuhebeln, damit es Inhalte produziert, die es eigentlich verweigern soll. Prompt Injection ist der weiter gefasste Begriff: Er beschreibt allgemein das Einschleusen fremder Instruktionen in den Verarbeitungskontext einer Anwendung – unabhängig davon, ob es dabei um Richtlinienverstöße oder um den Missbrauch von Funktionen und Daten geht. In der Praxis treten beide oft gemeinsam auf.
Man könnte annehmen, bessere Modelle würden Prompt Injection irgendwann vollständig verhindern. Nach aktuellem Stand ist das eine unrealistische Erwartung. Das Grundproblem ist keine bloße Trainingslücke, sondern eine Eigenschaft der Architektur: Anweisungen und zu verarbeitende Inhalte kommen als ein und derselbe Text an. Modelle werden zwar robuster – sie erkennen viele Manipulationsversuche zunehmend gut –, doch eine hundertprozentige Erkennung ist konzeptionell nicht garantiert. Sicherheitsfachleute betrachten Prompt Injection deshalb als Risiko, das man mindern und eindämmen, aber nicht durch ein einzelnes Feature „abschalten“ kann.
Für die Praxis folgt daraus ein wichtiger Grundsatz: Behandeln Sie jede Eingabe und jeden extern eingelesenen Inhalt als potenziell nicht vertrauenswürdig. Die Sicherheit einer LLM-Anwendung darf nicht davon abhängen, dass das Modell in jedem Einzelfall die richtige Entscheidung trifft. Stattdessen sollten die Konsequenzen einer fehlgeleiteten Modellausgabe von vornherein begrenzt sein – durch Rechtebeschränkung, Prüfschritte und klare Grenzen dessen, was das System überhaupt tun kann.
Prompt Injection ist kein isoliertes Phänomen, sondern Teil eines größeren Feldes von LLM-spezifischen Risiken, das in den letzten Jahren erhebliche Aufmerksamkeit erlangt hat. Fachcommunities und Sicherheitsorganisationen führen es regelmäßig unter den bedeutendsten Risiken für LLM-Anwendungen. Verwandte Themen sind unter anderem die Vergiftung von Trainings- oder Wissensdaten (Data Poisoning), das Extrahieren von Modellen oder Systemvorgaben sowie unkontrollierter KI-Einsatz ohne Freigabe (Schatten-KI). Diese Risiken hängen zusammen: Wer eine belastbare KI-Governance und ein strukturiertes Sicherheitsprogramm aufbaut, adressiert Prompt Injection nicht als Einzelfall, sondern als einen von mehreren Bausteinen.
Für mittelständische Unternehmen ist die gute Nachricht, dass die grundlegenden Abwehrprinzipien nicht exotisch sind. Sie greifen bewährte Konzepte der Informationssicherheit auf: Eingaben nicht blind vertrauen, Berechtigungen minimieren, kritische Aktionen absichern und den Betrieb überwachen. Die folgenden Kapitel übersetzen diese Prinzipien konkret in die Welt der LLM-Anwendungen.
Bei der direkten Prompt Injection stammt die manipulierende Eingabe unmittelbar von der Person, die mit dem System interagiert. Ein Nutzer formuliert seine Eingabe so, dass das Modell die eigentlich gültigen Vorgaben der Anwendung überschreibt oder ignoriert. Der Angriffsweg ist hier direkt und offensichtlich: Die schädliche Eingabe und die interagierende Person fallen zusammen. Direkte Injection ist typischerweise dann relevant, wenn ein Angreifer selbst Zugriff auf die Anwendung hat und versucht, sie zu missbrauchen – etwa um verborgene Vorgaben offenzulegen oder Funktionen zu missbrauchen.
Bei der indirekten Prompt Injection hingegen kommt die manipulierende Anweisung nicht vom interagierenden Nutzer, sondern aus einer externen Datenquelle, die das System im Rahmen seiner Aufgabe einliest. Das kann eine Webseite sein, ein Dokument, eine E-Mail, ein Kalendereintrag oder ein Datensatz aus einer angebundenen Wissensbasis. Der eigentliche Nutzer ahnt nichts – er stellt eine harmlose Anfrage, und das System liest im Hintergrund einen Inhalt ein, der versteckte Instruktionen enthält. Diese Form gilt als besonders tückisch, weil der Angreifer und der Nutzer nicht identisch sind und der Angriff zeitlich und örtlich vom Zugriff entkoppelt sein kann.
Die indirekte Variante verdient besondere Aufmerksamkeit, weil sie mit dem Trend zu vernetzten, autonomen KI-Systemen an Bedeutung gewinnt. Sobald ein LLM nicht mehr nur mit dem Nutzer spricht, sondern eigenständig Inhalte aus dem Web, aus Postfächern, aus Dokumentenablagen oder aus Datenbanken einliest, wächst die Zahl der Kanäle, über die fremde Instruktionen ins System gelangen können. Jede eingelesene Quelle wird zu einem potenziellen Einfallstor. Das Problem verschärft sich, wenn das System aufgrund dieser Inhalte selbstständig Aktionen auslöst – dann kann eine versteckte Anweisung nicht nur die Ausgabe verfälschen, sondern reale Handlungen anstoßen.
Ein weiteres Merkmal macht indirekte Injection heikel: die Verkettung. In komplexen Systemen kann die Ausgabe eines Verarbeitungsschritts zur Eingabe des nächsten werden. Eine einmal untergeschobene Instruktion kann sich so durch mehrere Schritte fortpflanzen, ohne dass ein Mensch sie zu Gesicht bekommt. Deshalb reicht es nicht, nur die unmittelbare Nutzereingabe zu prüfen; auch die Grenzen zwischen internen Verarbeitungsschritten müssen abgesichert werden.
Beiden Formen liegt dasselbe Grundmuster zugrunde: Fremde Instruktionen werden mit den legitimen Vorgaben vermischt und vom Modell nicht sauber getrennt. Die Konsequenz für die Abwehr ist jedoch unterschiedlich gewichtet. Gegen direkte Injection helfen vor allem robuste Eingabeprüfung, klare Systemvorgaben und Ausgabekontrollen. Gegen indirekte Injection sind zusätzlich die sorgfältige Behandlung externer Datenquellen, deren Kennzeichnung als nicht vertrauenswürdig sowie starke Beschränkungen der Aktionen entscheidend, die das System auf Basis solcher Inhalte ausführen darf. In der Praxis braucht ein gut abgesichertes System beide Schwerpunkte.
Die möglichen Folgen einer erfolgreichen Prompt Injection hängen stark davon ab, welche Fähigkeiten und Zugriffe die betroffene Anwendung besitzt. Ein reiner Text-Chatbot ohne Anbindung an sensible Daten oder Funktionen hat ein deutlich geringeres Schadenspotenzial als ein Agent, der eigenständig E-Mails versendet, Datenbanken abfragt oder Bestellungen auslöst. Grob lassen sich drei zentrale Risikofelder unterscheiden: der Abfluss von Daten, fehlerhafte oder manipulierte Ausgaben und die missbräuchliche Ausweitung von Rechten und Aktionen.
Ein zentrales Risiko ist der unbeabsichtigte Abfluss vertraulicher Informationen. LLM-Anwendungen haben häufig Zugriff auf Kontextdaten, die nicht für die Öffentlichkeit bestimmt sind – etwa interne Vorgaben, angebundene Dokumente, Kundendaten oder Systeminformationen. Über Prompt Injection kann ein Angreifer versuchen, das Modell dazu zu bewegen, solche Informationen preiszugeben oder in seine Ausgabe einzuflechten. Besonders sensibel ist dies in Systemen, die auf personenbezogene Daten oder Geschäftsgeheimnisse zugreifen. Der Schutz der Vertraulichkeit ist deshalb ein Kernanliegen jeder Absicherung und berührt unmittelbar datenschutzrechtliche Pflichten.
Ein verwandtes Risiko betrifft die Datenexfiltration über nachgelagerte Kanäle. Wenn ein System nicht nur Text ausgibt, sondern auch externe Aufrufe tätigt – etwa Inhalte nachlädt oder Anfragen an andere Dienste stellt –, können manipulierte Instruktionen versuchen, sensible Daten über solche Kanäle nach außen zu tragen. Der defensive Grundsatz lautet hier: Ausgehende Kanäle streng kontrollieren und einschränken, damit ein kompromittierter Verarbeitungsschritt keine Daten aus dem geschützten Bereich heraustragen kann.
Prompt Injection kann dazu führen, dass ein System inhaltlich falsche, verzerrte oder manipulierte Ausgaben liefert. Ein Angreifer könnte versuchen, das Modell zu voreingenommenen Aussagen, irreführenden Empfehlungen oder gezielt platzierten Falschinformationen zu bewegen. In geschäftskritischen Kontexten – etwa in der Kundenberatung, in Auskunftssystemen oder in der Entscheidungsunterstützung – kann dies erheblichen Schaden anrichten, weil Nutzer den Ausgaben vertrauen. Hier gibt es eine Nähe zum Thema Halluzinationen, wobei Prompt Injection die zusätzliche Dimension der gezielten Manipulation durch Dritte einbringt.
Ein besonders relevanter Fall sind manipulierte Ausgaben, die selbst wieder von anderen Systemen weiterverarbeitet werden. Wird die Ausgabe eines LLM etwa in einer Webseite dargestellt, in eine Datenbank geschrieben oder von einem weiteren Automatisierungsschritt aufgegriffen, kann eine manipulierte Ausgabe Folgeschäden auslösen. Deshalb sollten LLM-Ausgaben grundsätzlich als potenziell unsicher behandelt und vor der Weiterverarbeitung geprüft, kodiert oder gefiltert werden – analog zum Umgang mit nicht vertrauenswürdigen Eingaben in der klassischen Anwendungssicherheit.
Das gravierendste Risiko entsteht, wenn eine LLM-Anwendung über Werkzeuge und Berechtigungen verfügt, mit denen sie reale Aktionen ausführen kann. Über Prompt Injection kann versucht werden, diese Fähigkeiten zu missbrauchen – etwa um Aktionen anzustoßen, die der Nutzer nie beabsichtigt hat, um auf Ressourcen zuzugreifen, die außerhalb des vorgesehenen Rahmens liegen, oder um die Wirkung einer harmlosen Anfrage in eine schädliche Handlung zu verwandeln. Fachlich spricht man von Rechteausweitung (Privilege Escalation), wenn das System dadurch mehr tut, als es im Sinne des Nutzers und der Sicherheitsvorgaben dürfte.
Dieses Risiko wächst mit der Autonomie des Systems. Je mehr ein Agent selbstständig entscheiden und handeln kann, desto größer ist der potenzielle Schaden einer fehlgeleiteten Instruktion. Genau deshalb ist das Prinzip der minimalen Rechte (Least Privilege), das in Kapitel 05 vertieft wird, für agentische Systeme so zentral: Was ein System gar nicht tun kann, kann auch nicht missbraucht werden.
Zwei Architekturmuster prägen den heutigen Einsatz von Sprachmodellen im Unternehmen: RAG (Retrieval-Augmented Generation), bei dem das Modell mit Wissen aus angebundenen Datenquellen angereichert wird, und agentische Systeme, bei denen das Modell eigenständig Werkzeuge aufruft und mehrstufige Aufgaben löst. Beide erhöhen den Nutzen erheblich – und beide öffnen zusätzliche Kanäle, über die fremde Instruktionen ins System gelangen oder Wirkung entfalten können.
Bei RAG-Systemen wird zu einer Nutzeranfrage passendes Wissen aus einer Datenquelle abgerufen und dem Modell als Kontext mitgegeben. Der Charme des Ansatzes liegt darin, dass das Modell auf aktuelles, unternehmensspezifisches Wissen zugreifen kann, ohne dafür neu trainiert zu werden. Der Preis: Die abgerufenen Inhalte sind eine potenzielle Quelle für indirekte Prompt Injection. Enthält ein indexiertes Dokument versteckte Instruktionen, können diese zusammen mit dem legitimen Wissen in den Kontext des Modells gelangen.
Kritisch wird dies vor allem, wenn die Wissensbasis Inhalte aus weniger kontrollierten Quellen enthält – etwa nutzergenerierte Dokumente, extern eingespeiste Daten oder automatisch eingesammelte Webinhalte. Je offener der Weg, auf dem Inhalte in die Wissensbasis gelangen, desto sorgfältiger muss diese Quelle behandelt werden. Es besteht zudem eine Nähe zum Thema Data Poisoning: Wer Inhalte in eine Wissensbasis einschleusen kann, kann sowohl die Qualität der Antworten verfälschen als auch Injection-Instruktionen platzieren. Die Absicherung der Datenpipeline – Herkunftskontrolle, Kuratierung und Prüfung eingehender Inhalte – ist deshalb ein zentraler Baustein.
Agentische Systeme heben die Angriffsfläche auf eine neue Stufe. Sie zeichnen sich dadurch aus, dass das Modell nicht nur Text produziert, sondern Werkzeuge aufruft – etwa Suchfunktionen, Datenbankzugriffe, E-Mail-Versand oder Schnittstellen zu anderen Systemen. Damit wird aus einer manipulierten Ausgabe potenziell eine manipulierte Handlung. Drei Eigenschaften machen Agenten besonders sensibel: die Fähigkeit zu handeln, die Autonomie bei der Entscheidung über nächste Schritte und die Verkettung mehrerer Schritte, bei der Zwischenergebnisse ungeprüft weiterfließen.
Eine typische Konstellation: Ein Agent liest zur Bearbeitung einer Aufgabe externe Inhalte ein und entscheidet auf deren Basis über den nächsten Werkzeugaufruf. Enthält der eingelesene Inhalt versteckte Instruktionen, kann er den Entscheidungspfad des Agenten beeinflussen. Da diese Kette oft ohne menschlichen Zwischenschritt abläuft, kann sich der Effekt fortpflanzen, bevor jemand eingreift. Deshalb sind bei Agenten die Beschränkung der verfügbaren Werkzeuge, die Absicherung jedes Werkzeugaufrufs und menschliche Kontrollpunkte an kritischen Stellen besonders wichtig.
Die Tabelle macht deutlich: Es gibt nicht die eine Angriffsfläche, sondern eine Kette von Stellen, an denen fremde Instruktionen einwirken können. Eine wirksame Absicherung setzt deshalb nicht an einer einzigen Stelle an, sondern schützt jede Komponente entsprechend ihrem Risiko. Genau das ist der Kern des im nächsten Kapitel beschriebenen Prinzips der gestaffelten Verteidigung.
Das übergreifende Leitbild lautet Defense in Depth – gestaffelte Verteidigung. Da sich Prompt Injection nach aktuellem Stand nicht durch eine einzelne Maßnahme vollständig verhindern lässt, werden mehrere unabhängige Schutzschichten kombiniert. Versagt eine Schicht, fangen die anderen einen Teil des Risikos ab. Dieses Denken ist in der IT-Sicherheit etabliert und lässt sich direkt auf LLM-Anwendungen übertragen. Die drei wichtigsten Bausteine sind die Behandlung nicht vertrauenswürdiger Eingaben, die Trennung von Instruktionen und Daten sowie das Prinzip der minimalen Rechte.
Der erste Grundsatz lautet: Behandeln Sie jede Eingabe und jeden externen Inhalt als potenziell nicht vertrauenswürdig. Das entspricht dem bewährten Prinzip, Nutzereingaben in klassischer Software niemals blind zu verarbeiten. Für LLM-Anwendungen bedeutet das unter anderem, eingehende Inhalte zu bereinigen, unerwartete oder verdächtige Muster zu erkennen und den Umfang sowie die Herkunft verarbeiteter Inhalte bewusst zu kontrollieren. Wichtig ist die realistische Erwartungshaltung: Eingabefilter sind eine sinnvolle Schicht, aber kein vollständiger Schutz, da sich natürliche Sprache nicht abschließend „säubern“ lässt. Sie reduzieren das Risiko, sie eliminieren es nicht.
Zur Eingabeprüfung gehört auch die bewusste Begrenzung dessen, was das System überhaupt einliest. Nicht jede verfügbare Quelle muss in den Kontext des Modells gelangen. Wer den Umfang externer Inhalte reduziert, verkleinert die Angriffsfläche. Ebenso hilft es, die Herkunft von Inhalten mitzuführen, damit später nachvollziehbar bleibt, aus welcher Quelle eine bestimmte Information stammt und wie vertrauenswürdig sie ist.
Der zweite und vielleicht wichtigste Grundsatz ist die möglichst klare Trennung von Instruktionen und Daten. Das Grundproblem der Prompt Injection ist gerade, dass beide vermischt werden. Anwendungen sollten deshalb architektonisch dafür sorgen, dass die verbindlichen Vorgaben der Anwendung und die zu verarbeitenden Inhalte so weit wie möglich voneinander abgegrenzt sind. Dazu gehört, externe Inhalte deutlich als reine Daten zu kennzeichnen, ihnen keinen Instruktionscharakter zuzugestehen und die legitimen Systemvorgaben eindeutig und robust zu formulieren.
Vollständig lösen lässt sich die Trennung auf reiner Textebene nach aktuellem Stand nicht – das Modell sieht am Ende einen zusammenhängenden Kontext. Umso wichtiger ist es, die Trennung durch Architektur zu unterstützen: etwa durch getrennte Verarbeitungsschritte, durch die Begrenzung dessen, was aus Daten überhaupt folgen darf, und durch nachgelagerte Prüfungen. Die Kernbotschaft lautet: Was in einem eingelesenen Dokument steht, darf niemals automatisch den Rang einer verbindlichen Anweisung erhalten.
Der dritte Grundsatz ist der wirksamste Hebel gegen schwere Schäden: das Prinzip der minimalen Rechte. Eine LLM-Anwendung sollte nur genau die Zugriffe und Fähigkeiten besitzen, die sie für ihre Aufgabe zwingend benötigt – nicht mehr. Was ein System nicht tun kann, kann auch bei erfolgreicher Manipulation nicht missbraucht werden. Konkret bedeutet das: sparsame Vergabe von Berechtigungen, enge Grenzen für angebundene Werkzeuge, Beschränkung des Datenzugriffs auf das Notwendige und die Trennung sensibler Funktionen von öffentlich zugänglichen Schnittstellen.
Least Privilege ist deshalb so wertvoll, weil es unabhängig von der Erkennungsleistung des Modells wirkt. Selbst wenn ein Angriff die vorgelagerten Filter überwindet, bleibt der mögliche Schaden begrenzt, solange das System schlicht nicht über die Mittel verfügt, um größeren Schaden anzurichten. Für agentische Systeme ist dieses Prinzip nicht verhandelbar: Je autonomer ein System, desto strenger sollte sein Rechte- und Werkzeugrahmen sein.
Der Begriff Guardrails beschreibt Leitplanken, die das Verhalten einer LLM-Anwendung in vorgegebenen Bahnen halten. Sie können an mehreren Stellen ansetzen: vor der Verarbeitung (Eingangsprüfung), während der Verarbeitung (Verhaltensvorgaben) und nach der Verarbeitung (Ausgangsprüfung). Ziel ist es, unerwünschtes Verhalten zu verhindern oder zumindest abzufangen, bevor es Schaden anrichtet. Guardrails sind eine Schicht im Sinne der gestaffelten Verteidigung – wirksam in Kombination, unzuverlässig als alleiniger Schutz.
Am Eingang können Filter verdächtige Muster erkennen, unerwartete Inhalte kennzeichnen und den Umfang verarbeiteter Daten begrenzen. Am Ausgang – und das ist mindestens ebenso wichtig – sollten Ausgangsfilter prüfen, ob die Antwort des Modells vertrauliche Informationen enthält, unerwünschte Formate aufweist oder problematische Inhalte transportiert. Gerade für den Schutz vor Datenabfluss ist die Ausgangskontrolle zentral: Selbst wenn ein Angriff das Modell erreicht, kann ein guter Ausgangsfilter verhindern, dass sensible Daten die Anwendung verlassen.
Ein wichtiger Sonderfall ist die Behandlung von Ausgaben, die weiterverarbeitet werden. Bevor eine Modellausgabe in eine Webseite, ein Dokument oder ein Folgesystem gelangt, sollte sie – wie jede nicht vertrauenswürdige Ausgabe – geprüft, kodiert oder gefiltert werden. Damit wird verhindert, dass eine manipulierte Ausgabe in nachgelagerten Systemen unbeabsichtigte Wirkung entfaltet. Dieses Vorgehen entspricht bewährten Grundsätzen der Anwendungssicherheit und ist unabhängig von der konkreten LLM-Technik gültig.
Eine weitere Schutzschicht sind zusätzliche Prüfinstanzen, die Eingaben oder Ausgaben unabhängig bewerten. Das können regelbasierte Prüfungen sein oder eigene Prüfkomponenten, die verdächtige Inhalte klassifizieren. Der Grundgedanke ist, nicht allein dem verarbeitenden Modell zu vertrauen, sondern eine zweite, unabhängige Instanz über kritische Inhalte urteilen zu lassen. Auch hier gilt: Solche Prüfinstanzen erhöhen die Hürde, sind aber selbst nicht unfehlbar und können ihrerseits Ziel von Manipulation werden. Sie sind deshalb als ergänzende Schicht zu verstehen, nicht als abschließende Garantie.
Keine Prävention ist perfekt – deshalb ist die Fähigkeit, Vorfälle zu erkennen und darauf zu reagieren, ein unverzichtbarer Baustein. Ein wirksames Monitoring protokolliert Eingaben, Ausgaben und ausgelöste Aktionen in angemessenem Umfang, erkennt Auffälligkeiten und ermöglicht eine schnelle Reaktion. Dazu gehört, ungewöhnliche Nutzungsmuster, unerwartete Werkzeugaufrufe oder verdächtige Ausgaben sichtbar zu machen und klare Eskalationswege zu definieren. Die Protokollierung ist dabei mit dem Datenschutz in Einklang zu bringen – was protokolliert wird, sollte bewusst und datensparsam festgelegt werden.
Der Leitgedanke lautet: Gehen Sie davon aus, dass Manipulationsversuche gelegentlich erfolgreich sind – und gestalten Sie das System so, dass dies beherrschbar bleibt. Diese Haltung verschiebt den Fokus von der reinen Verhinderung hin zur Begrenzung der Folgen. Sie ist realistischer als die Hoffnung auf perfekte Erkennung und führt zu robusteren Systemen. Zwei Konzepte stehen dabei im Mittelpunkt: menschliche Kontrollpunkte an kritischen Stellen und die technische Isolation riskanter Verarbeitungsschritte.
Das Prinzip Human-in-the-Loop bedeutet, dass ein Mensch an definierten kritischen Punkten in den Ablauf eingebunden wird und folgenreiche Aktionen bestätigen muss, bevor sie ausgeführt werden. Nicht jede Aktion braucht diese Kontrolle – aber Aktionen mit erheblichem Schadenspotenzial sollten nicht vollautomatisch aus einer Modellausgabe folgen. Beispiele sind das endgültige Versenden externer Nachrichten, das Auslösen von Zahlungen oder Bestellungen, das Löschen oder Verändern wichtiger Daten und Zugriffe auf besonders sensible Ressourcen.
Der Charme des Ansatzes liegt darin, dass er unabhängig von der technischen Erkennungsleistung wirkt: Selbst wenn ein Angriff alle vorgelagerten Schichten überwindet, steht vor der eigentlich schädlichen Handlung noch eine menschliche Entscheidung. Die Kunst besteht darin, die Kontrollpunkte klug zu setzen – häufig genug, um Schaden zu verhindern, aber selten genug, um die Nutzbarkeit nicht zu ersticken. Für agentische Systeme mit weitreichenden Fähigkeiten sind solche Kontrollpunkte nach aktuellem Verständnis unverzichtbar.
Ein zweiter struktureller Baustein ist das Sandboxing – die Ausführung riskanter Verarbeitungsschritte in einer abgeschotteten Umgebung mit streng begrenzten Rechten und kontrollierten Verbindungen nach außen. Wenn ein System etwa externe Inhalte verarbeitet oder Werkzeuge ausführt, sollten diese Schritte so isoliert erfolgen, dass ein Missbrauch die geschützten Bereiche nicht erreicht. Zum Sandboxing gehört auch, ausgehende Netzwerkverbindungen zu kontrollieren, damit ein kompromittierter Schritt keine Daten unkontrolliert nach außen tragen kann.
Isolation lässt sich auf mehreren Ebenen umsetzen: die Trennung sensibler von öffentlich erreichbaren Komponenten, die Kapselung von Werkzeugaufrufen mit engen Berechtigungen und die Begrenzung des Kontexts, auf den ein einzelner Verarbeitungsschritt zugreifen kann. Der gemeinsame Nenner ist stets, den möglichen Wirkungsradius eines einzelnen kompromittierten Elements klein zu halten. Damit verzahnt sich das Sandboxing eng mit dem Least-Privilege-Prinzip aus Kapitel 05.
Der wichtigste Rat vorweg: Behandeln Sie die Sicherheit von LLM-Anwendungen nicht als Sonderthema, sondern als Teil Ihrer bestehenden Informationssicherheit und KI-Governance. Wer bereits Prozesse für Datenschutz, IT-Sicherheit und Freigaben besitzt, kann diese auf KI-Anwendungen ausweiten, statt bei null zu beginnen. Prompt Injection wird damit zu einem von mehreren Risiken, die in einem strukturierten Rahmen betrachtet werden – gemeinsam mit verwandten Themen wie Data Poisoning, unkontrolliertem KI-Einsatz und der Absicherung von Modellen.
Ein guter Ausgangspunkt ist eine schlanke, verständliche Richtlinie für den Einsatz von LLM-Anwendungen. Sie regelt, welche Anwendungen zugelassen sind, welche Daten in sie eingegeben werden dürfen, wann menschliche Kontrolle nötig ist und wie neue Anwendungen freigegeben werden. Ergänzend braucht es klare Verantwortlichkeiten: eine benannte Stelle, die KI-Sicherheitsthemen koordiniert, sowie einen definierten Weg für den Umgang mit Vorfällen. Diese organisatorischen Bausteine kosten wenig, entfalten aber große Wirkung, weil sie Sicherheit vom Zufall zur Regel machen.
Für Anwendungen, die selbst entwickelt oder wesentlich angepasst werden, empfiehlt sich zudem, die Sicherheitsanforderungen früh in den Entwicklungsprozess einzubauen – nach dem Grundsatz „Security by Design“. Least Privilege, Trennung von Instruktionen und Daten sowie Kontrollpunkte für kritische Aktionen lassen sich am günstigsten von Anfang an vorsehen, statt sie nachträglich einzubauen. Bei eingekauften Lösungen sollten die entsprechenden Fragen Teil der Anbieterauswahl sein.
Sicherheit, die nicht getestet wird, bleibt eine Annahme. Deshalb gehört zu jeder ernsthaften Absicherung das strukturierte Testen der eigenen LLM-Anwendungen auf Robustheit gegen Manipulation. Diese defensiven Tests – eng verwandt mit dem Thema Red Teaming – prüfen, ob die Schutzschichten wie vorgesehen greifen, ohne dass dabei ausnutzbare Anleitungen entstehen. Wichtig ist, dass solche Tests kontrolliert, dokumentiert und mit klaren Regeln durchgeführt werden; im Zweifel unter Einbindung spezialisierter Fachleute.
Tests sollten kein Einmalereignis sein, sondern regelmäßig wiederholt werden – insbesondere nach Änderungen an der Anwendung, an angebundenen Datenquellen oder an den verfügbaren Werkzeugen. Ebenso sinnvoll ist es, aus realen Vorfällen und aus dem Monitoring zu lernen und die Erkenntnisse in die Schutzmaßnahmen zurückzuspielen. So entsteht ein lebendiger Sicherheitsprozess statt einer statischen Momentaufnahme.
Die Übersicht verdeutlicht eine für den Mittelstand ermutigende Botschaft: Die wirkungsvollsten Maßnahmen – Least Privilege und menschliche Freigaben – sind nicht die aufwendigsten. Wer mit ihnen beginnt und die weiteren Schichten schrittweise ergänzt, erreicht mit überschaubarem Aufwand ein solides Schutzniveau. Perfektion ist nicht das Ziel; das Ziel ist ein angemessenes, dem jeweiligen Risiko entsprechendes Sicherheitsniveau.
Der EU AI Act (Verordnung (EU) 2024/1689) verlangt für bestimmte KI-Systeme – insbesondere Hochrisiko-Systeme – ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit sowie ein fortlaufendes Risikomanagement. Prompt Injection fällt konzeptionell genau in dieses Feld: Sie ist ein Angriff auf die Robustheit und Sicherheit einer KI-Anwendung. Wer ein solches System anbietet oder betreibt, sollte einschlägige Sicherheitsrisiken wie Prompt Injection nach aktuellem Stand im Rahmen seines Risikomanagements berücksichtigen. Ob und in welchem Umfang konkrete Pflichten greifen, hängt von der Risikoeinordnung des jeweiligen Systems ab und ist fachjuristisch zu klären.
Unabhängig von der genauen regulatorischen Einordnung ist die Absicherung gegen Prompt Injection Teil der allgemeinen Sorgfaltspflicht beim Betrieb von IT-Systemen. Wer eine Anwendung bereitstellt, die auf Eingaben reagiert und mit Daten oder Funktionen verbunden ist, trägt Verantwortung für deren sichere Gestaltung. Die in diesem Artikel beschriebenen Prinzipien – gestaffelte Verteidigung, Least Privilege, Trennung von Instruktionen und Daten, Kontrollpunkte und Monitoring – sind bewährte Ausdrucksformen dieser Sorgfalt, übertragen auf die Welt der Sprachmodelle. Sie fügen sich in bestehende Informationssicherheits-Managementsysteme ein und lassen sich mit etablierten Rahmenwerken verbinden.
Verarbeitet eine LLM-Anwendung personenbezogene Daten, kommt die Datenschutz-Grundverordnung ins Spiel. Prompt Injection berührt den Datenschutz an mehreren Stellen: Ein erfolgreicher Angriff kann zum unbefugten Zugriff auf oder zur Offenlegung von personenbezogenen Daten führen – also zu einer Verletzung der Vertraulichkeit im Sinne der DSGVO. Die DSGVO verlangt geeignete technische und organisatorische Maßnahmen, um solche Risiken angemessen zu adressieren. Die hier beschriebenen Schutzmaßnahmen zahlen unmittelbar auf diese Anforderung ein, insbesondere die Kontrolle von Datenzugriffen, die Ausgangsfilterung und die datensparsame Protokollierung.
Gleichzeitig ist beim Schutz vor Prompt Injection der Datenschutz selbst zu beachten: Monitoring und Protokollierung dürfen nicht zu einer unverhältnismäßigen Erfassung personenbezogener Daten führen. Was protokolliert wird, sollte bewusst, zweckgebunden und datensparsam festgelegt werden. Ob im konkreten Fall etwa eine Datenschutz-Folgenabschätzung erforderlich ist und wie die datenschutzrechtlichen Anforderungen mit den Sicherheitsmaßnahmen in Einklang zu bringen sind, ist eine Frage des Einzelfalls und sollte mit Datenschutz- und Rechtsfachleuten geklärt werden.
