TL; DR
Der Begriff „KI-Sicherheitsbedrohungen“ umfasst zwei verschiedene Dinge: Angriffe, die auf KI-Systeme abzielen, und Angriffe, bei denen KI als Waffe eingesetzt wird. Sie benötigen unterschiedliche Kontrollmechanismen, unterschiedliche Verantwortliche und unterschiedliche Nachweise, und die meisten Listen vermischen diese, weshalb sie so schwer umzusetzen sind. Die ersten fünf unten aufgeführten Punkte zielen auf Ihre KI ab. Die zweiten fünf setzen KI gegen Ihre Lieferkette ein.
- Die größten Bedrohungen für KI-Systeme liegen in der Konfiguration, nicht im Modell selbst. Werkzeugbereich, die Anmeldeinformationen, unter denen ein Agent ausgeführt wird, eine Regeldatei, ein
.mcp/servers.jsonZugang. Nichts davon ist vom Modellendpunkt aus erreichbar, weshalb auch das Red-Teaming allein keine Fehler liefert. - KI-gesteuerte Angriffe erfolgen meist über Abhängigkeiten, nicht über Ihre Perimeter. Halluzinierte Paketnamen, die von Angreifern registriert werden, sich selbst verbreitende Würmer, die Entwicklerzugangsdaten und KI-Anbieterschlüssel als Ziel verwenden.
- Neun der zehn Fragen beziehen sich auf konkrete Dinge. Welche MCP-Server, welche Agenten, welcher Bereich, welche Anmeldeinformationen, welche Regeldatei, welches Paket? Ein Richtliniendokument beantwortet keine dieser Fragen.
- Alle zehn haben eine gemeinsame Voraussetzung. Man kann eine KI-Anlage nicht verteidigen, die man nie kartiert hat; deshalb ist die Entdeckung der Schritt vor der Kontrolle und nicht der danach.
Welche zwei Arten von KI-Sicherheitsbedrohungen gibt es?
Die meisten Listen von KI-Sicherheitsbedrohungen vermischen die beiden Aspekte, weshalb es schwierig ist, darauf zu reagieren.
- Bedrohungen für KI-Systeme Betrachten Sie Ihre KI als Ziel. Jemand manipuliert ein Modell, verfälscht die Anweisungen, die es befolgt, oder missbraucht die einem Agenten erteilten Berechtigungen. Die Aufgabe des Verteidigers ist die Eindämmung: den Einflussbereich einer kompromittierten KI zu reduzieren.
- KI-gesteuerte Angriffe Betrachten Sie KI als Werkzeug des Angreifers. Das Ziel ist Ihre gewöhnliche Software: Abhängigkeiten, Zugangsdaten, Build-Systeme, Entwickler. Die Aufgabe des Verteidigers besteht in der schnellen Erkennung, da sich die Wirtschaftlichkeit der Angriffe verändert und ihr Umfang zugenommen hat.
Sie benötigen unterschiedliche Kontrollmechanismen, unterschiedliche Verantwortliche und unterschiedliche Nachweise. Ein Team, das seinen Chatbot einem Red-Team-Test unterzogen hat, hat nichts gegen Slopsquatting unternommen. Ein Team mit exzellenter Abhängigkeitsprüfung kann dennoch einen Agenten mit Schreibzugriff auf Produktions-Repositories und ohne jegliche Einschränkung des Zugriffsbereichs betreiben. Beides stellt eine Bedrohung für die KI-Sicherheit dar. Keines der beiden deckt das andere ab.
Bedrohungen für KI-Systeme: die fünf häufigsten
01. Schnelle Einspritzung, die einen Werkzeugablass erreicht
Nicht vertrauenswürdige Inhalte treffen ein, werden in eine Systemeingabeaufforderung integriert, und der Agent auf der anderen Seite kann Tools aufrufen. Die Eingabeaufforderung selbst ist nicht die Schwachstelle. Der Weg von nicht vertrauenswürdigen Eingaben zu einer gefährlichen Funktion ist es.
Deshalb ist die alleinige Filterung von Eingabeaufforderungen enttäuschend. Sie verfestigt ein Ende der Kette, während die interessante Frage ist, ob sich irgendwo zwischen Eingabe und Werkzeugaufruf eine Schutzbarriere befindet. OWASP Top 10 für LLM-Bewerbungen Die sofortige Injektion steht zwar weiterhin an erster Stelle der Liste, wird aber aus genau diesem Grund mit übermäßiger Handlungsfähigkeit kombiniert.
Wonach schauen: Nicht vertrauenswürdige Eingaben erreichen eine Systemabfrage, der Abruf von Daten liefert Kontextinformationen ohne vorherige Bereinigung, und erreichbare Tool-Senken sind ohne dazwischenliegende Schutzmechanismen zugänglich.
02. Bösartige Regeln und Fertigkeitsdateien
Eine Regeldatei ist einfacher Text. commitEs ähnelt einer Dokumentation und wird wie eine Dokumentation geprüft. Es gibt dem Assistenten Anweisungen, was zu tun ist. Nullbreitenzeichen machen Zeilen in einem Dokument unsichtbar. pull request diff, bleibt aber für den Agenten perfekt lesbar.
MITRE ATLAS Dies wird als „Rules File Backdoor“ (Fallstudie AML.CS0041) katalogisiert. Der Prüfer genehmigt eine Formatierungskonvention. Der Agent liest eine Anweisung zum Importieren aus einem vom Angreifer kontrollierten Paket und gibt keine Meldung darüber ab.
Wonach schauen: Regeldateien, Fertigkeitsdateien und Eingabeaufforderungsvorlagen werden als Code und nicht als Prosa analysiert, wobei unsichtbare Zeichen erkannt werden.
03. Unsichere MCP-Serverkonfiguration
MCP-Konfiguration Hier empfängt ein Agent seine Befehle und hier werden Anmeldeinformationen gespeichert. Beide Bereiche stellen ein Problem dar. CVE-2025-6514, veröffentlicht im Juli 2025, war eine kritische Sicherheitslücke, die es ermöglichte, Betriebssystembefehle in eine weit verbreitete MCP-Bridge einzuschleusen. Sie wies einen CVSS-Wert von 9.6 auf und erlaubte die Ausführung beliebiger Befehle auf dem Client-Host beim Verbindungsaufbau zu einem nicht vertrauenswürdigen Server.
Die Hälfte der Zugangsdaten ist noch problematischer, da sie passiv ist. Untersuchungen aus dem Jahr 2026 ergaben, dass mehr als 24,000 Geheimnisse in MCP-Konfigurationsdateien auf öffentlichem GitHub gespeichert sind, von denen über 2,000 noch gültig sind.
Wonach schauen: Eine Bestandsaufnahme der verwendeten MCP-Server, ihrer Versionen, ihrer deklarierten Tools und der anhand von Konfigurationsdateien ausgeführten Geheimniserkennung.
04. Übermäßige Agentur
Ein Agent mit weitreichenden Werkzeugrechten und dauerhaften Anmeldeinformationen stellt eine permanente Privilegienerweiterung dar, die nur auf einen Auslöser wartet. Es muss nichts ausgenutzt werden, damit dies Schaden anrichtet. Ein verwirrter und ein kompromittierter Agent richten ähnlichen Schaden an, wenn beide Schreibzugriff haben, den sie nie benötigt haben.
Dies ist der unspektakulärste Punkt auf der Liste und gleichzeitig der häufigste. Er lässt sich auch am günstigsten beheben, nämlich durch eine Reduzierung des Umfangs, doch diese Lösung wird selten angewendet, da die Fragestellung niemandem eindeutig zuzuordnen ist.
Wonach schauen: welche Agenten existieren, was jeder von ihnen aufrufen kann, unter wessen Berechtigungen und ob jemand diesen Umfang genehmigt hat.
05. Vergiftete Modelle, Datensätze und KI-Abhängigkeiten
Der KI-Stack basiert auf Standardpaketen und gehosteten Artefakten. Modelle werden von öffentlichen Plattformen heruntergeladen. Datensätze stammen aus beliebigen Quellen. Beides birgt das gleiche Herkunftsproblem wie jede andere Abhängigkeit, jedoch mit weniger Werkzeugaufwand und deutlich weniger Überprüfung.
Wonach schauen: Modelle, Rahmenwerke und Datensätze werden als Komponenten der Lieferkette behandelt, mit derselben Zusammensetzungsanalyse und demselben CVE-Tracking wie bei Ihren übrigen Abhängigkeiten.
KI-gesteuerte Angriffe: Die fünf, die Ihre Lieferkette verändern
06. Slopsquatting
Eine auf der USENIX Security 2025 vorgestellte Studie generierte 2.23 Millionen Codebeispiele in 16 Modellen und stellte fest, dass 19.7 % der empfohlenen Pakete nicht existierten. Dabei entstanden über 205,000 einzigartige, fiktive Namen. Rund 43 % dieser Namen traten bei wiederholter Ausführung derselben Eingabeaufforderung erneut auf, was sie anfällig für gezielte Code-Erzeugung macht.
Angreifer müssen nicht mehr den Systemadministrator kompromittieren. Sie registrieren den von Ihrem Agenten vergebenen Namen und warten auf die Installation. Das Paket enthält weder eine Signatur noch einen Warnhinweis, da es neu ist und noch niemand es zuvor gesehen hat.
Wonach schauen: Malware-Screening, das auf Verhalten statt auf Reputation basiert und auf jede Abhängigkeit angewendet wird, die ein Agent hinzufügt.
07. Sich selbst vermehrende Lieferkettenwürmer
Das npm-Wurm vom September 2025 Dies markierte den Punkt, an dem Entwicklerrechner selbst zum Verbreitungsmedium anstatt zum Ziel wurden. Dieses Muster wiederholte sich bis 2026 in großem Umfang. Jede kompromittierte Entwicklerzugangsdatengruppe veröffentlicht die nächste Welle kompromittierter Pakete, und der Wirkungsradius vergrößert sich, anstatt sich zu addieren.
Wonach schauen: anomale Veröffentlichungstätigkeit, ungewöhnlich commit Muster und die Verwendung von Anmeldeinformationen, die nicht dem normalen Verhalten des Entwicklers entsprechen.
08. Gezielte Manipulation von KI-Zertifizierungsstellen durch Nationalstaaten
Im März 2026 wurde ein Softwarepaket mit rund 100 Millionen wöchentlichen Downloads für wenige Stunden kompromittiert. Ziel war der Zugriff auf die API-Schlüssel eines KI-Anbieters. Das Zeitfenster war bewusst kurz gehalten: lang genug für die Datenerfassung, aber kurz genug, um die Entdeckungswahrscheinlichkeit zu minimieren.
KI-Zugangsdaten sind mittlerweile ein begehrtes Ziel an sich, da sie Rechenleistung, Zugriff und eine glaubwürdige Identität ermöglichen. Angriffe auf diese Zugangsdaten haben zwischen Ende 2025 und Anfang 2026 stark zugenommen.
Wonach schauen: Schlüssel von KI-Anbietern werden wie Geheimnisse behandelt und unterliegen denselben Erkennungs- und Widerrufsmechanismen wie Cloud-Zugangsdaten.
09. Malware, die mithilfe eines LLM erstellt oder eingeschleust wurde.
Bis 2026 gab es dokumentierte Fälle, in denen ein Sprachmodell missbraucht wurde, um Schadcode in den Workflow eines Agenten einzuschleusen. Die Bedeutung liegt nicht in der Neuartigkeit der Malware, sondern darin, dass die Autorisierung kein Hindernis mehr darstellte und die Menge an plausibel aussehendem Schadcode, die einem Angreifer zur Verfügung stand, entsprechend zunahm.
Wonach schauen: Erkennung das setzt nicht voraus, dass man das Muster zuvor gesehen hat.
10. Kapazitätszusammenbruch überprüfen
Dies ist kein Angriff, weshalb er zuletzt genannt wird und deshalb am wichtigsten ist. Wenn ein Agent tausend Dateien pro Woche produziert, verliert die Codeüberprüfung ihre Kontrollfunktion und wird zur bloßen Warteschlange. Jede andere Bedrohung auf dieser Liste wird leichter zu bewältigen, wenn die letzte menschliche Kontrollinstanz überlastet ist.
Wonach schauen: Die Ergebnisse werden nach ihrer Ausnutzbarkeit und nicht nach ihrer Schwere geordnet, sodass nur die wenigen Fälle, die eine Produktionsgefährdung darstellen, tatsächlich einen Entwickler erreichen.
Zehn Bedrohungen bilden die Karte. Was man gegen jede einzelne tun kann, sprengt den Rahmen eines Blogbeitrags, deshalb haben wir das ausführlich besprochen. In dieser Folge von SafeDev-GesprächeJesús Cuadrado, CEO von Xygeni, spricht mit Atanas Nikolov, DevSecOps-Experte und SSDLC Technischer Leiter für polymorphe Malware, Prompt-Injection, Modellmanipulation und deren wirksame Abwehrmechanismen. Ohne Formular kein Zugang.
Warum kann man KI-Systeme nicht verteidigen, die man nicht kartiert hat?
Liest man die zehn Fragen erneut, ist das Muster kaum zu übersehen. Neun davon sind Fragen zu konkreten Dingen: welche MCP-Server, welche Agenten, welcher Bereich, welche Anmeldeinformationen, welche Regeldatei, welches Paket.
Keine dieser Fragen lässt sich anhand eines Strategiepapiers beantworten. Antworten liefert eine Bestandsaufnahme, und die meisten Organisationen verfügen nicht über eine solche. Die KI entstand durch das schnelle Handeln von Entwicklern – ohne Ticket, Beschaffungsprozess oder einen Eintrag in einem Repository, der sie als KI kennzeichnete.
Das macht die Kartierung zur Voraussetzung und nicht zum ersten Schritt. Ein Programm zur Abwehr von KI-Sicherheitsbedrohungen, das mit Kontrollen beginnt, wendet diese auf die ihm bekannte KI an – eine Teilmenge, deren Größe nicht bestimmt werden kann. Die Ermittlung muss an erster Stelle stehen: Modelle, Frameworks, Datensätze, Inferenz-Endpunkte, Agenten, MCP-Server, Fähigkeiten, Eingabeaufforderungen und die KI-Programmierwerkzeuge, die Ihre Entwickler tatsächlich verwenden, sowie die Beziehungen zwischen ihnen. Denn ein isoliert betrachtetes Asset liefert nur sehr wenige Informationen, und das Risiko konzentriert sich in der Kette.
Das NIST AI Risk Management Framework Aus demselben Grund wird die Kartenfunktion vor der Mess- und Managementfunktion platziert. Sie ist die uninteressanteste Funktion im Framework und diejenige, von der alles andere abhängt.
Auf welche KI-Sicherheitsbedrohungen sollten Sie zuerst reagieren?
Nicht die ausgefeilteste Lösung. Die am einfachsten zugängliche.
- In dieser Woche: Zählen Sie Ihre MCP-Server und führen Sie eine Geheimnisprüfung ihrer Konfigurationsdateien durch. Bedrohung 03 weist das höchste Verhältnis von Gefährdung zu Aufwand auf der Liste auf, und fast niemand hat sie untersucht.
- Diesen Monat: Ermitteln Sie Ihre Agenten und notieren Sie, welche Aktionen jeder einzelne ausführen kann und unter welchen Zugangsdaten. Damit ist Bedrohung 04 abgedeckt, die am häufigsten auftritt und am kostengünstigsten zu reduzieren ist.
- In diesem Quartal: Setzen Sie die Verhaltensprüfung auf Malware vor jede Abhängigkeit, die ein Agent hinzufügt. Dadurch werden die Bedrohungen 06, 07 und 09 gleichzeitig abgedeckt, da alle drei aufgrund ihrer Neuheit reputationsbasierte Prüfungen umgehen.
Alles andere kann hinter diesen dreien warten, denn alles andere setzt voraus, dass man bereits weiß, was man hat.
Die Organisationen, die 2027 KI-Sicherheitsbedrohungen erfolgreich begegnen, werden nicht diejenigen mit den besten Modellbewertungen sein. Sie werden diejenigen sein, die an jedem beliebigen Dienstag beantworten können, welche KI in ihrer Software läuft und auf welche Daten sie zugreifen darf. Das ist die entscheidende Position. Xygeni basierte auf: der kontinuierlichen Erkennung aller KI-Assets in allen Repositories und pipelines, Risikobewertung anhand der Rahmenwerke, die Ihre Prüfer bereits anerkennen, und die Lieferkettenprüfung, die das erfasst, was noch nicht unterschrieben ist.
Zehn Bedrohungen, zwei Kategorien, eine Karte darunter.
FAQ
Unterscheiden sich KI-Sicherheitsbedrohungen wirklich von gewöhnlichen Anwendungssicherheitsbedrohungen?
Teilweise. Die Folgen sind bekannt: Codeausführung, Zugangsdatendiebstahl, Datenleck. Geändert haben sich der Angriffspunkt und die Geschwindigkeit. Konfigurationsdateien, die zuvor inaktiv waren, enthalten nun Anweisungen, die ausgeführt werden, und die Kosten für Angreifer, überzeugenden Schadcode zu erstellen, sind gesunken. Ihre bestehenden Kontrollmechanismen bleiben bestehen; sie decken nur nicht mehr alle Bereiche ab.
Werden durch Red-Teaming unserer Modelle die meisten dieser Bedrohungen abgedeckt?
Es behandelt einen Teilaspekt. Red-Teaming klärt, ob ein Modell zu etwas überredet werden kann, was es eigentlich ablehnen sollte – ein durchaus nützlicher Aspekt. Es kann weder den Werkzeugbereich, die Anmeldeinformationen, die Regeldatei noch die MCP-Konfiguration einsehen, da diese nicht über den Modellendpunkt erreichbar sind. Ein fehlerfreier Red-Team-Bericht und ein gefährlich überprivilegierter Agent können sich somit nicht widersprechen.
Welche dieser KI-Sicherheitsbedrohungen wird am meisten unterschätzt?
Übermäßige Handlungsfähigkeit, ganz klar. Es gibt keine CVE, keinen Exploit, der demonstriert werden könnte, und keinen Anbieter, der ein dediziertes Produkt dafür verkauft, daher besteht keine Dringlichkeit. Es ist auch der Unterschied zwischen einem eingedämmten und einem uneindämmten Vorfall, denn der Umfang bestimmt, wie weit sich etwas nach dem ersten Fehler ausbreitet.
Wie verändern KI-gesteuerte Angriffe das, was wir messen sollten?
Sie verschieben den relevanten Messwert von der Schwere der Schwachstelle hin zur Zeit. Wenn Schadsoftware schneller erstellt wird, als Signaturen veröffentlicht werden, ist die Anzahl der offenen kritischen Sicherheitslücken weniger wichtig als die Geschwindigkeit, mit der neue Probleme erkannt werden. Messen Sie die Zeitspanne zwischen dem Eintreffen einer Abhängigkeit in Ihrem Code und ihrer Überprüfung sowie die Zeitspanne zwischen der Meldung einer Sicherheitslücke und dem Erreichen eines Entwicklers, der darauf reagieren kann.
