KI-Agenten-Vorfall: Was echte Prompt-Injection-, Tool-Missbrauch- und Exfiltrations-Breaches lehren

Ein KI-Agenten-Vorfall sieht selten aus wie ein klassischer Hack. Es gibt keinen Brute-Force-Angriff, kein ausgenutztes Buffer-Overflow, oft nicht einmal einen Klick des Opfers. Stattdessen liest der Agent eine E-Mail, ein Ticket oder ein Dokument — und tut anschließend genau das, was ein Angreifer hineingeschrieben hat. Wer verstehen will, warum agentische KI ein eigenes Bedrohungsmodell braucht, muss die dokumentierten Breaches sezieren, statt über hypothetische Szenarien zu spekulieren.

Dieser Artikel nimmt drei reale, öffentlich belegte Vorfallsklassen auseinander: indirekte Prompt-Injection (EchoLeak in Microsoft 365 Copilot), Tool-Missbrauch über das Model Context Protocol (der GitHub-MCP-Vorfall von Invariant Labs) und die stille Daten-Exfiltration als gemeinsames Endspiel beider. Sie sind konkrete Belege für die Muster, die wir in der Bedrohungslandschaft für KI-Agenten 2026 im Überblick einordnen. Aus jeder Breach-Analyse ziehen wir konkrete Lehren, die sich am selben Tag in Ihrer Architektur umsetzen lassen.

Was ist ein KI-Agenten-Vorfall — und warum unterscheidet er sich von klassischen Breaches?

Ein KI-Agenten-Vorfall ist eine Sicherheitsverletzung, bei der ein LLM-gestützter Agent durch nicht vertrauenswürdige Eingaben dazu gebracht wird, Aktionen auszuführen, die der legitime Nutzer nie autorisiert hat — etwa Daten auszulesen, an Externe zu senden oder Werkzeuge (Tools) zweckzuentfremden. Der entscheidende Unterschied zum klassischen Breach: Es wird keine Software-Schwachstelle im engeren Sinn ausgenutzt, sondern die fehlende Trennung zwischen Anweisung und Inhalt im Kontextfenster des Modells.

Genau hier liegt die strukturelle Wurzel. Ein Sprachmodell verarbeitet die Systemanweisung des Betreibers, die Eingabe des Nutzers und abgerufene Fremdinhalte im selben Kontextfenster — und kann sie nicht zuverlässig auseinanderhalten. Die OWASP-Liste der Top-10-Risiken für LLM-Anwendungen führt Prompt-Injection 2025 deshalb als Risiko Nummer eins (LLM01). Es ist kein Bug, der sich mit einem Patch schließen lässt, sondern eine Eigenschaft der Architektur.

Daraus folgt eine unbequeme Wahrheit, die selbst die Hersteller offen aussprechen: OpenAI räumte beim Start von „Lockdown Mode“ für ChatGPT im Februar 2026 ein, dass Prompt-Injection in KI-Browsern „möglicherweise nie vollständig behoben“ werden kann. Wer einen Agenten produktiv einsetzt, plant also nicht für die Verhinderung jeder Injection, sondern für deren Eindämmung — eine Verschiebung der Denkweise, die das Fundament jeder seriösen Breach-Analyse bildet.

Fallstudie 1: EchoLeak — die erste Zero-Click-Prompt-Injection in einem Produktivsystem

Im Juni 2025 veröffentlichten die Forscher von Aim Security mit EchoLeak (CVE-2025-32711, CVSS 9.3) den ersten dokumentierten Fall, in dem eine indirekte Prompt-Injection in einem produktiven KI-System zu nachweisbarer Daten-Exfiltration führte. Das Bemerkenswerte: Das Opfer musste nichts anklicken. Eine einzige präparierte E-Mail genügte.

Wie lief die Angriffskette ab?

Die Stärke dieser Prompt-Injection-Fallstudie liegt in der Verkettung mehrerer Umgehungen, von denen jede für sich harmlos wirkt:

1. RAG-Spraying. Der Angreifer sendet eine E-Mail, die mit diversen Geschäftsthemen und Formaten gespickt ist. Ziel ist, dass Copilots Retrieval-Augmented-Generation-Engine diese Nachricht später bei irgendeiner legitimen Nutzerfrage als Kontext heranzieht.
2. XPIA-Bypass. Die schädliche Anweisung ist so formuliert, dass sie Microsofts Klassifikator für Cross-Prompt-Injection-Versuche (XPIA) nicht auslöst — sie liest sich wie an einen Menschen gerichtet, nicht wie ein Befehl an die KI.
3. Markdown-Bild-Exfiltration. Die Antwort des Agenten enthält ein Markdown-Bild im Referenz-Stil. Beim Rendern ruft der Browser die angreiferkontrollierte Bild-URL automatisch ab — und hängt die zuvor ausgelesenen Daten als Parameter an. Kein Klick nötig.
4. CSP-Umgehung. Die Content-Security-Policy hätte den Abruf blockieren müssen. Der Angreifer leitete den Payload jedoch über vertrauenswürdige Microsoft-Domains wie SharePoint oder Teams, die ohnehin erlaubt waren.

