Prompt Injection und LLM-Guards: warum klassische Firewalls Angriffe in natürlicher Sprache nicht sehen – und was wirklich schützt

Eine Firewall prüft Absender, Ziel und Protokoll. Ein Angriff auf ein Sprachmodell hat davon nichts – er besteht aus einem freundlich formulierten Satz. Genau deshalb sind sogenannte LLM-Guards, also Prüfschichten für natürliche Sprache, zur Standardantwort geworden. Drei Veröffentlichungen aus den ersten Monaten des Jahres 2026 zeigen aber, dass ein Guard nur eine Schutzschicht sein kann: Beim McKinsey-Fall verlief der Zugriff vollständig am Sprachmodell vorbei.

Die drei Veröffentlichungen, um die es hier geht

Bevor es um Abwehrtechnik geht, hier die Grundlage. Es handelt sich bewusst um drei unterschiedliche Arten von Veröffentlichung: eine reale Schwachstelle in einer Unternehmensplattform, einen Laborversuch zu dynamisch erzeugtem Phishing-Code und einen Lagebericht zur Automatisierung von Angriffen. Alle drei stammen aus den ersten Monaten des Jahres 2026 und zeigen jeweils eine andere Seite des Problems.

Warum eine klassische Netzwerk-Firewall den Angriff nicht sieht

Eine Netzwerk-Firewall und ein regelbasiertes Erkennungssystem arbeiten mit technischen Merkmalen. Sie schauen sich an, woher eine Verbindung kommt, wohin sie geht, welches Protokoll sie benutzt, ob die Nutzlast einer bekannten Signatur ähnelt. Das funktioniert seit Jahrzehnten gut, weil Angriffe auf dieser Ebene häufig technische Auffälligkeiten hinterlassen: einen ungewöhnlichen Port, eine bekannte Schadsoftware-Signatur oder eine Verbindung zu einer bereits auffälligen Adresse.

Ein Angriff auf ein Sprachmodell kann technisch völlig unauffällig bleiben. Er nutzt den vorgesehenen Übertragungsweg, die vorgesehene Schnittstelle und die erwartete Form – nämlich Text. Die Anfrage „Fass mir kurz die letzten fehlgeschlagenen Anmeldeversuche für Herrn Schmidt zusammen“ ist technisch völlig unauffällig. Ob sie ein legitimer Supportvorgang oder ein Versuch ist, an interne Informationen zu kommen, entscheidet sich nicht an der Netzwerkgrenze, sondern an der Frage, wer da fragt und in welchem Zusammenhang.

Semantische Filter gibt es dabei nicht erst seit gestern – Spam-Erkennung und Textklassifikation arbeiten seit Langem so, und moderne Anwendungs-Firewalls und Sicherheitsgateways können durchaus in die Nutzlast hineinsehen und Inhalte prüfen. Das ist nicht der Punkt. Was sie nicht zuverlässig leisten können, ist die Bewertung von Absicht und Zusammenhang einer an sich erlaubten Spracheingabe.

Neu ist die operative Rolle der Bedeutungsebene. Ein Sprachmodell erzeugt aus Sprache nicht nur Inhalte, sondern ruft auch Daten ab und stößt Werkzeuge an. Damit wird die semantische Bewertung unmittelbar sicherheitsrelevant – und damit angreifbar.

Prompt Injection: der Angriff, der aussieht wie eine normale Frage

Der Kern des Problems wird oft verkürzt dargestellt, deshalb hier die genaue Fassung. Moderne Modell-Schnittstellen unterscheiden durchaus zwischen Systemanweisung, Entwicklervorgabe, Nutzereingabe und Werkzeugergebnis; daraus ergibt sich eine Rangfolge der Anweisungen. Diese Rollenverteilung ist aber keine harte Sicherheitsgrenze. Fremdinhalte werden weiterhin vom selben Modell verarbeitet und können sein Verhalten beeinflussen. Prompt Injection nutzt aus, dass ein Modell vertrauenswürdige Anweisungen und manipulative Inhalte nicht unter allen Bedingungen zuverlässig auseinanderhält.

Die OWASP-Liste der zehn wichtigsten Risiken für KI-Anwendungen führt Prompt Injection deshalb an erster Stelle, und zwar in der zweiten Ausgabe hintereinander. Bemerkenswert ist die Einschätzung, die dort mitgeliefert wird: Weil der Effekt in der Funktionsweise generativer Modelle angelegt ist, ist unklar, ob es überhaupt eine narrensichere Verhinderung geben kann. Empfohlen wird deshalb keine einzelne Maßnahme, sondern eine gestaffelte Verteidigung.

Direkt und indirekt – der Unterschied entscheidet über das Risiko

Bei der direkten Prompt Injection schreibt der Angreifer die manipulierende Anweisung selbst ins Eingabefeld. Das ist die Form, die man aus Beispielen kennt: Anweisungen wie „vergiss alles Bisherige“ in immer neuen Verkleidungen. Sie ist unangenehm, aber sie setzt voraus, dass der Angreifer überhaupt Zugang zu dem System hat.

