LLM-Sicherheit: Absicherung des mehrschichtigen Stacks hinter einer LLM-Anwendung

Unter LLM-Sicherheit versteht man den Schutz einer Anwendung mit einem großen Sprachmodell auf allen Ebenen, die diese Anwendung unterstützen: das Modell selbst, die Eingabeaufforderungen und der abgerufene Kontext, den es verarbeitet, der Inferenzserver, auf dem es ausgeführt wird, die Orchestrierungssoftware, die die Daten an das Modell weiterleitet, sowie der Code, der die Rückgabewerte verarbeitet. In diesem Zusammenhang steht LLM für „großes Sprachmodell“ und nicht für den juristischen Master-Abschluss.

Die meisten veröffentlichten Leitfäden zu diesem Thema beschränken sich auf das Modell. Diese Seite setzt dort an, wo das Modell aufhört. Die darunterliegenden Schichten – also der Inferenzserver, das verteilte Rechen-Framework, der Abrufspeicher und das davor liegende Gateway – sind gewöhnliche Software mit gewöhnlichen CVE-Kennungen, festgelegten Versionen und in einigen Fällen bundesweiten Fristen für Abhilfemaßnahmen. Das ist der Teil, bei dem ein Sicherheitsteam noch in dieser Woche aktiv werden kann.

Was die LLM-Sicherheit abdeckt und worauf sich diese Seite konzentriert

Ein großes Sprachmodell ist ein Modell, das anhand sehr umfangreicher Textkorpora trainiert wurde, um Texte vorherzusagen und zu generieren. In einer Unternehmensumgebung läuft es so gut wie nie eigenständig. Es ist hinter einer API eingebunden, greift auf abgerufene Dokumente zurück, ruft Tools auf und gibt Ergebnisse zurück, die von anderer Software verarbeitet werden. Jede dieser Verbindungen ist eine Stelle, an der etwas schiefgehen kann, und nur bei einigen davon ist das Modell überhaupt beteiligt.

Das ist der Unterschied, den die meisten Leitfäden verwischen. Modellsicherheit und Modellsicherheit überschneiden sich, sind aber nicht dasselbe. Die am 18.11.2024 veröffentlichte technische Analyse von Red Hat zu den Risiken von LLM-Systemen zieht eine klare Grenze: „Wenn ein LLM-System die Ausgabe eines LLM verwendet und dies die Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigt, entsteht eine Sicherheitslücke.“ Ein Modell, das eine verzerrte oder falsche Antwort liefert, weist ein Sicherheitsproblem auf. Ein Modell, dessen Antwort unescaped in einen Shell-Befehl, eine Datenbankabfrage oder einen privilegierten API-Aufruf übergeben wird, weist ein Sicherheitsproblem auf, und dieses Problem liegt in der Komponente, die der Ausgabe vertraut hat.

Diese Seite befasst sich mit dem Stack, der das Modell bereitstellt, und ist bewusst eng gefasst. Die vollständige Risikotaxonomie gehört zum Bereich der GenAI-Sicherheit. Die Tiefe der Prompt-Injektion gehört zu prompt injection. Der übergreifende Bereich gehört zur KI-Sicherheit, und adversarische Tests gehören zum KI-Red-Teaming. Was Sie hier erhalten, ist eine schichtweise Bestandsaufnahme, die für diese Schichten erfassten Schwachstellen, die von der Anwendung ausgegebenen Informationen, die ein Sicherheitsteam nutzen kann, sowie eine Anleitung, wie Sie die Zahlen interpretieren, die Ihnen ein Anbieter nennt.

Der LLM-Anwendungsstack, Schicht für Schicht

Eine LLM-Anwendung besteht aus etwa acht Schichten, und die Literatur zum Thema Ranking deckt davon etwa drei ab. Die Schichten, mit denen sich Entwickler befassen, sind ausführlich dokumentiert. Über die Schichten, für die das Betriebsteam zuständig ist, wird hingegen kaum berichtet.

• Modell. Die trainierten Gewichte und die Architektur, die Text generieren.
• Eingabeaufforderung und Kontext. Die Systemeingabeaufforderung, die Benutzereingabe und alle weiteren Elemente werden im Kontextfenster zusammengefasst.
• Abfrage und Vektorspeicher. Das Dokumentenkorpus und die Einbettungsdatenbank werden abgefragt, bevor das Modell antwortet. Bei einem abfragegestützten Assistenten bildet das Korpus die Sicherheitsgrenze, nicht die Chat-Oberfläche.
• Aufruf von Tools und Funktionen. Die Funktionen, die das Modell aufrufen darf, sowie die damit verbundenen Berechtigungen.
• Inferenzserver. Der Dienst, der das Modell in den Arbeitsspeicher lädt und darauf basierende Anfragen bearbeitet.
• Orchestrierung und verteilte Datenverarbeitung. Die Software, die Anfragen weiterleitet, Aufgaben auf verschiedene Rechner verteilt und Modelle mit Tools und Daten verknüpft.
• Modellartefakt und Serialisierung. Das Dateiformat, in dem die Gewichte bereitgestellt werden, sowie der Code, der diese deserialisiert.
• Ausgabeverarbeitung. Der Code, der die vom Modell zurückgegebenen Werte verarbeitet.

Die ersten vier liegen in der Verantwortung der Entwickler. Die nächsten drei fallen in den Zuständigkeitsbereich der Plattform- und Betriebsteams, und die Ausgabeverarbeitung obliegt in der Regel dem jeweiligen Anwendungsteam, das sie eingerichtet hat. Diese Aufteilung ist von Bedeutung, da sich die von CVEs betroffenen Schichten fast ausschließlich auf der Betriebsseite befinden und häufig ohne einen namentlich benannten Sicherheitsverantwortlichen bereitgestellt werden.

