KI- und Agenten-Sicherheit

Die OWASP Top 10 für Agentic Applications, praktisch erklärt

Von CyberSec42 Research · Stand 2026

Am 9. Dezember 2025 hat das OWASP GenAI Security Project die OWASP Top 10 for Agentic Applications 2026 veröffentlicht, mit den Kennungen ASI01 bis ASI10. Sie ist die erste breit abgestimmte Referenz für die Risiken, die entstehen, wenn ein KI-System nicht nur antwortet, sondern plant, Werkzeuge aufruft, sich Dinge merkt und mit anderen Agenten spricht. Sie ergänzt die OWASP MCP Top 10: die MCP-Liste beschreibt den Server an der Nahtstelle, diese hier den Agenten selbst. Dieser Leitfaden nimmt jede der zehn Klassen und ergänzt praktische Tiefe: was im Kern schiefgeht, wie Sie es testen, und welche strukturelle Gegenmaßnahme greift.

Warum agentische Systeme eine eigene Top 10 brauchen

Ein Chatbot gibt Text zurück. Ein Agent handelt: er zerlegt ein Ziel in Schritte, ruft Werkzeuge mit echten Rechten auf, schreibt Ergebnisse in einen Speicher und übergibt an weitere Agenten. Damit wandern drei Dinge, die früher Menschen kontrolliert haben, in eine automatische Schleife: die Entscheidung, was als Nächstes zu tun ist, die Ausführung mit produktiven Zugangsdaten, und das Gedächtnis, auf das der nächste Schritt vertraut. Jede dieser Stellen wird zur Angriffsfläche, und keine davon deckt eine klassische Web- oder Server-Checkliste ab. Die folgende Übersicht bleibt bewusst auf Klassen-Ebene und nennt keine konkreten verwundbaren Produkte.

Die zehn Risikoklassen im Detail

ASI01. Ziel-Kaperung (Agent Goal Hijack)

Ein Angreifer schreibt das Ziel oder den Plan des Agenten um, ohne je direkten Zugriff zu haben. Der Hebel ist meist nicht vertrauenswürdiger Inhalt, den der Agent im Lauf liest: eine Webseite, ein Ticket, eine E-Mail, eine Datei. Darin versteckte Anweisungen verschmelzen mit der eigentlichen Aufgabe, und der Agent verfolgt plötzlich ein fremdes Ziel mit den Rechten des Betreibers. Das ist die agentische Form der indirekten Prompt-Injection, aber gefährlicher, weil am Ende eine Handlung steht und nicht nur eine Antwort.

Test: Kann Inhalt aus einer Tool-Antwort die Aufgabenstellung ändern? Ist die ursprüngliche Anweisung vom später gelesenen Material abgegrenzt? Fix: Systemauftrag und nicht vertrauenswürdige Daten strikt trennen und labeln, den Plan gegen das ursprüngliche Ziel prüfen, für zielverändernde Schritte eine Bestätigung verlangen.

ASI02. Werkzeug-Missbrauch (Tool Misuse and Exploitation)

Der Agent ruft ein legitimes Werkzeug auf eine Weise auf, für die es nicht gedacht war: ein Such-Tool wird zum Datenabfluss, ein Datei-Tool zum Schreiben außerhalb des Arbeitsordners, ein API-Tool zu Massenaktionen. Das Werkzeug selbst ist nicht kaputt, die Grenze zwischen erlaubtem und schädlichem Gebrauch wird nur nirgends durchgesetzt. Je mehr Tools ein Agent hat, desto größer die Zahl der Kombinationen, an die beim Design niemand gedacht hat.

Test: Ist für jedes Tool definiert, was ein erlaubter Aufruf ist, und wird das erzwungen? Kann eine Kette harmloser Aufrufe einen schädlichen Effekt erzeugen? Fix: jedes Tool eng auf seinen Zweck scopen, Parameter serverseitig validieren, Raten und Mengen begrenzen, gefährliche Kombinationen explizit sperren.

ASI03. Identitäts- und Rechte-Missbrauch (Identity and Privilege Abuse)

