OWASP Top 10 für agentic AI:
PII-Risiken und Mitigationen

OWASP veröffentlichte im Dezember 2025 die Top 10 für agentic AI — ein Framework speziell für autonome KI-Agenten, die Aktionen ausführen, Tools aufrufen und Entscheidungen verketten können, ohne schrittweise menschliche Überwachung. Im Gegensatz zur LLM Top 10 erkennt die Liste für agentic AI an, dass Agenten jedes PII-Risiko verstärken: Ein einziger manipulierter Speichereintrag oder ein falsch konfiguriertes Tool kann Daten über den gesamten Workflow hinweg offenlegen. Hier erfahren Sie, was jedes Risiko für personenbezogene Daten bedeutet — und wie Sie es minimieren.

Was hat sich geändert: LLM-Risiken vs. agentic AI-Risiken

Die ursprüngliche OWASP LLM Top 10 (2023/2025) konzentrierte sich auf Risiken, bei denen ein Mensch noch eingebunden war — Prompt Injection, Trainingsdaten-Vergiftung, excessive Agency. Die agentic AI Top 10 geht von einem grundlegend anderen Bedrohungsmodell aus: Die KI führt einen mehrstufigen Workflow aus, ruft echte APIs auf, schreibt in echte Datenbanken und trifft schneller Entscheidungen, als ein Mensch überprüfen kann.

Die Konsequenz für PII ist dramatisch. In einem agentic Workflow durchlaufen personenbezogene Daten nicht nur ein Modell — sie können in Vektor-Memory gespeichert, an Sub-Agenten weitergeleitet, in externe Tools geschrieben und bei jedem Schritt protokolliert werden. Jeder Hop ist ein potenzieller Offenlegungspunkt.

Die OWASP Agentic AI Top 10 (2026)

Die vollständige Liste wurde im Dezember 2025 als Teil von OWASPs Antwort auf die schnelle Adoption von autonomen Agent-Frameworks veröffentlicht. Die sieben Top-Einträge mit direkter PII-Relevanz:

AA1 — Memory Poisoning: das gefährlichste PII-Risiko

Memory Poisoning steht an der Spitze der OWASP Agentic AI Liste, weil es am schwierigsten zu erkennen und am weitesten in der Auswirkung ist. Im Gegensatz zu einer einmaligen Prompt Injection (die eine Antwort betrifft) bleibt ein manipulierter Memory-Eintrag über alle zukünftigen Sessions und alle Benutzer bestehen, die den gleichen Memory-Speicher teilen.

Das PII-Szenario: Ein Angreifer übermittelt ein Dokument mit einem sorgfältig ausgearbeiteten „Datensatz über einen Benutzer", das echte persönliche Identifikatoren in anscheinend harmlosen Text eingebettet enthält. Der Agent extrahiert diese als Fakten und speichert sie im Vector Memory. In einer zukünftigen Session — für einen völlig anderen Benutzer — ruft der Agent diesen Memory-Eintrag ab, wenn eine semantisch ähnliche Abfrage erfolgt, und das injizierte PII taucht in der Antwort auf.

AA3 & AA4 — Sensitive Information Disclosure und Tool Poisoning

AA3 (Sensitive Information Disclosure) und AA4 (Tool Poisoning) sind die beiden Agentic AI-Risiken, die sich am direktesten auf die MCP-Sicherheitskrise des Frühjahrs 2026 beziehen. Das Model Context Protocol hat keine native Authentifizierung, keine Verschlüsselung und keine PII-bewusste Filterung — was es zu einer idealen Angriffsfläche für beide Risiken macht.

Tool Poisoning (AA4) nutzt aus, dass MCP-Tool-Beschreibungen von Agenten implizit vertraut und ausgeführt werden. Eine böswillige Tool-Beschreibung kann den Agenten anweisen, env:ANTHROPIC_API_KEY oder den Inhalt von ~/.ssh/id_rsa in seinen nächsten Tool-Call einzubeziehen — beide echte Schwachstellen, die in den CVE-Offenlegungen von Januar–Februar 2026 gegen MCP-Server dokumentiert sind.

Die einzige strukturelle Verteidigung gegen AA4 ist die Gewährleistung, dass selbst wenn ein Agent manipuliert wird, vertrauliche Inhalte in eine Tool-Call-Payload einzubeziehen, dieser Inhalt vor der Ausführung der Vertrauensgrenze anonymisiert wurde. Eine anonymisierte Payload mit [CREDENTIAL_1] gibt einem Angreifer nichts Nützliches.

AA7 — Data Exfiltration: Agentic Automation als Exfil-Kanal