Prompt injection, die Manipulation des Modellverhaltens durch gezielt gestaltete Eingaben, ist das bekannteste Risiko auf der Prompt- und Kontextebene und wird nicht hier, sondern auf einer eigenen Seite ausführlich behandelt. Unverwaltete oder nicht genehmigte Inferenz-Endpunkte innerhalb Ihrer Infrastruktur stellen in erster Linie ein „Shadow-AI“-Problem dar, bevor sie ein LLM-Problem sind. Dort, wo das Modell handeln darf, anstatt nur zu antworten, wird die Tool-Aufruf-Ebene zu einem Sicherheitsproblem im Bereich der agentenbasierten KI.

‍

Die Server- und Orchestrierungsschicht verfügt über gewöhnliche, patchbare CVEs

Alles, was oben steht, ist Architektur. Das ist der Teil, auf den Sie Einfluss nehmen können.

Die Bereitstellungs- und Orchestrierungsschicht ist der einzige Bereich, in dem sich die Sicherheit von LLM auf drei bekannte Begriffe beschränken lässt: Bestandsaufnahme, Patching und Einschränkung. Diese Komponenten verfügen über CVE-Kennungen, behobene Versionen und öffentliche Schwachstelleneinträge, und für einige gelten bundesweite Fristen für die Behebung. Für die Umsetzung all dieser Maßnahmen sind keine Kenntnisse im Bereich des maschinellen Lernens erforderlich.

Ebene und Komponente, CVE-ID, Bewerter und Bewertungen, behobene Version und Status, Inferenzserver,vLLM, CVE-2026-22778, zweisekundäre Bewerter mit 9,8 (KRITISCH). Keine NVD-Primärbewertung Betrifft Versionen 0.8.3 bis unter 0.14.1, behoben in 0.14.1. Nicht in KEV Inferenzserver,Ollama CVE-2026-7482Dieselbe CNA veröffentlicht 8,8 (HIGH) nach CVSS 4.0 und 9,1 (CRITICAL) nach CVSS 3.1. Keine primäre NVD-Bewertung. In Version 0.17.1 behoben. Nicht im KEV-Inferenzserver, NVIDIATriton CVE-2026-47627. NVIDIAals CNA, 9,8 „KRITISCH“ nach CVSS 3.1. Noch nicht vom NVD bewertet. Betrifft Versionen 0.0 bis 26.05. Nicht in KEV. Verteiltes Rechnen,Ray. CVE-2023-48022. NISTals NVD-Primärquelle, 9,8 „CRITICAL“. CISA-ADP als Sekundärquelle, 9,8 „CRITICAL“. Formell als umstritten gekennzeichnet. Token-Authentifizierung verfügbar ab Version 2.52.0. Nicht in KEV, SSVC-Proof-of-Concept-Exploit. Verteiltes Rechnen,RayCVE-2025-62593. NISTals NVD-Primärquelle, 8,8 „HIGH“ nach CVSS 3.1. GitHub als CNA, 9,4 „CRITICAL“ nach CVSS 4.0. Behoben in Version 2.52.0. Am 17.08.2026 zu KEV hinzugefügt, Fälligkeit 20.08.2026; ML-Lebenszyklus,MLflow; CVE-2026-64849; GitHubals CNA, 9,3 „KRITISCH“ nach CVSS 3.1. NVD hat keinen Primärwert veröffentlicht, obwohl der Eintrag als „Analysiert“ gekennzeichnet ist; behoben in 3.15.0. Hinzugefügt zu KEV am 19.08.2026, fällig am 02.09.2026: LLM-Gateway,LiteLLM; CVE-2026-42271; NISTals NVD-Primär, 8,8 (HIGH), Vektor PR:L, d. h. ein authentifizierter Aufrufer; betrifft 1.74.2 bis 1.83.6, behoben in 1.83.7. Hinzugefügt zu KEV am 08.06.2026, fällig am 22.06.2026:Retrieval-augmented assistant, CVE-2025-32711, Microsoftals CNA, 9,3 KRITISCH. NIST als NVD-Primärquelle, 7,5 HOCH. Nicht in KEV, keine SSVC-Ausnutzung

Bildunterschrift: Erfasste Schwachstellen in der LLM-Bereitstellungs- und Orchestrierungsschicht, Stand: 25.08.2026. Hierbei handelt es sich um eine datumsgestempelte Stichprobe, nicht um eine vollständige Liste. Alternativtext: Tabelle mit acht Sicherheitslücken in der LLM-Infrastruktur, in der die betroffene Ebene und Komponente, die CVE-Kennung, die jeweiligen Bewertungsorganisationen mit ihren Bewertungen sowie die behobene Version und der KEV-Status aufgeführt sind.

Zwei Faktoren machen diese Tabelle nutzbar. Erstens: Geben Sie den Ersteller der Bewertung an. Eine Bewertung der CVE Numbering Authority (CNA) ist keine NVD-Bewertung, und in dieser Tabelle weichen sie häufig voneinander ab. CVE-2026-7482 weist bei derselben CNA einen Wert von 8,8 nach CVSS 4.0 und 9,1 nach CVSS 3.1 auf, und das NVD hat keinen unabhängigen Basiswert veröffentlicht, obwohl der Eintrag als „Analysiert“ gekennzeichnet ist; daher ist die Angabe „9,1 laut NVD“ falsch. Zweitens: Lesen Sie die Beschreibung statt der Überschrift. CVE-2026-22778 ist kein Fall von Remote-Code-Ausführung durch einen einzelnen Fehler: NVD klassifiziert ihn unter CWE-209 und CWE-532, beides Schwachstellen im Zusammenhang mit der Offenlegung von Informationen, und beschreibt ein Heap-Adressleck, das „mit einem Heap-Überlauf im JPEG2000-Decoder in OpenCV/FFmpeg verkettet werden kann, um eine Remote-Code-Ausführung zu erreichen“.

