Spaniens Datenschutzbehörde hat nach eigenen Angaben die erste Meldung des Landes über eine Verletzung des Schutzes personenbezogener Daten erhalten, bei der ein KI-Agent den Angriff ausgeführt haben soll. Der Vorgang ist bemerkenswert, weil das System nicht nur zum Formulieren von Phishing-Texten oder zum Vorschlagen von Befehlen eingesetzt wurde. Nach Angaben der Agencia Española de Protección de Datos (AEPD) nutzte der Agent ein bekanntes Large Language Model, verschaffte sich Zugang zu einer Anwendung eines Unternehmens, suchte nach Schwachstellen, veränderte personenbezogene Daten und griff auf Rechnungen zu.

Abstraktes Cybersicherheitsnetz mit Zugriffswegen eines KI-Agenten, Audit-Protokollen und einer roten Eindämmungsgrenze in einem dunklen Serverraum.

Diese Beschreibung verdient Aufmerksamkeit, muss aber vorsichtig eingeordnet werden. Die AEPD hat weder den Namen des Unternehmens noch den Namen des Modells, die genaue Schwachstelle, die Zahl der betroffenen Personen oder eine forensische Rekonstruktion des Vorfalls veröffentlicht. Die Behörde erklärt, dass die Informationen aus der Meldung des betroffenen Unternehmens stammen und noch analysiert werden müssen. Es handelt sich um einen gemeldeten Vorfall, nicht um einen Beleg dafür, dass jeder KI-Agent jede Anwendung selbstständig aufbrechen kann.

Trotzdem ist der Fall ein nützliches Sicherheitssignal. Die entscheidende Veränderung besteht nicht darin, dass ein Angreifer ein KI-Modell eingesetzt hat. Sie besteht darin, dass Software mit einem Ziel, Zugangsdaten, Werkzeugen und der Fähigkeit, Ergebnisse zu interpretieren, offenbar mehrere Phasen eines Eindringens in eine automatisierte Schleife verdichtet hat. Damit verschiebt sich die Verteidigungsfrage von der Frage, wie man einen KI-Angriff stoppt, zu der Frage, welche Konten, Werkzeuge und Aktionen ohne unabhängige Kontrolle zu schnell oder zu weit gehen können.

Was die AEPD tatsächlich berichtet hat

Die Darstellung der AEPD ist bewusst begrenzt. Eine Person setzte einen KI-Agenten mit einem bekannten Sprachmodell gegen eine Organisation ein. Der Agent durchsuchte zunächst allgemeine Dateien nach Schwachstellen und nutzte anschließend einen gültigen Login, um in das System der Organisation einzudringen. Dort suchte er weiter nach Schwächen in der Anwendung. Er fand eine Route, über die er personenbezogene Informationen ändern und auf Rechnungen zugreifen konnte.

Diese Angaben zeigen die Struktur des Ereignisses, nicht jeden technischen Einzelschritt. Aus den öffentlichen Berichten geht nicht hervor, ob der Login von einem gestohlenen Passwort, einem Sitzungstoken, einem offengelegten Geheimnis oder einer anderen Quelle stammte. Ebenso unbekannt ist, ob die Anwendung eine fehlende Autorisierungsprüfung, ein Injection-Problem, einen unsicheren Pfad zur Dateiverarbeitung oder eine andere Schwäche aufwies. Wer diese Lücken ausfüllt, macht aus einer vorsichtigen Mitteilung der Aufsicht einen erfundenen Incident-Report.

Der Unterschied zwischen einem Agenten, der sich anmeldete, und einem Agenten, der die Authentifizierung umging, ist wichtig. Auch nach einem gültigen Login kann unbefugte Aktivität folgen, wenn das Konto übermäßige Berechtigungen besitzt, wenn die Anwendung keine Autorisierung auf Objektebene durchsetzt oder wenn eine Benutzersitzung Funktionen außerhalb ihres vorgesehenen Zwecks erreicht. Viele schwere Vorfälle beginnen mit einer gewöhnlich wirkenden Identität und werden erst deshalb folgenreich, weil nachgelagerte Systeme dieser Identität zu weit vertrauen.

