6 kritische KI-Sicherheitsbedrohungen und wie Sie sich dagegen verteidigen

Künstliche Intelligenz (KI) treibt heutzutage alles an. Von automatisierter Diagnostik bis hin zu IT-Operationen, die für die Erreichung von Missionen von entscheidender Bedeutung sind. Gleichzeitig schafft sie Angriffsflächen, die von herkömmlichen Abwehrmechanismen nicht erfasst werden, da diese Schwachstellen mit dem Lernprozess von Modellen, der Verarbeitung von Eingaben und dem Umgang mit Daten verbunden sind. In diesem Artikel werden sechs entscheidende Methoden erörtert, die Angreifer*Innen in der Designphase bis zur Produktion anwenden können, um die Sicherheit zu kompromittieren. Darüber hinaus werden die erforderlichen technischen Kontrollen in den jeweiligen Phasen diskutiert, um die Sicherheit zu gewährleisten. Dazu zählen Kontrollen im Design, im Training, bei der Bereitstellung und im Monitoring. 

Böswillige Aktivitäten – Kleine Änderungen, große Konsequenzen 

Ein gängiger Weg, wie Angreifer*Innen KI-Systeme attackieren, besteht darin, Eingaben so zu verändern, dass das Modell zu falschen Vorhersagen verleitet wird. Diese Angriffe nutzen eine grundlegende Schwäche darin aus, wie KI-Modelle Eingabedaten verarbeiten  

In der Praxis würde ein solcher Angriff wie folgt aussehen: 

1. Zunächst erzeugen Angreifer*innen kleine, gezielte Änderungen an den Eingabedaten. Das Rauschen im Bild kann auf der Ebene der Pixel auftreten, während bei Texten subtile Wortänderungen die Ursache sein können. Es ist essenziell, die Änderungen dabei auf erste Modellabfragen zu stützen. 
2. Die veränderten Anfragen werden genauso wie legitime Anfragen an den Vorhersage-Endpunkt gesendet. 
3. Die Labels und Konfidenzwerte des Modells zu jeder Anfrage werden protokolliert. 
4. Die Veränderungen werden so lange anhand dieser Antworten angepasst, bis eine kaum wahrnehmbare Änderung zur falschen Vorhersage führt. 

Für einen Menschen wirkt die veränderte Eingabe identisch zum Original, für das Modell reicht sie jedoch aus, um die Eingabe über seine Entscheidungsgrenze zu schieben. Das führt zu Fehlern wie dem falschen Labeln eines Stoppschilds, der Freigabe einer betrügerischen Transaktion, dem Einschleusen schädlicher Inhalte durch einen Filter oder einer fehlerhaften Triage eines*einer Patient*In. 

Ein bekanntes Beispiel betraf ein Machine-Learning-Modell, das darauf trainiert war, Verkehrszeichen in autonomen Fahrzeugen zu erkennen. Forschende zeigten, dass kleine, den Fahrer*Innen kaum wahrnehmbare Aufkleber auf einem Stoppschild dazu führen konnten, dass das Modell es fälschlich als Tempolimitschild klassifizierte. In einer realen Umgebung könnte eine solche Fehlklassifizierung gefährliche Fahrentscheidungen auslösen und dadurch potenziell Unfälle verursachen, Passagiere oder Fußgänger*Innen verletzen und sogar zum Verlust von Menschenleben führen. Über die unmittelbaren menschlichen Folgen hinaus könnte dies auch zu rechtlicher Haftung, zu einem Vertrauensverlust in der Öffentlichkeit und zu erheblichen finanziellen Schäden führen.  

Anzeichen und Monitoring für böswillige Aktivitäten 

