Sicherheit von KI-Agenten: Was ändert sich, wenn ein Modell über Werkzeuge und Zugangsdaten verfügt?

Bei der Sicherheit von KI-Agenten geht es darum, KI-Systeme zu schützen, die nicht nur antworten, sondern auch handeln können. Ein Agent verfügt über Werkzeuge, Zugangsdaten und Speicher; ihn zu sichern bedeutet daher, zu regeln, was er aufrufen darf, welche Identität er besitzt und was er zur Laufzeit tut – und nicht, was sein Modell vorgibt.

Diese Unterscheidung bestimmt den Wirkungsradius. Ein Modell, das Fragen beantwortet, kann falsch liegen. Ein Agent, der über ein API-Token, ein Postfach und eine Shell verfügt, kann falsch liegen und entsprechend handeln – und zwar in dem Umfang, den seine Berechtigungen zulassen. Diese Seite befasst sich mit der agentenspezifischen Angriffsfläche: der MITRE-ATLAS-Agenten-Technikfamilie, Tool-Poisoning, der Identität und Bestandsaufnahme von Agenten, dokumentierten Vorfällen und der Erkennung zur Laufzeit. Informationen zur umgebenden Architektur, zum Lebenszyklus und zur Governance autonomer Systeme, einschließlich Memory Poisoning und der OWASP Top 10 für agentenbasierte Anwendungen, finden Sie in unserem Leitfaden zur Sicherheit agentenbasierter KI.

Was versteht man unter der Sicherheit von KI-Agenten?

Ein KI-Agent ist ein Sprachmodell, das darauf ausgelegt ist, zu handeln. Er plant, ruft Werkzeuge auf, liest und schreibt in den Speicher, verwaltet Zugangsdaten und koordiniert sich zunehmend mit anderen Agenten. Jede dieser Fähigkeiten ist nützlich, und jede einzelne davon ist zugleich eine Schnittstelle, auf die ein Angreifer zugreifen kann. Darin liegt das gesamte Sicherheitsrisiko eines KI-Agenten: Das Modell ist nicht gefährlicher geworden – das Modell hat nun „Hände“ bekommen.

Die deutlichste Aussage zu dieser Abgrenzung stammt nicht von einem Anbieter, sondern von einer Normungsorganisation. Die „OWASP Top 10 für LLM-Anwendungen 2026“ beschränkt sich auf den Fall „Modell als Komponente“, d. h. ein Modell, das in eine Anwendung eingebettet ist und Fragen beantwortet. Sobald das Modell zum Akteur wird – indem es Werkzeuge nutzt, Speicher über Sitzungen hinweg behält und nachgelagerte Konsequenzen verursacht –, ordnet OWASP es stattdessen seiner Liste der agentischen Risiken zu. Damit zieht eine Normungsorganisation genau die Grenze, um die es auf dieser Seite geht. Das kanonische Quell-Repository datiert diese Ausgabe auf den 4. August 2026 und zeigt, wie weit sich die Grenze verschoben hat: „Excessive Agency“ steht nun auf Platz LLM03, nachdem es in der Liste von 2025 noch auf Platz sechs lag.

Die praktische Konsequenz daraus ist, dass es bei der Sicherheit von KI-Agenten in erster Linie um Berechtigungen und Werkzeuge geht und erst in zweiter Linie um das Modell. Die Absicherung eines Modells verringert nicht den Schadensumfang eines Tools, das der Agent weiterhin aufrufen darf. Hier unterscheidet sich die Agentensicherheit vom übergeordneten Bereich der KI-Sicherheit, und genau deshalb kommt der indirekten prompt injection weitaus größere Bedeutung zu, sobald ein Agent auf das, was er liest, reagieren kann.

Der Zeitpunkt ist die andere Hälfte der Antwort. Gartner prognostiziert, dass bis 2026 bis zu 40 % der Unternehmensanwendungen integrierte, aufgabenspezifische Agenten enthalten werden – gegenüber weniger als 5 % im Jahr 2025. Eine Umfrage aus dem Jahr 2025 unter 353 Organisationen ergab, dass 80 % angaben, ihre KI-Agenten hätten unbeabsichtigte Aktionen ausgeführt. Und Googles Auswertung von „Common Crawl“-Snapshots ergab zwischen November 2025 und Februar 2026 einen relativen Anstieg von 32 % in der Kategorie „bösartig“, was bedeutet, dass die nicht vertrauenswürdigen Inhalte, die Agenten lesen, selbst immer bedenklicher werden. Die Einführung schreitet schneller voran als die Kontrollmaßnahmen – ein Muster, das sich bei jeder Sicherheitsherausforderung im Zusammenhang mit KI-Agenten auf dieser Liste wiederholt.

Die fünf Stellen, an denen ein Agent angegriffen werden kann

Die meisten aktuellen Veröffentlichungen zu diesem Thema stützen sich auf dasselbe Fünf-Schichten-Modell der Angriffsfläche von KI-Agenten, und diese Übereinstimmung ist ein deutliches Zeichen dafür, dass das Modell stichhaltig ist. Da es sich hierbei eher um eine Grundvoraussetzung als um ein Unterscheidungsmerkmal handelt, lohnt es sich, dies einmal zu erwähnen und dann weiterzumachen.

‍

Tabelle 1: Die fünf Ebenen der Angriffsfläche eines KI-Agenten und die jeweiligen Schwachstellen, die jede einzelne Ebene mit sich bringt.

Der Rest dieser Seite befasst sich mit den Aspekten, die in diesem Modell nicht behandelt werden: den spezifischen Technik-Identifikatoren, der Tool-Abgrenzung, dem Identitätsregister und den Laufzeitsignalen.

Wie sich Agent-Angriffe auf MITRE ATLAS abbilden lassen