Das Volumen auf dieser Ebene ist weder geringfügig noch statisch. Ein NVD-Schlüsselwort-Erhebung am 25.08.2026 ausgeführt, wobei die Gesamtanzahl der Ergebnisse Feld für jeden Produktnamen, liefert 129 Datensätze für Flowise, 70 für vLLM, 68 für LangChain, 63 für Triton Inference Server, 36 für Ollama, 35 für llama.cpp, 30 für LiteLLM, 18 für SGLang und 4 für TorchServe. Fünf Tage zuvor lagen drei dieser Zahlen niedriger, nämlich bei 69, 67 und 32, und keine war höher. Auch eine Konzentration ist zu erkennen: Am 18.08.2026 wurden fünf CVEs für den NVIDIA Triton Inference Server veröffentlicht, angeführt von CVE-2026-47627 mit 9,8 (KRITISCH), und alle fünf werden sekundär gewertet, ohne primäre NVD.

Das deutlichste Beispiel für Governance auf dieser Ebene ist Ray. Zwei Behörden stufen CVE-2023-48022 mit 9,8 als „CRITICAL“ ein, und das NVD kennzeichnet den Eintrag offiziell als „umstritten“, da der Hersteller den Standpunkt vertritt, dass „Ray, wie in der Dokumentation angegeben, nicht für den Einsatz außerhalb einer streng kontrollierten Netzwerkumgebung vorgesehen ist“. Umstrittene Einträge fallen aus einigen Workflows des Schwachstellenmanagements heraus. Diese CVE fehlt im Katalog der „Known Exploited Vulnerabilities“ (KEV) der CISA, und in der „Stakeholder-Specific Vulnerability Categorization“ der CISA wird ihr Ausnutzungsstatus als „Proof of Concept“ vermerkt, während MITRE eine Kampagne, die sie ausnutzt, als C0045 ShadowRay erfasst. Unterdessen wurde eine andere, unumstrittene Ray-Sicherheitslücke, CVE-2025-62593, am 17.08.2026 in den KEV-Katalog aufgenommen, mit einem Fälligkeitsdatum am 20.08.2026, und ihr Fix ist Version 2.52.0: genau die Version, die in dem umstrittenen Eintrag als diejenige genannt wird, ab der die Token-Authentifizierung verfügbar wurde. Die Annahme, dass die Sicherheit durch die Bereitstellung gewährleistet ist, stellt keine Kontrollmaßnahme dar.

KEV ist hier der präziseste operative Filter. Stand 25.08.2026 umfasst der Katalog 1.675 Einträge, von denen zehn LLM-Stack-Komponenten sind: sechs Langflow-Einträge, zwei LiteLLM, ein Ray und ein MLflow. Keines der vier CVEs, die in diesem Zusammenhang üblicherweise genannt werden, ist darunter zu finden. Richten Sie Ihr Inventar lieber an der Orchestrierungsschicht aus als an den zwei oder drei Marken, die in der Berichterstattung immer wieder auftauchen.

Die Gefährdung auf dieser Ebene ist real, wird jedoch nur unzureichend gemessen, und in keinem der unten aufgeführten Scans wird die verwendete Methode angegeben. SecurityWeek bezifferte unter Berufung auf Cyera im Mai 2026 die Zahl auf „etwa 300.000 Ollama-Server, die derzeit im öffentlichen Internet exponiert sind“. Eine Analyse gestohlener KI-Rechenkapazitäten vom Juni 2026 berichtete von „rund 175.000 öffentlich zugänglichen Ollama-Instanzen in mehr als 130 Ländern“. In einem Scan-Fenster, dessen Autoren den Stand November 2024 angeben, fand Trend Micro „über 3.000 vollständig offene Server“ und für llama.cpp „80 exponierte Server, von denen 57 offenbar keinerlei Authentifizierung aufwiesen“. SecurityWeek berichtete im November 2025 über die „Ray“-Kampagne und zitierte die Zahlen eines anderen Unternehmens von „mehr als 230.000 Ray-Servern, auf die über das Web zugegriffen werden kann“. Der eigene Eintrag von NVD zu CVE-2026-7482 enthält keine Zahlen und besagt lediglich, dass eine „umfangreiche Exposition im öffentlichen Internet beobachtet wurde“. Betrachten Sie den Bereich, die Daten und die fehlenden Methoden als Ergebnis.

Die Validierung des Patches ist eine andere Aufgabe als dessen Installation – und genau hier kommt das AI-Red-Teaming ins Spiel. Behandeln Sie die Tabelle als verfallbar: CVE-Inhalte veralten schnell, der KEV-Katalog ändert sich wöchentlich, und es handelt sich hierbei eher um eine Stichprobe als um ein vollständiges Verzeichnis. Weisen Sie ihr einen namentlich genannten Verantwortlichen und ein festgelegtes Überprüfungsintervall zu.

Modellartefakte und die gemessenen Grenzen der Abtastung

Ein Modellartefakt ist ausführbarer Code in einem Daten-Wrapper. Das ist das gesamte Problem in einem Satz.

Der Mechanismus beruht auf einem Fehler in der Abfolge der Schritte. Ein Scanner wie „picklescan“ „überprüft zunächst Pickle-Dateien auf ihre Gültigkeit und führt, sofern sie gültig sind, eine Sicherheitsüberprüfung durch“, während die Pickle-Deserialisierung „wie ein Interpreter funktioniert und Opcodes beim Einlesen interpretiert“. Das Scannen erfolgt vor dem Laden. Die Ausführung erfolgt während des Ladens. Alles, was eine Datei für den Scanner ungültig, unbekannt oder fehlerhaft erscheinen lässt, während sie vom Framework dennoch geladen werden kann, schlüpft direkt durch diese Lücke.

‍

Diese Lücke ist nicht rein theoretischer Natur und wurde inzwischen auf drei verschiedene Weisen gemessen.