Überwachen Sie Muster, die auf das Ausspähen oder die Manipulation des Modells hindeuten. Kennzeichnen Sie beispielsweise Fälle, in denen nahezu identische Eingaben unterschiedliche Labels erzeugen, ein Hinweis darauf, dass kleine Änderungen die Vorhersagen beeinflussen. Verfolgen Sie Sequenzen sehr kleiner Änderungen bei einzelnen Nutzenden, auf die plötzliche Anstiege der Konfidenzwerte des Modells folgen, da dies auf den Versuch hindeuten kann, Entscheidungsgrenzen zu finden und auszunutzen. Die Kombination dieser Signale hilft, böswilliges Verhalten zu erkennen und darauf zu reagieren, bevor Schaden entsteht. 

Praktische Schutzmaßnahmen gegen böswillige Aktivitäten 

Um zu verhindern, dass solche böswilligen Feinabstimmungen durchrutschen, setzen Sie folgende Kontrollen ein: 

• Edge-Input-Filterung: Prüfen Sie jede Anfrage und verwerfen Sie alle Daten außerhalb der erwarteten Grenzwerte. Stellen Sie zum Beispiel sicher, dass Bildpixel innerhalb normaler Farbbereiche liegen oder nur Wörter aus Ihrem freigegebenen Vokabular zugelassen sind. 
• Angriffssimulation im Modelltraining: Mischen Sie während des Modelltrainings bekannte Angriffsbeispiele ein, damit das Modell diese Änderungen als Rauschen statt als echte Merkmale behandelt. 
• Anomalieerkennung: Überwachen Sie zur Inferenzzeit die Muster eingehender Daten und markieren oder blockieren Sie automatisch Anfragen, die deutlich von Ihrem normalen Traffic abweichen. 

Modellinversion und -extraktion – von Antworten zu Rekonstruktionen und geklonten Modellen 

Sollten Angreifer*Innen nicht in der Lage sein, Ihr Modell zu täuschen, so besteht die Möglichkeit, dass sie versuchen Ihre Trainingsdaten zu rekonstruieren oder ein einen Klon Ihres Modells nachzubauen. Diese sogenannte Modellinversion bzw. -extraktion treten auf, wenn der Vorhersage-Endpunkt eines KI-Modells ohne starke Zugriffskontrollen oder Ausgabebegrenzungen exponiert ist und sich de facto in ein offenes Informations-Gateway verwandelt, das alle abfragen können. 

Angreifer*Innen können Hunderte oder Tausende sorgfältig variierter Eingaben senden, manchmal sogar sinnlose oder zufällige Daten und beobachten, wie sich die Konfidenzwerte oder Antworten des Modells verändern. Aus der Gesamtheit dieser Reaktionen können sensible Beispiele aus Ihrem Trainingssatz rekonstruiert werden (Modellinversion) oder ein eigenes Klon-Modell trainiert werden, das sich wie Ihres verhält (Modellextraktion). 

Die folgende Abbildung veranschaulicht den Unterschied zwischen beiden Angriffen: 

Links: Angreifer*Innen senden Anfragen an die API ihres Modells und nutzen die Antworten, um sensible Trainingsdaten zu rekonstruieren.
Rechts: Angreifer*Innen sammeln Eingabe-Ausgabe-Paare über dieselbe API und trainieren ein Klon-Modell, das ihr Originalmodell repliziert. 

Anzeichen und Monitoring für Modellinversionen und -extraktionen 

Mögliche Anzeichen für eine Modellinversion oder -extraktion sind ungewöhnlich hohe Anfragen von einzelnen Nutzer*Innen bzw. Identitäten, sowie eine hohe Vielfalt an Eingaben aus derselben Quelle. Diese sind darauf ausgelegt, ein breites Spektrum an Modellverhalten auszuleuchten. Ein weiteres Warnsignal ist das Ausspähen von Konfidenzwerten, bei dem Abfragen gezielt so gestaltet sind, dass die Sicherheit des Modells über verschiedene Eingaben hinweg abgebildet wird. Achten Sie schließlich genau auf Abfrageverteilungen, deren Merkmale, etwa Eingabelänge, Vokabularnutzung oder Embedding-Ähnlichkeit, deutlich von normalen Traffic-Mustern abweichen, da dies auf systematische Versuche hindeuten kann, das Modell zu invertieren oder zu replizieren. 