Die AEPD hat außerdem nicht gesagt, dass die Infrastruktur des Modellanbieters kompromittiert wurde. Die öffentliche Beschreibung deutet auf einen Agenten hin, der gegen die Anwendung einer separaten Organisation operierte. Der Fall ist daher vor allem für Anwendungsbetreiber, Identitätsteams und Organisationen relevant, die vernetzte Agenten einsetzen. Er ist kein Beleg für einen Einbruch beim nicht genannten Modellanbieter.

Warum sich der Fall von einem gewöhnlichen Chatbot unterscheidet

Ein herkömmlicher Chatbot liefert eine Antwort. Ein vernetzter Agent kann ein Ziel erhalten, einen Arbeitskontext behalten, Werkzeuge aufrufen, das Ergebnis einer Aktion prüfen und die nächste Aktion auswählen. Je nach Aufbau kann er Dateien durchsuchen, APIs abfragen, Code ausführen, sich bei Diensten anmelden oder Datensätze aktualisieren. Das Modell ist nur eine Komponente des Systems. Die Sicherheitsgrenze umfasst auch die Orchestrierung, die Werkzeugdefinitionen, Zugangsdaten, Netzwerkpfade, Datenspeicher und Freigabelogik.

Diese Unterscheidung erklärt, warum der spanische Bericht wichtig ist, ohne etwas Magisches zu zeigen. Die zugrunde liegenden Techniken sind vertraut: Nutzung von Zugangsdaten, Suche nach Schwachstellen, unbefugter Datenzugriff und unbefugte Änderungen. Ein Agent kann solche Schritte schneller, paralleler und mit weniger manuellen Entscheidungen ausführen. Ein menschlicher Operator macht naturgemäß Pausen: Er liest die Ausgabe, wechselt das Werkzeug, entscheidet, ob ein Ergebnis nützlich ist, und tippt den nächsten Befehl. Eine automatisierte Schleife kann diese Entscheidungen mit Maschinengeschwindigkeit wiederholen.

Geschwindigkeit wirkt sich auf Erkennung und Eindämmung aus. Ein Überwachungsteam hat möglicherweise Zeit, einen Menschen bei der Erkundung eines einzelnen Endpunkts zu bemerken. Ein Agent kann dagegen in einer einzigen Sitzung viele Anfragen stellen, Fehlermeldungen interpretieren und seinen Pfad ändern. Das erhöht auch den Wert präventiver Kontrollen. Wenn ein Konto mit geringen Rechten sensible Datensätze entdecken und anschließend verändern kann, erzeugt ein schnellerer Angreifer die ursprüngliche Schwäche nicht. Er macht sie lediglich leichter erreichbar, bevor jemand eingreift.

Autonomie schafft während einer Untersuchung zusätzliche Unklarheit. Ein Protokoll kann gültige API-Aufrufe zeigen, die mit einem gültigen Token vorgenommen wurden. Die Transportschicht kennzeichnet eine Anfrage nicht automatisch als KI-generiert. Ermittler müssen das Verhalten daher aus Abfolge, Zeitpunkten, Umfang und Zweck rekonstruieren: ungewöhnliche Verkettungen von Werkzeugen, schnelles Durchlaufen nicht zusammengehöriger Objekte, wiederholte Validierungsversuche, Zugriffe außerhalb des normalen Aufgabensatzes und Änderungen, die nicht zur Rolle des Kontos passen.

Ausnutzungsstatus: eine dokumentierte Meldung, keine Kampagne

Die derzeit öffentlich bekannten Informationen beschreiben eine Meldung, die bei der AEPD eingegangen ist. Sie belegen keine benannte Bedrohungsgruppe, keinen wiederverwendbaren Exploit, keine laufende Kampagne und keine modellspezifische Schwachstelle. Es gibt keine CVE, die gepatcht werden könnte, und keinen Grund zu behaupten, ein bestimmtes KI-Produkt habe eine systemische Kompromittierung verursacht.

Diese Unsicherheit sollte die Reaktion bestimmen. Sicherheitsteams sollten nicht auf einen spektakulären Indikator für KI-Malware warten. Sie sollten aber auch nicht unterschiedslos jede Anfrage untersuchen, die in der Nähe eines KI-Dienstes erfolgt. Die praktische Aufgabe besteht darin, zu erkennen, wo Automatisierung unter einer Identität handeln kann und wo die Anwendung dieser Identität zu stark vertraut.

