MITRE ATLAS für KI-Agenten: Taktiken, Techniken und die Erkennungssignale jeder Angriffsphase

Wer KI-Agenten in Produktion betreibt, steht vor einem Zuordnungsproblem: Klassische SIEM-Regeln kennen Prozesse, Netzwerkverbindungen und Anmeldungen — aber nicht das Verhalten eines Modells, das auf eine vergiftete Eingabe reagiert. MITRE ATLAS schließt genau diese Lücke. Dieser Beitrag ist die erkennungsseitige Ergänzung zu unserem Überblick über die Bedrohungslandschaft für KI-Agenten 2026. Dieser Beitrag zeigt, wie Sie reale Angriffe auf agentische KI den ATLAS-Taktiken zuordnen und welches Erkennungssignal jede Phase in Ihrer Telemetrie erzeugt.

Wie ordnet man Angriffe auf KI-Agenten dem MITRE-ATLAS-Modell zu?

Die Zuordnung von Agenten-Angriffen zu MITRE ATLAS folgt derselben Logik wie ATT&CK für klassische IT: Sie ordnen jede beobachtete Handlung einer Taktik (dem Ziel des Angreifers) und einer Technik (dem konkreten Vorgehen) zu. ATLAS — die Abkürzung steht für Adversarial Threat Landscape for Artificial-Intelligence Systems — bildet den gesamten Lebenszyklus eines KI-Systems ab, von der Aufklärung über die Manipulation von Trainingsdaten und Modellen bis zur Auswirkung auf den Geschäftsbetrieb.

In der Praxis bedeutet das: Sie nehmen einen Vorfall, zerlegen ihn in einzelne Schritte und tragen jeden Schritt in die ATLAS-Matrix ein. Ein vergifteter Wissensspeicher landet unter Poison Training Data, eine manipulierte Anweisung in einem abgerufenen Dokument unter Prompt Injection, das Absaugen von Modellantworten unter Exfiltration via ML Inference API. Der Wert dieser Zuordnung liegt nicht in der Taxonomie selbst, sondern in den Erkennungssignalen, die jede Technik hinterlässt — denn erst sie machen aus einer Klassifikation eine Detektion.

Mit Stand der Version 5.4.0 (Februar 2026) umfasst ATLAS 16 Taktiken, 84 Techniken, 56 Untertechniken sowie Dutzende von Gegenmaßnahmen und Fallstudien. Im Oktober 2025 ergänzte MITRE in Zusammenarbeit mit Zenity Labs 14 Techniken, die sich gezielt auf KI-Agenten und generative Systeme beziehen — ein deutliches Zeichen, dass agentische Architekturen inzwischen ein eigenständiges Angriffsfeld bilden. Diese Zahlen ändern sich zwischen den Releases; verbindlich ist stets atlas.mitre.org.

Was unterscheidet ATLAS von ATT&CK — und warum reicht ATT&CK allein nicht?

ATT&CK beschreibt, wie Angreifer Netzwerke und Endpunkte kompromittieren. ATLAS ist bewusst nach demselben Muster aufgebaut und gilt deshalb vielen als das ATT&CK für KI. Doch die entscheidenden Angriffsflächen eines KI-Agenten existieren in ATT&CK schlicht nicht: ein Modell, das durch sorgfältig gewählte Eingaben getäuscht wird, ein Vektorspeicher, dessen Inhalte zur Laufzeit zur Anweisung werden, oder eine Inferenz-Schnittstelle, über die ein Angreifer das zugrunde liegende Modell rekonstruiert.

Diese Angriffsklassen fasst die Forschung als adversariale ML-Taktiken zusammen. Das NIST gliedert sie in vier Kategorien — Umgehung (evasion), Vergiftung (poisoning), Vertraulichkeitsangriffe (privacy) und Missbrauch (abuse). ATLAS übersetzt diese akademischen Kategorien in operativ verwertbare Taktiken und Techniken, die ein SOC-Team tatsächlich verfolgen kann.