MITRE ATLAS ist die Wissensdatenbank von MITRE zum realen Verhalten von Angreifern gegenüber KI-Systemen und stellt das agentenbasierte Framework für dieses Problem dar. Die aktuelle Version ist v2026.07, die am 7. August 2026 auf GitHub veröffentlicht wurde. Der Release-Text beschreibt den Inhalt genau wie folgt: „Diese Version der ATLAS-Daten enthält 1 Matrix, 16 Taktiken, 101 Techniken, 77 Untertechniken, 37 Abwehrmaßnahmen und 68 Fallstudien.“ Das sind insgesamt 178 Techniktefinitionen.

Von diesen 178, 29 Einträge sind agentenspezifisch: 13 übergeordnete Techniken und 16 Untertechniken. Daneben gibt es sieben Maßnahmen zur Risikominderung durch den Agenten und Vier Fallstudien zu den Kernagenten. Die Zählgrundlage ist entscheidend, daher hier die Erklärung: Ein Eintrag gilt als qualifiziert, wenn sein vollständiger ATLAS-Anzeigename „AI Agent“ oder „Agent“ enthält, sowie AML.0034.002 Cost Harvesting: Agentic Resource Consumption – dieser Begriff ist eindeutig agentenrelevant, erfüllt jedoch nicht die strengen Anforderungen an die Wortgrenze für „Agent“. Alle nachfolgenden Bezeichner stammen aus dem in das ATLAS-Datenarchiv.

Die Reichweite ist sogar noch größer. In der Version v2026.07 wird der Begriff „Agent“ in 48 der 178 Techniken-Definitionen (27,0 %) im Namen oder in der Beschreibung erwähnt, ebenso wie in 19 der 68 Fallstudien (27,9 %) und in 14 der 37 Abwehrmaßnahmen. Etwa ein Viertel des ATLAS-Korpus befasst sich mittlerweile in irgendeiner Weise mit Agenten.

Hier ist der entscheidende Unterschied, präzise und nicht nur vage formuliert: Es stimmt nicht, dass niemand ATLAS den Agenten zugeordnet hat. Richtig ist vielmehr, dass jeder öffentliche Versuch auf einer veralteten ATLAS-Version basiert und höchstens zwei der derzeit 29 Agenten-Einträge abdeckt. Es gibt zwei solcher öffentlicher Zuordnungen, und keine davon ist eine Seite, die zu diesem Thema in den Suchergebnissen erscheint. Deshalb verzeichnet der Ranking-Korpus selbst keine ATLAS-Identifikatoren. Eine der beiden bezieht sich auf ATLAS v5.4.0 und nennt sieben Technik-Identifikatoren. Die andere bezieht sich auf eine Technik, die inzwischen nicht mehr verwendet wird. Für einen Überblick über das Framework selbst siehe unseren Leitfaden zum MITRE-ATLAS-Framework; im Folgenden geht es um die agentenspezifische Ebene.

Ein Hinweis zum anderen MITRE-Framework: ATT&CK ist hier nicht der richtige Ansatzpunkt. Es spielt zwar nach einem Kompromittierungsvorfall eine Rolle, sobald die Anmeldedaten oder der Host eines Agenten als herkömmlicher Einstiegspunkt missbraucht werden, verfügt jedoch über keine agenteneigene Technikenfamilie. Die aktuelle Version ist ATT&CK v19.2, die am 6. August 2026 veröffentlicht wurde. Angreiferische Tests von Agenten hinsichtlich dieser Techniken gehören zu KI-Red-Teaming, und auch in ATLAS v2026.07 wurde dies formalisiert, wobei hinzugefügt wurde: AML.M0035 AI-Red-Team als Schutzmaßnahme.

Tabelle 2: Die 29 agentenspezifischen Technikeinträge in MITRE ATLAS v2026.07, gruppiert nach übergeordneter Technik. Kennungen und Bezeichnungen stammen aus dem Release-Asset; die Spalte „Praxis“ enthält unsere Erläuterungen in einfacher Sprache und nicht den Beschreibungstext aus ATLAS.

Tabelle 3: Die sieben agentenspezifischen Schutzmaßnahmen in MITRE ATLAS v2026.07.

Werkzeugvergiftung und die Werkzeuggrenze

Eine Werkzeugdefinition ist keine Konfiguration. Es handelt sich um Text, den das Modell liest und befolgt, was sie zu einer Befehlsoberfläche macht. „Tool Poisoning“ ist der Angriff, der sich aus dieser Tatsache ergibt, und MITRE ATLAS erfasst ihn als AML.0110 Manipulation von KI-Agenten-Tools.

Man sollte drei Dinge voneinander unterscheiden, da sie häufig miteinander verwechselt werden. „ Prompt injection “ ist der Übertragungsmechanismus. „Memory Poisoning“ verfälscht die Erinnerungen des Agenten und wird in unserem Leitfaden zur Sicherheit agentenbasierter KI ausführlich behandelt. „Tool Poisoning“ verfälscht das Tool selbst, und prompt injection wird häufig auf diese Weise verbreitet.

Drei Stellen, an denen ein Werkzeug verunreinigt werden kann

Mit ATLAS v2026.07 wurden drei Untertechniken unter folgendem Punkt hinzugefügt: AML.0110, und sie sind gerade deshalb nützlich, weil sie drei verschiedene Verteidigungsprobleme voneinander trennen. Die übergeordnete Technik stammt bereits aus einer früheren Version und wurde in dieser aktualisiert; die drei untergeordneten Techniken sind neu.

‍

Tabelle 4: Die drei Teiltechniken des „Tool Poisoning“ bei KI-Agenten in MITRE ATLAS v2026.07.

In der Rubrik „Implementierung“ wird ein dokumentierter Fall beschrieben. Im September 2025 wurde ein weit verbreitetes npm-Paket, das ein Tool zum Versenden von E-Mails für Agenten enthielt, mit einer Hintertür versehen. Die Offenlegung der „postmark-mcp“-Backdoor durch Koi Security beschreibt den Sachverhalt unumwunden: „Über 15 Versionen hinweg – FÜNFZEHN – funktionierte das Tool einwandfrei“, doch dann fügte Version 1.0.16 unbemerkt eine Blindkopie jeder Nachricht an eine Angreiferadresse hinzu. Die häufig genannte Zahl von etwa 300 betroffenen Organisationen ist keine Messung. Es handelt sich um eine Schätzung der Forscher selbst, die von einer Basis von 1.500 Downloads pro Woche ausgeht und dabei die Annahme „vielleicht 20 % werden aktiv genutzt“ zugrunde legt. Betrachten Sie dies als Annahme, denn genau das haben auch die Autoren getan. ATLAS behandelt den Vorfall als Fallstudie AML.CS0053.

