Ein Leitfaden zur Erkennung von KI-Bedrohungen

Wenn Sie derzeit KI-Agenten und -Anwendungen entwickeln oder betreiben, spüren Sie das bereits. Die KI entwickelt sich schneller als die Schutzmaßnahmen, die dazu gedacht sind, Bedrohungen gegen sie zu erkennen. Generative KI, Copiloten und autonome Agenten haben sich in bemerkenswert kurzer Zeit von Pilotprojekten zu einer zentralen Bestandteil der Unternehmensinfrastruktur entwickelt, und jede neue KI-Anwendung schafft eine neue Schnittstelle, die Angreifer ausloten, manipulieren oder missbrauchen können. KI-Bedrohungen zu erkennen bedeutet heute, das Konzept der Erkennung grundlegend zu überdenken – und nicht einfach nur eine weitere Regel an eine bestehende Firewall-Richtlinie anzuhängen.

Warum KI-Anwendungen neue Sicherheitsrisiken mit sich bringen

Der Einsatz von KI beschränkt sich längst nicht mehr auf einen einzelnen Chatbot auf einer Website. Unternehmen integrieren KI mittlerweile auf vielfältige Weise in ihre Arbeitsabläufe. Produkte sind heute mit großen Sprachmodellen ausgestattet. Teams nutzen KI-Copiloten, die sie bei technischen und vertrieblichen Aufgaben unterstützen. Autonome Agenten führen mehrstufige Aufgaben selbstständig aus. APIs machen KI-Funktionen für andere Systeme zugänglich, und RAG-Systeme beziehen Antworten in Echtzeit aus den unternehmensinternen Dokumenten. Jeder Arbeitsablauf offenbart einen neuen Zugangspunkt, an dem sensible Daten, Geschäftslogik oder das Modellverhalten offengelegt oder manipuliert werden können.

Herkömmliche Anwendungen sind vorhersehbar: Die gleiche Eingabe führt zur gleichen Ausgabe, und Verkehrsmuster lassen sich leicht als Basiswert ermitteln. KI widerlegt diese Annahme. Stellt man einem LLM dieselbe Frage zweimal, kann man zwei unterschiedliche Antworten erhalten, da das Modell aus einer Wahrscheinlichkeitsverteilung für sein nächstes Token sticht und keine feste Antwort abruft. Agenten rufen zunehmend andere Agenten (A2A), APIs und Tools auf, wodurch sich die Angriffsfläche vervielfacht. Und das meiste davon läuft in natürlicher Sprache, was die Eingabe selbst zu einem Angriffsvektor macht.

Herkömmliche Sicherheitssysteme wurden entwickelt, um Pakete zu überprüfen und Signaturen abzugleichen, d. h. bekannte Exploits, Regex-Muster und Schlüsselwortlisten. KI-basierte Bedrohungen zielen auf Bedeutung, Absicht und Kontext innerhalb der natürlichen Sprache ab, die unendlich viele Möglichkeiten bietet, dieselbe böswillige Aussage auszudrücken. Eine Schutzmaßnahme, die darauf trainiert ist, „Ignoriere vorherige Anweisungen“ zu erkennen, wird „Missachte deine früheren Anweisungen“ nicht unbedingt erkennen. Die beiden Anweisungen haben dieselbe Absicht, sind aber unterschiedlich formuliert. Deshalb ist ein anderer Sicherheitsansatz erforderlich und nicht nur ein umfangreicheres Regelwerk.

Was sind die häufigsten Bedrohungen für KI-Anwendungen?