Wichtig ist die Reihenfolge: Wer bereits ein ATT&CK-gestütztes Erkennungsprogramm betreibt, erweitert es um ATLAS — er ersetzt es nicht. Ein realistischer Angriff auf einen produktiven Agenten kombiniert beide Welten. Der Erstzugang erfolgt oft klassisch (gestohlene API-Schlüssel, ATT&CK), die eigentliche Manipulation des Modells dagegen rein ATLAS-spezifisch.

Welche Erkennungssignale erzeugt jede ATLAS-Phase?

Der praktische Kern jeder Zuordnung ist die Frage: Wo sehe ich das? Die folgende Tabelle ordnet die zentralen Taktiken den typischen agentenbezogenen Techniken und den Erkennungssignalen zu, die sie in Telemetrie und Logs hinterlassen.

ATLAS-Taktik	Typische Technik (Agenten-Kontext)	Erkennungssignal in der Telemetrie
Reconnaissance	Sondieren der Modell-API, Abfragen zur Architektur, Test auf Leck des System-Prompts	Ungewöhnliche Abfragemuster an die Inferenz-API; Eingaben, die gezielt nach Konfiguration fragen; meist kein Eintrag in klassischen App-Logs
Resource Development	Aufbau eines Schattenmodells, Sammeln von Trainingsdaten, Erzeugen adversarialer Beispiele	Hohes Abfragevolumen einer einzelnen Quelle; systematisches Durchprobieren des Eingaberaums
Initial Access	Prompt Injection über abgerufene Inhalte, kompromittierte Lieferkette	Diskrepanz zwischen Nutzerabsicht und Modellaktion; injizierte Anweisungen im Kontextfenster
ML Model Access	Zugriff auf Inferenz-API, Zugang zum physischen Modell	Authentifizierte, aber atypische Zugriffe auf Modell-Endpunkte
Execution	Agent führt unautorisierte Tool-Aufrufe aus	Aufruf eines Werkzeugs ohne plausiblen Nutzerauftrag; Kette von Aktionen ohne menschliche Bestätigung
Persistence	Vergiftung des RAG-Speichers, dauerhafte Einträge im Gedächtnis des Agenten	Neue oder veränderte Einträge im Vektorspeicher; Inhalte, die als Anweisung statt als Information gelesen werden
Defense Evasion	Umgehung von Schutzfiltern (evasion), verschleierte Eingaben	Eingaben mit Steuerzeichen, Kodierungen oder mehrsprachiger Verschleierung; Antworten, die Leitplanken umgehen
Exfiltration	Absaugen über die Inferenz-API, Extraktion von Trainingsdaten	Antworten mit wörtlichen Trainingsdaten; auffällig viele Abfragen zur Modellrekonstruktion
Impact	Schwindendes Vertrauen in das Modell, Denial of ML Service, schädliche Agentenaktionen	Sprunghafter Anstieg der Fehlerrate; Aktionen mit realer Geschäftswirkung ohne Freigabe

Diese Zuordnung ist bewusst kein vollständiges Abbild der Matrix, sondern die Auswahl der Phasen, die bei agentischen Systemen am häufigsten relevant sind. Die offizielle Matrix unter atlas.mitre.org bleibt die maßgebliche Referenz.

Aufklärung und Ressourcenbeschaffung: die leisen Phasen

Die ersten beiden Phasen sind die schwierigsten zu erkennen, weil sie über genau die Schnittstelle laufen, die der Agent ohnehin anbietet. Aufklärung gegen einen produktiven LLM-Agenten geschieht häufig still über die Inferenz-API selbst und hinterlässt in herkömmlichen Anwendungslogs keine Spur. Das einzige verlässliche Signal ist die Form der Abfragen: Wer systematisch die Grenzen des System-Prompts austestet oder das Verhalten bei Randfällen kartiert, erzeugt ein Muster, das sich von echtem Nutzerverkehr unterscheidet.

Deshalb gilt: Ohne Protokollierung der vollständigen Eingaben — nicht nur der Metadaten — sind diese beiden Phasen praktisch blind. Wer Prompt- und Antwortpaare nicht speichert (unter Beachtung der DSGVO und sauberer Datenminimierung), kann adversariale ML-Taktiken in der Aufklärungsphase nicht nachweisen.

Initialer Zugang und Persistenz: das Kernproblem agentischer Systeme