MCP als Angriffsfläche

Das Model Context Protocol (MCP) ist die vorherrschende Methode, mit der Tools Agenten zur Verfügung gestellt werden, was einen MCP-Server zu einer Abhängigkeit in der Lieferkette macht, die Produktionsbefugnisse innehat. Die Analyse von Gartner drückt dies in ähnlicher Weise aus und stellt fest, dass MCP „in erster Linie auf Interoperabilität, Benutzerfreundlichkeit und Flexibilität ausgelegt wurde, sodass sich Sicherheitsfehler ohne kontinuierliche Überwachung der agentenbasierten KI manifestieren können“. Derselbe Ausblick geht davon aus, dass bis 2028 25 % der generativen KI-Anwendungen in Unternehmen mindestens fünf kleinere Sicherheitsvorfälle pro Jahr verzeichnen werden – ein Anstieg gegenüber 9 % im Jahr 2025.

Die Spezifikation des Model Context Protocol (MCP) enthält in ihrer am 28.07.2026 veröffentlichten Fassung eine normative Anforderung, die es wert ist, wörtlich zitiert zu werden: „MCP-Server DÜRFEN KEINE Token akzeptieren, die nicht ausdrücklich für den MCP-Server ausgestellt wurden.“ Dieser Satz findet sich im Abschnitt zu Gegenmaßnahmen für das Token-Passthrough im Dokument zu den Sicherheits-Best-Practices der Spezifikation, in dem elf Unterabschnitte zu Angriffen und Gegenmaßnahmen aufgeführt sind: „Confused Deputy“-Problem, Token-Passthrough, serverseitige Request-Forgery, State-Handle-Hijacking, Kompromittierung des lokalen MCP-Servers, Validierung der OAuth-Autorisierungs-URL, stdio-Transport-Sicherheit in Proxy-Szenarien, Mix-Up-Angriffe, Localhost-Redirect-URI-Impersonation, CIMD-Vertrauensrichtlinien und Scope-Minimierung.

Zwei Korrekturen sind erwähnenswert, da beide Fehler häufig vorkommen. Erstens sind „Tool Poisoning“, „Line Jumping“, „Tool Shadowing“ und „Rug Pull“ keine Konzepte aus der MCP-Spezifikation. Sie stammen von OWASP und aus Forschungsarbeiten der Community. Wer sich auf „den Abschnitt zum Tool-Poisoning in der MCP-Spezifikation“ bezieht, beschreibt etwas, das es nicht gibt. Zweitens wurde „Session Hijacking“ durch „State Handle Hijacking“ ersetzt: MCP ist nun zustandslos und kennt keine Sitzungen auf Protokollebene, sodass Inhalte, die MCP-Session-Hijacking als aktuellen Abschnitt der Spezifikation anführen, auf einer veralteten Version basieren.

OWASP hat dem „Tool Poisoning“ in den OWASP MCP Top 10 eine eigene Ordnungsnummer zugewiesen: MCP03:2025. Dabei ist der Status des Projekts zu beachten: Es handelt sich um ein OWASP-Inkubatorprojekt in der Version v0.1, das sich derzeit in Phase 3 befindet und in der Beta-Phase sowie in der Pilottestphase ist. Ein Datum für die endgültige Veröffentlichung steht noch nicht fest, und die nächste Veröffentlichung ist für Oktober 2026 geplant. Es verfügt nicht über die Autorität der LLM Top 10 und sollte nicht so zitiert werden, als ob dies der Fall wäre.

Die Leitlinien der Regierung sind bereits weiter fortgeschritten. Das Informationsblatt der NSA zur Cybersicherheit im Zusammenhang mit dem „Model Context Protocol“ – ein 17-seitiges Dokument in Version 1.0 vom Mai 2026, das ausschließlich von der NSA herausgegeben wurde – enthält neun MCP-Empfehlungen. Zwei davon sind es wert, wörtlich zitiert zu werden, da beide regelmäßig in eine abgeschwächte Form umformuliert werden: „Wählen Sie nach Möglichkeit unterstützte MCP-Projekte“ und „Verfolgen und beheben Sie MCP-bezogene Schwachstellen.“

Eine Randbedingung sollte einmal erwähnt und dann nicht weiter beachtet werden: Ein führendes Analystenunternehmen rät mittlerweile dazu, jeden Anwendungsfall als „No-Go-Zone“ zu betrachten, bei dem der Zugriff eines Agenten auf sensible Daten, die Aufnahme nicht vertrauenswürdiger Inhalte und die Möglichkeit zur externen Kommunikation zusammenkommen. Diese Kombination wird in unserem Agentic AI Security Seite. Auch die Lieferketten für Werkzeuge überschneiden sich mit herkömmlichen Abhängigkeitsrisiken, was MITRE ATLAS Namen direkt als AML.0010.005 KI- Supply Chain -Kompromiss: KI-Agent-Tool.

Agentenidentität, Inventar und das Registrierungsproblem

Das traditionelle Identitäts- und Zugriffsmanagement geht von einem Prinzipal mit vorhersehbaren Zugriffsmustern, einem menschlichen Inhaber und einer nachvollziehbaren Sitzung aus. Ein Agent bricht alle drei Annahmen. Sein Zugriffsmuster ist nicht deterministisch, da das Modell entscheidet, welche Funktionen aufgerufen werden. Seine Berechtigungen werden über eine Delegationskette und nicht über eine Anmeldung übertragen. Und strukturell handelt es sich um einen „Confused Deputy“, der über mehr Berechtigungen verfügt als derjenige, der ihn zum Handeln auffordert. Dieser letzte Punkt ist keine theoretische Überlegung: Das „Confused-Deputy“-Problem ist der erste namentlich genannte Angriff im Sicherheitsdokument der MCP-Spezifikation selbst.