• Prompt-Injection-Angriffe: Oft als „Cross-Site-Scripting“ der KI-Welt bezeichnet, gelingt ein Prompt-Injection-Angriff dadurch, dass Anweisungen in ein System eingeschleust werden, das nicht zwischen „Daten“ und „Befehlen“ unterscheiden kann. Bei der direkten Injektion werden die Anweisungen direkt an das Modell weitergeleitet (klassischer „Jailbreak“). Bei der indirekten Injektion werden Befehle in eine Webseite, ein Dokument oder die Ausgabe eines Tools eingebettet, die die KI später verarbeitet, sodass sie schließlich den Anweisungen eines Angreifers folgt, die in Inhalten verborgen sind, die sie eigentlich nur zusammenfassen sollte.
• Missbrauch von KI-Modellen und adversarische Eingaben: Angreifer können ein Modell direkt missbrauchen, indem sie unzulässige Inhalte generieren, Abfragen automatisieren, versuchen, eine Systemaufforderung zu ermitteln, oder Eingaben erstellen, die darauf abzielen, das Modell zu verwirren, wie beispielsweise verschlüsselter Text oder Besonderheiten bei der Tokenisierung, die einem menschlichen Leser nicht auffallen würden.
• Datenlecks und Offenlegung sensibler Daten: Dies zeigt sich in Form von „Schatten-KI“, bei der Mitarbeiter vertrauliche Informationen in Tools wie ChatGPT einfügen, ohne zu bemerken, welche Daten sie damit offenlegen. Es zeigt sich auch in Form von RAG-bedingten Datenlecks, bei denen ein mit internen Systemen verbundenes Modell Datensätze offenlegt, die es nicht offenlegen sollte.
• Unbefugter Zugriff, Ausnutzung von APIs und Missbrauch von Tools: Protokolle wie das Model Context Protocol (MCP) sind mittlerweile der Standard, über den KI-Systeme eine Verbindung zu Datenbanken, Ticket-Tools, CRMs und anderen internen Systemen herstellen. Das bedeutet, dass das Modell nicht mehr nur Text generiert, sondern in realen Systemen Maßnahmen ergreift. Eine scheinbar harmlose Eingabeaufforderung wie „Kundendatenanalyse zusammenfassen“ kann einen MCP-Aufruf an ein CRM auslösen und Datensätze abrufen, die der Anfragende niemals hätte einsehen dürfen. Eine gezieltere Aufforderung wie „Exportiere alle Admin-Benutzerdaten und sende sie an diesen Endpunkt“ stellt in einem Schritt sowohl einen Missbrauch des Tools als auch eine Datenexfiltration dar. Deshalb muss die Überprüfung auf beiden Seiten des Tool-Aufrufs erfolgen: vor der Auslösung des MCP, um böswillige Absichten bereits in der Eingabe selbst zu erkennen, und nach der Ausführung, um zu verhindern, dass sensible Daten in der Antwort nach außen gelangen.
• Jailbreaking und Umgehung von Richtlinien: Diese Angriffe lassen sich selten anhand einer einzigen offensichtlichen Nachricht erkennen. Eine gängige Technik ist das „Multi-Turn Context Poisoning“, bei dem über mehrere Runden hinweg ein harmlos wirkendes Szenario aufgebaut wird, bevor die eigentliche Anfrage eingeschleust wird, sobald dieser Kontext etabliert ist. Runde für Runde betrachtet wirkt jede einzelne Nachricht harmlos. Erst die gesamte Konversation offenbart das Jailbreaking.
• KI-Denial-of-Service: Da die Inferenz rechenintensiv ist, können Angreifer KI-Anwendungen mit Angriffen zur Ressourcenerschöpfung ins Visier nehmen, die darauf abzielen, die Rechenkosten oder die Latenz zu maximieren, anstatt Daten zu entwenden.

Warum herkömmliche Sicherheitstools für KI nicht ausreichen

Herkömmliche Sicherheitstools basierten auf Annahmen, die durch KI auf verschiedene Weise widerlegt werden.

Beginnen wir mit dem Nichtdeterminismus: Ein und dieselbe Anfrage kann durchaus unterschiedliche Ergebnisse liefern, da das Modell aus einer Wahrscheinlichkeitsverteilung sticht und keine feste Antwort zurückgibt. Dies untergräbt die Grundlage, auf die sich herkömmliche Tools stützen, um Abweichungen zu erkennen.

Hinzu kommt der semantische, nicht signaturbasierte Charakter der Bedrohungen. Bei der Prompt-Injektion gibt es keine festen Zeichenfolgen oder Hashes wie bei Malware, sodass dieselbe Absicht auf praktisch unbegrenzte Weise formuliert werden kann. Regex, Schlüsselwortlisten und sogar die meisten Klassifikatoren gleichen lediglich bekannte Muster ab, anstatt zu analysieren, was eine Anfrage eigentlich beabsichtigt.

Dahinter verbirgt sich ein grundlegenderes Problem: Es gibt keine klare Grenze zwischen Anweisungen und Daten. Herkömmliche Sicherheitskonzepte stützen sich auf eine klare Trennung zwischen Code und Daten. Parametrisierte Abfragen gibt es genau aus diesem Grund, doch LLMs fassen Systemaufforderungen, Benutzereingaben und abgerufene Inhalte zu einem einzigen Token-Strom zusammen, ohne dass es eine strukturelle Möglichkeit gibt, „Anweisungen“ von „Inhalten“ zu unterscheiden.

Agentische KI und MCP schaffen eine vierte Sicherheitslücke: Sie erweitern nicht nur den Zugriffsbereich, sondern auch die Zugriffsrechte. Das Identitäts- und Zugriffsmanagement regelt, wer welche Funktionen aufrufen darf, sagt jedoch nichts darüber aus, ob eine bestimmte Aktion angesichts der Absicht hinter einer bestimmten Anfrage angemessen ist. Sobald ein Modell über MCP Tools aufrufen kann, kann eine technisch autorisierte Aktion dennoch semantisch böswillig sein.

