OWASP Top 10 für agentische KI

Agentische KI verändert die Sicherheitsdebatte, weil sie verändert, was KI-Systeme tun können.

Ein Chatbot, der Fragen aus einer Wissensdatenbank beantwortet, ist das eine. Ein KI-Agent, der Aufgaben planen, Tools aufrufen, auf interne Systeme zugreifen, Daten abfragen, in Anwendungen schreiben, Code ausführen, sich mit anderen Agenten koordinieren und Informationen dauerhaft speichern kann, ist etwas völlig anderes.

Viele Organisationen experimentierten 2024 und 2025 mit LLM-Integrationen, internen Copiloten, Retrieval-Systemen, KI-Assistenten und ersten agentischen Workflows. Einige dieser Arbeiten blieben sicher begrenzt. Andere wurden stillschweigend ausgeweitet. Agenten erhielten Zugriff auf APIs, SaaS-Tools, Datenbanken, Dateien, Ticketsysteme, CRM-Datensätze, Repositories und operative Workflows.

Hier verändert sich das Sicherheitsrisiko. Ein KI-Agent ist nicht einfach eine weitere Benutzeroberfläche. Er ist ein Software-Akteur mit Anweisungen, Berechtigungen, Tools und Kontext sowie der Fähigkeit, innerhalb eines Workflows Entscheidungen zu treffen.

Die Top 10 für agentische Anwendungen 2026 der OWASP Foundation bieten Sicherheitsteams eine praktische Möglichkeit, diesen Wandel zu verstehen. Das durch die Zusammenarbeit von mehr als 100 Branchenexperten, Forschern und Praktikern entwickelte Framework identifiziert die kritischsten Risiken für autonome und agentische KI-Systeme. Es ist nicht nur eine Warnung vor zukünftigen Bedrohungen. Es ist eine Übersicht über die Probleme, mit denen Organisationen bereits beginnen, sich auseinanderzusetzen, während Agenten vom Pilotbetrieb in die Produktion übergehen.

Warum agentische KI die Sicherheitsgleichung verändert

Die traditionelle Anwendungssicherheit basiert auf vertrauten Annahmen. Benutzer authentifizieren sich. Anwendungen setzen Berechtigungen durch. Dienste rufen bekannte APIs auf. Protokolle zeigen Aktionen. Sicherheitsteams überwachen Zugriffsmuster, Schwachstellen, Netzwerkverhalten und verdächtige Aktivitäten.

Agentische KI erschwert diese Annahmen.

Agenten verhalten sich nicht wie gewöhnliche Benutzer. Sie können Anweisungen interpretieren, Zwischenpläne erstellen, entscheiden, welche Tools verwendet werden, Kontext abrufen, wiederholt Systeme aufrufen und Aktionen ausführen, die legitim erscheinen, weil sie genehmigte Anmeldedaten und genehmigte Integrationen verwenden.

Die Analyse der OWASP-Veröffentlichung durch Palo Alto Networks unterstreicht die Notwendigkeit einer agentenzentrierten Bestandsaufnahme, umfassender Transparenz, Integrität der Lieferkette über alle KI-Komponenten hinweg, Governance, Sicherheitsleitplanken und aktiver Kontrolle zur Laufzeit. Diese Einordnung ist hilfreich, weil das Sicherheitsproblem nicht auf Prompt-Injection beschränkt ist. Es umfasst Tools, Identitäten, Lieferketten, Speicher, Kontext, Berechtigungen und Verhalten zur Laufzeit.

Mit anderen Worten: Einen Agenten abzusichern ist nicht dasselbe wie ein Modell abzusichern. Das Modell ist nur ein Teil des Systems.

Die OWASP Top 10 für agentische Anwendungen

Die OWASP-Liste für 2026 identifiziert zehn wichtige Risikokategorien für agentische Systeme:

ASI01 — Übernahme des Agentenziels: Angreifer manipulieren oder lenken das Ziel des Agenten um, häufig durch natürliche Sprache, versteckte Anweisungen oder bösartigen Kontext.
ASI02 — Missbrauch und Ausnutzung von Tools: Agenten verwenden Tools auf unsichere, unbeabsichtigte oder ausnutzbare Weise.
ASI03 — Missbrauch von Agentenidentität und Berechtigungen: Agenten erhalten übermäßige Berechtigungen, erben riskante Anmeldedaten oder arbeiten ohne angemessene Identitätsgrenzen.
ASI04 — Schwachstellen in der Lieferkette agentischer Systeme: Prompts, Plugins, MCP-Server, Tools, Datensätze, Orchestrierungslogik, Abhängigkeiten oder Integrationen werden kompromittiert.
ASI05 — Unerwartete Codeausführung: Agenten lösen über Tools, Skripte, Plugins oder verbundene Systeme unsicheres ausführbares Verhalten aus oder erzeugen es.
ASI06 — Vergiftung von Speicher und Kontext:Angreifer manipulieren, was der Agent sich merkt, abruft oder als Kontext verwendet.
ASI07 — Unsichere Kommunikation zwischen Agenten: Agenten kommunizieren miteinander ohne ausreichende Authentifizierung, Validierung oder Abgrenzungen.
ASI08 — Kaskadierende Agentenausfälle: Der Ausfall, die fehlerhafte Ausgabe oder die unsichere Aktion eines Agenten breitet sich in einem größeren agentischen Workflow aus.
ASI09 — Ausnutzung des Vertrauens zwischen Mensch und Agent: Nutzer vertrauen den Ausgaben, Genehmigungen oder Empfehlungen von Agenten übermäßig, was Angreifer ausnutzen können.
ASI10 — Nicht autorisierte Agenten: Agenten handeln außerhalb des vorgesehenen Umfangs, bleiben über die Autorisierung hinaus aktiv oder arbeiten ohne ausreichende Überwachung.

Die Liste ist relevant, weil sie widerspiegelt, wie agentische Systeme tatsächlich ausfallen. Die Risiken sind verhaltensbezogen, architektonisch und operativ. Es handelt sich nicht nur um Schwachstellen im herkömmlichen Sinne.

Das Identitätsproblem, für das niemand geplant hat

Sicherheitsteams verwalten bereits nichtmenschliche Identitäten: Dienstkonten, Workloads, Geräte, Anwendungen, Bots, Automatisierungsskripte und API-Schlüssel. Agentische KI fügt eine weitere Ebene hinzu.

Ein Agent kann mit delegierten Berechtigungen arbeiten. Er kann die Anmeldedaten eines Benutzers, ein Dienstkonto, ein tokenspezifisches Token oder eine von der Plattform verwaltete Identität verwenden. Er kann in einem Workflow auf mehrere Systeme zugreifen. Er kann anhand des Kontexts entscheiden, welches Tool verwendet werden soll. Er kann zu unterschiedlichen Zeitpunkten im Auftrag verschiedener Benutzer handeln.

Das führt zu einer schwierigen Frage: Was genau darf der Agent tun?

Wenn die Antwort lautet: „Alles, was das verbundene Konto tun kann“, hat die Organisation ein Problem. Die Berechtigungen von Menschen sind für die autonome Nutzung oft zu weitreichend. Ein Benutzer kann Zugriff auf sensible Dateien, Kundendaten, Abrechnungssysteme, Administratoreinstellungen oder Quellcode haben, weil er diesen Zugriff in bestimmten Kontexten benötigt. Einem Agenten dieselbe Breite an Zugriff zu gewähren, kann unnötige Risiken schaffen.

Agentenidentitäten müssen bewusst gesteuert werden. Dazu gehören das Prinzip der geringsten Privilegien, eingeschränkte Anmeldedaten, klare Zuständigkeiten, Berechtigungen auf Tool-Ebene, Genehmigungsschranken, Protokollierung sowie die Möglichkeit, Zugriffe schnell zu widerrufen oder zu rotieren.

Das Entführen von Agentenzielen unterscheidet sich von einem herkömmlichen Angriff