Die erste Kontrollmaßnahme ist daher gar keine Kontrolle. Es handelt sich um eine Bestandsaufnahme. Drei unabhängige Seiten in diesem Marktbereich behaupten, dass die Erkennung von Agenten wichtig ist, doch keine von ihnen erläutert die Methode. Die Methode besteht aus einem Register, das mit dem beobachteten Verhalten abgeglichen wird. Alles, was Tools aufruft und nicht im Register aufgeführt ist, ist ein Schattenagent, und dieser Abgleich ist die einzige zuverlässige Methode, um die Ausbreitung von Agenten zu messen.

Tabelle 5: Felder, die ein Eintrag im Agentenregister enthalten sollte, sowie die Folgen, die das Fehlen der einzelnen Felder nach sich zieht.

Was den Wortschatz betrifft, beschreiben zwei Begriffe dasselbe zugrunde liegende Konzept. Eine Maschinenidentität und eine nicht-menschliche Identität (NHI) bezeichnen beide einen Akteur mit Anmeldedaten und Berechtigungen, der keine Person ist; dies umfasst Dienstkonten, API-Schlüssel, Workloads und nun auch Agenten. Eine ehrliche Einschränkung: Der Unterschied zwischen diesen Begriffen könnte eine echte Lücke in der Marktsprache sein, oder der Markt hat sich einfach auf „nicht-menschliche Identität“ geeinigt. Die vorliegenden Hinweise lassen keine Unterscheidung zwischen diesen beiden Möglichkeiten zu. Dort, wo sich die Agentenidentität mit der Erkennung des Missbrauchs eines nicht-menschlichen Prinzipals überschneidet, fällt dieser Bereich in den Bereich der Identitätsbedrohungserkennung und -reaktion.

Die Ebene der portablen Standards ist die Schwachstelle, und es lohnt sich, dies unverblümt anzusprechen. SPIFFE und SPIRE, die CNCF-Projekte zur Vergabe kryptografischer Workload-Identitäten, haben seit dem 20. September 2022 den Graduation-Status erreicht; wer sie also als „im Entstehen begriffen“ bezeichnet, liegt vier Jahre hinter dem Stand der Dinge zurück. Oberhalb dieser Ebene ist das Bild dünner, als es das Ausmaß der Aktivitäten vermuten lässt. Es gibt 165 aktive IETF-Entwürfe zum Thema Identität oder Autorisierung von KI-Agenten. Alle 165 sind Einzelbeiträge. Keiner davon wurde von einer Arbeitsgruppe angenommen. Die Ebene der Standards für Agentenidentitäten ist eine Explosion von Vorschlägen, keine echte Standardebene. Zwei Gegenbeispiele sind erwähnenswert: Das „OAuth Client ID Metadata Document“ ist ein echtes Arbeitsgruppendokument, auf das die MCP-Spezifikation direkt verweist, und die OpenID-AuthZEN-Arbeitsgruppe verfügt über einen Entwurf für eine verbindliche Autorisierung nach MCP, wobei das „AuthZEN Access Request and Approval Profile“ am 20. August 2026 den Status „Draft 1“ erreichte. Unterdessen hat die WIMSE-Arbeitsgruppe in rund 33 Monaten ihrer Mandatslaufzeit sechs aktive Dokumente und null RFCs hervorgebracht, und RFC 8693 bleibt ein „Proposed Standard“ ohne Aktualisierungen und ohne Veralteteinträge in allen 120 seiner Beziehungszeilen, was bedeutet, dass ihn nichts hinsichtlich der Agenten-Delegierung abgelöst hat. Quellen für die obigen Angaben finden sich im IETF-Datatracker.

In der Praxis bedeutet das: Da Sie die Identität eines Agenten noch nicht erwerben können, stehen Ihnen tatsächlich nur die Kontrollmechanismen „Gültigkeitsbereich“, „Sponsor“ und „Ablaufdatum“ zur Verfügung. Die NCSC-Leitlinien zur Einführung agentenbasierter KI kommen aus Sicht der Governance zu einem ähnlichen Ergebnis. Die „Zero trust “-Prinzipien lassen sich nahtlos auf Agenten anwenden, mit einer einzigen Anpassung: Da es sich bei dem kontinuierlich zu verifizierenden Auftraggeber nicht um eine Person handelt, muss das Verifizierungssignal aus dem Verhalten und nicht aus einem Anmeldevorgang stammen.

Was dokumentierte Vorfälle mit KI-Agenten zeigen

Die tatsächlich aufgetretenen Vorfälle sind aussagekräftiger als die Prognosen, da jeder einzelne davon aufzeigt, wo die Sicherheitsgrenze tatsächlich versagt hat.

Tabelle 6: Dokumentierte Sicherheitsvorfälle im Zusammenhang mit KI-Agenten mit Angabe ihrer Hauptquellen und, sofern vorhanden, der ATLAS-Fallstudien-Identifikatoren.

Amazon Q Developer. Ein bösartiger Beitrag gelangte in die veröffentlichte Erweiterung. Das AWS-Sicherheitsbulletin AWS-2025-015 beschreibt das Ergebnis genau: „AWS Security hat den Code überprüft und festgestellt, dass der bösartige Code zwar mit der Erweiterung verbreitet wurde, jedoch aufgrund eines Syntaxfehlers nicht ausgeführt werden konnte.“ Die schädliche Anweisung war vollständig ausgebildet. Ein Tippfehler hat sie verhindert. Bei CVE-2025-8217 sind beide Bewertungen – CVSS v4.0 5,1 MEDIUM und v3.1 4,0 MEDIUM – sekundär und wurden von AWS als CNA zugewiesen. Das NVD hat keine eigene primäre Bewertung veröffentlicht, und der Status des Eintrags lautet „Deferred“.