Der Agent handelt mit einer Identität oder mit Rechten, die ihm nicht zustehen: er teilt ein Dienstkonto mit zu breitem Zugriff, übernimmt die Rechte des aufrufenden Nutzers ohne erneute Prüfung, oder eskaliert über einen Schritt, der die Autorisierung nicht wiederholt. Das Grundmuster teilt sich mit BOLA und IDOR aus der Web-Welt: Zugriff auf ein Objekt ohne Ownership-Prüfung, nur dass hier eine Maschine in der Schleife die Anfragen stellt.

Test: Handelt der Agent unter einer eigenen, eng geschnittenen Identität? Wird jede sensible Aktion pro Aufruf gegen den echten Nutzer autorisiert? Fix: jedem Agenten und jedem Tool eine minimale eigene Identität geben, Rechte pro Schritt prüfen statt einmal am Anfang, kurzlebige Tokens, deny by default.

ASI04. Schwachstellen in der agentischen Lieferkette (Agentic Supply Chain Vulnerabilities)

Ein Agent ist selten allein: er zieht Frameworks, Tool-Definitionen, Plugins, Prompt-Vorlagen und Modell-Artefakte aus fremden Quellen. Jede dieser Komponenten kann kompromittiert oder manipuliert sein, und ein vergifteter Baustein wirkt tief in der Schleife, oft ohne Spur. Eine manipulierte Tool-Beschreibung reicht bereits, um das Verhalten des Agenten zu lenken, lange bevor überhaupt Code ausgeführt wird.

Test: Woher stammen Tools, Vorlagen und Modelle, und sind sie versioniert und geprüft? Kann eine externe Definition ungeprüft ins System gelangen? Fix: Herkunft festhalten und Integrität prüfen, Versionen pinnen, Tool-Definitionen und Vorlagen wie Code reviewen, nicht vertrauenswürdige Quellen aussperren.

ASI05. Unerwartete Code-Ausführung (Unexpected Code Execution)

Der Agent oder seine Sandbox führt Code aus, den ein Angreifer bestimmt. Das passiert über ein Code-Interpreter-Tool, über eine Sandbox, die keine ist, oder über einen Sink wie eval, einen Subprozess oder eine unsichere Deserialisierung, den ein Tool-Argument erreicht. Das sind die schärfsten Severities im Katalog, weil ein einziger Schritt zur vollständigen Kompromittierung des Hosts führt. Das Muster ist immer dasselbe: nicht vertrauenswürdiger Input trifft einen mächtigen Interpreter.

Test: Kann agent-kontrollierter Input eine Shell, einen Interpreter oder einen Deserialisierer erreichen? Ist die Sandbox echt isoliert, ohne Netz? Fix: Agent-Input nie an eine Shell geben, echte Isolation mit Ressourcen- und Netzgrenzen, für Ausdrücke einen echten Parser statt eval(), default-deny für Ausführung.

ASI06. Vergiftung von Speicher und Kontext (Memory & Context Poisoning)

Agenten merken sich Dinge: in einem Kurzzeit-Kontext, in einer Vektordatenbank, in einem geteilten Zustand zwischen Läufen. Wird dieser Speicher mit manipulierten Inhalten gefüllt, leitet er spätere Schritte still fehl, auch lange nach dem ursprünglichen Angriff. Besonders heikel ist geteiltes Gedächtnis über Nutzer oder Sitzungen hinweg: ein vergifteter Eintrag wirkt dann auf jeden, der ihn später abruft.

Test: Landet nicht vertrauenswürdiger Inhalt ungeprüft im dauerhaften Speicher? Ist Gedächtnis pro Nutzer und pro Aufgabe isoliert? Fix: Herkunft und Vertrauensgrad an jedem Eintrag mitführen, Speicher pro Kontext trennen, was in den Speicher darf validieren, sensible Einträge ablaufen lassen.

ASI07. Unsichere Kommunikation zwischen Agenten (Insecure Inter-Agent Communication)

In Multi-Agenten-Systemen reden Agenten miteinander, delegieren Aufgaben und tauschen Ergebnisse. Sind diese Nachrichten weder authentifiziert noch integritätsgeschützt, lassen sie sich fälschen, wiederholen oder einschleusen. Ein Agent hält dann eine untergeschobene Nachricht für eine legitime Anweisung eines Partners und handelt danach. Das ist das agentische Gegenstück zu ungeschützter Maschine-zu-Maschine-Kommunikation.