Die indirekte Prompt Injection ist die gefährlichere Variante. Hier steht die Anweisung in einem Inhalt, den die KI später einliest: in einem Dokument, auf einer Webseite, in einer E-Mail, in einem Support-Ticket, in einem Datenbestand, aus dem das System Zusatzwissen holt. Der Angreifer braucht keinen Zugang zu deinem System – es genügt, dass er einen Text platzieren kann, den dein System irgendwann verarbeitet. Sobald das Modell mit Werkzeugen verbunden ist, kann eine solche eingeschleuste Anweisung Funktionen auslösen, die der Angreifer selbst nie hätte aufrufen dürfen.

Der Fall McKinsey: zwei Stunden, 22 offene Endpunkte – und keine einzige Prompt Injection

Wer verstehen will, warum ein Sprach-Wächter allein nicht reicht, sollte sich den McKinsey-Fall genauer ansehen. McKinsey betreibt seit 2023 eine interne KI-Plattform namens Lilli, die firmeneigenes Wissen für die Beratung aufbereitet. Nach Unternehmensangaben nutzt der Großteil der Belegschaft sie, sie greift auf über 100.000 interne Dokumente zu und verarbeitet monatlich über eine halbe Million Anfragen.

Am 28. Februar 2026 setzte die Sicherheitsfirma CodeWall einen autonomen Angriffsagenten darauf an. Der Agent hatte nach Darstellung der Firma weder Zugangsdaten noch Insiderwissen und suchte sich das Ziel sogar selbst aus – begründet mit der öffentlich zugänglichen Richtlinie zur verantwortungsvollen Offenlegung und den kurz zuvor erfolgten Aktualisierungen der Plattform. Alle folgenden technischen Einzelheiten und Mengenangaben stammen ebenfalls aus dieser Veröffentlichung.

Der beschriebene Ablauf ist für jeden lehrreich, der gerade eine KI an interne Daten hängt:

• Der Agent kartierte die öffentlich einsehbare Schnittstellendokumentation mit über 200 dokumentierten Endpunkten.
• 22 dieser Endpunkte verlangten überhaupt keine Anmeldung.
• Einer davon schrieb Suchanfragen direkt in die Datenbank. Dabei waren zwar die Werte der JSON-Anfrage korrekt abgesichert – die Feldnamen aber wurden ungeprüft in die Datenbankabfrage eingebaut.
• Über rund fünfzehn Testdurchläufe anhand von Datenbank-Fehlermeldungen entstand daraus eine klassische SQL-Injection mit Lese- und Schreibrecht.
• Parallel ließ sich über eine unsichere Objektreferenz auf die Suchverläufe einzelner Mitarbeiter zugreifen.

Erreichbar waren nach Darstellung der Forscher Millionen Chat-Nachrichten, hunderttausende Dateien, zehntausende Benutzerkonten und die hinterlegten Systemanweisungen der Plattform. Der letzte Punkt ist der unangenehmste: Die Systemanweisungen lagen in derselben Datenbank. Mit Schreibrecht hätte ein Angreifer sie unbemerkt überschreiben können – und damit die Antworten, die Sicherheitsvorgaben und die Quellenangaben des Assistenten, ohne eine einzige Zeile Schadcode auszuliefern.

Der Ablauf danach: CodeWall meldete die Schwachstelle am 1. März 2026 an das Sicherheitsteam von McKinsey, das den Eingang am Folgetag bestätigte und Nachweise anforderte. Die nicht authentifizierten Endpunkte wurden geschlossen, die Entwicklungsumgebung vom Netz genommen und die öffentliche Dokumentation gesperrt. Am 9. März veröffentlichte CodeWall den Bericht.

Was ein LLM-Guard tatsächlich prüft

Damit ist ein LLM-Guard nicht überflüssig – er ist nur nicht die ganze Antwort. Je nach Aufbau prüft er Eingaben, Ausgaben oder beide Richtungen; manche Systeme kontrollieren ausschließlich Werkzeugaufrufe. Bewertet werden dabei vor allem drei Dinge: die beabsichtigte Bedeutung, der Zusammenhang des Anwendungsfalls und bekannte Angriffsmuster. Er ist damit eine zusätzliche Prüfschicht, keine vollständige Sicherheitsgrenze.

Bedeutung

Der Guard bewertet, worauf eine Anfrage hinausläuft, nicht wie sie formuliert ist. Ein Versuch, bestehende Anweisungen außer Kraft zu setzen, soll auch dann auffallen, wenn er höflich, kreativ oder in einer Geschichte verpackt daherkommt. Starre Wortlisten und einfache Regeln können das nur eingeschränkt: Eine bekannte Formulierung erkennen sie, eine umgeschriebene oder verschleierte Absicht übersehen sie vergleichsweise leicht.

Zusammenhang