Welche Lehren zieht man aus EchoLeak?

Die wichtigste Erkenntnis: Eingebettete Klassifikatoren und Link-Redaktion sind notwendige, aber keine hinreichenden Schutzschichten. Jede einzelne Hürde wurde umgangen, weil sie isoliert betrachtet wurde. Wer Agenten absichert, muss den gesamten Datenfluss vom Abruf bis zum Rendering als eine Vertrauensgrenze behandeln — nicht als Kette unabhängiger Filter. Microsoft schloss die Lücke serverseitig im Mai 2025 — noch vor der öffentlichen Bekanntgabe im Juni 2025 —, doch der zugrunde liegende Konstruktionsfehler RAG-basierter Systeme betrifft potenziell viele weitere Anwendungen.

Fallstudie 2: Der GitHub-MCP-Vorfall — wenn Tool-Missbrauch private Repositories leert

Wenige Wochen zuvor, Ende Mai 2025, demonstrierten die Forscher von Invariant Labs aus Zürich einen Tool-Missbrauch-Vorfall, der zeigt, wie aus einer Prompt-Injection ein konkreter Datenabfluss wird. Schauplatz: der offizielle GitHub-MCP-Server, über den ein KI-Agent mit Repositories interagiert.

Wie wird ein harmloses Issue zum Exfiltrations-Werkzeug?

Der Angriff beginnt mit einem bösartigen, öffentlich erstellten GitHub-Issue in einem Repository des Opfers. Bittet der Entwickler seinen Agenten später um etwas so Banales wie „Schau dir die offenen Issues an“, liest der Agent die versteckte Anweisung im Issue-Text — und folgt ihr. In der dokumentierten Demonstration zog der gekaperte Agent daraufhin Inhalte aus privaten Repositories und schrieb sie in einen öffentlichen Pull Request: interne Projektdetails und sogar persönliche Gehaltsinformationen.

Warum gibt es dafür keinen einfachen Patch?

Die entscheidende Lehre dieses Vorfalls: Die Schwachstelle liegt nicht im Code des MCP-Servers, sondern in der Architektur der Berechtigungen. Entwickler hinterlegen typischerweise einen Personal Access Token (PAT) mit breitem Zugriff auf alle Repositories — öffentliche wie private. Der Agent erbt diese vollen Rechte. Sobald er gekapert ist, handelt er mit der Autorität des legitimen Nutzers – das klassische Muster des verwirrten Stellvertreters. Invariant Labs betonte, dass es keine triviale Lösung gibt; mildern lässt sich das Problem nur durch das Prinzip der minimalen Rechte: ein Token pro Session, Zugriff auf genau ein Repository, kein Schreibrecht ohne menschliche Freigabe. Wie Angreifer solche Ketten von der Aufklärung bis zur Aktion aufbauen, beleuchtet unser Forschungsbereich zu Angriffen auf KI-Agenten.

Tool-Missbrauch vs. Prompt-Injection vs. Exfiltration — wie hängen die drei zusammen?

Die drei Begriffe beschreiben keine getrennten Angriffe, sondern Phasen derselben Kette. Prompt-Injection ist der Einstieg, Tool-Missbrauch die Handlung, Exfiltration das Ziel. Die folgende Gegenüberstellung ordnet die diskutierten Vorfälle ein:

Phase	Mechanismus	Beispiel-Vorfall	Wirksame Gegenmaßnahme
Einstieg (Prompt-Injection)	Schädliche Anweisung in abgerufenem Fremdinhalt	EchoLeak (E-Mail), GitHub-MCP (Issue)	Inhalt strikt als Daten, nie als Anweisung behandeln
Handlung (Tool-Missbrauch)	Agent ruft legitime Werkzeuge mit fremder Absicht auf	GitHub-MCP (Repo-Zugriff via PAT)	Minimale Rechte, Tool-Allowlist, Bestätigung bei Schreibaktionen
Ziel (Exfiltration)	Daten verlassen die Vertrauensgrenze	EchoLeak (Markdown-Bild), MCP (öffentlicher PR)	Ausgehende Kanäle einschränken, Egress-Filter, CSP härten

Diese Phasenlogik ist die praktische Quintessenz jeder Breach-Analyse: Eine einzelne Verteidigungslinie reicht nicht. Wer nur die Injection bekämpft, scheitert an deren Unvermeidbarkeit; wer nur den Egress filtert, lässt den Agenten bereits kompromittiert agieren. Robuste Sicherheit setzt an allen drei Phasen gleichzeitig an — Tiefenverteidigung statt Einzelfilter.

Welche konkreten Lehren gelten für DACH-Teams im Jahr 2026?

Die Vorfälle wirken spektakulär, doch die Konsequenzen sind nüchtern und umsetzbar. Drei Prinzipien tragen die meiste Last.