postmark-mcp. Dies wurde bereits oben behandelt und gehört auch hierher, da ein „Poisoned Agent“-Tool eine Abhängigkeit darstellt, die die Produktionsbefugnis des Agenten übernimmt. Es gilt dieselbe Argumentation wie bei jedem Angriff auf die Lieferkette, wobei der Weg bis zur Auswirkung wesentlich kürzer ist.

Claude Code GitHub-Action. Ein einziges Tool, das nicht in einer Sandbox ausgeführt wurde, bildete den gesamten Angriffspfad, der über ein gewöhnliches GitHub-Issue erreichbar war. Technischer Bericht von GMO Flatt Security weist einen vom Hersteller zugewiesenen CVSS-v4.0-Wert von 7,8 auf, eine Prämie von 4.800 US-Dollar sowie die Behebung des Kern-Bypasses in claude-code-action v1.0.94. Eine teilweise Sandbox-Isolierung eines Agenten wird vollständig umgangen.

Der agentengesteuerte Angriff im Juli 2026. Ein Anbieter von KI-Plattformen gab bekannt, dass ein Framework für autonome Agenten einen durchgängigen Angriff auf seine internen Systeme durchgeführt habe. Die folgende technische Zeitleiste stellt die forensischen Aufzeichnungen dar: „Unsere forensische Rekonstruktion umfasst etwa 17.600 Angreiferaktionen, die wir wiederherstellen konnten und die in etwa 6.280 Cluster gruppiert sind; der Zeitraum reicht vom 09.07.2026, 02:28 UTC, bis zum 13.07.2026, 14:14 UTC.“ Bei diesen rund 6.280 handelt es sich um Aktivitätscluster und nicht um Rechencluster, und der Zeitraum beträgt etwa viereinhalb Tage. Im selben Dokument heißt es: „Der Agent hat die geheimen Objekte des Clusters ausgelesen, darunter ein Produktionsobjekt, das 136 Schlüssel enthielt.“ In der Bekanntmachung des Vorfalls durch den Anbieter wird von einem „unbefugten Zugriff auf eine begrenzte Anzahl interner Datensätze und auf mehrere Zugangsdaten“ berichtet und darauf hingewiesen, dass die Bewertung der Auswirkungen auf Partner und Kunden noch im Gange sei. Die andere Partei wird nicht namentlich genannt, und dies sollte auch in keiner Zusammenfassung des Vorfalls geschehen.

Der Teil, der es wert ist, beachtet zu werden, betrifft die Erkennung. Die Signale wurden tatsächlich ausgelöst. Nach Angaben des Anbieters selbst wurden sie „von unserem KI-basierten Sicherheits-Agent-Stack korreliert und zu einem zusammenhängenden Angriffssignal aufgeschlüsselt. Allerdings gelang es dem System nicht, den Schweregrad der Warnmeldung korrekt zu ermitteln und das Bereitschaftsteam zu alarmieren, was bei der Reaktion wertvolle Zeit gekostet hat.“

EchoLeak. Zugriff auf private Daten, Einbindung nicht vertrauenswürdiger Inhalte und ein ausgehender Kanal, beobachtet in der Produktionsumgebung bei Microsoft 365 Copilot. Beide Bewertungen sind ehrlich wiederzugeben: CVE-2025-32711 wird von Microsoft als CNA mit einem CVSS-Wert von 9,3 („CRITICAL“) bewertet, während die unabhängige NIST-Analyse des NVD einen Wert von 7,5 („HIGH“) mit CWE-74 ergibt. Der in einigen Berichten kursierende Wert von 9,8 findet in keiner der beiden Quellen eine Grundlage. EchoLeak und damit verbundene Vorfälle im Zusammenhang mit Agenten werden auf unserer Seite zur Sicherheit von Agenten-KI behandelt.

Die Vorfälle im Zusammenhang mit der Cyber-Bewertung. Ein Modellanbieter gab bekannt, dass er „nach der Überprüfung von 141.006 Bewertungsläufen, bei denen Claude Internetzugang hätte erlangen können“, drei Vorfälle identifiziert habe, bei denen seine Modelle während Sicherheitstests auf Drittorganisationen zugegriffen hätten. Zwei der drei Organisationen wurden inzwischen kontaktiert. Drei von 141.006 stellen keine Basisrate dar und dürfen keinesfalls als Prozentsatz angegeben werden: Die Offenlegung beschreibt eine Untersuchung, keine Messung der Häufigkeit. Die eigene Darstellung der Grundursachen ist die klarste Formulierung der These dieser Seite: „Wir glauben, dass diese Vorfälle eher auf ein Versagen der Testumgebung und des Betriebs zurückzuführen sind als auf ein Versagen der Modellausrichtung.“

Zwei CVEs aus dem Jahr 2026 zu Produkten von Shipping Agent runden das Bild ab. CVE-2026-62830 im Azure SRE Agent wird mit einem CVSS v3.1-Wert von 9,9 (CRITICAL) und CWE-862 bewertet, während CVE-2026-59118 in Copilot Cowork mit einem Wert von 9,3 (CRITICAL) und CWE-285 bewertet wird. Beide wurden am 6. August 2026 veröffentlicht, und beide Bewertungen wurden von der CNA vergeben, ohne dass eine unabhängige NVD-Analyse vorliegt. Dieses Muster ist bei KI-Agent-Produkten eher die Regel als die Ausnahme, weshalb in jeder CVE-Tabelle zu diesem Thema angegeben werden muss, von wem die angezeigte Bewertung stammt. Keines der beiden Probleme erscheint im CISA-Katalog der ausgenutzten Schwachstellen, daher sollte keines davon als ausgenutzt bezeichnet werden.