Bei einem KI-Agenten verschmelzen Daten und Anweisungen. Ein abgerufenes Dokument, eine E-Mail im Postfach oder ein Eintrag im Vektorspeicher kann eine versteckte Anweisung enthalten, die der Agent als legitimen Befehl ausführt — die klassische indirekte Prompt Injection als Erstzugang. Vergiftet ein Angreifer den RAG-Speicher dauerhaft, erreicht er Persistenz: Die Manipulation überdauert die einzelne Sitzung und wirkt bei jedem Abruf erneut.

Das Erkennungssignal ist hier weniger ein einzelner Logeintrag als eine Diskrepanz: Die Aktion des Agenten passt nicht zur ursprünglichen Absicht des Nutzers. Wer Nutzerauftrag, abgerufenen Kontext und ausgeführte Aktion gemeinsam protokolliert, kann diese Abweichung sichtbar machen — getrennte Logs verhindern genau das.

Wie baut man eine Erkennung entlang von ATLAS konkret auf?

Die Zuordnung wird erst dann zur Verteidigung, wenn aus jedem Erkennungssignal eine konkrete Maßnahme wird. Ein pragmatischer Aufbau folgt vier Schritten:

1. Telemetrie zentralisieren. Erfassen Sie pro Agenteninteraktion mindestens: Eingabe, abgerufener Kontext, Tool-Aufrufe, Modellantwort und ausgeführte Aktion. Ohne diese fünf Felder bleibt die halbe Matrix unbeobachtbar.
2. Signale auf Taktiken abbilden. Verknüpfen Sie jede Detektionsregel ausdrücklich mit einer ATLAS-Technik-ID (etwa AML.T-Kennungen). So wird Ihre Abdeckung messbar — und Lücken werden benennbar.
3. Gegenmaßnahmen verankern. ATLAS liefert zu jeder Technik passende Gegenmaßnahmen; Dutzende sind derzeit dokumentiert. Trennen Sie Daten von Anweisungen, begrenzen Sie Werkzeugrechte, und verlangen Sie für folgenreiche Aktionen eine menschliche Freigabe.
4. Mit realen Fallstudien testen. Die dokumentierten Fallstudien sind ein Übungsfeld für das Red Team: Spielen Sie sie nach und prüfen Sie, ob Ihre Telemetrie das jeweilige Erkennungssignal tatsächlich zeigt. Wie sich solche Übungen strukturiert aufsetzen lassen, vertieft unser Forschungsbereich zu Red Teaming und Evaluierung von Agenten.

Dieser Ablauf macht aus ATLAS kein Compliance-Dokument, sondern ein lebendiges Erkennungsprogramm. Entscheidend ist der Schritt von der Klassifikation zum Signal: Eine Technik, die Sie zwar zuordnen, aber nicht beobachten können, schließt keine Lücke — sie benennt sie nur.

Wo liegen die Grenzen der ATLAS-Zuordnung?

ATLAS ist eine lebende Wissensbasis, kein abgeschlossener Standard. Das hat zwei praktische Folgen. Erstens ändert sich die Matrix: Die Zahl der Taktiken stieg allein im Herbst 2025 von 15 auf 16, die der Techniken von 66 auf 84. Wer seine Zuordnung an feste Technik-IDs koppelt, muss diese Entwicklung nachpflegen.

Zweitens beschreibt ATLAS das Was, nicht das Wie viel. Die Matrix sagt Ihnen, welche Phasen ein Angriff durchläuft — sie liefert keine Schwellenwerte dafür, ab wann ein Abfragemuster verdächtig ist. Diese Kalibrierung bleibt Ihre Aufgabe und hängt vom Normalverhalten Ihres konkreten Agenten ab. Die Zuordnung ist das Gerüst; die belastbaren Erkennungssignale entstehen erst aus Ihrer eigenen Telemetrie.

---

Dieser Beitrag dient der Information und stellt keine verbindliche Sicherheitsberatung dar. Maßgeblich ist stets die aktuelle Fassung der MITRE-ATLAS-Matrix unter atlas.mitre.org.

Quellen: MITRE ATLAS (atlas.mitre.org, Version 5.4.0, Februar 2026); NIST-Taxonomie adversarialer ML-Angriffe.