Im Februar 2025 wurden auf einer öffentlichen Modell-Plattform genau zwei bösartige Modelle entdeckt, bei denen eine Technik namens „nullifAI“ zum Einsatz kam, die den Scanner umging, indem das Artefakt mit 7z statt im ZIP-Format komprimiert wurde, das das Framework üblicherweise verwendet. Zwei – das sind nicht viele. Der Wert dieses Falls liegt im Mechanismus, nicht in der Menge.

Zwischen Februar und März 2025 wurden vier verschiedenen Scanner-Bypässen CVE-Kennungen zugewiesen. Die Abweichungen bei der Bewertung dieser Bypässe sind größer als bei allen im vorigen Abschnitt genannten Fällen.

CVE-IDCNA-Wert (CVSS 4.0) NVD-Primärwert (CVSS 3.1) Was wurde umgangen?CVE-2025-17165,3 MITTEL 9,8 KRITISCHpip wurde nicht als unsichere globale Variable behandelt, sodass ein Modell, das ein Paket darüber abrief, den Scan bestandCVE-2025-18895.3 MITTEL 9,8 KRITISCH Da nur standardmäßige Pickle-Dateiendungen berücksichtigt wurden, wurde eine nicht standardmäßige Endung nie überprüftCVE-2025-19445.3 MEDIUM6.5 MEDIUMA Ein modifizierter ZIP-Header führte zum Absturz des Scanners, während das Framework das Modell noch ludCVE-2025-19455.3 MITTEL 9,8 KRITISCH: Durch das Umkehren der ZIP-Flag-Bits wurde die Pickle-Datei vor dem Scanner verborgen, nicht jedoch vor dem Loader.

Bildunterschrift: Vier von CVE erfasste Umgehungsmöglichkeiten eines weit verbreiteten Modell-Scanners, die alle zwischen Februar und März 2025 veröffentlicht wurden, wobei bei drei der vier eine Differenz von 4,5 Punkten bei der Bewertung besteht. Keine davon ist zum Stand vom 25.08.2026 im KEV-Katalog enthalten. Alternativtext: Tabelle mit vier Sicherheitslücken zur Umgehung eines Scanner-Modells, in der die CNA-CVSS-4.0-Bewertung von 5,3 mit den NVD-Primär-CVSS-3.1-Bewertungen von 9,8, 9,8, 6,5 und 9,8 verglichen wird, jeweils mit Angabe der jeweiligen Umgehungstechnik.

Im Juli 2026 wurde dies in einem Preprint quantifiziert. ShadowPickle beschreibt drei heimliche Pickle-Deserialisierungsangriffe und berichtet, dass diese Angriffsfamilie „zehn SOTA-Scanner und vier Modell-Hubs umgeht“. Die Variante „Overwritten“ weist für sich genommen „eine Umgehungsrate von 63 % über alle Scanner hinweg auf und bis zu 50 % höhere Umgehungsraten als bestehende Angriffe“. Die Studie liefert weder Angaben zur Anzahl der Scanner noch zur Anzahl der Hubs, auf die sich diese 63 % beziehen. Es handelt sich um einen Preprint, der noch nicht begutachtet wurde, aus einer einzigen Quelle stammt und nicht unabhängig repliziert wurde; betrachten Sie die Zahl daher eher als Anlass zur Sorge denn als verlässliche Angabe. Entscheidend ist die Tendenz: Die Scan-Maßnahmen, auf die sich die meisten Teams verlassen, weisen eine veröffentlichte Umgehungsrate auf – und nicht nur eine angenommene.

Die Lieferkette ist zudem umfangreicher als die Modelldatei. In einer am 16.07.2026 veröffentlichten Sicherheitsmeldung des Modell-Hubs des Anbieters selbst wird festgehalten, dass der Vorfall nicht mit einem bösartigen Modell, sondern mit einem bösartigen Datensatz begann: „Ein bösartiger Datensatz nutzte zwei Codeausführungspfade in unserer Datensatzverarbeitung aus (einen Datensatz-Loader für Remote-Code und eine Template-Injection in einer Datensatzkonfiguration), um Code auf einem Verarbeitungs-Worker auszuführen.“ Von dort aus, so der Hub selbst, „erweiterte der Angreifer seine Zugriffsrechte auf Knotenebene, erbeutete Anmelde cloud en für Cluster und bewegte sich über das Wochenende hinweg lateral in mehrere interne Cluster hinein.“

Die hier geltenden Sicherheitsmaßnahmen sind wenig spektakulär. Bevorzugen Sie „Safetensors“ gegenüber „Pickle“ für jedes Format, das Sie kontrollieren, verlangen Sie einen Herkunftsnachweis für Artefakte, die Sie nicht kontrollieren, und laden Sie nicht vertrauenswürdige Modelle in einer Sandbox, die auf der Annahme basiert, dass das Laden gleichbedeutend mit der Ausführung ist.

Was eine LLM-Anwendung ausgibt und worauf ein SOC reagieren kann

Eine Leitplanke verrät dir, was sie aufgehalten hat. Fast nichts verrät dir, was sie übersehen hat.

Diese Asymmetrie stellt das Sichtbarkeitsproblem auf dieser Ebene dar, und vorab muss ein Vorbehalt angemerkt werden: Da es bislang noch kein maßgebliches öffentliches Verzeichnis zur Telemetrie von LLM-Anwendungen gibt, basiert die nachstehende Tabelle auf den Komponenten und nicht auf Beispielen aus der Praxis. Verwenden Sie sie als Anregung für die Architektur, nicht als Standard.