Der Fall eignet sich als wertvolle Validierungsübung. Organisationen sollten testen, ob ein kompromittiertes oder missbrauchtes Konto mehr personenbezogene Daten lesen kann, als seine Aufgabe erfordert, ob es Datensätze ohne zweite Kontrolle verändern kann, ob API-Tokens lange gültig sind, ob sensible Aktionen Warnungen auslösen und ob Einsatzkräfte Zugriffe sofort entziehen können. Diese Fragen bleiben sinnvoll, unabhängig davon, ob ein späterer forensischer Bericht die Handlungen einem KI-Agenten, einem Skript oder einer Person mit gewöhnlichen Werkzeugen zuschreibt.

Die erste Priorität ist eine Karte der Agentenbefugnisse

Viele Organisationen wissen, auf welche KI-Werkzeuge Mitarbeitende zugreifen können. Eine vollständige Übersicht darüber, was diese Werkzeuge tun dürfen, fehlt jedoch oft. Die effektive Befugnis eines Agenten ist die Vereinigung aus Modellanweisungen, Werkzeugberechtigungen, Laufzeitidentität, Netzwerkzugriff und erreichbaren Daten. Ein schreibgeschützter Prompt macht eine schreibfähige API nicht schreibgeschützt. Eine eingeschränkte Benutzeroberfläche schützt kein API-Token, das direkt administrative Endpunkte aufrufen kann.

Für jeden eingesetzten oder erprobten Agenten sollten die geschäftliche Aufgabe, erreichbare Systeme, lesbare Datenkategorien, mögliche Operationen, die für jede Operation verwendete Identität, menschliche Freigabebedingungen und der Abschaltmechanismus dokumentiert werden. Das Inventar sollte interne Agenten, von Anbietern gehostete Assistenten, Browser-Automatisierung, Programmierwerkzeuge und Workflows umfassen, die externe Dienste aufrufen können.

Berechtigungen sollten sowohl im Umfang als auch in der Dauer eng begrenzt sein. Ein Agent erhält nur die Werkzeuge, die er für die aktuelle Aufgabe braucht. Jedes Werkzeug sollte auf bestimmte Ressourcen beschränkt werden, und Lese- und Schreibvorgänge sollten getrennt sein. Wo möglich, sind zeitlich befristete Zugangsdaten, an eine Workload-Identität gebundene Zugriffe und der Entzug erhöhter Rechte nach Abschluss der Aufgabe vorzusehen. Wenn ein Agent nur eine bestimmte Gruppe von Datensätzen abrufen muss, darf er keine Datenbankrolle erhalten, mit der sich alle Kunden auflisten lassen.

Dasselbe Prinzip gilt für Daten, die Werkzeuge zurückgeben. Ein Werkzeug sollte Datensätze filtern, bevor sie in den Kontext des Agenten gelangen. Es sollte nicht darauf vertraut werden, dass das Modell Informationen ignoriert, die es bereits erhalten hat. Protokolle müssen genügend strukturierte Metadaten erfassen, um zu zeigen, welche Identität welche Ressource anforderte, welche Richtlinie den Zugriff erlaubte, ob eine Freigabe erforderlich war und was sich danach änderte. Sensible Werte gehören weder in gewöhnliche Prompts noch in ungeschwärzte Diagnoseprotokolle.

Anwendungskontrollen leisten weiterhin die Hauptarbeit

Ein Agent kann neuartig sein; eine Anwendung, die Autorisierung nicht durchsetzt, ist es nicht. Die AEPD beschreibt, dass der Agent nach dem Eindringen einen Weg fand, personenbezogene Daten zu ändern und Rechnungen abzurufen. Solange weitere technische Details fehlen, sollten Anwendungsbetreiber die Kontrollen für diese beiden Handlungsklassen überprüfen.

Die Autorisierung auf Objektebene muss bei jeder Anfrage geprüft werden. Der Server sollte entscheiden, ob die authentifizierte Identität den konkreten Datensatz lesen oder ändern darf. Er darf sich nicht auf einen vom Client oder Agenten gelieferten Bezeichner verlassen. Ebenso wichtig ist die Autorisierung auf Funktionsebene: Ein Konto, das ein Kundenprofil ansehen darf, sollte nicht automatisch Abrechnungsdaten ändern, Datensätze exportieren oder die Eigentümerschaft eines Kontos wechseln können.

