Sechs KI-Sicherheitsframeworks: Welches Sie brauchen

Es gibt mehr KI-Sicherheitsframeworks, als ein einzelnes Team sinnvoll einführen kann. Viele Teams scheitern daran, weil diese Rahmenwerke so verglichen werden, als seien sie austauschbare Alternativen. Einige zählen konkrete Risiken auf, andere beschreiben eine Methode, um Risiken systematisch zu identifizieren, und wieder andere regeln, wie eine Organisation das gesamte Thema steuert. Die entscheidende Wahl liegt zwischen diesen Kategorien. Die Auswahl innerhalb einer Kategorie ist meist Geschmackssache.

Dieser Beitrag versteht sich als Landkarte, nicht als bloßer Katalog: Für jedes Framework wird geklärt, welche Frage es beantwortet, für wen es gedacht ist und wann Sie danach greifen sollten.

Das Problem

Ein Plattformverantwortlicher erhält die Vorgabe, sich vor dem Produktivstart eines internen KI-Assistenten an einem Framework zu orientieren. Die Recherche liefert OWASP-Listen, ein NIST-Rahmenwerk, eine CSA-Methodik, eine MITRE-Wissensdatenbank und eine Handvoll neuerer Entwürfe. Er wählt NIST, weil es am offiziellsten klingt, verbringt sechs Wochen damit, organisatorische Funktionen zu dokumentieren, und bringt ein System in Produktion, das weiterhin mit einem gemeinsamen Service-Account und ohne Egress-Beschränkungen läuft.

An dieser Arbeit war nichts grundlegend falsch. Sie beantwortete lediglich eine Frage, die niemand gestellt hatte. Das NIST AI RMF beschreibt, wie eine Organisation KI-Risiken steuert; es warnt Sie jedoch nicht davor, dass die Berechtigungen Ihres Agenten viel zu weit gefasst sind.

Warum es bei KI anders ist

Diese Kategorien existieren auch in der klassischen IT-Sicherheit. Der Unterschied liegt darin, wie neu die meisten dieser Rahmenwerke sind, wie rasch sie überarbeitet werden und mit welcher Selbstsicherheit Dokumente zitiert werden, die sich bei genauer Prüfung als nicht existent erweisen.

Bei der Quellenprüfung für diese Beitragsreihe tauchten drei neuere Frameworks auf einer Konferenzfolie auf. Zwei davon besitzen fundierte Primärquellen. Das dritte, aufgeführt unter dem Namen SAILORS, ließ sich nirgends auffinden: kein Paper, keine Projektseite, keine Publikation unter diesem Namen in diesem Fachgebiet. Möglicherweise handelte es sich um einen Hörfehler oder ein internes Tool. In jedem Fall lässt es sich nicht implementieren, und es ist ehrlicher, dies klar zu benennen, statt den Namen ungeprüft weiterzutragen, nur weil er neben realen Standards stand. Wenn ein Framework kein lesbares Dokument besitzt, kann es keine verlässliche Grundlage sein.

Diese Recherche lieferte eine weitere zentrale Erkenntnis: Nennen Sie immer die genaue Ausgabe. Die OWASP LLM Top 10 hat in ihrer Version 2026 Einträge neu sortiert, sodass eine Sicherheitsmaßnahme, die auf eine Kennung aus einer früheren Version verweist, heute möglicherweise ein völlig anderes Risiko adressiert [1].

Die sechs Frameworks nach Kategorien

Risikolisten: Was schiefgehen kann

OWASP Top 10 for LLM Applications 2026 [1] umfasst zehn Risiken in Systemen, die Sprachmodelle nutzen, von Prompt Injection unter LLM01 bis hin zu fehlerhafter Ausgabeverarbeitung unter LLM10. Die Liste erschien am 3. August 2026. Starten Sie hier, wenn Sie Anwendungen entwickeln oder betreiben, die ein Modell einbinden; die Kriterien sind konkret genug, um ein System an einem einzigen Nachmittag dagegen abzugleichen.

OWASP Top 10 for Agentic Applications 2026 [2], veröffentlicht am 9. Dezember 2025, listet jene Risiken auf, die entstehen, sobald Modelle eigenständig handeln können: Goal Hijacking, Tool-Missbrauch, Identitäts- und Rechte-Missbrauch, Memory Poisoning und unkontrollierte Agenten. Sie ergänzt die LLM-Liste sinnvoll, statt sie zu ersetzen. Führen Sie diese Liste ein, sobald Ihre Systeme Zugangsdaten besitzen und Aktionen anstoßen.

MITRE ATLAS [3] ist eine Wissensdatenbank für Taktiken und Techniken von Angreifern gegen KI-Systeme, strukturiert nach dem Vorbild von ATT&CK. Es ist keine Checkliste. Red Teams und Detection Engineers profitieren am stärksten davon, weil sie Angriffe in einer Terminologie beschreiben können, die Kollegen aus der IT-Sicherheit bereits verstehen.

Methodiken: Wie Sie Risiken systematisch finden

MAESTRO [4] ist ein Threat-Modeling-Framework der Cloud Security Alliance, das agentische Systeme in sieben Schichten unterteilt, von Basismodellen bis zum Agenten-Ökosystem, und Bedrohungen innerhalb und zwischen diesen Schichten analysiert. Der praktische Wert liegt in den klaren Grenzen: Es legt explizit fest, welche Schichten in Ihrer Verantwortung liegen und welche einem Mandanten oder dem Modellanbieter gehören. Dadurch wird die Frage "Sind wir sicher?" zu einer Aufgabe mit eindeutiger Zuständigkeit.