Ereignisausgebende Komponente – Warum sie sicherheitsrelevant ist – Was ihr Fehlen verbirgt – Protokoll der Eingabeaufforderung und der Vervollständigung – Anwendung oder Gateway – Die einzige Aufzeichnung dessen, was gefragt und was beantwortet wurde – Datenexfiltration über das Modell, und Missbrauch eines legitimen KontosGuardrail-Urteil und zugeordnete RegelGuardrailZeigt, was blockiert wurde und aufgrund welcher RegelAlles, was das Guardrail durchgelassen hatAbfrage und zurückgegebene Dokument-IdentifikatorenAbruf und VektorspeicherVerknüpft eine Antwort mit einem Quellkorpus und einem BerechtigungssatzOb ein Nutzer auf Dokumente zugegriffen hat, die er nicht sehen sollteAufruf eines Tools oder einer Funktion mit ArgumentenOrchestrierungsschichtDer Punkt, an dem generierter Text zur Aktion wirdBerechtigungsmissbrauch, und die Ausbreitungsreichweite einer erfolgreichen Injektion; Ereignis zum Laden eines Modellartefakts mit Hash und Quelle; Inferenzserver; stellt die Provenienz zum Zeitpunkt des Ladens fest; welches Artefakt tatsächlich ausgeführt wurde, und ob es das genehmigte war; Fehlerantworten des Inferenzservers; Inferenzserver: Fehlerantworten stellen eine Angriffsfläche dar und geben den internen Zustand preis; Aufklärung gegen die Servingschicht; Authentifizierungs- und Autorisierungsentscheidung am Endpunkt; Gateway oder Inferenzserver: Unterscheidet einen autorisierten Aufrufer von einem offenen Endpunkt; nicht authentifizierter Zugriff auf einen Modell-Upload- oder Job-Einreichungspfad; Token, Kosten- und Ratenanomalien: Gateway. Erkennt Ressourcenmissbrauch und Rechenleistungdiebstahl mithilfe gestohlener Anmeldedaten. Ungrenzte Nutzung und unauffällige kostenbasierte Angriffe

Bildunterschrift: Eine fundierte Aufstellung dessen, was eine LLM-Anwendung ausgeben kann, abgeleitet aus den Komponenten im Stack und nicht aus einer zitierten Norm, da es keine maßgebliche öffentliche Aufstellung gibt. Alternativtext: Tabelle mit acht Telemetrieereignissen von LLM-Anwendungen, in der die auslösende Komponente, die Sicherheitsrelevanz jedes Ereignisses und die Nachteile für das Sicherheitsteam aufgeführt sind, wenn das Ereignis nicht erfasst wird.

Die einzige verfügbare maßgebliche Richtlinie befasst sich mit dem Fall der agentischen KI. Das britische National Cyber Security Centre schreibt am 20.08.2026 zum Thema „Umgang mit dem Cyberrisiko agentischer KI“, dass „die Aktivitäten agentischer KI als eine Form der Benutzeraktivität behandelt werden sollten. Sie sollten daher in die rund um die Uhr stattfindende Sicherheitsüberwachung und die Reaktion auf Vorfälle einbezogen werden.“ Die Formulierung ist entscheidend: Diese Leitlinie bezieht sich auf die Sicherheitsüberwachung rund um die Uhr und verwendet an keiner Stelle weder den Begriff „LLM“ noch den Begriff „SOC“. Sie legt zudem fest, welche Daten während der Ausführung eines Agenten erfasst werden sollen, darunter „Chain-of-Thought“-Protokolle und Transkripte des Agenten sowie Protokollereignisse aus der übergeordneten Sandbox-Umgebung wie Zugriffsprotokolle, Proxy-Daten und Netzwerkverkehr, und schreibt vor, dass diese Protokolle vor Änderungen oder Löschungen geschützt werden müssen.

Dieser letzte Satz ist der Schlüssel zur Erkennung. Manipulationen an Leitplanken und Protokollen lassen sich zu T1685 Werkzeuge deaktivieren oder ändern, die unter „TA0112 Defense Impairment“ in „ MITRE ATT&CK “ aufgeführt ist und sich auf Angreifer bezieht, die „Sicherheitstools oder -anwendungen deaktivieren, beeinträchtigen oder manipulieren“, um „die Sichtbarkeit von Verteidigungsfähigkeiten zu beeinträchtigen oder zu verringern“. Es handelt sich um die einzige ATT&CK-Technik, die auf dieser Seite genannt wird.

Die Erkennung ist ein anerkannter Teilbereich dieses Fachgebiets, auch wenn sie in den meisten Praxisbeiträgen kaum Beachtung findet. Eine wissenschaftliche Studie aus dem Jahr 2025 zum Thema Sicherheit im LLM-Bereich unterteilt Abwehrmaßnahmen in „zwei Hauptkategorien: präventionsbasierte und erkennungsbasierte Abwehrmaßnahmen“ – genau die Achse, auf der jedes ausgereifte Sicherheitsprogramm bereits basiert.

Dieser Abschnitt beschränkt sich bewusst auf die von der Anwendung ausgegebenen Signale. Die SIEM-Integration, die Entwicklung von Erkennungsregeln und die SOC-Arbeitsabläufe für generative KI werden im Abschnitt „GenAI-Sicherheit“ behandelt, während die Anwendung von Analysen auf diese Signale im Abschnitt „KI-Bedrohungserkennung“ behandelt wird. Wenn die Anwendung selbst aktiv wird, anstatt nur zu antworten, lesen Sie bitte den Abschnitt „Sicherheit agentischer KI“.

Schutzmaßnahmen, Firewalls, Gateways und Scanner sowie die von ihnen genannten Zahlen

Definieren Sie diese Tools anhand ihrer Funktionen, da sich sowohl die Bezeichnungen der Anbieter-Kategorien als auch die Zuständigkeiten bei Open-Source-Projekten schneller ändern als die Funktionen selbst.