Dieselbe Frage kann harmlos oder auffällig sein, je nachdem, wo sie gestellt wird. Eine Abfrage von Personaldaten ist in einer Personalanwendung Alltag und im öffentlichen Kundenchat ein Warnsignal. Ein Guard, der den Anwendungsfall kennt, kann diesen Unterschied machen – und genau hier liegt der praktische Gewinn für kleine Installationen, weil sich der erlaubte Rahmen dort meist sehr eng beschreiben lässt.

Muster

Reine Mustererkennung ist schnell und bei bekannten Angriffsformen nützlich – ein großer Teil der Versuche im Alltag besteht aus abgewandelten Standardmustern. Umformulierte, übersetzte oder verschleierte Anweisungen können starre Regeln allerdings vergleichsweise leicht umgehen.

Drei typische Ansätze für LLM-Guards

Die Darstellung, es gebe genau zwei Bauarten, greift zu kurz. In der Praxis kommen mehrere Ansätze zum Einsatz: feste Regeln und Heuristiken, speziell trainierte Erkennungsmodelle, große Modelle als Prüfinstanz sowie nachgelagerte Richtlinienprüfungen. Häufig kommt ein semantischer Abgleich über Einbettungen dazu.

Einordnung der drei gängigen Ansätze. In produktiven Systemen werden sie häufig kombiniert statt gegeneinander abgewogen.

Welche Erkennungsleistung dabei herauskommt, lässt sich nicht allgemein angeben. Sie muss am eigenen Modell, in der tatsächlich verwendeten Sprache und mit realistischen Angriffen gemessen werden – Zahlen aus einer Herstellermessung sagen über den eigenen Aufbau wenig.

Für den deutschsprachigen Betrieb lohnt ein besonderer Blick auf den mittleren Weg. Ein Erkennungsmodell, das überwiegend an englischen Angriffsbeispielen gelernt hat, muss bei deutschen Formulierungen nicht gleich gut abschneiden. Wer ein solches Modell einkauft, sollte deshalb ausdrücklich nach der Sprachabdeckung der Trainingsdaten fragen und die eigenen Fälle stichprobenartig auf Deutsch durchtesten, statt sich auf eine Erkennungsquote zu verlassen, die an fremdsprachigen Daten gemessen wurde.

Warum ein Guard allein nicht reicht: die gestaffelte Verteidigung

Der Gedanke der tiefgestaffelten Verteidigung ist in der IT-Sicherheit alt und passt hier besonders gut, weil keine der einzelnen Maßnahmen für sich zuverlässig ist. Drei Bausteine kommen neben dem Guard regelmäßig zum Einsatz.

Eingabetrennung

Systemanweisung, Nutzereingabe und zu verarbeitende Daten werden schon bei der Übergabe ans Modell getrennt behandelt und klar als das gekennzeichnet, was sie sind. Das ist eine wichtige Basisschicht und der Grund, warum viele Angriffe genau darauf zielen, diese Grenzen verschwimmen zu lassen. Eine Sicherheitsgrenze ist es aber nicht: Sobald das Modell Werkzeuge oder Schreibrechte hat, wiegen minimale Berechtigungen, fest definierte Funktionen, geprüfte Parameter und eine menschliche Freigabe für folgenreiche Aktionen schwerer.

Gezieltes Angreifen der eigenen Systeme

Sicherheitsverantwortliche sollten die eigene KI-Anwendung regelmäßig selbst angreifen, statt auf den ersten echten Vorfall zu warten. Dafür braucht es keine große Abteilung: Eine Sammlung eigener Angriffsversuche, die nach jeder Änderung erneut durchlaufen wird, findet die meisten Regressionen. Wichtig ist, dass die Sammlung wächst – jeder neue Trick, der irgendwo beschrieben wird, kommt als Testfall dazu.

Spotlighting und Datamarking

Unter diesem Namen hat Microsoft Research eine Gruppe von Verfahren beschrieben, die Fremdinhalte im Prompt durchgehend markieren, mit besonderen Zeichenfolgen abgrenzen oder umkodieren, damit sie sich für das Modell erkennbar von Anweisungen unterscheiden. In den Versuchen der Forscher sank die Erfolgsquote indirekter Einschleusungen dadurch erheblich, während die Leistung bei den zugrunde liegenden Aufgaben nur geringfügig beeinträchtigt wurde.

Das ist ein Ergebnis aus einem bestimmten Versuchsaufbau und keine allgemeine Garantie. Eine 2025 veröffentlichte Untersuchung nahm sich acht verbreitete Abwehrverfahren gegen indirekte Prompt Injection vor und umging alle davon mit gezielt angepassten Angriffen – die Erfolgsquote lag dabei jeweils über 50 Prozent. Also auch hier: zusätzliche Schicht, kein Ersatz für die Rechtevergabe.

Der gefährlichste Punkt: wenn das Modell handeln darf

