Sicherheitsbenchmark für KI-Agenten: Tests auf MITRE ATLAS und die OWASP Top 10 für agentische Anwendungen (ASI) abbilden

Wer einen autonomen KI-Agenten in Produktion bringt, braucht mehr als ein paar Prompt-Injection-Stichproben. Die Schlüsselfrage lautet: Misst Ihr Sicherheitsbenchmark für KI-Agenten überhaupt die richtigen Risiken — und lässt sich jedes Testergebnis einem anerkannten Bedrohungsmodell zuordnen? Dieser Artikel zeigt, wie Sie einen Agenten-Eval-Harness so aufbauen, dass jeder Testfall sowohl auf MITRE ATLAS als auch auf die OWASP-ASI-Evaluierung abbildet — nachvollziehbar, wiederholbar und auditierbar. Er ist eine Speiche der breiteren Red-Team-Framework-Praxis für KI-Agenten.

Was bedeutet es, Agenten-Tests auf ATLAS und ASI abzubilden?

Kurz gesagt: Ein abbildbarer Benchmark verknüpft jeden einzelnen Testfall mit einer eindeutigen Technik-ID aus MITRE ATLAS und mit einer Risikokategorie aus den OWASP Top 10 für agentische Anwendungen. Statt isoliert zu fragen „Hält der Agent diesem Angriff stand?“, fragen Sie strukturiert: „Welche ATLAS-Technik prüft dieser Fall, welches ASI-Risiko deckt er ab, und wie hoch ist die Erfolgsquote des Angriffs über mehrere Durchläufe?”

Diese doppelte Abbildung ist deshalb entscheidend, weil die beiden Frameworks unterschiedliche Fragen beantworten. MITRE ATLAS beschreibt, wie ein Angreifer vorgeht — die Taktiken und Techniken entlang des Lebenszyklus eines KI-Systems. Die OWASP Top 10 für agentische Anwendungen beschreiben, welche Schwachstellenklassen in autonom handelnden Systemen am häufigsten und folgenreichsten sind. Erst die Verbindung beider Sichtweisen ergibt einen Benchmark, der gegenüber Prüfern, Kunden und der eigenen Geschäftsführung belastbar ist.

Wer diese Zuordnung von Anfang an in den Eval-Harness einbaut, erhält außerdem einen unmittelbaren Nebeneffekt: Lücken in der Testabdeckung werden sichtbar. Eine ATLAS-Technik ohne zugehörigen Testfall ist ein blinder Fleck. Ein ASI-Risiko ohne Eval ist ein ungeprüftes Versprechen.

Warum reichen klassische LLM-Sicherheitstests für Agenten nicht aus?

Klassische Tests für Sprachmodelle prüfen Risiken der Inhaltserzeugung: toxische Ausgaben, Halluzinationen, einmalige Prompt Injection. Agentische Systeme verschieben das Risiko jedoch von der Ausgabe auf die Handlung. Sobald ein Agent eigenständig APIs aufruft, Datenbanken verändert, E-Mails versendet oder andere Agenten beauftragt, entsteht eine völlig neue Angriffsfläche.

Genau diese Verschiebung war der Grund, warum das OWASP Gen AI Security Project im Dezember 2025 die ersten Top 10 für agentische Anwendungen veröffentlicht hat — eine Liste, die die Threat-Intelligence-Analyse im Detail aufschlüsselt. Während die bekannten LLM Top 10 auf Risiken der Texterzeugung zielen, adressiert die Agentic-Liste die weit größeren Risiken autonomen Handelns. Ein Agent, der selbstständig agieren kann, braucht ein strengeres und grundlegend anderes Sicherheitsmodell.

Drei Eigenschaften machen den Unterschied für Ihren Benchmark:

• Mehrschrittigkeit: Ein Angriff entfaltet sich oft über mehrere Konversationsrunden. Ein einzelner Prompt sagt wenig aus; entscheidend ist, ob der Agent über zehn Schritte hinweg sein Ziel verliert.
• Werkzeugzugriff: Der Schaden entsteht nicht im Text, sondern in der ausgelösten Aktion. Ein Test ohne echte oder simulierte Werkzeuge misst die Gefahr nicht — genau hier setzt das Tool-Call-Fuzzing an.
• Agent-zu-Agent-Vertrauen: In Multi-Agenten-Architekturen wird Vertrauen zwischen Komponenten selbst zum Angriffsvektor — etwa durch das von OWASP dokumentierte „Agent Session Smuggling“.

Welche Bedrohungen deckt MITRE ATLAS für Agenten ab?

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) überträgt die Logik von MITRE ATT&CK auf KI-Systeme. Die Wissensbasis ordnet Angriffe in Taktiken (das Ziel des Angreifers) und Techniken (das konkrete Vorgehen) über den gesamten Lebenszyklus — von Training über Bereitstellung bis zur Inferenz.