KategorieWas es überprüftWo es angesiedelt istWas es nicht kannGuardrailPrompt- und AntworttextInnerhalb der Anwendung, an der ModellgrenzeKann die darunterliegende Infrastruktur nicht einsehen und meldet nur, was es blockiert hatLLM-FirewallPrompt- und AntworttextInline im Netzwerk-Anforderungspfad, vor der AnwendungTeilt den blinden Fleck des Guardrails und bietet keine zusätzliche Transparenz bei prozessinternen AufrufenAI-GatewayAnfragen, Routing, Kontingente und AnmeldedatenZwischen der Anwendung und einem oder mehreren ModellanbieternPrüft keine Modellartefakte und testet kein ModellverhaltenModell-ScannerDas serialisierte Modellartefakt, bevor es geladen wirdIn der Build-Pipeline oder am Modell-HubVerfügt über eine gemessene Umgehungsrate und sieht zur Laufzeit nichtsRed-Team-HarnessModell- und Anwendungsverhalten unter adversarialen EingabenOffline oder in einer VorproduktionsumgebungLiefert eher Erkenntnisse als Kontrollen, und seine Bewertungen sind harnessspezifisch

Bildunterschrift: Die fünf Funktionskategorien von LLM-Sicherheitstools, definiert anhand dessen, was sie jeweils überprüfen und wo sie im Anforderungsweg angesiedelt sind, und nicht anhand der Bezeichnungen der Anbieter. Alternativtext: Tabelle zum Vergleich von Guardrail, LLM-Firewall, KI-Gateway, Modell-Scanner und Red-Team-Harness anhand der jeweiligen Prüfobjekte, ihrer Position im Anforderungspfad und ihrer wesentlichen Einschränkungen.

Um die häufig gestellte Frage direkt zu beantworten: Ein LLM-Guard ist eine Art Leitplanke – eine Kontrollmaßnahme, die Eingaben oder Antworten an der Anwendungsgrenze überprüft und diese blockiert, redigiert oder umschreibt. Es handelt sich dabei um Prävention, nicht um Erkennung, und die Maßnahme wirkt auf den Text, der die Grenze überschreitet, und nicht auf die zugrunde liegende Infrastruktur.

Der Begriff „LLM-Firewall“ sollte definiert, aber nicht weiter verfolgt werden. Es handelt sich um eine von Anbietern verwendete Bezeichnung für eine im Netzwerk positionierte Schutzbarriere, die eine echte Entscheidung hinsichtlich der Platzierung beschreibt: inline im Anforderungspfad statt innerhalb des Anwendungsprozesses.

Die Wahl zwischen den Kategorien ist eine Frage der Abdeckung, keine Frage der Rangfolge. Fragen Sie, welche Ebene ein Tool tatsächlich abdeckt, wo es im Anforderungspfad angesiedelt ist, was es bei einem Ausfall tut, ob es Telemetriedaten oder nur Bewertungen ausgibt und ob es die einzige Kontrollinstanz auf dieser Ebene ist. Ein „Guardrail“ und ein Modell-Scanner stehen nicht in Konkurrenz zueinander, da sie unterschiedliche Ebenen abdecken. KI-Red-Teaming-Tools ersetzen keines von beiden, sondern testen beide. Und nichts in dieser Tabelle verhindert prompt injection .

‍

So interpretieren Sie einen LLM-Sicherheits-Benchmark

Die Angriffserfolgsrate (ASR) ist der Anteil der Versuche, die ein Test-Harness bei einem Zielmodell als erfolgreich gewertet hat. Sie ist nur innerhalb des jeweiligen Test-Harness von Bedeutung und sonst so gut wie nirgendwo.

Drei Variablen beeinflussen diese Zahl unabhängig voneinander: der Aufgabensatz, das Bewertungsprotokoll und die Definition von Erfolg. Ändert man auch nur eine davon, verschiebt sich der Wert – weshalb zwei veröffentlichte Erfolgsraten von Angriffen selten vergleichbar sind, selbst wenn sie dieselbe Angriffsklasse beschreiben. Die StrongREJECT-Benchmark-Studie gibt die Richtung ausdrücklich vor und stellt fest, dass „es vielleicht eher die Regel als die Ausnahme ist, dass Jailbreak-Entwickler die Wirksamkeit ihrer Jailbreaks erheblich übertreiben“ und dass „bestehende Bewertungsmethoden die Wirksamkeit von Jailbreaks im Vergleich zu menschlichen Beurteilungen deutlich überbewerten“. Beachten Sie diese Richtung und beachten Sie, dass die Studie der Überbewertung keinen Prozentsatz zuordnet. Wer einen solchen angibt, zitiert etwas anderes.

Stellen Sie daher jedem Anbieter vier Fragen: Welches Testverfahren, welcher Bewerter, welche Aufgabenstellung und was galt als Erfolg? Wenn diese vier Antworten nicht vorliegen, handelt es sich bei der Zahl eher um ein Marketinginstrument als um eine Messgröße.

Übersicht über Rahmenbedingungen und Vorschriften, festgelegte Version

Die meisten Frameworks auf dieser Seite wurden in den letzten dreizehn Monaten aktualisiert, daher sind die Version und das Datum wichtiger als der Name.