PHANTOM-B [5] ist eine Gedankenstütze in der STRIDE-Tradition, die von Shostack + Associates speziell für LLM-Komponenten entwickelt und auf der Black Hat USA 2026 vorgestellt wurde. Sie ist so konzipiert, dass sie in unter einer Stunde angewendet werden kann und STRIDE sinnvoll ergänzt, statt bestehende Prozesse zu verwerfen. Nutzen Sie PHANTOM-B, wenn Sie bereits Bedrohungsmodellierung betreiben und die LLM-Komponenten abdecken möchten, ohne einen komplett neuen Ablauf einzuführen.

Governance: Wie die Organisation das Thema steuert

NIST AI Risk Management Framework [6] beschreibt organisatorische Funktionen zur Steuerung, Erfassung, Messung und Bewältigung von KI-Risiken. Es ist die richtige Wahl, wenn Ihr Impuls von Wirtschaftsprüfern, dem Vorstand oder regulatorischen Vorgaben ausgeht, und die falsche Wahl, wenn Ihr Assistent am kommenden Freitag produktiv gehen soll.

Zudem existiert ein akademisches Papier zu STRIDE-AI (Cyrille und Schwarz, arXiv-Preprint, Mai 2026), das sich explizit als Brücke zwischen Governance-Ebene und technischen Taxonomien versteht [7]. Ein Blick lohnt sich, falls genau diese Lücke Ihr Problem darstellt. Beachten Sie, dass es sich um einen Preprint handelt und ein älteres Paper aus dem Jahr 2021 denselben Namen trägt.

Was in der Praxis funktioniert

Wählen Sie genau ein Framework aus jeder Kategorie, die Sie tatsächlich benötigen, und lassen Sie die übrigen Kategorien vorerst beiseite. Die meisten Infrastrukturteams brauchen in diesem Quartal eine Risikoliste und sonst nichts; Governance-Rahmenwerke rechtfertigen ihren Aufwand erst, wenn externe Parteien danach verlangen.

Nutzen Sie vorhandene Querverweise, statt eigene Zuordnungen von Hand zu erstellen. Die Publikationen verweisen bewusst aufeinander, und diese Mappings in einer Tabelle nachzubauen, erzeugt doppelten Pflegeaufwand, der bei der nächsten Version veraltet ist.

Dokumentieren Sie die genaue Versionsausgabe bei jeder erfassten Maßnahme. Der Vermerk "Mildert LLM03 ab" hat ein kurzes Verfallsdatum. Der Vermerk "Mildert LLM03:2026 Excessive Agency ab" übersteht auch spätere Revisionen oder fällt bei Widersprüchen zumindest sofort auf.

Lassen Sie die Methodik der Risikoliste folgen. Eine Risikoliste zeigt Ihnen, wonach Sie suchen müssen. Wenn sie nicht mehr ausreicht, meist sobald Systeme selbstständig handeln und interagieren, zeigt Ihnen eine Methodik, wie Sie suchen. Wer zuerst zur Methodik greift, riskiert genau jene sechs verlorenen Wochen.

Was nicht funktioniert

Das am offiziellsten klingende Rahmenwerk zu wählen, führt in die Irre, da formale Autorität die falsche Dimension ist; entscheidend ist die funktionale Kategorie.

Ein Framework als Qualitätsbeweis misszuverstehen, schlägt ebenfalls fehl. Die Aussage, einem Framework zu folgen, beschreibt lediglich Ihren internen Prozess, beweist aber keine Sicherheit. Kein Framework auf dieser Seite stellt Zertifikate aus, und keiner der Herausgeber bietet eine offizielle Zertifizierung an.

Alles mit allem abzugleichen, erzeugt ein unübersichtliches Kreuz-Mapping über vier Frameworks hinweg, ein Dokument, das niemand liest, aber jeder pflegen muss.

Ein Framework zu zitieren, das man nicht gelesen hat, ist die letzte typische Falle. Der Fall SAILORS ist die harmlose Variante; die schädliche Variante besteht darin, Sicherheitsmaßnahmen einer Kennung zuzuordnen, deren Bedeutung sich zwischen zwei Ausgaben verschoben hat.

Wo Sie anfangen sollten

• Wenn Sie mit Modellen entwickeln, nutzen Sie die OWASP LLM Top 10 2026 und prüfen Sie noch diese Woche ein konkretes System dagegen.
• Wenn diese Systeme eigenständig Aktionen ausführen, ergänzen Sie die Agentic Top 10 2026.
• Wenn Sie klären müssen, wer für welche Schicht zuständig ist, nutzen Sie MAESTRO, insbesondere wenn Mandanten oder externe Anbieter Teile des Stacks betreiben.
• Wenn ein Audit der Auslöser Ihrer Recherche ist, greifen Sie zum NIST AI RMF und planen Sie ausreichend Vorlaufzeit ein.
• Wenn Sie bereits Bedrohungsanalysen durchführen, binden Sie PHANTOM-B für die LLM-Komponenten ein, statt neue Prozesse aufzusetzen.
• Welches Framework Sie auch wählen: Dokumentieren Sie die Version und das Prüfdatum. Alle genannten Standards werden fortlaufend überarbeitet, und gerade jene mit kurzen Revisionszyklen verlangen präzise Zitate.

Quellen

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, veröffentlicht am 3. August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, veröffentlicht am 9. Dezember 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
3. MITRE ATLAS: https://atlas.mitre.org/
4. Agentic AI Threat Modeling Framework: MAESTRO, Cloud Security Alliance, Februar 2025: https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
5. PHANTOM-B, Shostack + Associates Whitepaper #6, Juli 2026: https://shostack.org/files/papers/PHANTOM-B_Whitepaper_Shostack.pdf
6. NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
7. STRIDE-AI: A Threat Modeling Framework for Generative AI Security Assessment, Cyrille und Schwarz, arXiv-Preprint, Mai 2026: https://arxiv.org/abs/2605.17163