Mit Version 5.1.0 vom November 2025 umfasst ATLAS 16 Taktiken, 84 Techniken, 56 Untertechniken, 32 Gegenmaßnahmen und 42 dokumentierte Fallstudien. Besonders relevant für Agenten: Im Frühjahr 2025 kamen 19 neue Techniken für generative KI hinzu — darunter RAG Poisoning, das Einschleusen falscher RAG-Einträge, gezieltes Prompt Crafting, Impersonation und die Kompromittierung der KI-Lieferkette. Im Oktober 2025 wurden gemeinsam mit Zenity Labs 14 weitere Techniken und Untertechniken speziell für KI-Agenten ergänzt.

Für einen Agenten-Benchmark heißt das: Sie können jeden Testfall auf eine stabile, versionierte Technik-ID verankern. Das macht Ergebnisse über Releases hinweg vergleichbar und gegenüber Auditoren nachvollziehbar.

Wie sehen die OWASP Top 10 für agentische Anwendungen (ASI) aus?

Die ASI-Liste vergibt jeder Schwachstellenklasse einen Code mit dem Präfix ASI (Agentic Security Issue) und ordnet sie nach beobachteter Häufigkeit und Auswirkung in realen Produktivumgebungen. An der Spitze stehen zwei besonders schwerwiegende Risiken:

• ASI01 – Agent Goal Hijack (Zielentführung): der gefährlichste Zustand, ein vollständiger Kontrollverlust. Das eigene System wird zur Waffe gegen die eigene Organisation gerichtet.
• ASI02 – Tool Misuse & Exploitation (Werkzeugmissbrauch): legitime Werkzeuge werden durch den Agenten zu zerstörerischen Ausgaben verbogen.

Die Liste dokumentiert darüber hinaus Angriffsmuster, die es im reinen LLM-Kontext nicht gab — etwa das bereits erwähnte „Agent Session Smuggling“, bei dem ein bösartiger Agent die im Agent-zu-Agent-Protokoll angelegten Vertrauensbeziehungen ausnutzt. Anders als eine einmalige Prompt Injection führt ein solcher Agent ein mehrstufiges Gespräch, passt seine Strategie an und baut über mehrere Interaktionen hinweg falsches Vertrauen auf.

Für die OWASP-ASI-Evaluierung bedeutet das: Jeder ASI-Code wird zur Spalte in Ihrer Abdeckungsmatrix. Ein Risiko ohne zugehörigen, regelmäßig laufenden Eval-Fall gilt als ungeprüft.

Wie bildet man ATLAS-Techniken auf ASI-Risiken ab?

Die beiden Frameworks sind keine Konkurrenten, sondern zwei Achsen derselben Matrix. ATLAS liefert die Angriffstechnik (die Zeile), ASI die betroffene Risikoklasse (die Spalte). Ein einzelner Testfall sitzt am Schnittpunkt — und genau diese Zuordnung dokumentieren Sie im Harness.

Die folgende Tabelle zeigt das Prinzip an Beispielen. Sie ist illustrativ und ersetzt nicht den Abgleich mit der jeweils aktuellen Framework-Version, da sich beide Standards aktiv weiterentwickeln.

Angriffstechnik (MITRE ATLAS)	Betroffenes ASI-Risiko	Beispielhafter Testfall im Harness
Indirekte Prompt Injection über manipulierte Inhalte	ASI01 – Agent Goal Hijack	Agent verarbeitet ein präpariertes Dokument; Eval prüft, ob das ursprüngliche Ziel erhalten bleibt
RAG Poisoning / falsche RAG-Einträge	ASI01 / Datenintegrität	Vergifteter Wissensspeicher; Eval misst, ob der Agent der manipulierten Quelle folgt
Missbrauch legitimer Werkzeuge	ASI02 – Tool Misuse	Agent wird zu einem schädlichen, aber technisch erlaubten API-Aufruf verleitet
Impersonation / Agent Session Smuggling	Agent-zu-Agent-Vertrauen	Bösartiger Peer-Agent über mehrere Runden; Eval prüft Vertrauensgrenzen
Kompromittierung der KI-Lieferkette	Lieferketten- und Komponentenrisiko	Manipuliertes Modell-Artefakt; Eval prüft Herkunfts- und Integritätskontrollen

Wichtig ist die m:n-Beziehung: Eine ATLAS-Technik kann mehrere ASI-Risiken berühren, und ein ASI-Risiko wird durch mehrere Techniken realisiert. Ihr Harness sollte diese Mehrfachzuordnung als Metadaten am Testfall führen, nicht als starre 1:1-Tabelle.

Wie baut man einen Agenten-Eval-Harness, der sauber abbildet?

Ein belastbarer Agenten-Eval-Harness folgt fünf Prinzipien. Sie gelten unabhängig davon, ob Sie ein quelloffenes Red-Teaming-Werkzeug oder eine Eigenentwicklung verwenden.