Solange eine KI ausschließlich antwortet, ist ihr unmittelbarer technischer Handlungsspielraum kleiner. Auch dann können Datenabfluss, manipulierte Entscheidungen oder gefährliche Falschauskünfte erheblichen Schaden anrichten. Deutlich größer wird das Risiko aber, sobald das System selbst handeln darf: Datenbanken abfragen, Dateien anlegen, Mails verschicken, Schnittstellen anderer Programme aufrufen.

Ab dort trägt ein vorgelagerter Sprach-Wächter nur noch einen Teil der Last. Wenn eine Nutzereingabe fälschlicherweise in einen zerstörerischen Befehl übersetzt wird, also aus einer Abfrage ein Löschbefehl, dann wird die zweite Reihe entscheidend: harte Prüfungen auf der Ebene der angebundenen Systeme und ein Rechtekonzept, das den möglichen Schaden von vornherein begrenzt. Unternehmensdaten sind für KI-Anwendungen wertvoll – aber eine Kette, in der Freitext ohne Zwischenschicht zu Datenbankbefehlen wird, ist ein zuverlässiger Weg in den Vorfall.

Damit die Zuständigkeiten klar bleiben, hilft eine nüchterne Aufstellung. Jede Schicht kann genau eine Sache – und keine davon ersetzt eine andere:

Zuordnung der Schutzschichten. Keine Zeile ersetzt eine andere – das ist der Kern der gestaffelten Verteidigung.

Der McKinsey-Fall liefert dazu die passende Fußnote: Dort waren die Systemanweisungen in derselben Datenbank gespeichert, auf die der Angreifer Schreibrecht erlangte. Trennung von Zuständigkeiten ist also nicht nur eine Frage der Zugänge, sondern auch der Ablage.

Festplatte sichern und ein System-Image erstellen – wer noch nie ein Abbild zurückgespielt hat, sollte das einmal ohne Zeitdruck üben, bevor der Ernstfall es erzwingt. Die verlinkte Anleitung zeigt, woran Sicherungen typischerweise scheitern: Sie sind zu alt, sie enthalten nicht die Systempartition, oder sie liegen auf demselben Rechner, der ausgefallen ist. Für eine KI-Anwendung auf einem eigenen Rechner gilt dasselbe wie für jeden anderen Server auch.

Wenn der Angreifer das Sprachmodell benutzt statt es anzugreifen

Es gibt eine zweite Richtung, die in der Diskussion um Guards oft untergeht: Angreifer greifen KI nicht nur an, sie benutzen sie auch. Die Forschungsabteilung Unit 42 von Palo Alto Networks hat dazu einen Machbarkeitsnachweis veröffentlicht, der die Erkennung vor ein grundsätzliches Problem stellt.

Der Aufbau: Eine auf den ersten Blick harmlose Webseite enthält ein unscheinbares Skript. Sobald sie im Browser des Besuchers geladen ist, schickt dieses Skript Anfragen an bekannte, vertrauenswürdige Sprachmodell-Dienste und lässt sich einzelne Code-Schnipsel zurückgeben. Zusammengebaut und ausgeführt werden sie erst in der Laufzeitumgebung des Browsers – und ergeben dort eine funktionierende Phishing-Seite.

Drei Eigenschaften machen das für klassische Erkennung unangenehm. Erstens entstanden im Versuchsaufbau bei wiederholten Anfragen syntaktisch unterschiedliche, funktional aber vergleichbare Varianten. Sprachmodelle können solche Abweichungen liefern; dass jeder Aufruf zwingend anders ausfällt, ist damit nicht gesagt. Zweitens wird der Code von einer Domain ausgeliefert, der Sicherheitswerkzeuge üblicherweise vertrauen. Drittens gibt es auf dem Weg dorthin keine feste Schaddatei, die man wiedererkennen könnte.

Bemerkenswert ist auch, wie die Schutzmechanismen der Modelle umgangen wurden: Eine direkte Bitte um Code zum Abgreifen von Anmeldedaten wurde blockiert. Eine Anfrage nach einer allgemein formulierten Übertragungsfunktion nicht. Das ist im Kleinen dasselbe Muster wie bei der Prompt Injection – die Absicht steckt nicht im einzelnen Baustein, sondern in der Zusammensetzung.

Phishing erkennen und abwehren bleibt damit die Grunddisziplin, an der sich der Rest ausrichtet. Phishing und der Missbrauch gestohlener Zugangsdaten gehören weiterhin zu den häufigen Einstiegswegen in Unternehmensumgebungen, und daran hat sich durch KI nichts geändert außer der Qualität der Texte. Schulung hilft weiterhin dabei, verdächtige Absender, ungewöhnliche Anmeldeaufforderungen und falsche Internetadressen zu erkennen. Eine professionell nachgebaute Seite lässt sich am Aussehen allein aber nicht zuverlässig von der echten unterscheiden – deshalb bleibt die technische Prüfung des Verhaltens im Browser nötig.

Was der DDoS-Bericht wirklich zeigt