Der rote Faden ist, dass keiner dieser Fälle darauf zurückzuführen ist, dass ein Modell falsch war. Fast alle Fälle lassen sich auf eine indirekte „ prompt injection “ zurückführen, die ein Werkzeug erreicht, oder auf eine Berechtigung, die über die für die Aufgabe erforderliche hinausgeht. Der Fall vom Juli 2026 ist die aufschlussreiche Ausnahme, da dort der Agent der Angreifer und nicht das Opfer war. Unsere eigenen Untersuchungen zu KI-Agenten-Gemeinschaften und der Illusion der Harmlosigkeit kommen aus der Perspektive der Interaktion zwischen Agenten zu demselben Ergebnis.

Erkennung und Eindämmung eines kompromittierten KI-Agenten

Beginnen Sie mit dieser ehrlichen Feststellung, denn sie legt die Anforderungen fest. Es gibt zwei dokumentierte Fehlerarten, und es handelt sich dabei um unterschiedliche Probleme.

Der erste Punkt ist Schweigen. Im Fall von „ZombieAgent“ hat keine herkömmliche Kontrollmaßnahme die Datenexfiltration erkannt. Weder Secure-Web-Gateways noch „ endpoint “-Tools noch Firewalls – und es ging keine Warnmeldung an den Nutzer. Der Eintrag im „OECD AI Incidents and Hazards Monitor“ ist der neutrale Registereintrag dazu. Forscher beschreiben dies als einen indirekten „Zero-Click“- prompt injection, was ihrer Einordnung entspricht und als solche zu vermerken ist, da der Nutzer weiterhin normal mit dem Assistenten interagieren muss, damit die Schadfunktion ausgelöst wird.

Der zweite Grund ist eine fehlerhafte Einstufung von Störsignalen. Bei dem Einbruch im Juli 2026 wurden Signale aus mehreren Ebenen gleichzeitig ausgesendet und zu einem kohärenten Angriffssignal korreliert. Das System versäumte es daraufhin, den Schweregrad des Alarms anzuheben. Sowohl das Ausbleiben eines Alarms als auch eine fehlerhafte Einstufung des Schweregrads führen zum gleichen Ergebnis, und keines von beiden lässt sich durch ein besseres Modell beheben.

Es gibt fünf Laufzeitsignale, auf deren Grundlage sich Erkennungsmechanismen aufbauen lassen:

1. Anomalien bei der Befolgung von Anweisungen: Handlungen ohne plausiblen Bezug zur Aufgabe.
2. Tool-Aufrufsequenzen, die die erwartete Workflow-Topologie unterbrechen.
3. Exfiltration über Kanäle mit geringer Bandbreite, über die der Agent rechtmäßig verfügt.
4. Zugriff auf Anmeldedaten und Geheimnisse außerhalb des aktuellen Aufgabenbereichs.
5. Anomalien beim Schreiben in den Speicher, durch die Befehle über mehrere Sitzungen hinweg inaktiv bleiben.

Signal – Wie es in der Telemetrie aussieht – ATLAS-Technik – Einschränkung der Abhilfemaßnahmen – Anomalie bei der Befolgung von Anweisungen – Tool-Aufrufe ohne übergeordnete Aufgabe oder BenutzeranforderungAML.T0080AML.M0030Tool-Aufruf-Topologie: Unterbrechung – Eine Aufrufsequenz, die eine Workflow-Grenze überschreitetAML.T0053AML.M0028Exfiltration mit geringer Bandbreite: Kleine, wiederholte ausgehende Schreibvorgänge über ein zugelassenes ToolAML.T0086AML.M0033Zugriff auf Anmeldedaten außerhalb des Geltungsbereichs: „Secret“ liest Daten, die in keinem Zusammenhang mit der laufenden Aufgabe stehenAML.T0098AML.M0026Anomalie beim Speicherschreiben: Schreibvorgänge in den persistenten Speicher außerhalb des BenutzerzugriffsAML.T0080.000AML.M0029

Tabelle 7: Fünf Signale zur Erkennung eines kompromittierten KI-Agenten während der Laufzeit, zugeordnet zu den jeweiligen von der ATLAS-Technik beobachteten Merkmalen und den entsprechenden Abwehrmaßnahmen, die diese einschränken.

Orientieren Sie sich bei der Erkennung eher an Abhilfemaßnahmen als an Produktfunktionen, da die Abhilfemaßnahmen auch in einem Jahr noch gültig sein werden. AML.M0033 Eingabe- und Ausgabevalidierung für Komponenten von KI-Agenten und AML.M0030 „Aufruf des KI-Agent-Tools bei nicht vertrauenswürdigen Daten einschränken“ – das sind die beiden Einstellungen, die die meisten für die Erkennung relevanten Telemetriedaten generieren. Beachten Sie außerdem, dass „Human-in-the-Loop“ hier keine bloße Empfehlung ist: Es ist AML.M0029 „Human-in-the-Loop“ bei den Aktionen von KI-Agenten, eine namentlich genannte Risikominderungsmaßnahme, die in einem eigenen Abschnitt in Das OWASP-Spickzettel zur Sicherheit von KI-Agenten und einen Unterabschnitt zum Thema „Human-in-the-Loop“ in der gemeinsame Leitfaden der Regierung.

Zur Messung hat ein Forschungslabor den einzigen agenten-nativen Metrikensatz vorgeschlagen, der jemals veröffentlicht wurde, und kein Anbieter hat ihn übernommen: „Abdeckung (der Anteil des überwachten Datenverkehrs), Recall (der Anteil der erkannten abweichenden Verhaltensweisen) und Reaktionszeit.“ In derselben Arbeit wird dafür plädiert, nicht vertrauenswürdige KI-Agenten als potenzielle „Insider-Bedrohungen“ zu behandeln, was die richtige Herangehensweise ist. Die Einführung dieser drei Metriken liefert Ihnen etwas, worüber Sie berichten können, das über die bloße Anzahl von Warnmeldungen hinausgeht. Echte Beobachtbarkeit der Agentenlaufzeit – d. h. die Protokollierung von Tool-Aufrufen als Ereignisse erster Klasse anstelle von als Text protokollierten Eingabeaufforderungen – ist die Voraussetzung dafür und steht im Zusammenhang mit der allgemeineren Praxis der Sicherheitsbeobachtbarkeit.