Schutzmaßnahmen gegen Modellinversion und -extraktion 

Verhindern Sie, dass Angreifer*Innen Ihre API wie einen Datenhahn oder eine Klonfabrik behandeln, indem Sie folgende Maßnahmen durchsetzen: 

• Gehärtete API-Zugänge: Authentifizierung sollte immer verlangt werden und Ratelimits pro Nutzer*In sollten durchgesetzt werden. 
• Gehärtete Ausgaben: Um Angreifer*Innen das präzise Feedback zu entziehen, das sie zum Rekonstruieren Ihrer Daten oder zum Klonen Ihres Modells benötigen, können Sie die Konfidenzwerte runden oder in Buckets einsortieren (oder etwas Rauschen hinzufügen). 
• Scan-Erkennung: Achten Sie in Ihren Logs auf systematische Sweeps durch Ihren Eingaberaum (z.B. Grid-Searches) und lassen Sie beim Auftreten Alarme auslösen. 

Model DoS (Sponge Attack) – Ihre Rechenleistung aufsaugen 

Scheitert der Versuch des direkten Datendiebstahls, wechseln Angreifer*Innen häufig die Taktik und fluten Ihren Dienst mit einer hohen Anzahl an Datenanfragen. Modell-DoS- bzw. Sponge-Angriffe treten auf, wenn Angreifer*Innen das KI-Modell mit Eingaben überschwemmen, die gezielt darauf ausgelegt sind, übermäßig viel Rechenzeit und Speicher zu verbrauchen. Dies können sehr lange Texte, große Bildbatches oder Inputs, die intensive Vorverarbeitung auslösen, sein. Die wiederholte Ausführung ressourcenintensiver Anfragen an die KI-Model-API führt zu einer Steigerung der Rechenlast und der Ressourcenauslastung. Dies kann dazu führen, dass legitime Anfragen verzögert oder gar nicht ausgeführt werden. Ein Vorhersage-Endpunkt, der jede Anfrage unabhängig von den Kosten bis zum Ende verarbeitet, kann einem sogenannten Sponge-Angriff ausgesetzt werden. In der Praxis kann dies geschehen, wenn der Dienst unbegrenzte Eingaben ohne Vorabvalidierung akzeptiert, Größen- und Formatlimits nicht durchsetzt, pro Client weder Ratenbegrenzung noch Parallelitätskontrollen hat und Profiling- oder Debug-Endpunkte exponiert. 

Anzeichen und Monitoring für Model DoS (Sponge Attacks) 

Überwachen Sie zentrale Leistungsmetriken wie p95- und p99-Latenz, Queue-Tiefe, Token-Zahlen bzw. Sequenzlängen, Bildabmessungen sowie CPU-, GPU- oder Speichernutzung pro Aufrufer*In. Achten Sie besonders auf plötzliche Peaks bei übergroßen Inputs sowie auf Anstiege bei Timeouts, 5xx-Fehlerraten oder Ressourcensättigung, die sich auf wenige Identitäten konzentrieren. Solche Muster können auf gezielte Versuche hindeuten, Ihren Dienst zu überlasten oder zu degradieren. 

Schutzmaßnahmen gegen Model DoS (Sponge Attacks)  

• Strikte Payload-Grenzen: Weisen Sie Anfragen zurück, die sichere Grenzen überschreiten (maximale Textlänge, Bilddimensionen, Batch-Größe), damit übergroße oder verschachtelte Payloads keine Ressourcen monopolisieren. 
• Parallelitätskontrollen: Begrenzen Sie gleichzeitige In-Flight-Anfragen pro Nutzer*In oder Knoten, damit kein einzelner Akteur CPU, GPU oder Speicher erschöpfen kann. 
• Early-Exit-Leistungsschutz (Circuit Breakers): Führen Sie am Edge einen leichtgewichtigen Kosten-Schätzer aus, mit einfachen Heuristiken oder einem Proxy-Modell und brechen Sie jede Anfrage ab, die voraussichtlich Ihren vordefinierten Ressourcen-Schwellenwert überschreitet. 