Im zweiten Halbjahr 2025 hat NETSCOUT weltweit über acht Millionen DDoS-Angriffe registriert, verteilt auf mehr als 200 Länder und Gebiete; einzelne Angriffe erreichten Spitzenwerte im Bereich von 30 Terabit pro Sekunde, und bei etwa 42 Prozent wurden mehrere Angriffsarten kombiniert. Die Zahlen werden gern als Beleg dafür zitiert, dass KI die Angriffe steuert. Das steht so nicht im Bericht.

Was der Bericht beschreibt, ist etwas anderes und für kleine Betriebe eigentlich relevanter: Mietbare Angriffsdienste lassen sich zunehmend über einfache Texteingaben bedienen. Damit kann jemand ohne technische Kenntnisse einen mehrstufigen Angriff auslösen, für den früher Fachwissen nötig war. Die Einstiegshürde sinkt – nicht die Angriffe werden klüger, sondern der Kreis derer, die sie starten können, wird größer.

Für die eigene Einschätzung ist der Unterschied wichtig. Wer glaubt, es mit einer neuartigen, autonom agierenden Bedrohung zu tun zu haben, sucht nach neuartigen Werkzeugen. Wer versteht, dass vor allem die Zahl der Gelegenheitsangreifer steigt, kümmert sich zuerst um die Grundlagen: Erreichbarkeit begrenzen, Zugänge aufräumen, Wiederanlauf üben.

Was das für Selbstständige und kleine Unternehmen bedeutet

Die meisten der bisher beschriebenen Maßnahmen klingen nach einer Sicherheitsabteilung. Der praktische Kern ist aber für einen Ein-Personen-Betrieb genauso gültig – nur kleiner. Drei Situationen kommen im Alltag tatsächlich vor.

Der Assistent auf der eigenen Website. Ein öffentlich zugänglicher Chat-Assistent sollte nur auf Inhalte zugreifen, die ohnehin für die Öffentlichkeit bestimmt sind. Keine Preislisten mit Sonderkonditionen, keine Kundendaten, keine interne Dokumentation. Ein Assistent hinter einer Anmeldung darf durchaus interne Daten verarbeiten – dann muss aber bei jedem einzelnen Zugriff geprüft werden, wer fragt und wofür diese Person berechtigt ist.

Fremde Inhalte, die durch die KI laufen. Wer sich Lebensläufe, Angebote, Rechnungen oder Kunden-Mails von einer KI zusammenfassen lässt, verarbeitet Fremdtext – und damit potenziell eingeschleuste Anweisungen. Solange die KI nur zusammenfasst, ist der mögliche Schaden begrenzt. Sobald sie im selben Ablauf etwas verschickt oder speichert, ist er es nicht mehr.

Schatten-KI im Betrieb. Ein häufiger und besonders banaler Vorfall ist, dass jemand einen Vertrag, eine Kundenliste oder einen Quelltext in einen Dienst kopiert, den niemand freigegeben hat. Das ist kein Angriff, sondern ein Abfluss – und der wirksamste Gegenzug ist nicht ein Verbot, sondern ein freigegebener Weg, der bequem genug ist, dass ihn alle benutzen.

So sieht der Alltag mit sauber abgesicherter KI aus

Es lohnt sich, das Ergebnis konkret zu machen, weil Sicherheit sonst nach Verzicht klingt. Wenn die beschriebenen Punkte sitzen, ändert sich für dich im täglichen Arbeiten fast nichts – und genau das ist der Punkt.

Du lässt dir weiterhin Angebote entwerfen und Verträge zusammenfassen – nur eben auf einer Maschine, die im eigenen Netz steht, sodass die Inhalte nicht an einen externen Modellanbieter gehen. Voraussetzung dafür ist, dass Modell, Oberfläche und Speicher tatsächlich lokal arbeiten und keine Cloud-Dienste, externen Erweiterungen oder unkontrollierten Telemetrieverbindungen mitlaufen; Zugriffsschutz, Verschlüsselung und geprüfte Sicherungen bleiben trotzdem nötig. Deine Mitarbeiter benutzen den freigegebenen Weg, weil er der schnellste ist, nicht weil eine Richtlinie es verlangt. Der Assistent auf deiner Website beantwortet Fragen zu deinen Leistungen und kommt an nichts anderes heran, weil er an nichts anderes angeschlossen ist.

Und wenn doch etwas schiefgeht, ist es eher ein Zwischenfall als eine Katastrophe: Der betroffene Rechner wird aus dem Abbild zurückgesetzt, der technische Zugang der KI wird getauscht, im Protokoll steht, was ausgelöst wurde. Ein geübter Wiederanlauf verkürzt die Ausfallzeit erheblich und macht aus einer unkontrollierten Lage einen beherrschbaren Vorfall.

In neun Schritten zur abgesicherten KI-Nutzung

Die Reihenfolge beginnt mit Bestandsaufnahme, öffentlich erreichbaren Schnittstellen und Berechtigungen. Je nachdem, ob die KI nur Inhalte verarbeitet oder selbst Aktionen auslösen darf, müssen einzelne Schritte früher oder umfassender umgesetzt werden.