Behandeln Sie jeden abgerufenen Inhalt als feindlich. E-Mails, Tickets, Webseiten, Dokumente — alles, was ein Agent liest, kann eine Anweisung enthalten. Die Systemarchitektur muss zwischen vertrauenswürdiger Betreiber-Anweisung und nicht vertrauenswürdigen Daten unterscheiden, auch wenn das Modell es selbst nicht zuverlässig kann. Markieren Sie Herkunft und Vertrauensstufe explizit im Kontext.

Geben Sie Agenten nur minimale Rechte. Der GitHub-MCP-Vorfall war erst durch den überprivilegierten Token möglich. Ein Agent sollte ausschließlich die Werkzeuge und Datenräume erreichen, die seine konkrete Aufgabe erfordert — scoped Tokens, Allowlists für Tools, getrennte Sessions. Schreibende oder irreversible Aktionen verlangen eine menschliche Freigabe (Human-in-the-Loop).

Härten Sie den ausgehenden Kanal. EchoLeak gelang, weil Daten den vertrauenswürdigen Bereich über ein automatisch geladenes Bild verlassen konnten. Prüfen Sie, welche Domains ein Agent kontaktieren darf, deaktivieren Sie das automatische Nachladen externer Ressourcen in KI-Antworten und behandeln Sie die Content-Security-Policy als aktive Sicherheitsgrenze, nicht als Formalität. Für Teams im DACH-Raum kommt die DSGVO-Dimension hinzu: Eine erfolgreiche Exfiltration personenbezogener Daten ist meldepflichtig — eine wirksame Egress-Kontrolle ist damit nicht nur Sicherheits-, sondern Compliance-Maßnahme.

Wie sollte eine Vorfallsanalyse für KI-Agenten konkret ablaufen?

Wenn der Verdacht eines KI-Agenten-Vorfalls aufkommt, hat die klassische Forensik eine Lücke: Der „Exploit“ steht oft im Klartext in einer harmlos aussehenden Eingabe. Eine belastbare Breach-Analyse folgt deshalb der Spur des Kontextfensters.

Rekonstruieren Sie zuerst die vollständige Eingabekette: Welche Dokumente, E-Mails oder Tickets landeten im Kontext, und woher stammten sie? Protokollieren Sie zweitens jeden Tool-Aufruf des Agenten mit Zeitstempel, Parametern und Ergebnis — dieser Trace ist das Pendant zum Audit-Log und entscheidet darüber, ob ein Vorfall überhaupt rekonstruierbar ist. Identifizieren Sie drittens den Übergangspunkt, an dem der Agent von legitimer Aufgabe zu fremdgesteuerter Handlung wechselte. Genau dort sitzt die Injection. Ohne lückenlose Protokollierung der Tool-Aufrufe bleibt jede nachträgliche Analyse Stückwerk — die wichtigste Vorbereitung auf einen Vorfall ist deshalb das Logging vor dem Vorfall. Kontinuierliche AgentOps-Observability-Plattformen wie OpsAgent liefern genau diese Tool-Aufruf-Traces und Reasoning-Logs bereits im laufenden Betrieb, statt sie erst nach einem Vorfall mühsam rekonstruieren zu müssen.

Fazit: Vorfälle sind die ehrlichste Bedrohungsmodellierung

Die dokumentierten Breaches von 2025 zeichnen ein klares Bild. EchoLeak zeigte, dass eine einzige E-Mail ohne Klick Unternehmensdaten abfließen lässt. Der GitHub-MCP-Vorfall bewies, dass ein überprivilegierter Token einen hilfreichen Agenten in einen Datendieb verwandelt – genau die identitätsbezogene Schwäche, die mehrere Punkte der OWASP Top 10 für agentische Anwendungen durchzieht. Beide enden bei derselben Exfiltration — und beide widerlegen die Hoffnung, ein einzelner Filter könne das Problem lösen.

Die übergeordnete Lehre ist zugleich beruhigend und unbequem: Prompt-Injection lässt sich nicht vollständig verhindern, ihre Folgen aber drastisch begrenzen. Wer nicht vertrauenswürdige Inhalte als feindlich behandelt, Rechte minimiert und den ausgehenden Kanal härtet, verwandelt einen potenziell katastrophalen KI-Agenten-Vorfall in einen kontrollierbaren Zwischenfall. Genau das ist die Aufgabe für Sicherheitsverantwortliche im Jahr 2026 — und sie beginnt damit, aus den realen Vorfällen anderer zu lernen, bevor man den eigenen erlebt.

Quellen

• EchoLeak / CVE-2025-32711, Aim Security (Juni 2025): The Hacker News, arXiv 2509.10540, Cato Networks
• GitHub-MCP-Vulnerability, Invariant Labs (Mai 2025): Invariant Labs, devclass
• OWASP LLM01:2025 Prompt Injection: OWASP Gen AI Security Project