Jailbreaking – das Modell in verbotene Bereiche zwingen 

Wenn Angreifer*Innen gelernt haben, Ihr Modell zu überlasten oder auszutesten, versuchen sie, es in verbotene Bereiche zu drängen. Beim Jailbreaking verfolgen Angreifer*Innen das Ziel, die Filter und Richtlinien zu umgehen, die dazu dienen, die Ausgaben des Modells innerhalb akzeptabler Grenzen zu halten. Sie formulieren Aufforderungen, die auf den ersten Blick harmlos oder regelkonform erscheinen, um die Logik der Moderation auf etwaige Schwachstellen zu prüfen. Sobald die Erkenntnisse aus diesen Sondierungen vorliegen, werden die Formulierungen und das Layout optimiert und es werden unzulässige Inhalte in scheinbar unbedenkliche Fragen eingebettet. Auch wenn Prüfer*Innen eine Frage für harmlos halten mögen, kann sie dennoch Richtlinienprüfungen umgehen. Das Modell lässt sich so zu eingeschränkten oder böswilligen Ausgaben verleiten. 

Anzeichen und Monitoring für Jailbreaking 

Überwachen Sie „erst blockiert, dann erlaubt“-Muster, bei denen Prompts nach leichter Umformulierung zunächst blockiert, später aber zugelassen werden. Behalten Sie steigende Raten von Prompts im Blick, die dicht an den Richtliniengrenzen liegen, da dies auf systematische Versuche hindeuten kann, Schutzmechanismen zu umgehen. Verfolgen Sie außerdem Fälle, in denen eine Zweitprüfung oder ein zusätzlicher Klassifikator eine Ausgabe als richtlinienverletzend markiert, obwohl sie die Erstfilterung bestanden hat. Das kann Lücken in den Primärkontrollen offenlegen. 

Schutzmaßnahmen gegen Jailbreaking 

Schützen Sie Ihr Modell durch Defense-in-Depth, sodass Angreifer*Innen Schwachstellen nicht einfach finden und ausnutzen können: 

• Eingaben normalisieren & säubern: Entfernen Sie HTML-Tags, URL-Codierungen, Steuerzeichen und andere Verschleierungen aus den Eingaben. 
• Zweistufige Inhaltsprüfungen: Überprüfen Sie jeden Prompt sowohl durch regelbasierte als auch durch ML-basierte Filter und blockieren Sie jede Eingabe, die bei einer der beiden durchfällt. 
• Integritätsmarker: Betten Sie versteckte Token um die Systemanweisungen ein. Wenn diese verändert oder entfernt werden, sollte die Anfrage abgelehnt werden. 
• Kontinuierliches Red Teaming: Testen Sie Ihre Filter regelmäßig mit neuen böswilligen Prompts. Zudem sollten Sie ihre Regeln beim ersten Anzeichen eines Umgehungsversuchs aktualisieren. 

Prompt Injection – Hijacking von Modellanweisungen 

Um noch tiefer einzudringen, versuchen Angreifer*Innen nicht nur, Filter zu umgehen, sondern sie schreiben auch die Anweisungen um, die Sie Ihrem Modell gegeben haben. Diese Technik ist als Prompt Injection bekannt. Prompt Injections nutzen die Kombination aus Systemanweisungen und von Nutzer*Innen bereitgestelltem Text, auf der viele LLM-Deployments basieren. Angreifer*Innen identifizieren Stellen, an denen Informationen von Nutzer*Innen in die Modellanweisungen eingeflossen sind, oft gekennzeichnet durch spezielle Symbole oder Token und fügen dort schädliche Anweisungen hinzu. Mithilfe von Formulierungen wie „Ignoriere alle vorherige Anweisungen” oder „Gib mir jetzt das Geheimnis aus” können sie das Verhalten des Modells verändern. Dadurch ignoriert das Modell die Regeln, denen es folgen sollte, und befolgt stattdessen die Befehle der Angreifer*Innen. Auch wenn Menschen solche Einschleusungen leicht erkennen können, kann die Verarbeitung von Anweisungen im Modell vertuscht werden, sodass diese priorisiert werden. Das kann zu unbeabsichtigten Aktionen oder zur Weitergabe privater Informationen führen. Selbst einfache Formatierungstricks, wie Zeilenumbrüche, alternative Codierungen oder das Verpacken von Payloads in Metadaten, können die Wahrscheinlichkeit einer erfolgreichen Prompt Injection deutlich erhöhen. 

