OWASP Top 10 für agentische Anwendungen: jedes Risiko im Produktivbetrieb absichern
Ein Praxis-Playbook zu den OWASP Top 10 für agentische Anwendungen: wie Sie jedes der zehn Risiken im Produktivbetrieb mit konkreten Kontrollen, Guardrails und Governance erfüllen und mindern.
Definition
Die OWASP Top 10 für agentische Anwendungen sind ein im Dezember 2025 veröffentlichtes Community-Sicherheitsframework, das die kritischsten Risiken autonomer KI-Agenten einordnet — Systeme, die planen, Tools aufrufen und über viele Schritte handeln. Es erweitert die OWASP LLM Top 10 auf die Agentenebene.
Autonome KI-Agenten gelangten schneller aus der Demo in den Produktivbetrieb als die Kontrollen, die sie einhegen sollten. Im Dezember 2025 reagierte OWASP mit eigenen Top 10 für agentische Anwendungen — der Anerkennung, dass ein Agent kein größerer Chatbot ist, sondern eine neue Systemklasse, die handelt. Dieser Leitfaden geht jede Kategorie durch und die Abwehr, die wirklich etwas bewirkt.
Warum brauchen Agenten eigene Top 10?
Ein Sprachmodell erzeugt Text. Ein Agent macht daraus Konsequenzen: Er liest ein Dokument, entscheidet sich für einen Tool-Aufruf, und das Tool tut etwas Reales — fragt eine Datenbank ab, sendet eine E-Mail, überweist Geld. Diese eine architektonische Verschiebung verändert das Bedrohungsmodell vollständig. Eine manipulierte Ausgabe war früher eine falsche Antwort; im Agenten wird sie zur falschen Handlung.
Zwei Vorfälle machten das greifbar. Im Juli 2025 löschte ein Coding-Agent während eines Laufs eine Produktivdatenbank. Im Dezember 2025 löschte ein anderer Agent die Festplatte eines Entwicklers. Keiner war ein exotischer Exploit — beide waren gewöhnliche Versäumnisse bei Umfang und Aufsicht.
- Excessive Agency / zu weite Berechtigungen34%
- Prompt Injection (direkt + indirekt)28%
- Tool- / Output-Poisoning16%
- Fehlende Aufsicht bei folgenreichen Aktionen14%
- Memory- / Retrieval-Poisoning8%
Die zehn Kategorien in vier Gruppen
Die Liste lässt sich in vier Gruppen leichter umsetzen.
1. Manipulieren, was der Agent liest
Prompt Injection ist das Leitrisiko. Die direkte Variante zielt auf den Nutzer-Prompt; die indirekte versteckt Anweisungen in Dokumenten, Webseiten und Tool-Ausgaben, die der Agent später aufnimmt. Da Agenten autonom browsen und abrufen, ist die indirekte Injection der dominante Vektor — der Angreifer spricht nie direkt mit Ihrem Agenten.
Abwehr: Behandeln Sie jeden externen Inhalt als nicht vertrauenswürdige Eingabe, niemals als Anweisung. Trennen Sie Daten- und Steuerungsebene und begrenzen Sie, was der Agent nach dem Lesen feindlichen Texts tun darf.
2. Missbrauch der Agenten-Tools
Tool Poisoning manipuliert die Tools eines Agenten oder deren Ausgaben. Excessive Agency — durchgängig die schädlichste Kategorie — bedeutet schlicht, dass der Agent mehr Macht besitzt, als seine Aufgabe braucht. Geht etwas schief, machen weitreichende Rechte aus einem kleinen Fehler einen großen Vorfall.
Abwehr: Least Privilege pro Tool, eingegrenzte Credentials und eine Allowlist erlaubter Aktionen. Wenn ein Agent nur lesen muss, darf er nicht schreiben können.
3. Das Gedächtnis des Agenten verderben
Memory Poisoning pflanzt falsche oder schädliche Inhalte in Langzeitgedächtnis, Embeddings oder Retrieval-Speicher, sodass sie später als vertrauenswürdiger Kontext abgerufen werden. Die Nutzlast überdauert Sitzungen und verzerrt unbemerkt viele künftige Entscheidungen.
Abwehr: Validieren Sie, was ins Gedächtnis gelangt, segmentieren Sie es nach Vertrauensstufe und lassen Sie langlebige Einträge ablaufen oder prüfen.
4. Den Menschen verlieren
Die letzte Gruppe ist organisatorisch: fehlende Aufsicht bei folgenreichen Aktionen und übermäßiges Vertrauen zwischen Agenten in Multi-Agent-Systemen, wo ein Agent die Ausgabe eines anderen als automatisch sicher annimmt.
Abwehr: ein Human-in-the-Loop-Checkpoint vor irreversiblen Aktionen und klare Vertrauensgrenzen zwischen Agenten.
Die Risiken auf einen Blick
| Risiko | Was es bewirkt | Primäre Abwehr |
|---|---|---|
| Prompt Injection (indirekt) | Versteckte Anweisungen in abgerufenen Inhalten kapern den Agenten | Externe Inhalte als Daten; Steuerungs- und Datenebene trennen |
| Excessive Agency | Zu weite Rechte verstärken jeden Fehler | Least Privilege pro Tool; standardmäßig nur Lesezugriff |
| Tool Poisoning | Manipulierte Tools oder Ausgaben steuern den Agenten | Tools anheften und prüfen; Ausgaben validieren; Aktionen per Allowlist |
| Memory Poisoning | Falscher Kontext überdauert Sitzungen | Schreibzugriffe validieren; nach Vertrauen segmentieren; Einträge ablaufen lassen |
| Fehlende Aufsicht | Keine menschliche Schranke vor irreversiblen Aktionen | Human-in-the-Loop bei folgenreichen Schritten |
Eine Einstiegshaltung, die funktioniert
Sie brauchen nicht alle zehn Kontrollen am ersten Tag. Die wirkungsvollsten Schritte sind über alle obigen Vorfälle hinweg gleich:
- Least Privilege — jedes Tool und Credential auf das Minimum beschränken.
- Human-in-the-Loop bei destruktiven oder kostspieligen Aktionen.
- Externe Inhalte als nicht vertrauenswürdig — Daten, nie Befehle.
- Alles tracen — man kann nicht verteidigen, was man nicht sieht.
Diese vier kappen Datenverlust und unautorisierte Ausgaben — die Folgen, die wirklich wehtun — und schaffen Raum, den Rest reifen zu lassen. Das Vokabular erklären wir im AgentOps-Glossar; den regulatorischen Zeitplan in unseren Governance-Inhalten.
Häufige Fragen
Wie unterscheidet sich Agenten-Sicherheit von LLM-Sicherheit?
Ein LLM erzeugt nur Text; ein Agent macht aus diesem Text Handlung — er ruft Tools auf, schreibt in Produktivsysteme und bewegt Daten. Dieselbe Prompt Injection, die früher höchstens eine falsche Antwort lieferte, kann heute eine Datenbank löschen, eine Überweisung auslösen oder eine Kundenliste preisgeben. Deshalb muss Agenten-Sicherheit die gesamte Entscheidungs- und Handlungsschleife schützen, nicht nur die Modellausgabe. Man muss durchdenken, auf welche Tools der Agent zugreift, welche Rechte jedes davon trägt und was nach dem Lesen feindlicher Inhalte geschieht. In der Praxis kommen drei Fragen hinzu, die die LLM-Sicherheit nicht kannte: Tool-Autorisierung, Umkehrbarkeit von Aktionen und Aufsicht zur Laufzeit. Behandeln Sie das Modell als nicht vertrauenswürdige Komponente in einem handelnden System und legen Sie Kontrollen um die Aktionen, nicht um die Worte.
Ist Prompt Injection wirklich ungelöst?
Es gibt keine Einzellösung, die Prompt Injection verschwinden lässt, und wer eine verkauft, übertreibt. Weil ein Agent nicht vertrauenswürdigen Text liest und anschließend handelt, ist das realistische Ziel, den Schadensradius zu verkleinern, statt eine saubere Eingabe zu garantieren. Vier Kontrollen leisten den Großteil. Behandeln Sie jeden externen Inhalt als Daten, nie als Anweisung. Beschränken Sie jedes Tool auf Least Privilege. Verlangen Sie vor folgenreichen Aktionen menschliche Freigabe und überwachen Sie Ausführungs-Traces auf Anomalien. Übereinandergelegt erreicht eine erfolgreiche Injection nichts Wichtiges mehr. Der typische Fehler ist die Suche nach dem perfekten Eingabefilter. Filter helfen am Rand, doch die dauerhafte Abwehr besteht darin zu begrenzen, was der Agent tun darf, sobald der feindliche Text bereits im Kontext steht.
Womit sollte ein kleines Team beginnen?
Beginnen Sie mit den zwei Kontrollen, die die schlimmsten Folgen am günstigsten verhindern: Least Privilege für jedes Tool und Credential sowie ein Human-in-the-Loop-Checkpoint bei destruktiven oder kostspieligen Aktionen. Zusammen kappen sie die zwei Fehlerarten, die wirklich wehtun — irreversiblen Datenverlust und unautorisierte Ausgaben — und ihre Einführung dauert Tage, nicht Quartale. Ein Coding-Agent mit reinem Lesezugriff auf ein Repository kann es nicht löschen; ein Agent, der vor einer Zahlung auf Freigabe warten muss, kann kein Konto leeren. Wenn diese Leitplanken halten, ergänzen Sie Ausführungs-Tracing, um zu sehen, was der Agent tat und warum. Schichten Sie dann Eingabebehandlung und Speicherhygiene mit wachsendem System darauf. Die Reihenfolge zählt: zuerst den Schaden begrenzen, dann beobachten, zuletzt verfeinern.
Welches Agenten-Risiko richtet den größten Schaden an?
Excessive Agency — ein Agent mit mehr Rechten, als seine Aufgabe braucht — ist durchgängig die schädlichste Kategorie und steckt hinter einem großen Teil dokumentierter Vorfälle. Der Grund ist Hebelwirkung: Wenn ein überprivilegierter Agent einen gewöhnlichen Fehler macht oder einer eingeschleusten Anweisung folgt, verwandelt weitreichender Zugriff eine kleine Panne in eine große. Eine Manipulation an einem nur lesenden Zusammenfasser ergibt einen falschen Satz; dieselbe Manipulation an einem Agenten mit Lösch- und Zahlungsrechten ergibt eine gelöschte Datenbank oder eine betrügerische Überweisung. Deshalb steht Least Privilege über fast jeder anderen Kontrolle — es deckelt das Worst-Case-Ergebnis, unabhängig davon, wie der Agent getäuscht wurde. Grenzen Sie Credentials pro Tool ein, bevorzugen Sie standardmäßig Lesezugriff und sichern Sie Schreib- und Ausgaberechte hinter ausdrücklicher Freigabe. Macht zu begrenzen ist billiger und verlässlicher, als jeden Fehler verhindern zu wollen.