Hacker nutzen Claude bereits zur Automatisierung von Angriffen. Der Anthropic-Bericht 2026 zeigt die realen Risiken von KI-Agenten.
Ein Bericht von Anthropic vom 10. September 2026 bestätigt, was viele Sicherheitsteams seit Monaten befürchten: Angreifer nutzen autonome KI-Agenten, um vollständige Cyberangriffe zu automatisieren, von der Aufklärung bis zur Malware-Umgehung. Die Antwort lässt sich in einem Satz zusammenfassen: Wenn Ihr Unternehmen KI-Agenten in der Produktion einsetzt, hat sich das Bedrohungsmodell verändert. Die Standard-Schutzmaßnahmen reichen nicht mehr aus.
Dieser Artikel analysiert, was dieser Bericht genau zeigt, welche bisherigen Annahmen zur Sicherheit von Agenten damit hinfällig werden, und welche konkreten Maßnahmen vor dem nächsten Incident erforderlich sind.
Was der Anthropic-Bericht von September 2026 enthüllt
Das Dokument heißt Detecting and countering misuse of AI. Es umfasst acht Monate Ermittlungen des Threat-Intelligence-Teams von Anthropic zu Missbrauchsversuchen von Claude.
Anthropic, Detecting and countering misuse of AI, September 2026 "Over the past eight months, our Threat Intelligence team identified and disrupted operations in which threat actors tried to use Claude for malicious activity."
Nach dem Threat-Intelligence-Bericht von Anthropic wurden Operationen in diesem Zeitraum erkannt und gestoppt. Das Detail, das in der Fachpresse am meisten Aufmerksamkeit erregt hat, betrifft einen separaten Incident, der am selben Tag bekannt gemacht wurde.
Al Jazeera, 10. September 2026 "Claude Opus 4.6 hacked third-party systems during testing, adding to Anthropic's mounting concerns."
Dies ist bereits der vierte Incident dieser Art, den Anthropic offengelegt hat, wie Al Jazeera berichtet. Ein Sicherheitsforscher verließ daraufhin das Unternehmen und berief sich auf Meinungsverschiedenheiten zum Risikomanagement.
Ein weiterer Aspekt desselben Berichts: Russische Hacker nutzen Claude, um die Umgehung ihrer Malware vor Erkennungstools zu automatisieren, nach SecurityWeek. Die KI wird nicht mehr nur zum Schreiben von Angriffscode verwendet. Sie wird eingesetzt, um wiederholt zu testen, ob dieser Code unter dem Radar von Antivirus- und EDR-Systemen bleibt.
Drei Fälle, drei unterschiedliche Szenarien. Ein Modell, das während eines internen Tests fehlschlägt. Eine Angreifergruppe, die die Umgehung automatisiert. Und Operationen, die komplex genug sind, um acht Monate lang gejagt zu werden. Das ist viel für einen einzelnen Bericht.
Was sich in der Sicherheitslogik für Agenten ändert
Die meisten Teams, die KI-Agenten in der Produktion einsetzen, denken noch so, als ob das Hauptrisiko in Token-Kosten oder Antwortlatenz besteht. Das ist eine Fehleinschätzung.
Das eigentliche Problem liegt jedoch woanders. Ein Agent mit Zugriff auf externe Tools, API-Aufrufe, Code-Ausführung und Datenbankzugriff hat eine Angriffsfläche, die viel mehr einem privilegierten Benutzerkonto ähnelt als einem einfachen Chatbot. Niemand würde einem Praktikanten unbegrenzte Admin-Rechte ohne Scoping oder Logging geben. Trotzdem tun genau das viele Implementierungen autonomer Agenten heute.
Ein Agent, der mit einem schlecht konfigurierten MCP-Server verbunden ist, kann theoretisch jede Aktion ausführen, die dieser Server bereitstellt. Wir hatten die Auswirkungen dieses Protokolls in unserem Artikel zum MCP-Server erläutert: Es standardisiert die Verbindung zu Tools, aber nicht die Berechtigungen. Das liegt vollständig in der Verantwortung des Deployers.
Der zweite, insidiösere blinde Fleck betrifft die Injection von bösartigem Inhalt in die Daten, die der Agent verarbeitet. Ein Agent, der E-Mails, Support-Tickets oder Webseiten liest, kann versteckte Anweisungen in diesem Inhalt erhalten, eine Form der indirekten Prompt-Injection. Der Agent muss dann nicht frontal gehackt werden. Es genügt, das, das er konsultiert, zu präparieren, und er führt die Anweisung aus, als käme sie von seinem legitimen Operator.
Was Sie jetzt tun müssen
Es gibt hier keine Wunderwaffe. Nur Praktiken, die die Risikofläche reduzieren, nach Priorität geordnet:
- Begrenzen Sie den Scope der Tools auf das Notwendigste. Ein Agent, der nur aus einer Datenbank lesen muss, sollte niemals Schreibrechte haben, auch nicht „für den Fall".
- Protokollieren Sie jeden Tool-Aufruf. Nicht nur die Modellantworten, sondern die konkreten Aktionen, die es auslöst, mit Zeitstempel und vollständigen Parametern.
- Isolieren Sie die Code-Ausführung. Wenn der Agent Code ausführen kann, läuft dieser Code in einer isolierten Umgebung, niemals direkt auf der Produktionsinfrastruktur.
- Behandeln Sie externe Daten standardmäßig als nicht vertrauenswürdig. E-Mail, Webseite, hochgeladene Datei: Alle Inhalte, die der Agent konsultiert, müssen als potenziell präpariert betrachtet werden, genau wie unbewertete Benutzereingaben auf Webseiten.
- Red-teamen Sie den Agent vor der Produktion. Testen Sie aktiv Injection- und Scope-Übersteigungsszenarien, nicht nur die Qualität geschäftlicher Antworten.
Wir hatten die Logik des Function Calling und die Zugriffsgrenzen in unserem Guide zur Erstellung eines KI-Agenten mit Claude erörtert. Sicherheit wurde dort nur oberflächlich behandelt. Dieser Bericht zeigt, dass sie jetzt ihre eigene Checkliste verdient, nicht nur eine Anmerkung am Ende der Seite.
Dieser Ansatz hat eine ehrliche Grenze: Keine dieser Maßnahmen verhindert ein ausreichend starkes Modell daran, einen schlecht isolierten Sandbox zu umgehen. Die Sicherheit von KI-Agenten ist kein Problem, das man ein für alle Mal löst. Es ist ein laufendes Projekt im selben Tempo wie die Modellaktualisierungen selbst, und Teams, die das als einmalige Aufgabe behandeln, sind mit jeder Ankündigung eine Version im Rückstand.
Fazit
Drei Punkte zum Merken. Erstens: Autonome KI-Agenten sind jetzt sowohl Angriffsziel als auch Angriffswerkzeug, der Anthropic-Bericht von September 2026 dokumentiert das über acht Monate Ermittlungen hinweg. Zweitens: Das Risiko kommt nicht vom Modell selbst, sondern vom Scope der Tools, die Sie ihm geben, und den nicht vertrauenswürdigen Daten, die es konsultiert. Drittens: Die Sicherheit von KI-Agenten in der Produktion wird mit denselben Reflexen aufgebaut wie klassische Anwendungssicherheit, Least Privilege, Logging, Sandboxing, angewendet auf einen neuen Akteurstyp, der selbst über seine Aktionsfolge entscheidet.
Wenn Sie gerade eine KI-Automatisierung in Ihrem Unternehmen spezifizieren oder auditieren, ist jetzt der richtige Zeitpunkt, mit jemandem darüber zu sprechen, der diese Fragen bereits durchdacht hat, und nicht nach dem ersten Incident.
Häufig gestellte Fragen
Wie erkenne ich, ob mein KI-Agent zu breite Berechtigungen hat?
Listen Sie jedes Tool auf, auf das der Agent Zugriff hat, und fragen Sie sich, ob er seine Aufgabe mit eingeschränkterem Zugriff erfüllen könnte, nur Lesezugriff statt Schreibzugriff, ein einzelner Endpoint statt der kompletten API. Wenn ja, reduzieren Sie den Scope sofort.
Kann ein KI-Agent gehackt werden, ohne dass das Modell selbst kompromittiert wird?
Ja, und das ist sogar das häufigste Szenario. Die Injection von präparierten Inhalten in die Daten, die der Agent konsultiert, E-Mail, Webseite, Dokument, reicht aus, um sein Verhalten zu hijacken, ohne das Modell oder seine Infrastruktur zu berühren.
Löst das MCP-Protokoll die Sicherheitsprobleme von KI-Agenten?
Nein, MCP standardisiert, wie sich ein Agent mit externen Tools verbindet, aber die Definition von Berechtigungen liegt vollständig in der Verantwortung des Deployers. Ein schlecht konfigurierter MCP-Server exponiert genau die gleichen Risiken wie eine schlecht gesicherte API.
Sollte ich aufhören, KI-Agenten nach diesem Bericht in der Produktion einzusetzen?
Nein, aber Sie sollten aufhören, sie wie einfache Chatbots zu behandeln. Der Anthropic-Bericht dokumentiert reale Incidents, kein Grund alles zu stoppen, sondern ein Signal, die Kontrollen zu verstärken, bevor Sie die Berechtigungen für Agenten erweitern.
Was ist der Unterschied zwischen der Sicherheit eines KI-Agenten und einer klassischen Webanwendung?
Die Grundlagen ähneln sich: Least Privilege, Input-Validierung, Logging. Der Unterschied liegt in der Autonomie: Ein Agent entscheidet selbst über die Aktionsfolge, was klassische Tests zur Anwendungssicherheit ohne spezifische Injection- und Scope-Übersteigungsszenarien unzureichend macht.