2025 ID und Titel2026 ID und TitelMovementNoteLLM01:2025 Prompt-InjektionLLM01:2026 Prompt-InjektionUnverändertBelegte in beiden Ausgaben den ersten PlatzLLM02:2025 Offenlegung sensibler InformationenLLM02:2026 Offenlegung sensibler InformationenUnverändertBelegte in beiden Ausgaben den zweiten PlatzLLM03:2025 LieferketteLLM04:2026 LieferketteUm 1 Platz gefallenBezieht sich auf den obigen Abschnitt zu Modell-ArtefaktenLLM04:2025 Daten- und ModellvergiftungLLM05:2026 Daten- und ModellvergiftungUm 1 Platz gefallenNeunummeriert, sodass eine Kennung „2025“ nun irreführend istLLM05:2025 Unsachgemäße AusgabehandhabungLLM10:2026 Unsachgemäße AusgabehandhabungUm 5 Plätze gesunkenDie größte Einzelverschiebung in der ListeLLM06:2025 Übermäßige HandlungsautonomieLLM03:2026 Übermäßige HandlungsfähigkeitUm 3 nach obenVerfolgt den Trend hin zu agentenbasierten EinsatzszenarienLLM07:2025 System-Prompt-LeckageLLM08:2026 Offenlegung versteckter KontexteUm 1 nach unten, umbenannt und erweitertDer Geltungsbereich wurde von der System-Prompt allein auf den gesamten versteckten Kontext ausgeweitet, einschließlich abgerufener Richtlinientexte und der Schemata von Tools, die die Anwendung dem Modell offenlegtLLM08:2025 Schwachstellen bei Vektoren und Einbettungen LLM09:2026 Schwachstellen bei Vektoren und Einbettungen -1 Die Abruf- und Vektorspeicherebene LLM09:2025 Falschinformationen LLM07:2026 Falschinformationen +2 LLM10:2025 Unbegrenzter Verbrauch LLM06:2026 Unbegrenzter Verbrauch +4

Bildunterschrift: Zuordnungstabelle zwischen den OWASP Top 10 für LLM-Anwendungen der Jahre 2025 und 2026. Die Spalte „2026“ stammt aus dem kanonischen Repository, die Spalte „2025“ aus der Seite mit der abgelegten Liste und die Umbenennungen aus dem Bericht von Help Net Security; alle Informationen wurden am 25.08.2026 abgerufen. Alt-Text: Vergleichstabelle, die jede Kennung der OWASP LLM Top 10 von 2025 ihrer Kennung von 2026 zuordnet und zeigt, dass zwei Einträge unverändert geblieben sind und die anderen acht verschoben wurden, wobei einer dieser acht zudem umbenannt und erweitert wurde.

Zwei Einträge behalten ihre Position bei, während sich die anderen acht alle verschieben. Einer dieser acht wurde zudem umbenannt und erweitert: In der Berichterstattung von Help Net Security über die Veröffentlichung heißt es: „‚System Prompt Leakage‘ wurde umbenannt und zu ‚Hidden Context Exposure‘ erweitert.“ Es wurde nichts gestrichen und nichts ist völlig neu – was wichtig ist, wenn Sie die Kontrollen aus dem Jahr 2025 auf die Liste für 2026 übertragen. Die Ausgabe 2026 wurde am 04.08.2026 veröffentlicht und kombiniert die Einschätzung der Community mit Vorfalldaten: In derselben Berichterstattung heißt es, dass „die Abstimmung nach wie vor 75 % des Gewichts ausmachte, die verbleibenden 25 % jedoch durch Daten aus 6.639 realen Vorfällen beeinflusst wurden, die aus öffentlichen Schwachstellendatenbanken und einer KI-Schadensdatenbank stammen“. Die Liste wird hier nicht erneut aufgeführt. Beschreibungen der einzelnen Risiken gehören zum Thema GenAI-Sicherheit, und die Liste für 2026 ist in zusammengefasster Form auf der entsprechenden OWASP-Ressourcenseite verfügbar. Die Versionsabweichung ist real und nicht hypothetisch: Einundzwanzig Tage nach der Veröffentlichung enthielt die ältere Listenseite noch immer nur Identifikatoren aus dem Jahr 2025, weshalb in der Zuordnungstabelle jede Spalte auf ihre eigene Quelle verweist.

Framework-VersionStandWas entspricht dem auf dieser SeiteOWASP Top 10 für LLM-AnwendungenAusgabe 2026, veröffentlicht am 04.08.202625.08.2026Die oben abgebildete RisikotaxonomieMITRE ATT&CK Enterprise v19.2, 15 Taktiken 25.08.2026 Die Zuordnung einzelner Techniken im Abschnitt „Telemetrie“ MITRE ATLAS 2026.07: 1 Matrix, 16 Taktiken, 101 Techniken, 77 Untertechniken, 37 Abhilfemaßnahmen, 68 Fallstudien 25.08.2026 KI-spezifisches Angreiferverhalten und der unten aufgeführte Namenskonflikt NIST AI Risk Management Framework 1.0, veröffentlicht am 26.01.2023, in Überarbeitung 25.08.2026 Programm-Governance in den Bereichen „Govern“, Map, Measure und ManageNIST AI 100-2 E2025, endgültige Fassung, März 202525.08.2026Taxonomie und Terminologie des adversarischen maschinellen LernensEU-KI-GesetzVerordnung (EU) 2024/1689, konsolidiert am 27.07.2026, geändert durch die Verordnung (EU) 2026/1744 vom 25.08.2026 Transparenz und Verpflichtungen bei hohem Risiko sowie deren Anwendungsdaten ISO/IEC 42001 Grundtext von 2023, EN ISO/IEC 42001:2026 – europäische Übernahme 25.08.2026 Zertifizierung von KI-Managementsystemen, Daten ausschließlich aus Sekundärquellen

Bildunterschrift: Zuordnung der an bestimmte Versionen gebundenen Frameworks für diese Seite, überprüft am 25.08.2026. MITRE ATLAS veröffentlicht monatliche Versionsangaben; überprüfen Sie daher die Version erneut, bevor Sie sich auf die Elementanzahlen verlassen. Alternativtext: Tabelle, in der sieben Frameworks einer bestimmten Version und einem Verifizierungsdatum zugeordnet sind, mit einem Hinweis darauf, worauf sich die jeweilige Zuordnung in diesem Artikel bezieht.

Eine Falle beim Mapping sollte man kennen. MITRE ATT&CK Unternehmen Version 19.2 enthält genau 15 Taktiken, und keine davon trägt den Namen „Verteidigungsausweichen“: TA0005 heißt nun „Tarnung“ und TA0112 „Verteidigungsbeeinträchtigung“. MITRE ATLAS Veröffentlichung 2026.07 trägt nach wie vor eine Taktik mit dem Namen AML.0007 „Defense Evasion“, und das Angriffsreferenzfeld dieses ATLAS-Datensatzes verweist auf TA0005. Die beiden Frameworks sind formal miteinander verknüpft, weichen jedoch hinsichtlich der Bezeichnung desselben abgebildeten Konzepts voneinander ab; daher muss bei jeder Aussage zu „Defense Evasion“ angegeben werden, zu welchem Framework sie gehört.