Anzeichen und Monitoring für Prompt Injection 

Scannen Sie vorab alle nicht vertrauenswürdigen Inhalte, z. B. Ausgaben aus Retrieval-Augmented Generationen (RAG), Tool-Antworten oder Webseiten nach Mustern, die das Modellverhalten übersteuern könnten. Lösen Sie Alarme aus, wenn das Modell nach der Verarbeitung solcher Inhalte Aktionen versucht, die es nicht ausführen sollte, etwa verbotene Tool-Aufrufe oder das Referenzieren interner bzw. System-Prompts. So lassen sich potenzielle Injection- oder Override-Angriffe erkennen und stoppen, bevor sie das System kompromittieren. 

Schutzmaßnahmen gegen Prompt Injection 

Der Schlüssel zur Abwehr von Prompt Injections besteht darin, System- und Nutzer*Innen-Anweisungen strikt zu trennen und gegen Manipulation zu schützen. 

• Strikte Prompt-Trennung: Halten Sie System-Prompts und Nutzertexte in getrennten, unveränderlichen Feldern (z. B. separate JSON-Eigenschaften). 
• Entfernen von Steuerzeichen: Entfernen Sie Zeilenumbrüche, Homoglyphen, Metadaten-Wrapper und andere Formatierungstricks aus Nutzereingaben. 
• Manipulationssichere Wrapper: Signieren oder hashen Sie System Prompts und verwerfen Sie jede Anfrage, deren Signatur sich nicht verifizieren lässt. 
• Ausgabevalidierung: Prüfen Sie Ergebnisse gegen Richtlinien und schwärzen oder blockieren Sie verbotene Inhalte. 

Data Poisoning – Hintertüren in Ihren Trainingsdaten 

Im Gegensatz zu vorherigen Angriffen, deren Folgen oft unmittelbar sichtbar sind, ist die Data Poisoning-Methode eine Bedrohung, die lange unentdeckt bleiben kann, bevor sie sichtbar wird. Beim Data Poisoning wird ein Modell kontaminiert, indem der Trainings- oder Fine-Tuning-Datensatz verunreinigt wird. In diesem Szenario fügen Angreifer*Innen unauffällig Beispiele hinzu, die entweder falsch gelabelt sind oder versteckte Backdoor-Trigger enthalten, und leiten sie in die Lernpipeline weiter. Wird das Modell mit diesen verunreinigten Daten neu trainiert, erlernt es sowohl die guten als auch die schädlichen Muster. Später, im Einsatz, können Angreifer*Innen den spezifischen Trigger auslösen (eine im Input versteckte Phrase oder ein Muster), um das Backdoor-Verhalten zu aktivieren. Dadurch klassifiziert das Modell falsche Ergebnisse oder gibt vertrauliche Informationen preis. Die vergifteten Beispiele sind vereinzelt und ähneln echten Daten, weshalb sie in regulären Audits oft unentdeckt bleiben. Das Modell wirkt völlig normal, bis das verborgene schädliche Verhalten ausgelöst wird. 

Anzeichen und Monitoring für Data Poisoning 