Test: Sind Nachrichten zwischen Agenten authentifiziert und gegen Replay geschützt? Prüft ein Agent, von wem eine Anweisung wirklich stammt? Fix: jede Agenten-Nachricht signieren und die Herkunft prüfen, Replay über Nonce oder Zeitstempel verhindern, Vertrauen zwischen Agenten explizit machen statt anzunehmen.

ASI08. Kaskadierende Ausfälle (Cascading Failures)

Ein Fehler oder eine Kompromittierung in einem Agenten fächert sich über das System aus. Weil Agenten sich gegenseitig auslösen und einander vertrauen, wird aus einem lokalen Problem eine Kette: ein falsches Ergebnis wird als Wahrheit weitergereicht, eine Schleife feuert unkontrolliert, oder ein kompromittierter Agent zieht die nächsten mit. Ohne Sollbruchstellen gibt es keinen Punkt, an dem die Kaskade stoppt.

Test: Gibt es Grenzen, an denen ein Fehler eines Agenten gestoppt wird? Können Rückkopplungen zwischen Agenten unbegrenzt laufen? Fix: Circuit-Breaker und harte Limits pro Agent und pro Kette, Zwischenergebnisse validieren statt blind vertrauen, Ausfälle eingrenzen und protokollieren, im Zweifel anhalten.

ASI09. Ausnutzung des Vertrauens zwischen Mensch und Agent (Human-Agent Trust Exploitation)

Menschen vertrauen der flüssigen, selbstsicheren Ausgabe eines Agenten zu schnell und geben Bestätigungen, die sie nicht geben sollten. Ein Angreifer nutzt das aus: der Agent präsentiert eine manipulierte Handlung als harmlos, verschweigt einen Nebeneffekt, oder holt eine Freigabe für etwas ein, das der Mensch bei genauem Hinsehen ablehnen würde. Die Schwachstelle sitzt an der Schnittstelle, nicht im Code.

Test: Sieht der Mensch bei einer Freigabe, was wirklich passiert, inklusive Nebeneffekten? Werden riskante Aktionen als solche kenntlich gemacht? Fix: folgenreiche Aktionen klar und vollständig darstellen, bei destruktiven Schritten explizit und reibungsbewusst bestätigen lassen, keine Aktionen im Hintergrund verstecken.

ASI10. Abtrünnige Agenten (Rogue Agents)

Ein Agent operiert außerhalb der Vorgaben, durch Designfehler, durch Drift über die Zeit, oder weil er kompromittiert wurde. Er tut Dinge, die niemand angeordnet hat, und weil er Teil des Systems ist, fällt das lange nicht auf. Diese Klasse ist die Summe der anderen: sie beschreibt den Zustand, in dem ein Agent nicht mehr das tut, wofür er gebaut wurde, und niemand es merkt, weil keine Instanz sein Verhalten laufend gegen die Vorgabe prüft.

Test: Wird das Verhalten jedes Agenten laufend gegen seine erlaubte Rolle geprüft? Gibt es einen Not-Aus? Fix: jedem Agenten eine explizite Rolle und Grenze geben, Verhalten gegen diese Grenze überwachen, Abweichungen alarmieren, einen zuverlässigen Kill-Switch bereithalten.

Von der Checkliste zum belastbaren Nachweis

Eine Klasse zu kennen ist nicht dasselbe, wie zu wissen, dass die Kontrolle in Ihrem System hält. Ein Teil dieser Klassen ist statisch erkennbar, als Code-Muster, unsicherer Sink oder zu breite Berechtigung. Ein anderer Teil liegt im Design von Rollen, Vertrauensgrenzen und Gedächtnis und wird erst im Verhalten der Agent-Schleife sichtbar, etwa Ziel-Kaperung oder Vertrauensmissbrauch. Belastbare Sicherheit braucht deshalb beide Ebenen: eine statische Prüfung gegen definierte Invarianten und eine dynamische Prüfung, die jeden Einzelbefund mit einem ausgeführten Nachweis belegt, statt ihn nur zu vermuten.

Häufige Fragen