1. Aufschreiben, welche KI im Betrieb wirklich benutzt wird. Nicht welche freigegeben ist, sondern welche tatsächlich läuft – einschließlich der Browser-Erweiterungen und der Dienste, die jemand privat mitbenutzt.
2. Technische Zugänge und alte Berechtigungen aufräumen. Jeder Zugang, den eine Anwendung benutzt, bekommt nur die Rechte, die sie tatsächlich braucht. Geteilte Zugänge mit weitreichenden Rechten sind der Klassiker, an dem sich Angriffe entlanghangeln.
3. Prüfen, was öffentlich erreichbar ist. Schnittstellendokumentation, Testumgebungen, Verwaltungsoberflächen. Genau hier begann der McKinsey-Fall. Gerade in gewachsenen Umgebungen lohnt sich die Prüfung, weil Testsysteme, alte Schnittstellen und Dokumentationen oft länger erreichbar bleiben als ursprünglich vorgesehen.
4. Eingabetrennung sauber umsetzen. Systemanweisung, Nutzereingabe und Fremdinhalte klar getrennt übergeben und als das kennzeichnen, was sie sind.
5. Festlegen, was die KI überhaupt darf. Nur lesen, oder auch schreiben? Nur bestimmte Datensätze? Alles, was verändert, läuft über feste, benannte Funktionen mit geprüften Parametern.
6. Einen Prüfschritt vor und gegebenenfalls nach das Modell setzen. Infrage kommen feste Regeln, Klassifikatoren, ein speziell trainiertes Erkennungsmodell oder ein zweites großes Modell. Bei deutschsprachigem Betrieb muss die Erkennung auch mit deutschen Angriffsmustern getestet werden.
7. Eigene Angriffsversuche sammeln und nach jeder Änderung wiederholen. Eine kleine, wiederholbare Testsammlung ist wertvoller als ein umfangreicher Test, der nur einmal durchgeführt wird.
8. Protokollieren, was ausgelöst wurde. Nicht nur die Anfragen, sondern die tatsächlich ausgeführten Aktionen. Ohne dieses Protokoll ist ein Vorfall im Nachhinein nicht rekonstruierbar.
9. Den Wiederanlauf einmal durchspielen. Abbild zurückspielen, Zugänge tauschen, Dienst wieder hochfahren – einmal geübt, bevor es nötig ist.

Die ehrlichen Grenzen dieser Maßnahmen

Ein paar Dinge sollte man wissen, bevor man loslegt, sonst entsteht ein falsches Sicherheitsgefühl.

Ein LLM-Guard kostet immer etwas. Beim großen Modell mit Prüfauftrag zahlt man mit Rechenzeit und Wartezeit, beim kleinen Spezialmodell mit laufender Pflege. Wer die laufende Pflege nicht einplant, betreibt irgendwann eine veraltete Schutzschicht, die trotzdem falsches Vertrauen erzeugt.

Lokale Modelle reduzieren die Weitergabe an einen Modellanbieter. Sie beseitigen weder Schadsoftware noch übernommene Benutzerkonten, unsichere Sicherungen, offene Netzwerkfreigaben – und Prompt Injection erst recht nicht. Ein lokales Modell mit weitreichenden Rechten auf dem Dateisystem ist eher gefährlicher als ein Cloud-Modell ohne jede Handlungsbefugnis.

Dazu die Leistungsgrenze: Sehr große Modelle sind auf einem Mini-PC mit 32 oder 64 Gigabyte gemeinsam genutztem Speicher meist nur stark quantisiert und mit spürbar begrenzter Geschwindigkeit sinnvoll nutzbar. Quantisierung heißt: Die Modellgewichte werden mit geringerer Rechengenauigkeit abgelegt, damit das Modell weniger Speicher braucht. Welche Modellgröße praktikabel ist, hängt an Arbeitsspeicher, Quantisierungsstufe, Speicherbandbreite und daran, wie schnell die Antwort kommen soll. Für Zusammenfassungen, Entwürfe und Auswertungen kann eine solche Ausstattung reichen; das hängt vom konkreten Modell ab. Beim verlinkten Gerät beruht diese Einschätzung auf den Angaben des Herstellers – ein Praxistest des Seriengeräts liegt noch nicht vor.

Ein praktischer Hinweis zum verlinkten Gerät: Das Netzteil ist im Gehäuse integriert, der Anschluss ist ein IEC-C6-Netzeingang. Dazu gehört ein Netzkabel mit IEC-C5-Kupplung, umgangssprachlich Kleeblattkabel. Der Anbieter liefert standardmäßig ein Kabel mit US-Stecker und nennt regionale Ausführungen einschließlich EU als Option – ein EU-Kabel sollte man also bei der Bestellung ausdrücklich verlangen oder separat beschaffen.