Schreibvorgänge an personenbezogenen, finanziellen oder betrieblichen Datensätzen brauchen eine unabhängige Prüfung. Das kann je nach Risiko eine Policy-Engine, ein Transaktionslimit, ein zweiter Dienst, eine menschliche Freigabe oder eine unveränderliche Workflow-Regel sein. Die Konfidenzbewertung eines Modells ist keine Autorisierungsentscheidung. Eine natürliche Anweisung wie, sensible Daten nicht zu verändern, ist ebenfalls keine technische Barriere, wenn das verbundene Werkzeug genau dies tun kann.

Anwendungen sollten sich standardmäßig sicher verhalten. Unerwartete Felder sind abzulehnen, Typen und Wertebereiche zu prüfen, Massenoperationen zu begrenzen, Wiederholungsangriffe zu verhindern, Sitzungen und Tokens ablaufen zu lassen und für folgenreiche Änderungen eine erneute Autorisierung zu verlangen. Ratenbegrenzungen sind keine vollständige Verteidigung, können aber bremsen, wenn ein Prozess Datensätze oder Werkzeuge mit ungewöhnlicher Geschwindigkeit durchläuft.

Überwachung muss Verhalten statt nur Malware erkennen

Herkömmliche Erkennung beginnt häufig mit bekannten Schadcode-Dateien, Domains oder Hashes. Ein agentischer Eindringversuch kann ohne diese Spuren auskommen. Die Anfragen können aus einer legitimen Cloud-Region kommen, einen genehmigten API-Client verwenden und sich mit einem gültigen Token authentifizieren. Deshalb müssen Verhaltenssignale Teil der Erkennung sein.

Nützliche Signale sind ein Login, auf den rasche Erkundung vieler Anwendungsfunktionen folgt; Zugriffe auf Datentypen, die nicht zur üblichen Arbeit des Kontos gehören; wiederholte Anfragen mit veränderten Parametern nach Fehlern; ein plötzlicher Anstieg von Werkzeugaufrufen; gleichzeitiger Zugriff auf Daten und Verwaltungsfunktionen; ungewöhnliche Folgen von Lese- und Schreibvorgängen; sowie Aktivität außerhalb des erklärten Aufgabenfensters. Keines dieser Signale beweist einen KI-gesteuerten Angriff. Zusammen können sie ein Konto oder einen Workflow markieren, der seine erwartete Grenze verlassen hat.

Die Telemetrie muss Ebenen verbinden, die häufig getrennt protokolliert werden. Identitätsdaten sollten mit API-Gateway-Protokollen, Anwendungsprüfspuren, Datenbankänderungen, Agenten-Werkzeugaufrufen und ausgehendem Netzwerkverkehr korreliert werden. Wo möglich, ist die Agenten- oder Workflow-Identität ausdrücklich zu protokollieren. Teilen sich mehrere Agenten ein Dienstkonto, wird die Zuordnung schwieriger und die Eindämmung umfassender als nötig.

Warnungen müssen mit einer Reaktion verbunden sein. Eine Meldung, die erst nach Abschluss einer Massenänderung eintrifft, ist weniger hilfreich als eine Kontrolle, die den Vorgang pausiert, die Sitzung isoliert oder ab einem Schwellenwert eine Freigabe verlangt. Für folgenreiche Workflows sollte es einen Echtzeit-Notausschalter geben, der den Agenten deaktiviert, Tokens widerruft, den Netzwerkzugriff blockiert und eingereihtes Arbeiten stoppt. Für einen autonomen Prozess mit Zugriff auf personenbezogene Daten reicht die Aussage, man könne morgen ermitteln, nicht aus.

Was Datenschutzteams prüfen sollten

Der Vorfall liegt an der Schnittstelle von Cybersicherheit und Datenschutz. Nach der DSGVO bewerten Organisationen das Risiko einer Verletzung des Schutzes personenbezogener Daten und benachrichtigen die Aufsichtsbehörde, wenn die geltende Schwelle erreicht ist. Bei Verstößen mit hohem Risiko kann zusätzlich eine Information der betroffenen Personen erforderlich sein. Die Hinweise der AEPD zur Meldung von Datenschutzverletzungen machen diese risikobasierte Struktur ausdrücklich.