Das Entführen von Agentenzielen ist eines der wichtigsten Risiken, weil dabei die Anweisungen des Agenten und nicht der zugrunde liegende Code angegriffen werden.

Ein Angreifer muss möglicherweise keine Software-Schwachstelle im herkömmlichen Sinne ausnutzen. Er kann bösartige Anweisungen in ein Dokument, eine Webseite, eine E-Mail, ein Support-Ticket, ein Repository-Issue, eine Tool-Ausgabe oder einen anderen Kontext einfügen, den der Agent liest. Wenn der Agent vertrauenswürdige Anweisungen nicht von nicht vertrauenswürdigen Inhalten unterscheiden kann, kann er sein Verhalten umleiten.

Die Analyse von Auth0 zur OWASP-Liste beschreibt die ersten beiden Kategorien, das Entführen von Zielen und den Missbrauch von Tools, als Risiken, die entstehen, weil Agenten natürliche Sprache verarbeiten und möglicherweise Systemanweisungen nicht zuverlässig von bösartigen Nutzdaten unterscheiden können, die in Inhalten oder Tool-Ausgaben verborgen sind.

Das ist ein anderes Denkmodell für Verteidiger. Die Angriffsfläche umfasst Text, Kontext, Tool-Antworten, Speicher, abgerufene Dokumente und Workflows – nicht nur offengelegte Endpunkte.

Toolzugriff macht aus fehlerhaftem Denken echte Aktionen

Agentische KI wird leistungsfähiger, wenn sie Tools verwenden kann. Sie wird dadurch auch gefährlicher.

Ein Modell, das eine falsche Antwort gibt, ist ein Qualitätsproblem. Ein Agent, der eine falsche Antwort gibt und anschließend einen Kundendatensatz aktualisiert, ein Ticket eröffnet, eine E-Mail sendet, eine Konfiguration ändert, eine API aufruft oder Code ausführt, stellt ein operatives Risiko dar.

Toolmissbrauch kann auch ohne böswillige Absicht auftreten. Der Agent kann eine Anfrage missverstehen. Er kann ein Tool in der falschen Reihenfolge verwenden. Er kann auf veralteten Daten handeln. Er kann eine API mit den falschen Parametern aufrufen. Er kann möglicherweise nicht erkennen, dass ein menschlicher Genehmigungsschritt erforderlich ist.

Die Lösung lautet nicht einfach „besseres Prompting“. Agenten benötigen klare Tool-Grenzen. Sie benötigen Berechtigungsbereiche. Sie benötigen sichere Standardeinstellungen. Für Aktionen mit hohen Auswirkungen benötigen sie Testläufe ohne Ausführung. Für sensible Vorgänge benötigen sie die Genehmigung eines Menschen. Sie benötigen eine Überwachung, die das Verhalten von Agenten versteht und nicht nur den API-Datenverkehr.

Speicher und Kontext schaffen eine neue Angriffsfläche

Der Speicher von Agenten ist nützlich, weil er es Systemen ermöglicht, Präferenzen, Workflow-Zustände, frühere Entscheidungen und Kontext sitzungsübergreifend zu speichern. Er schafft jedoch auch Risiken.

Wenn der Speicher manipuliert werden kann, führt der Agent möglicherweise falsche Annahmen weiter. Wenn der Kontextabruf schwach ist, verwendet der Agent möglicherweise die falschen Dokumente, veraltete Richtlinien oder bösartig veränderte Daten. Wenn Benutzer den gemeinsamen Speicher ohne Kontrollen beeinflussen können, kann die Eingabe eines Benutzers die Erfahrung eines anderen Benutzers beeinflussen.

Speicher- und Abrufsysteme sollten als Teil der Sicherheitsarchitektur betrachtet werden. Organisationen müssen wissen, was gespeichert wird, wer es ändern kann, wie lange es aufbewahrt wird, wie es validiert wird und wie manipulierte oder veraltete Kontextdaten korrigiert werden können.

Das Lieferkettenrisiko umfasst jetzt auch Prompts, Tools und MCP-Server