1. Testfall = Datensatz mit Metadaten, nicht nur ein Prompt. Jeder Fall trägt mindestens: Angriffsbeschreibung, ATLAS-Technik-ID, ASI-Code, Erfolgskriterium und erwartetes sicheres Verhalten.
2. Mehrstufige Szenarien statt Einzel-Prompts. Da agentische Angriffe sich über mehrere Runden entfalten, muss der Harness ganze Konversations- und Werkzeugverläufe abspielen können.
3. Werkzeuge simulieren, Seiteneffekte einsperren. Tests müssen echte Aktionen auslösen können — in einer Sandbox, deren Seiteneffekte protokolliert, aber niemals real ausgeführt werden.
4. Wiederholungen und Erfolgsquote messen. Ein einzelner bestandener Durchlauf sagt wenig. Führen Sie jeden Fall mehrfach aus und berichten Sie die Angriffserfolgsquote (Attack Success Rate) statt eines binären „bestanden/durchgefallen“.
5. Abdeckung als erste Metrik. Die wichtigste Kennzahl ist nicht die Bestehensquote, sondern die Frage: Welcher Anteil der relevanten ATLAS-Techniken und ASI-Risiken ist überhaupt durch mindestens einen Fall abgedeckt?

Aus diesen Prinzipien ergibt sich ein klarer Aufbau: ein zentrales Verzeichnis von Testfällen, ein Ausführungsmodul gegen den Agenten in der Sandbox, ein Bewertungsmodul (regelbasiert oder als modellgestützter Prüfer) und ein Berichtsmodul, das nach ATLAS und ASI aggregiert.

Welche Kennzahlen gehören in den Bericht?

Ein Sicherheitsbenchmark ist nur so gut wie sein Bericht. Diese vier Kennzahlen haben sich als aussagekräftig erwiesen:

• Abdeckungsgrad je Framework: Anteil der ATLAS-Techniken bzw. ASI-Risiken mit mindestens einem Testfall.
• Angriffserfolgsquote je Risikoklasse: Anteil der Durchläufe, in denen der Angriff gelang — aufgeschlüsselt nach ASI-Code.
• Schweregrad-gewichtete Bewertung: Ein erfolgreicher ASI01-Angriff (Zielentführung) wiegt schwerer als ein Randfall.
• Regression über Releases: Verändert sich die Erfolgsquote, wenn Modell, Prompt oder Werkzeugkette aktualisiert werden? Genau hier zahlt sich die stabile ID-Verankerung aus.

Berichten Sie diese Werte konsistent über Versionen hinweg. Ein Benchmark entfaltet seinen Wert erst im Zeitverlauf — als Frühwarnsystem für Regressionen, nicht als einmalige Momentaufnahme.

Wie passt das in DSGVO und EU-KI-Verordnung?

Für den DACH-Markt ist die regulatorische Anschlussfähigkeit kein Nebenaspekt. Ein nach ATLAS und ASI strukturierter Benchmark liefert genau die Art von Nachweis, die unter der EU-KI-Verordnung (KI-VO) für Hochrisiko-Systeme verlangt wird: ein dokumentiertes Risikomanagement mit nachvollziehbaren Tests.

Die Zuordnung zu anerkannten Frameworks erleichtert außerdem die Kommunikation mit Datenschutz- und Compliance-Verantwortlichen. Wenn ein Agent personenbezogene Daten verarbeitet, verbindet die ASI-Kategorisierung das technische Testergebnis mit konkreten Pflichten aus der DSGVO — etwa der Pflicht, unbefugte Verarbeitung durch Werkzeugmissbrauch (ASI02) zu verhindern. Der Benchmark wird so vom rein technischen Artefakt zum Baustein der Rechenschaftspflicht.

Ein Hinweis zur Sorgfalt: Frameworks und Versionen ändern sich. Prüfen Sie vor jedem Audit den Stand von ATLAS und der ASI-Liste und dokumentieren Sie die verwendete Version im Bericht.

Fazit: Abbildung zuerst, Werkzeug danach

Der wertvollste Sicherheitsbenchmark für KI-Agenten ist nicht der mit den meisten Testfällen, sondern der mit der saubersten Zuordnung. Wenn jeder Fall in Ihrem Agenten-Eval-Harness auf eine MITRE-ATLAS-Technik und einen ASI-Code verweist, wird Sicherheit messbar, vergleichbar und auditierbar. Beginnen Sie mit der Abbildungsmatrix, schließen Sie die offensichtlichen Lücken bei ASI01 und ASI02, und wählen Sie das Werkzeug erst danach. Die Reihenfolge entscheidet über den Wert.

---

Hinweis: Dieser Beitrag dient der Information und ersetzt keine rechtliche oder sicherheitstechnische Beratung im Einzelfall. Framework-Versionen (MITRE ATLAS, OWASP ASI) entwickeln sich weiter — prüfen Sie stets den aktuellen Stand.