Ein KI-Agent nimmt der Organisation nicht die Verantwortung für die von ihm ausgeführte Verarbeitung ab. Die maßgeblichen Fragen sind bekannt: Auf welche Daten konnte zugegriffen werden, was wurde gelesen oder geändert, wie viele Personen könnten betroffen sein, wie lange dauerte der Zugriff, wurden Daten exfiltriert und welcher Schaden könnte entstehen? Die Autonomie des Agenten kann Wahrscheinlichkeit, Geschwindigkeit oder Umfang des Vorfalls verändern. Sie ersetzt jedoch nicht die eigentliche Bewertung der Datenschutzverletzung.

Datenschutz-Folgenabschätzungen und Sicherheitsrisikobewertungen sollten agentenspezifische Ausfallarten beschreiben. Dazu gehören Prompt Injection über Dokumente oder Webseiten, unbeabsichtigte Werkzeugnutzung, Confused-Deputy-Verhalten, mandantenübergreifender Zugriff, übermäßige Speicherung im Gedächtnis, Preisgabe von Zugangsdaten, unsichere Ausgaben, die an ein anderes System weitergegeben werden, sowie nicht rückgängig zu machende Aktionen. Die AEPD warnt in ihren Hinweisen zu agentischer KI, dass unkontrollierte Zugriffsketten, unzureichende Filterung von Funktionsargumenten und schwache Grenzen für Anzahl oder Kategorie von Zugriffen Datenminimierung und Sicherheit untergraben können.

Die Prüfung sollte auch die Beschaffung einbeziehen. Verträge und Betriebsverfahren müssen festlegen, wer Werkzeuge genehmigen darf, wo Prompts und Protokolle gespeichert werden, wie Anbieter Daten verarbeiten, wie Vorfälle gemeldet werden, wie Zugriffe entzogen werden und wie die Organisation nach einem Ereignis Belege erhält. Ein System ohne brauchbare Prüfspuren ist schwer zu steuern, selbst wenn seine beworbene Aufgabe risikoarm wirkt.

Ein praktischer Reaktionsplan für Organisationen

Organisationen müssen wegen einer einzigen gemeldeten Mitteilung nicht jedes KI-Pilotprojekt abschalten. Sie müssen jedoch vor der Verbindung eines Agenten mit realen Systemen eine klare Grenze festlegen. Für Sicherheits-, Entwicklungs- und Datenschutzteams bietet sich folgende Reihenfolge an.

  1. Befugnisse sichtbar machen. Inventarisieren Sie Agenten, Plugins, Browser-Automatisierungen, API-Integrationen und Dienstkonten. Listen Sie für jedes Element erreichbare Systeme, Datenklassen und Schreibfähigkeiten auf. Berücksichtigen Sie auch inoffizielle Experimente, die Unternehmenszugangsdaten verwenden.

  2. Den Schadensradius verkleinern. Ersetzen Sie geteilte und langlebige Zugangsdaten durch kurzlebige Workload-Identitäten. Entfernen Sie ungenutzte Werkzeuge, trennen Sie Umgebungen, beschränken Sie ausgehenden Verkehr und begrenzen Sie den Zugriff auf den kleinsten für die Aufgabe nötigen Datensatz. Ein Werkzeug mit beliebiger Codeausführung oder uneingeschränktem Netzwerkzugriff ist als Hochrisiko-Integration zu behandeln.

  3. Unumkehrbare Aktionen erschweren. Verlangen Sie eine unabhängige Autorisierung für Massenexporte, Datensatzänderungen, Zahlungen, Kontowiederherstellung, Berechtigungsänderungen und Löschungen. Setzen Sie Transaktions- und Mengenlimits. Die Freigabepolitik muss im Code und in der nachgelagerten Anwendung durchsetzbar sein.

  4. Den Workflow instrumentieren. Protokollieren Sie Werkzeugaufrufe, Identitäten, Richtlinienentscheidungen, Freigaben, Ressourcenbezeichner und daraus resultierende Änderungen. Korrelieren Sie diese Angaben mit Authentifizierungs- und Netzwerkdaten. Schwärzen Sie Zugangsdaten und nicht erforderliche personenbezogene Informationen in Protokollen.

  5. Eindämmung üben. Entziehen Sie die Zugangsdaten des Agenten, stoppen Sie eingereihtes Arbeiten, blockieren Sie ausgehenden Verkehr und stellen Sie in einem kontrollierten Test einen bekannten sicheren Zustand wieder her. Messen Sie die Dauer und klären Sie, welches Team jeden Schritt besitzt. Ein Notausschalter, der nie getestet wurde, ist eine Annahme.

  6. Den Datenschutzprozess neu bewerten. Definieren Sie, wann Sicherheitsteam, Datenschutzstelle, Rechtsabteilung, Anbieter und betroffene Fachverantwortliche einbezogen werden. Sichern Sie Beweise, ohne den Zugriff des Agenten fortzusetzen. Halten Sie die Vorfallsakte sachlich und trennen Sie bestätigte Beobachtungen von Hypothesen darüber, wie der Agent angewiesen wurde oder wie Zugangsdaten erlangt wurden.