Traditionelle Datenexfiltration erforderte, dass ein Angreifer aktiv Daten extrahierte — Zugang gewann, Abfragen ausführte, Daten bewegte. Agentic AI dreht dies um: Der Agent selbst wird zum Exfiltrationsmechanismus. Ein kompromittierter oder schlecht konfigurierter Agent mit Zugang zu Kundendaten und der Fähigkeit, ausgehende HTTP-Calls durchzuführen (über Webhooks, Notification-Tools oder File Uploads), kann angewiesen werden, diese Daten an einen Angreifer-kontrollierten Endpoint in einem einzelnen, prüfbar normal aussehenden Tool-Call zu leiten.

Die OWASP AA7-Mitigation ist zweifach: Begrenzen Sie ausgehende Tool-Berechtigungen und anonymisieren Sie alle ausgehenden Payloads. anonymize.dev adressiert die zweite Kontrolle — jeder Parameter, der an einen ausgehenden Tool-Call übergeben wird, wird durch die Anonymisierungs-Pipeline verarbeitet, bevor er versendet wird.

Der Toxic Agent Flow: AA1 + AA3 + AA7 kombinieren

Das gefährlichste agentic PII-Szenario ist nicht eine einzelne Schwachstelle — es ist eine Kette. Sicherheitsforscher haben dokumentiert, was jetzt „Toxic Agent Flow" genannt wird:

1. AA1 (Memory Poisoning): Angreifer manipuliert den Agent-Memory mit einer Trigger-Anweisung, die in ein Kundendokument eingebettet ist.
2. AA3 (Privilege Compromise): Der Trigger aktiviert sich, wenn ein privilegierter Benutzer den Agent abfragt — sein Session-Token oder Kontext wird zur manipulierten Memory-Abrufung übergeben.
3. AA7 (Data Exfiltration): Die aus dem Memory abgerufene Anweisung lenkt den Agenten an, die aktuellen Dokumente des Benutzers zusammenzufassen und die Zusammenfassung an eine externe URL zu POSTen.

Die vollständige Kette erfordert keine Code-Ausführung, keine Schwachstelle-Exploitation und keine Netzwerk-Einbruch. Sie erfordert nur, dass der Agent untrusted Dokumentinhalte verarbeitet und ausreichende Berechtigungen hat.

Wie anonymize.dev die Agentic AI Top 10 adressiert

Das MCP Server-Integrationsmodell ist mit der OWASP Agentic AI-Verteidigungsarchitektur ausgerichtet: Behandeln Sie jeden KI-Input und jeden Tool-Call-Parameter als untrusted, und wenden Sie PII-Kontrollen auf der Protokoll-Schicht statt im Application-Code an.

Das Operator-System erlaubt granulare Kontrolle über welche Entities pro Tool und pro Workflow-Schritt anonymisiert werden. Ein finanzieller agentic Workflow könnte replace für Kundennamen und redact für Kontonummern verwenden — konsistent über alle 7 MCP-Tools in der Integration angewendet.

GDPR-Compliance-Implikationen der agentic AI-Verarbeitung

Aus GDPR-Perspektive führen agentic AI-Workflows drei unterschiedliche Rechtsverpflichtungen ein, die Single-Model-Integrationen nicht haben:

• Datenminimierung (Art. 5(1)(c)): Jeder Agent-Schritt sollte nur die für diese spezifische Operation notwendigen personenbezogenen Daten verarbeiten. Anonymisierung bei jedem Schritt erzwingt Datenminimierung strukturell.
• Zweckbindung (Art. 5(1)(b)): Für eine agentic Task gesammelte Daten dürfen nicht von anderen Agenten oder Memory-Lookups umfunktioniert werden. Anonymisierte Memory-Speicher können nicht umfunktioniert werden, weil sie keine identifizierbaren Daten enthalten.
• Datenverarbeitungsvereinbarungen (Art. 28): Jedes externe Tool, das ein Agent aufruft, ist ein separater Datenverarbeiter. Wenn das Tool PII erhält, ist eine DPA erforderlich. Das Anonymisieren von Tool-Eingaben könnte diese Anforderung für viele Tools beseitigen.

Implementierung: Privacy-as-Code für agentic Workflows

Das praktische Implementierungsmuster für OWASP Agentic AI-Compliance mit anonymize.dev sind vier Zeilen Konfiguration in Ihrem MCP-Server-Setup:

{
  "anonymize": {
    "command": "npx",
    "args": ["-y", "@anonymize/mcp-server"],
    "env": {
      "ANONYMIZE_API_KEY": "your-key",
      "ANONYMIZE_OPERATORS": "replace"
    }
  }
}

Mit dieser Konfiguration durchlaufen alle Tool-Aufrufe, die Ihr KI-Coding-Agent tätigt, den anonymize.dev MCP Server. PII in Prompts, File Reads und Tool-Outputs wird abgefangen und ersetzt, bevor es das Modell erreicht — adressiert AA1, AA2, AA3, AA4 und AA7 mit einer einzigen Infrastruktur-Kontrolle.