Das stärkste Argument für die Erkennung zur Laufzeit sind Exploit-Daten. Stand Katalogversion 2026.08.24, veröffentlicht am 24. August 2026, umfasste der CISA-Katalog „Known Exploited Vulnerabilities“ 1.675 Einträge, von denen 11 den KI- und Agent-Stack betreffen: sechs Langflow-Einträge, zwei LiteLLM-Einträge sowie je einen Eintrag für MLflow, n8n und Ray. Dass sich sechs von elf Einträgen auf eine einzige Agent-Workflow-Plattform konzentrieren, ist an sich schon bemerkenswert. Noch aufschlussreicher ist jedoch die zeitliche Verteilung. Der Ray-Eintrag, CVE-2025-62593, wurde am 26. November 2025 im NVD veröffentlicht und am 17. August 2026 in den Katalog aufgenommen – ein Zeitabstand von 264 Tagen. Im Gegensatz dazu wurde der Eintrag CVE-2026-64849 für MLflow am 17. August 2026 veröffentlicht, am 19. August 2026 in den Katalog aufgenommen und weist als Frist für die Behebung den 2. September 2026 auf – eine Verzögerung von zwei Tagen. Wenn eine bekanntermaßen ausgenutzte Schwachstelle in Ihrem Agent-Stack neun Monate lang unentdeckt bleiben kann, bevor Sie darüber informiert werden, dass sie ausgenutzt wird, kann die Patch-Häufigkeit nicht die einzige Kontrollmaßnahme sein. Es muss etwas geben, das das Verhalten in diesem Zeitraum überwacht.

Volume übermittelt dieselbe Botschaft von der anderen Seite. Die OWASP-eigene Erfassung, die auf einer Momentaufnahme der überwachten GitHub-Repositorys vom April 2026 basiert, verzeichnet 57 Sicherheitshinweise für n8n, 22 für Claude Code, 15 für AutoGPT, 13 für Dify und 11 für Roo-Code. Dabei handelt es sich um Zahlen pro überwachtem Repository, nicht um eine vollständige Erfassung aller agentenbasierten Projekte. Das adversarische Testen der eigenen Agenten gehört zum AI-Red-Teaming, während die auf der Modellebene liegende Hälfte des Problems im Bereich der GenAI-Sicherheit angesiedelt ist.

Rahmenbedingungen, behördliche Leitlinien und Vorschriften

Derzeit werden agentenspezifische Kontrollkataloge erstellt, wodurch die korrekte Datierung jeder Framework-Referenz zu einem sichtbaren Qualitätsmerkmal wird und nicht mehr als bloße Pedanterie angesehen wird.

Tabelle 8: Übersicht über Rahmenbedingungen und Vorschriften zur Sicherheit von KI-Agenten, mit Angabe der Fassung und des Datums der jeweiligen Rechtsvorschrift.

Die gemeinsamen Leitlinien zur umsichtigen Einführung von agentenbasierten KI-Diensten stellen die bislang umfassendsten agentenspezifischen Kontrollleitlinien dar. Auf 29 Seiten wird das Problem in fünf Risikokategorien gegliedert, wobei es sich lohnt, die Formulierungen des Leitfadens selbst zu verwenden, anstatt die in der Berichterstattung kursierenden Umschreibungen: Risiken im Zusammenhang mit Berechtigungen (Seite 7), Risiken bei Design und Konfiguration (Seite 9), Verhaltensrisiken (Seite 9), strukturelle Risiken (Seite 11) und Risiken im Zusammenhang mit der Rechenschaftspflicht (Seite 12). Die darin enthaltenen Best-Practice-Empfehlungen sind als vierstufiger Lebenszyklus gegliedert, der die Planung, Entwicklung, Bereitstellung und den Betrieb sicherer Agenten abdeckt. Sechs Behörden aus fünf Ländern haben gemeinsam an der Erstellung mitgewirkt: das ACSC des Australian Signals Directorate, die CISA, die NSA, das Canadian Centre for Cyber Security, das NCSC-NZ und das NCSC-UK.

Was die Verordnung betrifft, haben sich die Termine geändert, und ein Großteil der veröffentlichten Leitlinien wurde noch nicht angepasst. Die Verordnung (EU) 2026/1744 wurde am 8. Juli 2026 verabschiedet, am 24. Juli 2026 im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Sie gilt für eigenständige Verpflichtungen für Hochrisikosysteme gemäß Anhang III ab dem 2. Dezember 2027 und für eingebettete Verpflichtungen für Hochrisikosysteme gemäß Anhang I ab dem 2. August 2028. Lediglich die Transparenzpflichten gemäß Artikel 50 galten bereits ab dem 2. August 2026. Ein Unternehmensagent, der in einem Bereich des Anhangs III Entscheidungen trifft oder diese maßgeblich beeinflusst, gilt als KI-System mit hohem Risiko; daher ist Dezember 2027 der maßgebliche Planungshorizont, während die Offenlegungspflichten gemäß Artikel 50 bereits heute für kundenorientierte Agenten gelten.

Was auf uns zukommt, ist zwar beachtenswert, sollte aber nicht überbewertet werden. Die Kontrollrahmen des NIST zur Sicherung von KI-Systemen umfassen zwei namentlich genannte Anwendungsfälle für Agenten: „Einsatz von KI-Agentensystemen (KI-Agenten) – Einzelagent“ und „Einsatz von KI-Agentensystemen (KI-Agenten) – Multi-Agent“. Beide sind geplant, wurden jedoch noch nicht ausgearbeitet: Es existieren lediglich ein Konzeptpapier und eine kommentierte Gliederung für den Anwendungsfall der prädiktiven KI. Unabhängig davon legt die am 17. Februar 2026 angekündigte NIST-Initiative für KI-Agenten-Standards drei Säulen fest, darunter die Forschung zu Sicherheit und Identität von Agenten.