Und die Schutzlösung auf dem Arbeitsplatz schützt den Arbeitsplatz, nicht die KI-Anwendung. Sie erkennt Schadcode und blockiert bösartige Seiten – gegen eine eingeschleuste Anweisung in einem Dokument, das dein eigener Assistent verarbeitet, kann sie nichts ausrichten. Beim Kauf ist außerdem üblich, dass der Einstiegszeitraum günstiger ist als die automatische Verlängerung; wer das nicht will, stellt die Verlängerung gleich nach dem Kauf im Kundenkonto ab.

Häufige Fragen

Was ist Prompt Injection einfach erklärt?

Moderne Modell-Schnittstellen unterscheiden zwar zwischen Systemanweisung, Nutzereingabe und Werkzeugergebnis, und daraus ergibt sich eine Rangfolge. Diese Trennung ist aber keine harte Sicherheitsgrenze: Fremdinhalte werden vom selben Modell verarbeitet und können sein Verhalten beeinflussen. Prompt Injection nutzt genau das aus – der Angreifer schreibt seinen Text so, dass das Modell ihn wie eine Anweisung behandelt.

Man unterscheidet zwei Formen. Bei der direkten Prompt Injection tippt jemand die manipulierende Anweisung selbst ins Eingabefeld. Bei der indirekten Prompt Injection steht sie in einem Dokument, einer Webseite, einer E-Mail oder einem Ticket, das die KI später einliest. Die zweite Form ist die gefährlichere, weil der Angreifer dafür gar keinen Zugang zu deinem System braucht.

Warum hilft eine normale Firewall gegen solche Angriffe nicht?

Eine klassische Firewall entscheidet anhand technischer Merkmale: Absender, Ziel, Port, Protokoll, bekannte Signaturen. Ein Angriff über natürliche Sprache hat davon keines. Er kommt als ganz normale Anfrage über einen erlaubten Weg herein und sieht auf Paketebene aus wie jede andere Frage eines Kunden.

Der Unterschied liegt allein in der Absicht hinter dem Satz. Absicht ist aber kein technisches Merkmal, sondern eine Bedeutungsfrage. Deshalb braucht es eine Prüfschicht, die den Sinn einer Anfrage bewertet – und zusätzlich harte Grenzen dort, wo das Modell tatsächlich handeln darf.

Was macht ein LLM-Guard konkret?

Je nach Aufbau prüft ein LLM-Guard Eingaben, Ausgaben, Werkzeugaufrufe oder mehrere dieser Ebenen. Er versucht zu erkennen, ob eine Formulierung bestehende Anweisungen aushebeln soll, ob eine Anfrage außerhalb des vorgesehenen Anwendungsfalls liegt oder ob sie bekannten Angriffsmustern ähnelt.

Garantieren, dass nichts durchkommt, kann ein Guard nicht. Wie stark er die Erfolgsquote von Angriffen senkt, hängt vom Modell, von der Sprache, vom Anwendungsfall und vom konkreten Angriff ab. Als alleinige Absicherung reicht er deshalb nicht aus – vor allem dann nicht, wenn die Anwendung auf Dateien, Datenbanken oder andere Werkzeuge zugreifen darf.

Welcher LLM-Guard-Ansatz ist der richtige?

Gängig sind drei: feste Regeln und Heuristiken, ein kleines eigens trainiertes Erkennungsmodell und ein großes Modell, das per Systemanweisung zum Prüfer wird. Dazu kommen semantische Abgleiche über Einbettungen und nachgelagerte Richtlinienprüfungen. In produktiven Systemen werden diese Verfahren häufig kombiniert statt gegeneinander abgewogen.

Die Auswahl entscheidet sich in der Praxis über Kosten und Wartezeit. Regeln kosten fast nichts, sind aber leicht zu umgehen. Ein eigenes Erkennungsmodell ist im Betrieb günstig, hängt aber vollständig an den Trainingsdaten – ein überwiegend an englischen Beispielen trainiertes Modell kann bei deutschen Formulierungen schlechter abschneiden. Ein großes Prüfmodell ist schnell eingerichtet, kostet aber je Anfrage Rechenzeit und Wartezeit. Welche Erkennungsleistung dabei herauskommt, muss am eigenen Modell und in der eigenen Sprache gemessen werden.

Warum war der McKinsey-Vorfall keine Prompt Injection?

Der Zugriff auf die interne KI-Plattform Lilli lief über eine SQL-Injection. Die öffentlich einsehbare Schnittstellendokumentation führte über 200 Endpunkte auf, von denen 22 keine Anmeldung verlangten. Einer davon schrieb Suchanfragen in die Datenbank, und dabei wurden die Feldnamen der JSON-Anfrage ungeprüft in die Datenbankabfrage eingebaut.

Das ist ein Fehler aus dem klassischen Anwendungssicherheits-Lehrbuch, kein KI-Problem. Genau darin liegt die Lehre: Dieser Zugriff wäre von keinem LLM-Guard verhindert worden, weil er nie durch das Modell hindurchmusste. McKinsey hat die Schwachstelle bestätigt, erklärt aber, sie binnen weniger Stunden behoben zu haben; eine forensische Untersuchung habe keine Hinweise auf einen Zugriff auf Klientendaten ergeben.