Die Sicherheit der Software-Lieferkette umfasst bereits Abhängigkeiten, Pakete, Container, Build-Systeme, APIs und Anbieterdienste. Agentische KI erweitert die Lieferkette.

Prompts, Tool-Definitionen, Orchestrierungsskripte, RAG-Datensätze, Plugins, MCP-Server, externe Tools, Vektorspeicher und Modellanbieter werden alle Teil des agentischen Systems. Ein kompromittiertes Tool oder ein manipulierter Datensatz kann das Verhalten eines Agenten ebenso sicher verändern wie ein kompromittiertes Paket das Verhalten einer Anwendung verändern kann.

Palo Alto Networks betont die Integrität der Lieferkette für Prompts, Plugins, RAG-Datensätze, Orchestrierungsskripte und Modellabhängigkeiten. Das ist die richtige Perspektive. Sicherheitsteams müssen agentische Komponenten als produktive Abhängigkeiten und nicht als informelle Konfiguration behandeln.

Compliance darf kein nachträglicher Gedanke sein

Agentische KI erweitert die Compliance-Risiken, weil Agenten möglicherweise auf sensible Daten zugreifen, Entscheidungen beeinflussen, Datensätze erstellen, extern kommunizieren oder Aktionen innerhalb regulierter Workflows ausführen.

Bei der Compliance-Frage geht es nicht nur darum, ob das Modell genehmigt ist. Es geht darum, ob der gesamte agentische Workflow erklärt, überwacht, geprüft und kontrolliert werden kann.

Organisationen müssen folgende Fragen beantworten:

Welche Agenten sind im Einsatz?
Wer ist für die einzelnen Agenten verantwortlich?
Auf welche Daten kann jeder Agent zugreifen?
Welche Tools kann jeder Agent verwenden?
Für welche Aktionen ist die Genehmigung eines Menschen erforderlich?
Wie werden Prompts, Tools und Konfigurationen versioniert?
Wie werden Ausgaben protokolliert?
Wie werden Vorfälle erkannt und eskaliert?
Wie werden Agenten außer Betrieb genommen oder stillgelegt?

Wenn diese Fragen nicht beantwortet werden können, verfügt die Organisation nicht über ein Governance-Programm für agentische KI. Sie nutzt lediglich agentische KI.

Was Sicherheitsteams jetzt tun sollten

Die richtige Reaktion besteht nicht darin, jedes agentische System zu verbieten. Stattdessen muss ein Sicherheitsmodell geschaffen werden, das dem Risiko entspricht.

Erstellen Sie ein Inventar der Agenten: Identifizieren Sie bereits verwendete Agenten, Copiloten, Automatisierungen, Plugins, MCP-Server, Tool-Calling-Workflows und KI-Funktionen von Anbietern.
Berechtigungen und Tools erfassen: Dokumentieren Sie, auf welche Systeme jeder Agent zugreifen kann, welche Anmeldedaten er verwendet und welche Aktionen er ausführen kann.
Prinzip der geringsten Privilegien anwenden: Lassen Sie Agenten standardmäßig keine weitreichenden menschlichen Berechtigungen übernehmen. Beschränken Sie den Zugriff auf die jeweilige Aufgabe.
Vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Inhalten trennen: Behandeln Sie Dokumente, Webseiten, E-Mails, Tickets und Tool-Ausgaben als potenziell schädliche Eingaben.
Aktionen mit hoher Auswirkung absichern: Verlangen Sie für sensible Vorgänge eine Genehmigung, Überprüfung oder einen Probelaufmodus.
Speicher und Abruf absichern: Kontrollieren Sie, woran sich Agenten erinnern, was sie abrufen, ändern und über Benutzer- oder Sitzungsgrenzen hinweg teilen können.
Laufzeitverhalten überwachen: Protokollieren Sie Tool-Aufrufe, die Nutzung von Berechtigungen, Datenzugriffe, Ausgaben, Fehler und ungewöhnliche Aktionsmuster.
Agentische Workflows Red-Team-Tests unterziehen: Testen Sie auf Zielübernahme, Tool-Missbrauch, Missbrauch von Berechtigungen, Kontextvergiftung, unsichere Codeausführung und kaskadierende Ausfälle.