Während des Intake-Prozesses führen Sie Schema-/Label-Plausibilitätsprüfungen, LSH-Deduplizierung sowie Ausreißer-/Spektralsignaturtests durch, um anomale Cluster zu identifizieren, die auf den ersten Blick normal erscheinen, aber Backdoor-Trigger enthalten. Bewerten Sie die Proben mit einflussbasierten Metriken, um diejenigen hervorzuheben, die einen signifikanten Einfluss auf den Verlust haben. Nach dem Training halten Sie Canary-/Backdoor-Suiten (z. B. Trigger-Phrasen und -Patches) bereit und lösen Alarme aus, wenn Leistungsabfälle oder Aktivierungsmuster auftreten, die mit bekannten Backdoor-Verhaltensweisen übereinstimmen. Plötzliche Regressionen in sauberen Evaluierungen, während „mysteriöserweise” seltene Muster bestanden werden, sind ebenfalls ein Alarmsignal. 

Schutzmaßnahmen gegen Data Poisoning 

Verhindern Sie mit diesen Checks, dass bösartige Samples unbemerkt in Ihren Trainingssatz gelangen: 

• Schreibzugriffe absichern: Setzten Sie RBAC und MFA in allen Trainingsdaten-Repos durch, damit nur vertrauenswürdige Accounts Änderungen vornehmen können. 
• Automatisierte Datenprüfung: Führen Sie für jedes neue Sample ein Schema-Check und eine statistische Ausreißererkennung durch. 
• Provenienz-Tagging: Hängen Sie immer Quelle, Zeitstempel und Versions-Metadaten an jeden Datenpunkt an, um die Rückverfolgbarkeit und Isolation zu erleichtern. 
• Geplante Backdoor-Audits: Testen Sie ihre Daten regelmäßig mit bekannten Challenge-Triggern. Wenn diese eine Backdoor auslösen, setzten Sie Ihre Daten auf einen sauberen Checkpoint zurück und entfernen Sie die verunreinigten Daten. 

Baseline-Sicherheitsanforderungen – die Must-Haves 

Wirklich resiliente KI aufzubauen erfordert, Sicherheit von Anfang an zur Kernpriorität zu machen – das ist das Grundprinzip unserer Secure-by-Design-Philosophie.  

Zusätzlich zu den gezielten Maßnahmen oben sollten diese Basis-Kontrollen stets aktiv sein: 

• Authentifizierung & Autorisierung: Jede Anfrage muss gültige Anmeldedaten vorweisen (API-Schlüssel, OAuth-Tokens oder Service-Zertifikate). Erzwingen Sie rollenbasierte Berechtigungen und Netzwerkrichtlinien, damit nur autorisierte Systeme oder Nutzer*Innen Ihr Modell aufrufen können. 
• Request-Rate-Limiting: Begrenzen Sie pro Client die Anzahl der Aufrufe je Zeitfenster und limitieren Sie gleichzeitige laufende Anfragen pro Nutzer*In oder IP. So verhindern Sie sowohl großflächiges Ausspähen als auch ressourcenzehrende Fluten. 
• Zentralisiertes Logging & Anomalie-Alarme: Erfassen Sie jede Anfrage, jede Antwort, die Client-Identität und Payload-Metadaten in einem zentralen System. Definieren Sie Schwellwerte für abnormes Verhalten und lösen Sie bei Erreichen sofortige Benachrichtigungen aus. 

Sicherheitslücken in KI vermeiden: Mit Architektur, Automation & Audits zur Resilienz

KI bringt eine ganz neue Klasse von Bedrohungen mit sich. Unbeachtet können diese Exploits alles kompromittieren, von der Modellgenauigkeit über den Datenschutz bis zur Systemverfügbarkeit. Die Frage ist nicht, ob diese Bedrohungen auftreten, sondern ob Ihre Pipeline secure-by-design ist. Das bedeutet, Sicherheitsanforderungen bereits in der Architekturphase zu definieren, sie über Training und Deployment hinweg umzusetzen und sie in der Produktion kontinuierlich zu verifizieren. Wenn Kontrollen von Anfang an spezifiziert, in der Delivery-Pipeline automatisiert und durch klare Zuständigkeiten sowie regelmäßige Reviews abgesichert sind, verringern Sie die Angriffsfläche, beschleunigen die Erkennung und gestalten die Wiederherstellung diszipliniert statt ad hoc.