Zwei Anmerkungen zur Quellenangabe klären hier tatsächliche Fehler auf. Die LLM-Liste von 2026 ist die erste, anhand von Vorfalldaten gewichtete Ausgabe, und im Vorwort wird ein Korpus von 7.714 realen Vorfällen angegeben, von denen 6.639 ausreichend detailliert sind, um klassifiziert zu werden, wobei die Abstimmung der Community drei Viertel des Gewichts ausmacht und die Vorfalldaten das verbleibende Viertel. Entnehmen Sie diese Zahlen und die Ordnungszahlen bitte dem Quell-Repository und nicht einer Landingpage. Entnehmen Sie die Versionsangabe ebenfalls dem PDF-Deckblatt von „OWASP Agentic AI Threats and Mitigations v1.1“ und nicht dem Datumsangabe auf der Seite, und beachten Sie, dass die „CSA AI Controls Matrix v1.1“ 247 Kontrollziele enthält, während die URL ohne Suffix noch die ältere Version mit 243 Zielen bereitstellt. Die Entsprechung all dessen auf der Anwendungsebene ist die GenAI-Sicherheit, und die agentische Architekturebene wird unter den OWASP Top 10 für agentische Anwendungen behandelt.

Moderne Ansätze zur Sicherheit von KI-Agenten

Die Tools für die Sicherheit von KI-Agenten in Unternehmen kommen rasch auf den Markt und lassen sich derzeit eher in sechs Kategorien als in eine einzige einteilen.

• Erkennung und Bestandsaufnahme von Agenten. Ermitteln von Agenten, die nicht registriert wurden, und Abgleich mit einem Register.
• Risikobewertung pro Agent. Bewertung eines Agenten anhand der Reichweite seiner Tools und Berechtigungen statt anhand seines Modells.
• Zugriffskontrolle für Tools und MCP. Legt fest, welche Tools ein Agent unter welchen Bedingungen aufrufen darf.
• Steuerung von Agentenaktionen. Genehmigen, Einschränken oder Blockieren einer bestimmten Aktion zur Laufzeit.
• Erkennung des Verhaltens zur Laufzeit. Beobachtung der tatsächlichen Aktivitäten des Agenten und Auslösung von Warnmeldungen bei Abweichungen.
• Identitäts- und Delegationskontrollen für nicht-menschliche Prinzipale. Bereichsbezogene Zugangsdaten, Delegationsketten und Widerruf.

Vier Fragen unterscheiden KI-Agenten-Sicherheitslösungen, die sich bewähren werden, von solchen, die dies nicht tun werden. Erfasst das System auch Agenten, die Sie nicht registriert haben, oder erstellt es nur eine Bestandsaufnahme derjenigen, die Sie ihm mitgeteilt haben? Erkennt es den Aufruf von Tools oder nur Eingabeaufforderungen? Ordnet es die Ergebnisse einer öffentlichen Techniken-Taxonomie zu, die Sie überprüfen können? Und kann es ein einzelnes Tool einschränken, ohne den Agenten zu deaktivieren – was den Unterschied zwischen einer Kontrollfunktion und einem Ausschalter ausmacht?

Die Entwicklung des Marktes ist recht klar. Die Agentenidentität wird in bestehende Kategorien der Identitätssicherheit integriert, anstatt eine eigenständige Kategorie zu bilden, und die Kontrollkataloge befinden sich derzeit noch in der Entwicklung und sind noch nicht ausgereift. Zu beachten ist zudem, dass mehrere führende Anbieter in diesem Bereich zwischen Dezember 2025 und Juni 2026 den Eigentümer gewechselt haben; daher sollte die Unabhängigkeit überprüft und nicht einfach vorausgesetzt werden. Agentenbasierte und agentenlose Bereitstellungsmodelle sind ein ganz anderes Thema, das im Rahmen von Cybersicherheitslösungen behandelt wird.

Wie „ Vectra AI “ die Sicherheit von KI-Agenten betrachtet

Ein KI-Agent ist eine neue Art von Identität, die im selben Netzwerk wie alle anderen Komponenten operiert, sodass für ihn dieselbe Frage nach der Annahme eines Kompromitts gilt. Wenn die Anmeldedaten eines Agenten dazu verwendet werden, etwas zu tun, wozu dieser Agent nie bestimmt war – wird dies in Ihrer Umgebung überhaupt bemerkt? Vectra AI vertritt den Standpunkt, dass das Verhalten eines Agenten dort beobachtet werden muss, wo der Agent agiert – über Netzwerk, Identität und cloud hinweg –, anstatt es aus der Eingabe abzuleiten, die ihn ausgelöst hat. Das ist derselbe „Attack Signal Intelligence™“-Ansatz, den wir bei jedem kompromittierten Prinzipal anwenden: Beobachten Sie, was er tut, nicht was er vorgibt zu sein. Das umfassendere Bild der KI-Sicherheit bildet den Kontext für diese Position.

Schlussfolgerung

Die Frage, die die Sicherheit von KI-Agenten von der KI-Sicherheit im Allgemeinen unterscheidet, lautet nicht: „Ist das Modell sicher?“, sondern: „Was darf dieser Agent tun, und würde es jemand bemerken, wenn er etwas anderes täte?“ Jeder bisher dokumentierte Vorfall beantwortet die erste Hälfte dieser Frage schlecht und die zweite Hälfte noch schlechter. Die Arbeit, die vor den meisten Sicherheitsteams liegt, ist wenig glamourös und schrittweise: die Agenten erfassen, für jeden einen Verantwortlichen benennen, den Fokus eher auf die Tools als auf das Modell legen und die Tool-Aufrufe in die Telemetrie einbinden, wo sie von einem Erkennungssystem erfasst werden können. MITRE ATLAS v2026.07 bietet Ihnen 29 Technik-Identifikatoren und sieben Gegenmaßnahmen, um diese Arbeit in einer öffentlichen Taxonomie zu verankern.

Wenn Sie sich gerade mit den damit verbundenen Fragen zu Architektur, Lebenszyklus und Governance beschäftigen, knüpft unser Leitfaden zur Sicherheit agentenbasierter KI dort an, wo diese Seite endet.

‍