Dieser Plan folgt der Richtung etablierter Hinweise des britischen National Cyber Security Centre und von OWASP: mit risikoarmen, begrenzten Anwendungsfällen beginnen, das Prinzip der geringsten Rechte anwenden, Sandboxing und Netzwerkkontrollen nutzen, sinnvolle menschliche Aufsicht erhalten, Verhalten überwachen und sicherstellen, dass jemand das System stoppen kann. Die Kontrollen sind nicht an einen einzelnen Modellanbieter gebunden. Gerade deshalb bleiben sie nützlich, solange die Fakten des spanischen Vorfalls unvollständig sind.

Was aus der Geschichte nicht folgen sollte

Der Bericht zeigt nicht, dass Sprachmodelle einen unabhängigen Willen entwickelt haben. Er zeigt, sofern die Darstellung der Meldung bestätigt wird, dass eine Person ein automatisiertes System konfiguriert oder eingesetzt hat, das ein Ziel über verbundene Werkzeuge verfolgen konnte. Verantwortung führt weiterhin zu den Menschen und Organisationen zurück, die den Zugriff eingerichtet, die Anwendung offengelegt und das System betrieben haben.

Ebenso zeigt der Fall nicht, dass menschliche Prüfung nutzlos ist. Prüfung bleibt wertvoll, wenn sie an den richtigen Stellen stattfindet: vor der Erteilung von Befugnissen, vor der Aktivierung folgenreicher Operationen, wenn Verhalten einen Schwellenwert überschreitet und während der Eindämmung. Unwirksam wird sie, wenn sie jede einzelne Aktion erst nachträglich kontrollieren soll, obwohl der Agent bereits weitreichende Rechte besitzt und schneller handeln kann, als ein Mensch reagiert.

Schließlich ist die Geschichte kein Argument dafür, ein Produkt mit der Aufschrift KI-Sicherheit zu kaufen. Erkennung, Identitätsverwaltung, sichere Anwendungsarchitektur, Schwachstellenmanagement, Segmentierung, Backups und eine getestete Reaktion auf Vorfälle bleiben wichtig. Ein Agent kann Schwächen in diesen Kontrollen sichtbar machen, aber er macht sie nicht überflüssig.

Die zentrale Lehre ist gewöhnliche Sicherheit mit weniger Zeit

Spaniens erste gemeldete Meldung über einen Datenverstoß durch einen KI-Agenten ist bedeutsam, weil sie einer abstrakten Sorge eine konkrete operative Form gibt: gültiger Zugriff, automatisierte Erkundung, eine Schwäche der Anwendung, Offenlegung personenbezogener Daten und eine unbefugte Änderung. Die Fakten können klarer werden, sobald die AEPD die Meldung untersucht hat. Bis dahin besteht die vertretbare Reaktion darin, die hervorgehobenen Kontrollfehler anzugehen, ohne mehr zu behaupten, als die Belege tragen.

Organisationen, die Agenten einsetzen, sollten genau wissen, welche Reichweite jede Identität besitzt, was jedes Werkzeug tun kann und welche Aktionen eine getrennte Entscheidung verlangen. Sie sollten abnormales Verhalten schnell sehen, Zugriffe sofort entziehen und genügend Beweise sichern, um den Ablauf zu bestimmen. Das Ziel ist keine Panik vor einem KI-Angreifer. Es geht darum, sicherzustellen, dass ein automatisierter Workflow nicht aus einem Zugang oder einer Anwendungsschwäche einen Vorfall macht, bevor die erste Warnung der Verteidiger überhaupt gelesen wurde.

Quellen