Was die Regulierung betrifft, so galten die Transparenzpflichten gemäß Artikel 50 des EU-KI-Gesetzes ab dem 2. August 2026 und wurden nicht aufgeschoben. Mit der Verordnung (EU) 2026/1744 wurden die Verpflichtungen für Systeme mit hohem Risiko verschoben: Die Bestimmungen für Systeme mit hohem Risiko gemäß Anhang III gelten ab dem 2. Dezember 2027 und die gemäß Anhang I ab dem 2. August 2028. Gemäß dem konsolidierten Text müssen Anbieter von Systemen zur Erzeugung synthetischer Inhalte, die bereits auf dem Markt sind, bis zum 2. Dezember 2026 die Anforderungen von Artikel 50 Absatz 2 erfüllen, und die Artikel 102 bis 110 gelten ab dem 27. Juli 2026. Dies sind die Termine mit den größten Schwankungen auf dieser Seite; überprüfen Sie sie daher erneut anhand von EUR-Lex sowie mit den KI-Governance-Tools, die Sie zu ihrer Verfolgung verwenden.

Zwei weitere Anker sind für die Arbeit auf Programmebene von Bedeutung: das NIST-Rahmenwerk zum KI-Risikomanagement, das am 26.01.2023 veröffentlicht wurde und derzeit „im Rahmen des KI-Aktionsplans des Weißen Hauses überarbeitet wird“, sowie NIST AI 100-2 E2025, die im März 2025 fertiggestellte Taxonomie für adversarische Angriffe auf maschinelles Lernen und entsprechende Abhilfemaßnahmen. ISO/IEC 42001 ist die Managementsystemnorm für KI, und EN ISO/IEC 42001:2026 ist die aktuelle europäische Übernahme desselben Grundtextes, die eine zurückgezogene nationale Übernahme aus dem Jahr 2025 ersetzt. Die Veröffentlichungsdaten stammen hier aus sekundären Quellen, da die Seiten der Normungsorganisation nicht öffentlich abrufbar sind.

Moderne Ansätze zur Absicherung des LLM-Stacks

Die Budgetmittel fließen zunehmend in diesen Bereich. Der Bericht „State of Security 2026“ von Enterprise Technology Research, der auf einer Befragung von 517 auf Sicherheit spezialisierten Technologieführern basiert und ohne Angabe eines Erhebungszeitraums veröffentlicht wurde, ergab, dass „mehr als die Hälfte (59 %) der Unternehmen plant, die Ausgaben in dieser Kategorie zu erhöhen“, während „ein Fünftel (20 %) der Unternehmen angibt, keine agentenspezifischen Sicherheitskontrollen zu haben, und nur 3 % diese flächendeckend in Produktionsumgebungen eingesetzt haben.“

Die von den Leitern des OWASP-Projekts für die Ausgabe 2026 vorgestellte Design-These lautet: Begrenzung des Schadensumfangs statt perfekter Prävention. Wie Help Net Security in seiner Berichterstattung über die Veröffentlichung zitiert, beginnen sie mit den Worten: „Hört auf, ein Modell entwickeln zu wollen, das nicht ausgetrickst werden kann.“ In der Praxis lässt sich dies in drei Funktionen unterteilen: das Sicherheitsstatus-Management für die gesamte KI-Infrastruktur, das unter dem Begriff „AI Security Posture Management“ zusammengefasst wird; die Erkennung während der Laufzeit auf der Serverschicht; sowie die Rückverfolgbarkeit des Modellartefakts. Das umfassendere Programm ist in den Leitlinien des NCSC für die sichere Entwicklung von KI-Systemen festgelegt und erstreckt sich über sicheres Design, sichere Entwicklung, sichere Bereitstellung sowie sicheren Betrieb und Wartung. Die zukunftsorientierte Arbeit ist enger gefasst: Es geht darum, dieselbe Disziplin bei der Bestandserfassung und beim Patchen auf Orchestrierungskomponenten anzuwenden, für die es derzeit keinen Sicherheitsverantwortlichen gibt.

Wie „ Vectra AI “ die Sicherheit von LLMs betrachtet

Vectra AI geht von der Prämisse aus, dass das moderne Netzwerk eine einzige Angriffsfläche darstellt und der LLM-Serving-Stack nun Teil davon ist. Der „Assume-Compromise“-Ansatz gilt hier genauso wie für Identitäten, „ cloud “ und die lokale Infrastruktur. Prävention an der Eingabegrenze ist notwendig, reicht aber nicht aus. Operativ entscheidend sind die Beobachtbarkeit des KI-Infrastruktursegments, ein Signal, das echtes Angreiferverhalten von Modellrauschen unterscheidet, sowie die Fähigkeit, auf dieses Signal zu reagieren. Das ist die Methodik hinter „ Attack Signal Intelligence “, angewandt auf ein Segment, das die meisten Unternehmen noch nicht erfasst haben – und genau dorthin entwickeln sich KI-Sicherheitsprogramme als Nächstes.

LLM-Sicherheit ist eine Stack-Disziplin. Erfassen Sie die Ebenen, für die Sie verantwortlich sind, patchen Sie die Komponenten mit CVE-Kennungen und KEV-Fristen, überwachen Sie die von Ihren Anwendungen ausgegebenen Daten und ordnen Sie jede Herstellernummer dem System zu, aus dem sie stammt. Das Modell ist der Teil, über den alle schreiben. Der darunterliegende Stack ist der Teil, den Sie beheben können.

‍