Diese Kontrollen sollten vor der Bereitstellung in die agentische Architektur integriert werden. Eine nachträgliche Ergänzung ist schwieriger, insbesondere nachdem Benutzer begonnen haben, sich auf das System zu verlassen.

Wie Ridiculous Engineering über die Sicherheit agentischer KI denkt

Bei Ridiculous Engineering betrachten wir die Sicherheit agentischer KI als Architekturproblem und nicht nur als Problem der Prompt-Härtung. Prompts sind wichtig, aber Agenten werden riskant, weil sie mit Tools, Identitäten, Daten, Speicher, APIs, Workflows und Menschen verbunden sind.

Das bedeutet, dass die Sicherheit von Agenten über das gesamte System hinweg konzipiert werden muss. Worauf kann der Agent zugreifen? Was kann er ändern? Welcher Kontext kann ihn beeinflussen? Was wird protokolliert? Was erfordert eine Überprüfung? Wer ist nach der Bereitstellung für den Agenten verantwortlich? Wie erkennt die Organisation unsicheres Verhalten, bevor daraus ein geschäftlicher Vorfall wird?

Wir helfen Kunden, diese Fragen praxisnah anzugehen. Das kann bedeuten, agentische Workflows zu inventarisieren, Berechtigungen und Datenzugriffe zu erfassen, Tool-Integrationen zu überprüfen, Governance-Gates zu entwerfen, Überwachung aufzubauen, sicherere Bereitstellungsmuster zu entwickeln oder Teams dabei zu unterstützen, von experimentellen Agenten zu Produktionssystemen mit klareren Kontrollen überzugehen.

Das Ziel besteht nicht darin, Innovation um ihrer selbst willen zu verlangsamen. Ziel ist es, agentische KI nutzbar zu machen, ohne dass die Autonomie die Verantwortlichkeit überholt.

Das Wichtigste in Kürze

Agentische KI ist kein Sicherheitsproblem der Zukunft. Sie ist ein gegenwärtiges Architekturproblem.

Die OWASP Top 10 für agentische Anwendungen, die Sicherheitsempfehlungen von Palo Alto Networks, die Analyse von Auth0 zu Zielübernahme und Tool-Missbrauch sowie die breitere Sicherheitsgemeinschaft weisen alle in dieselbe Richtung: Organisationen benötigen Transparenz, Identitätskontrolle, Schutzvorkehrungen zur Laufzeit, Tool-Governance, Speicherschutz und menschliche Aufsicht für KI-Agenten.

All das kann man nicht am Ende an eine fragile Architektur anbauen und erwarten, dass sie standhält.

Wenn Ihre Organisation mit KI-Agenten experimentiert, agentische Workflows bereitstellt oder herausfinden möchte, ob ihr Sicherheitsmodell für autonome Systeme bereit ist, kann Ridiculous Engineering helfen. Wir arbeiten mit Teams zusammen, um die Architektur zu bewerten, agentische Risiken zu identifizieren und Kontrollen zu entwickeln, die KI-Systemen ermöglichen, innerhalb der richtigen Grenzen zu arbeiten.

Agentische KI kann leistungsfähig sein. Sie muss aber auch wie etwas Leistungsfähiges gesteuert werden.

Quellen und weiterführende Literatur: OWASP: Top 10 für agentische Anwendungen 2026, OWASP GenAI Security Project: Top 10 Risiken und Gegenmaßnahmen für die Sicherheit agentischer KI, Palo Alto Networks: OWASP Top 10 für agentische Anwendungen 2026, Auth0: Erkenntnisse aus den OWASP Top 10 für agentische Anwendungen, DeepTeam: OWASP Top 10 für Agenten 2026, Teleport: OWASP Top 10 für agentische Anwendungen

OWASP Top 10 für agentische KI: Worauf sich Sicherheitsteams 2026 vorbereiten müssen