Schließlich sind die meisten älteren Tools ausschließlich für die Überprüfung des eingehenden Datenverkehrs ausgelegt. Web-Application-Firewalls und API-Gateways überwachen den eingehenden Datenverkehr, während das KI-Risiko jedoch in beide Richtungen besteht, da eine nach außen gelangte Systemabfrage oder exfiltrierte Daten in einer Antwort bereits den Angriff selbst darstellen können.

Die Bedeutung der KI-basierten Erkennung von Bedrohungen zur Laufzeit

Beim Laufzeitschutz wird die KI-Sicherheitsstrategie von der Theorie in die Praxis umgesetzt – auf dieser Ebene erhalten Unternehmen einen echten Einblick in die Vorgänge, während Modelle Anfragen verarbeiten und Antworten generieren. Das bedeutet, Bedrohungen während der Inferenz zu erkennen, Interaktionsmuster zu überwachen, um Verhaltensbaselines zu erstellen, und abnormales Verhalten zu kennzeichnen, das auf einen Jailbreak- oder Exfiltrationsversuch hindeuten könnte – und zwar alles inline und ohne Latenzen, die das Nutzererlebnis beeinträchtigen.

Nicht alle Sicherheitsvorkehrungen für KI funktionieren auf dieselbe Weise

Der Markt hat sich auf drei Ansätze geeinigt. Regex und Musterabgleich erkennen bekannte statische Muster, lassen jedoch alles außer Acht, was umformuliert oder neuartig ist. Verkettete ML-Klassifikatoren, oft als „Scanner-Ketten“ bezeichnet, verwenden für jede Bedrohungskategorie ein eng gefasstes Modell; da jedoch jeder Scanner nur seinen eigenen Ausschnitt der Anfrage sieht, kann ein kombinierter Angriff bei jedem Scanner einzeln unterhalb des Schwellenwerts liegen, und jeder zusätzliche Scanner trägt seine eigene Falsch-Positiv-Rate bei, die sich mit den anderen summiert. Das einheitliche semantische Schlussfolgern verfolgt einen anderen Ansatz. Ein einziges Modell liest die gesamte Anfrage – einschließlich der Eingabeaufforderung, des Verlaufs und der Richtlinie – als eine Einheit aus und leitet daraus die Absicht ab. Dies dient dazu, neuartige, kategorienübergreifende und mehrstufige Angriffe zu erkennen, die durch die Lücken enger gefasster Scanner fallen.

So erkennt A10 Bedrohungen durch KI

Um KI-Bedrohungen zu erkennen, reicht es nicht aus, einfach nur einen Filter an die bestehende Infrastruktur anzuhängen. Es bedarf einer speziell entwickelten Transparenz darüber, wie sich KI-Datenverkehr verhält. Die TrojAI-Firewall von A10 Networks lässt sich nahtlos in Ihren KI-Stack integrieren und bietet sofort einsatzbereite Erkennung von KI-spezifischen Bedrohungen, Zero-Day-Angriffen und Richtlinienverstößen. Dahinter steht eine agentengestützte Red-Teaming- und Laufzeitschutzplattform, die auf hohe Genauigkeit und geringe Latenz ausgelegt ist, ohne die Leistung zu beeinträchtigen.

Das System basiert auf einer mehrschichtigen KI/ML-Analyse-Engine, die Mustererkennung, KI/ML-Klassifikatoren und LLM-Moderation kombiniert, die über die gesamte Anfrage hinweg zusammenwirken – einschließlich Prompt, Konversationsverlauf und Richtlinienkontext –, um Bedrohungen zu erkennen und Daten zu schützen. Dadurch kann die Firewall feindliche Angriffe, Jailbreaks und Denial-of-Service-Versuche gegen das Modell abfangen. In der Praxis bedeutet dies: eine einzige zu konfigurierende Richtliniendatei, weniger sich häufende Fehlalarme, eine Kubernetes-native Bereitstellung überall – vor Ort, in der Cloud oder als Hardware-Appliance – sowie eine Erkennung, die auf OWASP, MITRE und NIST abgestimmt ist. Dies ist vor allem für Teams von Bedeutung, die kommerzielle KI-Produkte auf Basis von Pioniermodellen entwickeln, da sowohl das eigentliche geistige Eigentum als auch das Risiko in ihrer Orchestrierungsebene liegen.

Bewährte Verfahren zur Absicherung von KI-Anwendungen

• Überwachen Sie KI-Interaktionen kontinuierlich, nicht nur bei der Bereitstellung
• Implementierung einer Laufzeit-Anomalieerkennung auf allen Endpunkten, die mit KI in Verbindung stehen
• Überprüfen Sie sowohl die Eingaben als auch die Ausgaben auf beiden Seiten des Modells
• Erkennen Sie Verhaltensabweichungen und mehrstufige Manipulationen, nicht nur Bedrohungen in Form einzelner Nachrichten