Ab wann wird es für ein kleines Unternehmen wirklich riskant?

Auch eine KI, die ausschließlich antwortet, kann erheblichen Schaden verursachen – etwa durch die Offenlegung vertraulicher Informationen, falsche Empfehlungen oder manipulierte Entscheidungen. Ihr unmittelbarer technischer Handlungsspielraum ist allerdings kleiner.

Deutlich größer wird das Risiko, sobald die KI selbst Datenbanken abfragen, Dateien verändern, Nachrichten verschicken oder andere Systeme aufrufen darf. Die Formulierung bleibt dabei relevant, aber die Berechtigung entscheidet über die möglichen Folgen: Ein Zugang, der nur lesen darf, kann auf Zuruf nichts löschen. Deshalb zählen ab dieser Stufe minimale Berechtigungen, fest definierte Funktionen, geprüfte Parameter und Freigaben für folgenreiche Aktionen besonders.

Schützt ein lokal betriebenes Sprachmodell vor Prompt Injection?

Nein. Lokal betreiben löst ein anderes Problem: Die Eingaben gehen nicht an einen externen Modellanbieter. Das gilt allerdings nur, wenn Modell und Oberfläche wirklich lokal laufen, keine Cloud-Schnittstelle dahintersteckt, keine externen Erweiterungen oder Websuchen aktiv sind und Telemetrie und Fehlerberichte entsprechend eingestellt sind.

Die Anfälligkeit für manipulierte Anweisungen bringt das Modell aber mit, egal wo es läuft. Ein lokales Modell mit weitreichenden Rechten auf dem Dateisystem ist eher gefährlicher als ein Cloud-Modell ohne jede Handlungsbefugnis. Der Betriebsort ersetzt die Rechtevergabe nicht.

Was ist polymorphes Phishing über ein Sprachmodell?

Die Forschungsabteilung von Palo Alto Networks hat als Machbarkeitsnachweis eine Seite gebaut, die im Browser des Besuchers Anfragen an bekannte Sprachmodell-Dienste schickt und sich die Bausteine für eine Phishing-Seite Stück für Stück zurückgeben lässt. Zusammengesetzt und ausgeführt wird alles erst im Browser.

Für die Abwehr ist das unangenehm: Im Versuchsaufbau entstanden bei wiederholten Aufrufen syntaktisch unterschiedliche Varianten, und der Schadcode kam von einer Domain, der man üblicherweise vertraut. Bisher ist das ein Laborversuch und keine beobachtete Angriffswelle. Was dagegen wirkt, ist eine Erkennung, die das Verhalten zur Laufzeit bewertet statt eine bekannte Datei wiederzuerkennen.

Weiterlesen

KI sicher nutzen als Selbstständiger – wenn dich der praktische Teil mehr interessiert als die Angriffstechnik, ist das der passende Einstieg. Dort geht es um die Fragen, die vor der Absicherung kommen: welche Aufgaben sich überhaupt sinnvoll abgeben lassen und welche Daten dabei zwangsläufig durchlaufen. Auch der freigegebene Weg gegen Schatten-KI wird dort ausführlicher beschrieben als hier. Das ist der Beitrag, den du zuerst lesen solltest, wenn KI im Betrieb noch neu ist.

EU AI Act, NIS2 und DORA – die regulatorische Seite entscheidet mit darüber, welchen Aufwand du für deinen KI-Einsatz überhaupt einplanen musst. Der Beitrag ordnet ein, wen die Regeln betreffen und wen nicht, und trennt die Anforderungen an große Anbieter von dem, was für einen kleinen Betrieb tatsächlich übrig bleibt. Das erspart die verbreitete Panik ebenso wie das ebenso verbreitete Übersehen. Wer eine KI an Kundendaten hängt, sollte den Rahmen einmal gelesen haben.

Disaster Recovery im Unternehmen – der Abschnitt über Rechte und Wiederanlauf auf dieser Seite endet dort, wo dieser Beitrag anfängt. Er beschreibt, wie sich Ausfallzeit begrenzen lässt, wenn Rechner und Server nicht mehr starten, warum sich eine Reparatur im Ernstfall oft nicht zentral ausrollen lässt und in welcher Reihenfolge man Systeme zurückholt. Für jeden relevant, der eine KI-Anwendung an produktive Systeme hängt.

KI lokal betreiben – welche Hardware ein Mini-PC für lokale Sprachmodelle wirklich braucht, ist die Frage, an der die meisten Vorhaben scheitern. Der Beitrag geht durch Arbeitsspeicher, Grafikleistung und die Modellgrößen, die auf welcher Ausstattung noch flüssig laufen. Wenn du nach dem Lesen dieser Seite überlegst, die Anfragen im eigenen Haus zu halten, ist das der nächste Schritt. Er nennt auch die Grenze, ab der ein Mini-PC nicht mehr reicht.