Sicherheit von Claude ist Chefsache

Die Verantwortung für den KI-Einsatz liegt nicht in der Fachabteilung, sondern bei der Leitung. Drei Pflichtenkreise greifen gleichzeitig ineinander:

• Datenschutz (DSGVO): Sobald personenbezogene Daten (z.B. Namen und Adressen von Personen) in einen Prompt gelangen, ist Anthropic Auftragsverarbeiter. Das setzt einen Auftragsverarbeitungsvertrag (AVV/DPA) voraus – den es bei privaten Consumer-Konten nicht gibt. Wenn der Mitarbeiter also Kundendaten in sein persönliches Claude-Konto überführt, entsteht das erste knackige Problem.
• EU AI Act: Seit Februar 2025 verpflichtet Art. 4 KI-VO Unternehmen, für ausreichende KI-Kompetenz der Mitarbeitenden zu sorgen. Wer Claude einsetzt, muss die Belegschaft schulen. Wer das bisher versäumt hat, kann auch gerne unsere KI-Kompetenzschulung in Anspruch nehmen.
• Geschäftsgeheimnisschutz & Haftung: Unkontrollierte Tool-Nutzung,  zu deutsch: Schatten-KI bzw. „Shadow AI“, kann Betriebsgeheimnisse in Trainingsdaten überführen und die Sorgfaltspflichten der Geschäftsleitung verletzen. Auch die meisten Arbeitsverträge von Mitarbeitern sind auf dieses Szenario längst nicht vorbereitet.

Die zentrale Erkenntnis vorweg: Nicht Claude selbst ist das Risiko, sondern die gewählte Nutzungsvariante und der zugrunde liegende Vertrag.  Erst in der zweiten Ebene kommen zusätzliche Risiken durch die technische Integration auf dem Endgerät (z.B. Claude Code oder Claude Cowork) zum Tragen.

Dieselbe Technologie ist in einem Enterprise-Vertrag mit Zero Data Retention compliancetauglich und im privaten Pro-Konto eines Mitarbeiters ein kritischer Datenschutzvorfall in Lauerstellung. Werfen wir also zunächst einen Blick auf die Nutzungsvarianten von Claude.

Die Nutzungsvarianten von Claude im Überblick

Claude lässt sich auf sehr unterschiedlichen Wegen einsetzen. Entscheidend für die Sicherheit sind drei Dimensionen:

• der Datenfluss (was verlässt das Unternehmen?),
• der Systemzugriff (kann das Tool Dateien lesen oder Befehle ausführen?) und
• der Vertrag (Consumer oder Commercial Terms?).

Die nachfolgende Tabelle gibt einen kompakten Überblick über Nutzungsvariante, Anwendung und Sicherheitsrisiko für Claude:

Ein verbreiteter Irrtum: Die Claude-App sei „harmlos“ und Claude Code per se ein „hohes Sicherheitsrisiko“.

In der Praxis entscheidet beim Datenschutz nicht die Oberfläche, sondern der Vertrag und die rechtlichen Rahmbedingungen. Eine Web-App unter einem privaten Pro-Konto ist riskanter als die API unter Commercial Terms, obwohl die API technisch mächtiger ist. Die Nutzung von Claude Code ist durch die direkte Systemintegration natürlich grundsätzlich ein technisches Sicherheitrisiko, das im Rahmen eines durchdachten Setups aber aktiv eingegrenzt werden kann.

Datenschutz & DSGVO: der entscheidende Unterschied zwischen den Plänen

Anthropic trennt seine Angebote in zwei vertragliche Welten : Einzelpersonen (Consumer) und Enterprise (oder Team-Konten). Genau hier entscheidet sich die Compliance-Tauglichkeit.

Nutzungsvarianten und Pläne von Claude (© Claude.ai)

Einzelperson bzw. Consumer-Konten (Free, Pro, Max)

Diese Pläne laufen unter den Consumer Terms. Seit der Richtlinienänderung im Herbst 2025 werden Chats und Coding-Sessions standardmäßig zur Modellverbesserung genutzt – es sei denn, der Nutzer widerspricht aktiv. Konkret bedeutet das:

• Opt-out ist Pflicht, nicht Voreinstellung: Unter Einstellungen → Datenschutz → „Claude für alle verbessern“ bzw. „Hilf uns, unsere KI-Modelle zu verbessern“ muss der Schalter manuell auf Aus gestellt werden.
• Verlängerte Speicherung: Mit aktiviertem Training steigt die Datenaufbewahrung auf bis zu fünf Jahre. Wer widerspricht, bleibt nach aktuellem Stand bei 30 Tagen (Juni 2026).
• Kein AVV: Für Consumer-Konten gibt es keinen Auftragsverarbeitungsvertrag . damit fehlt die rechtliche Grundlage für die Verarbeitung personenbezogener Daten im Unternehmenskontext, die nach Art. 28 DSGVO notwendig ist.
• Wichtige Einschränkung: Das Opt-out wirkt nur in die Zukunft. Bereits für das Training verwendete Inhalte lassen sich nicht zurückholen. Zudem können sicherheitsmarkierte Konversationen unabhängig von der Einstellung weiter ausgewertet werden.

Wer Claude sicher nutzen will, muss diese zentrale Einstellung für die Modellverbesserung kennen. (© Claude.ai)

Vorsicht beim Team-Plan: Trotz des Namens läuft der reine Claude-Team-Plan in wesentlichen Teilen weiterhin unter Consumer-Logik. Erst Enterprise liefert die volle vertragliche Absicherung. Im Zweifel den konkreten Vertragsstatus prüfen. Gerne beraten wir Sie bei der Auswahl des richtigen Plans über unsere Claude Code Beratungsleistung.

Commercial-Konten (Claude for Work / Enterprise, API, Bedrock, Vertex AI)

Claude Enterprise / Commercial Plans (© claude.ai)

Wie der Name schon verrät, laufen diese Konten unter den Commercial Terms, was für Unternehmen und Mitarbeiter den entscheidenden Unterschied macht:

• Kein Training auf Ihren Daten: Inputs und Outputs werden standardmäßig nicht zur Modellverbesserung verwendet – ohne dass Sie etwas umstellen müssen.
• AVV/DPA verfügbar: Anthropic stellt einen Auftragsverarbeitungsvertrag (AVV) bereit und nutzt EU-Standardvertragsklauseln (SCC) für Datenübermittlungen.
• Kürzere API-Aufbewahrung: Die Standard-Aufbewahrung der API liegt bei nur 7 Tagen, was deutlich strenger als die meisten Wettbewerber. Auf Wunsch per DPA (Data Processing Agreement) auf 30 Tage erweiterbar.
• Zero Data Retention (ZDR): Für qualifizierende Enterprise-Kunden verfügbar. Daten werden über die unmittelbare Verarbeitung hinaus gar nicht gespeichert. Der Goldstandard für sensible Branchen oder hoch brisante Unternehmensinformationen, wie sie in Banken, Versicherungen, Medizintechnik, Gesundheitswesen oder Rüstungsindustrie vorkommen.
• Branchenspezifika: Für das Gesundheitswesen ist ein Business Associate Agreement (BAA) verfügbar, Standard-Consumer-Claude ist nicht HIPAA-konform und darf nicht mit Gesundheitsdaten genutzt werden. Daher erfordert es hier gesonderter Vereinbarungen.

Claude Code sicher einsetzen: Ein Sonderfall mit eigenem Risiko

Das KI-Werkzeug Claude Code verdient einen eigenen Abschnitt, weil es sich grundlegend von der Chat-App unterscheidet. Es ist kein abgeschotteter Chatbot, sondern ein Agent mit echter Entwicklungs-Autorität, das als direkte Integration im Betriebssystem eines Nutzers laufen kann: Es liest Quellcode, ändert Dateien, führt Shell-Befehle aus und kann externe Werkzeuge über das Model Context Protocol (MCP) ansprechen und nutzen – und zwar mit denselben Rechten wie der Nutzer, der es startet.

Damit entsteht eine Angriffsfläche, die klassische IDE-Plugins nie hatten. Denn Claude Code kann insbesondere im „Auto mode“ erhebliche Sicherheitsrisiken mit sich bringen, wenn ein Nutzer keine adäquate Rechteverwaltung beherrscht oder Claude Code als abgeschotteter Agent z.B. in einer isolierten Container-Umgebung läuft.

Claude Code ist ein Sonderfall mit eigenen Risiko-Klassen und kann direkt im Terminal mit User-Rechten laufen

Die zentralen Risiken

• Dateizugriff: Ohne Sperren kann Claude Code sensible Dateien wie Umgebungsvariablen (.env), SSH-Schlüssel und Zugangsdaten lesen.
• Befehlsausführung: Der Agent führt Bash-Befehle im Kontext der Entwickler-Shell aus, ein fehlgeleiteter Befehl kann Daten komplett löschen oder überschreiben.
• Prompt Injection: In Dateien, READMEs oder Paket-Metadaten versteckte Anweisungen können den Agenten manipulieren. Sicherheitsforscher haben gezeigt, dass repository-gesteuerte Hooks und MCP-Konfigurationen zu Befehlsausführung oder Schlüsselabfluss führen können. Öffentlich verfügbare MCP-Packages, Libraries oder andere Open-Source Komponenten können hier ein erhebliches Einfallstor für schadhaften Code und böswillige Software sein.

Berechtigungsmodus: vom Vorsichtigen zum Riskanten

Claude Code folgt einem „ask before act“-Prinzip. Standardmäßig fragt es vor jeder relevanten Aktion nach. Drei Stufen sind relevant:

• Plan-/Standardmodus: Claude schlägt Änderungen vor, führt sie aber erst nach Freigabe aus. Für sensible Repositories die richtige Wahl. Die sicherste Methode, wenn ein Nutzer weiß, worauf er achten muss. Allerdings ist diese Methode zeitfressend und erfordert manuelle Prüfung der generierten Code-Artefakte.
• Accept-Edits / Allowlist: Vertraute Befehle (z. B. npm run test) werden vorab freigegeben, der Rest fragt weiter nach. Guter Kompromiss für den Alltag. Kostet aber deutlich mehr Zeit in der Entwicklung von Software.
• Auto-Mode: Vor jedem Tool-Aufruf prüft ein Klassifikator die Aktion auf potenziell destruktive Vorgänge wie Massenlöschungen, Exfiltration sensibler Daten oder Ausführung schädlichen Codes. Als sicher eingestufte Aktionen laufen automatisch, riskante werden geblockt und Claude auf einen anderen Weg umgeleitet; besteht Claude wiederholt auf einer geblockten Aktion, wird schließlich doch eine Rückfrage an den Nutzer ausgelöst.
• –dangerously-skip-permissions: Hebt alle Sicherheitsabfragen auf. Der Name ist eine bewusste Warnung. Niemals auf der lokalen Maschine! Diese Permission  sollte nur in einer isolierten Sandbox / Container laufen.

Claude Code Berechtigungen im Überblick:

Lokal vs. Container/VM: die Entscheidungslogik

Hier liegt die wichtigste Sicherheitsentscheidung für technische Teams:

Faustregeln aus der Cybersecurity:

• Die Sandbox ist die Wand, die Berechtigungen sind das Schloss an der Tür.
• Erst die Isolation (Container/VM) macht die volle Autonomie verantwortbar, weil der maximale Schaden auf den Container begrenzt bleibt.
• Konkrete Schutzmaßnahmen im Container: nur das eine Projektverzeichnis mounten, Egress auf eine Allowlist beschränken (Anthropic-API, nötige Paket-Registries)
• Secrets gar nicht erst in den Container lassen, sondern parametrisiert einsteuern

Enterprise-Kontrollen, die nicht umgangen werden können

Einzelne Berechtigungsabfragen sind keine Unternehmenspolitik. Für durchsetzbare Vorgaben nutzen Organisationen Managed Settings (per MDM oder server-seitig ausgeliefert, nicht durch Repository-Dateien überschreibbar).

Wer Claude Code sicher nutzen will, sollte ein paar zentrale Faktoren berücksichtigen und sicherstellen:

• Least-Privilege-Berechtigungen,
• Deny-Regeln für Secret-Dateien und Hochrisiko-Befehle,
• Sperre von –dangerously-skip-permissions außerhalb isolierter Container,
• genehmigte MCP-Server,
• Audit-Logging via OpenTelemetry und ein
• LLM-Proxy für Sichtbarkeit über alle Tool-Aufrufe.

Damit lässt sich Claude Code als effizientes, agentisches Tool in der KI-Entwicklung schon sehr sicher einsetzen.

Claude sicher nutzen: Governance-Rahmen für Unternehmen

Technische Einstellungen allein genügen nicht. Sicherer Claude-Einsatz braucht einen organisatorischen Rahmen (Leitplanken) und der ist zugleich AI-Act-Pflicht:

• KI-Richtlinie (Policy): Schriftlich regeln, welche Varianten und Pläne erlaubt sind, welche Daten eingegeben werden dürfen und wer freigibt.
• Freigabe- und Beschaffungsprozess: Keine privaten Konten für dienstliche Zwecke. Zentrale Bereitstellung von Enterprise-/API-Zugängen verhindert Shadow AI.
• KI-Inventar: Erfassen, welche KI-Systeme im Einsatz sind – inklusive der unbemerkt gewachsenen. Das ist zugleich die Grundlage für die Risikoklassifizierung nach AI Act.
• Mitarbeiterschulung (Art. 4 EU AI Act): Seit Februar 2025 verpflichtend. Die Belegschaft muss KI verstehen, Halluzinationen erkennen und die internen Regeln kennen.
• Audit & Review: Regelmäßige Prüfung der Einstellungen (Training-Opt-out, Plan-Status, Konten) und Bereinigung alter Konversationen.

Das Thema ist für Ihren Schreibtisch zu komplex? Kein Problem – Elsen GRC berät Unternehmen im Rahmen der KI-Governance Beratung zu den relevanten Aspekten rund um die Vorbereitung auf den EU AI Act. Einfach ein Erstgespräch buchen und wir kümmern uns um die Umsetzung dieser Leitplanken in Ihrem Unternehmen.

Sicherheits-Checkliste: Claude im Unternehmen

Kompakt zusammengefasst – die zentralen Punkte für den sicheren Claude-Einsatz im Unternehmen:

• Nur Commercial-Verträge (Enterprise/API) für dienstliche Nutzung – keine privaten Pro-Konten!
• AVV/DPA mit Anthropic abgeschlossen
• Bei hohem Schutzbedarf: Zero Data Retention aktiviert
• Auf verbliebenen Consumer-Konten: Training-Opt-out geprüft und dokumentiert
• KI-Richtlinie verabschiedet und kommuniziert
• KI-Inventar erstellt, Shadow-AI-Konten identifiziert
• Art.-4-Schulung durchgeführt und dokumentiert
• Claude Code nur im Container/VM mit Secret-Sperren und Egress-Allowlist betrieben
• Autonomer Modus ohne Sicherheitsabfragen außerhalb der Sandbox gesperrt
• Audit-Logging und regelmäßige Reviews etabliert

Die Checkliste gibt es natürlich auch noch als PDF Version zum Download:

• Claude sicher nutzen Checkliste (PDF, 1 Seite)

Wie Elsen GRC Sie unterstützt

Der sichere Einsatz von Claude berührt genau die Schnittstelle von Datenschutz, KI-Governance und AI-Act-Compliance, auf die Elsen GRC spezialisiert ist:

• KI-Kompetenzschulung nach Art. 4 EU AI Act: Erfüllt die gesetzliche Schulungspflicht – inklusive Mitarbeiter-Zertifikat, Schulungsregister und KI-Richtlinien-Entwurf.
• AI Act Readiness Scan: KI-Inventar, Risikoklassifizierung und Roadmap mit Blick auf die AI Act Fristen bis August 2026.
• KI-Governance-Beratung: Vollständiges Governance-Framework mit Policies, Rollen und Freigabeprozessen für den kontrollierten KI-Einsatz.

So wird aus einem unkontrollierten Tool ein gesteuerter, prüffester Bestandteil Ihrer GRC-Struktur.

Ein paar häufige Fragen zur Claude Sicherheit im Überblick (FAQ)

Ist Claude DSGVO-konform nutzbar?

Ja -aber nur unter Commercial Terms (Enterprise oder API) mit abgeschlossenem AVV. Private Consumer-Konten (Free, Pro, Max) bieten keinen AVV und nutzen Daten standardmäßig zum Training, wenn nicht aktiv widersprochen wird.

Werden meine Chats zum Training von Claude verwendet?

Bei Consumer-Konten standardmäßig ja, solange nicht widersprochen wird. Bei Commercial-Konten (Enterprise, API) standardmäßig nein.

Reicht der Team-Plan für Unternehmen?

Der Team-Plan läuft in wesentlichen Teilen unter Consumer-Logik. Für volle vertragliche Absicherung mit AVV und Trainings-Ausschluss ist Enterprise oder die API erforderlich.

Warum ist Claude Code riskanter und nicht so sicher wie die App?

Weil Claude Code mit den vollen Rechten des Nutzers auf das Dateisystem zugreift und Befehle ausführt. Es sollte deshalb in einem Container oder einer VM betrieben werden – nicht ungeschützt auf dem lokalen Gerät.

Was ist Zero Data Retention?

Ein Modus für qualifizierende Enterprise-Kunden, bei dem Daten über die unmittelbare Verarbeitung hinaus nicht gespeichert werden – der höchste Datenschutzstandard ohne eigene Infrastruktur.

Verwandte Themen

• ChatGPT sicher nutzen: Guideline für Sicherheit bei OpenAI ChatGPT und Codex
• EU AI Act: Definition, Bedeutung & Pflichten
• KI-Governance: Definition, Bedeutung & GRC-Relevanz
• Shadow AI: Definition, Risiken & Maßnahmen

Quellen & Bilder

Bilder: Screenshots, © Claude.ai

• Anthropic: Updates to Consumer Terms and Privacy Policy
• Anthropic Privacy Center: Is my data used for model training?
• Claude Code Docs: Development containers / Security

Der Beitrag Claude sicher nutzen: Guideline für Claude Code, Cowork und die Claude Desktop App erschien zuerst auf ELSEN GRC.

Executive Summary: US-Regierung erzwingt Abschaltung von Claude Fable 5 und Mythos 5 – was Unternehmen daraus lernen müssen

Nur drei Tage nach dem Launch seiner bislang leistungsfähigsten KI-Modelle musste Anthropic die Systeme Claude Fable 5 und Claude Mythos 5 am 12. Juni 2026 weltweit abschalten. Auslöser ist nach Darstellung des Unternehmens eine Exportkontrolldirektive der US-Regierung, die jeglichen Zugriff durch ausländische Staatsangehörige untersagt – innerhalb wie außerhalb der USA und sogar für eigene Mitarbeiter ohne US-Staatsbürgerschaft. Da eine Filterung auf Nutzerebene nicht kurzfristig umsetzbar war, blieb nur die vollständige globale Deaktivierung beider Modelle. Anthropic bezeichnet die Maßnahme als „Missverständnis“ und verweist auf einen lediglich engen, nicht-universellen Jailbreak. Aus Sicht von Governance, Risk & Compliance (GRC) ist der Fall ein Lehrstück: Er zeigt, wie geopolitische und exportrechtliche Risiken binnen Stunden zu einem Ausfall geschäftskritischer KI-Dienste führen können – und warum Modell-Abhängigkeit ein eigenständiges Compliance-Risiko ist.

Der Vorgang um Claude Fable 5 und Mythos 5 ist dabei kein gewöhnlicher Produktausfall. Er führt vor Augen, dass leistungsfähige KI-Modelle inzwischen im Spannungsfeld von Außenwirtschaftsrecht, nationaler Sicherheit und kommerzieller Verfügbarkeit stehen und dass Unternehmen, die solche Modelle in ihre Prozesse oder Software-Produkte einbinden, ein Risiko tragen, das weit über die Technik hinausreicht. Wie gravierend ist also die Abschaltung von Claude und welche Fallback-Szenarien sind realistisch?

Was ist passiert? Kurze Einordnung

Am 12. Juni 2026 erhielt Anthropic nach eigenen Angaben um 17:21 Uhr Ostküstenzeit eine Exportkontrolldirektive der US-Regierung. Diese untersagt den Zugriff auf Fable 5 und Mythos 5 für sämtliche ausländische Staatsangehörige – unabhängig vom Aufenthaltsort und ausdrücklich auch für ausländische Anthropic-Mitarbeiter. Weil sich Nationalität und Verwendungszweck aber nicht in Echtzeit auf Account-Ebene trennen lassen, sah sich das Unternehmen gezwungen, beide Modelle für alle Kunden weltweit abzuschalten. Alle übrigen Claude-Modelle bleiben laut Anthropic verfügbar. Diese Abschaltung ist in Europa kürzlich durch eine simple Meldung innerhalb der Claude-Anwendung sichtbar, wie der nachfolgende Screenshot zeigt.

Ein einfacher Hinweis in den Desktop- und Mobil-Apps von Claude informiert über die Abschaltung der Modelle

Hintergrund ist nach Darstellung Anthropics die Annahme der Regierung, es existiere eine Methode, um die Schutzmechanismen von Fable 5 zu „jailbreaken“. Laut Medienberichten soll ein nicht namentlich genanntes Unternehmen einen solchen Jailbreak demonstriert haben; Handelsminister Howard Lutnick habe Anthropic bereits Anfang Juni auf entsprechende Sicherheitsbedenken hingewiesen, bevor am 12. Juni die formale Anordnung folgte.

Bei Heise gibt es inzwischen Berichte darüber, dass der Amazon CEO die Fable-Sperre ausgelöst haben soll.

Anthropics Position: „Missverständnis“ und enger Jailbreak

Anthropic befolgt die Anordnung, widerspricht ihr aber öffentlich und ungewöhnlich deutlich. Das Unternehmen erklärt, die der Regierung vorliegende Demonstration habe lediglich eine kleine Anzahl bereits bekannter, geringfügiger Schwachstellen identifiziert – solche, die auch mit anderen öffentlich verfügbaren Modellen (genannt wird unter anderem OpenAIs GPT-5.5) reproduzierbar seien. Es habe sich um einen engen, nicht-universellen Jailbreak gehandelt, der im Kern darin bestehe, das Modell um die Analyse einer bestimmten Codebasis und das Beheben von Software-Fehlern zu bitten.

Anthropic argumentiert, das Auffinden eines derart begrenzten Jailbreaks rechtfertige nicht den Rückruf eines kommerziell breit eingesetzten Modells. Würde dieser Maßstab branchenweit angelegt, käme er nach Auffassung des Unternehmens faktisch einem Stopp sämtlicher neuer Modell-Deployments aller Anbieter von Frontier-Modellen gleich. Zugleich betont Anthropic, der Staat solle unsichere Deployments grundsätzlich blockieren dürfen – jedoch nur im Rahmen eines Verfahrens, das transparent, fair und technisch fundiert sei. Genau das sieht das Unternehmen hier nicht erfüllt.

Der regulatorische Kern: Exportkontrolle als Hebel

Bemerkenswert aus Compliance-Sicht ist dabei das verwendete Rechtsinstrument. Die US-Regierung greift nicht auf KI-spezifische Regulierung zurück, sondern auf Exportkontrollrecht – also klassisches Außenwirtschaftsrecht. KI-Modelle werden damit faktisch wie kontrollierbare Güter mit doppeltem Verwendungszweck (Dual-Use) behandelt.

Das hat eine weitreichende Logik: Wenn der Zugriff durch „ausländische Staatsangehörige“ den Tatbestand eines Exports erfüllt, dann ist nicht der physische Standort des Servers entscheidend, sondern die Staatsangehörigkeit des Nutzers. Für global aufgestellte Cloud-Dienste ist das ein kaum trennscharf umsetzbares Kriterium, was erklärt, warum die einzige praktikable Reaktion für den Claude-Hersteller die vollständige Abschaltung des Modells war.

Bewertung aus GRC-Sicht: Vier zentrale Risikofelder

1. Verfügbarkeits- und Kontinuitätsrisiko (Business Continuity)

Ein als „leistungsfähigstes Modell der Unternehmensgeschichte“ beworbenes System war drei Tage nach dem Launch nicht mehr verfügbar. Für Organisationen, die KI-Modelle produktiv in Geschäftsprozesse einbinden, ist das ein Lehrstück in Sachen Business Continuity Management (BCM): Ein erzwungener Modellwechsel ist die unangenehmste Form der Betriebsunterbrechung, weil sie ungeplant und von außen verursacht ist. Wer kein Fallback-Modell und keinen Ausweichprozess definiert hat, riskiert den absoluten Stillstand, insbesondere als SaaS-Betreiber oder bei tiefer Integration der KI-Modelle in die eigenen Geschäftsprozesse.

2. Konzentrations- und Anbieterabhängigkeit (Concentration Risk)

Der Fall verdeutlicht das Risiko einer einseitigen Abhängigkeit von einem einzelnen KI-Anbieter oder Modell. Was im Finanzsektor unter „Konzentrationsrisiko“ und „Auslagerungsmanagement“ längst reguliert ist (etwa durch DORA, Digital Operational Resilience Act und die EBA-Leitlinien), gilt sinngemäß für jede KI-gestützte Wertschöpfung: Eine Multi-Vendor- oder Multi-Modell-Strategie ist kein technisches Nice-to-have, sondern eine Risikomanagement-Entscheidung und – angesichts der aktuellen Vorfälle – ein absolutes „Must-Have“!

3. Geopolitisches und exportrechtliches Risiko

KI-Dienste US-amerikanischer Anbieter unterliegen US-Recht – mit extraterritorialer Wirkung. Der Zugriff europäischer Unternehmen kann durch Entscheidungen einer fremden Regierung binnen Stunden entfallen, ohne dass der Kunde Einfluss oder Vorlauf hat. Für die Bewertung von KI-Dienstleistern gehört diese Jurisdiktions- und Souveränitätsfrage künftig zwingend in die Lieferanten-Due-Diligence – vergleichbar mit den Debatten um Cloud-Souveränität und den DSGVO-Drittlandtransfer.

4. Verantwortung der Geschäftsleitung

Wie schon bei NIS-2 und dem EU AI Act gilt: Die Verantwortung für solche Risiken liegt auf der Leitungsebene. Die Frage „Was passiert, wenn unser zentrales KI-Modell morgen nicht mehr verfügbar ist?“ ist keine Frage der IT-Verfügbarkeit, sondern eine konkrete Governance-Entscheidung, die entsprechende Implikationen für Haftung, Sorgfaltspflichten und Notfallvorsorge mit bringt.

Was bedeutet das für deutsche Unternehmen und öffentliche Stellen?

Auch wenn Fable 5 und Mythos 5 für die meisten Organisationen längst nicht im alltäglichen Einsatz waren, hat der Fall strukturelle Konsequenzen:

• KI-Notfallplanung: Jedes Unternehmen, das KI-Modelle produktiv nutzt, sollte ein dokumentiertes Fallback-Szenario besitzen: welches Ersatzmodell kann schnell an die eigenen Services angebunden oder vorgehalten werden, welche Umschaltzeit ist realistisch, welche Qualitätssicherung existiert?
• Vertrags- und Exit-Management: Verträge mit KI-Anbietern sollten Regelungen zu Verfügbarkeit, Modell-Abkündigung und Datenportabilität enthalten.
• Souveränitätsabwägung: Für sensible Anwendungen (KRITIS, öffentliche Verwaltung, regulierte Branchen) gewinnt die Frage nach europäischen oder selbst-gehosteten Alternativen an Gewicht. Insbesondere lokale LLM-Modelle können eine attraktive Alternative darstellen.
• Lieferanten-Due-Diligence: Die Jurisdiktion des Anbieters und mögliche extraterritoriale Eingriffe gehören in jede Risikobewertung eingesetzter KI-Dienste.

Bedeutung für Governance, Risk und Compliance

Der Fall reiht sich in eine Entwicklung ein, die GRC-Verantwortliche zunehmend beschäftigt: KI-Risiken sind nicht mehr nur technischer oder datenschutzrechtlicher Natur, sondern berühren Außenwirtschaftsrecht, Geopolitik und Betriebskontinuität gleichzeitig.

• Governance muss klären, von welchen KI-Anbietern und Modellen die Organisation abhängt und wer über Ausweichoptionen entscheidet.
• Risk Management muss Anbieter-, Konzentrations- und Jurisdiktionsrisiken als eigene Risikokategorie erfassen und mit Verfügbarkeits- und Cyber-Risiken verknüpfen.
• Compliance muss die Brücke schlagen zu Auslagerungsanforderungen (z.B. DORA, MaRisk (Mindestanforderungen an das Risikomanagement), BAIT), zum EU AI Act und zu vertraglichen Verfügbarkeitszusagen – und dies nachweisbar dokumentieren.

Die zentrale Lehre ist nüchtern: Wer ein einzelnes KI-Modell zum kritischen Bestandteil seiner Wertschöpfung macht, übernimmt damit auch dessen regulatorische und geopolitische Risiken – oft ohne Mitsprache und ohne Vorwarnung. Und im Jahr 2026 kann auch eine launische US-Exportkontrolle am Wochenende unerwartet hart einschlagen.

Unterstützung durch Elsen GRC

Elsen GRC unterstützt Unternehmen und öffentliche Stellen dabei, Abhängigkeiten von KI-Modellen und -Anbietern strukturiert zu bewerten und in bestehende Governance-, Risk- und Compliance-Strukturen zu integrieren. Dazu gehören die Bewertung eingesetzter KI-Dienste, der Aufbau einer KI-Governance im Sinne des EU AI Acts, die Entwicklung von Fallback- und Exit-Strategien sowie die Verzahnung mit Auslagerungs-, NIS-2- und Datenschutzanforderungen.

Der Fall Fable 5 und Mythos 5 sollte nicht als Anlass für Panik, sondern für eine nüchterne Bestandsaufnahme dienen: Von welchen KI-Modellen hängen wir ab? Was passiert bei einem plötzlichen Ausfall? Welche Risiken akzeptieren wir bewusst – und welche nicht?

Gerne unterstütze ich Sie dabei im Rahmen eines unverbindlichen Erstgesprächs. Vereinbaren Sie einfach einen unverbindlichen Termin.

Quellen:

• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 – Anthropic
• US-Regierung erzwingt Abschaltung von Anthropics KI Fable 5 und Mythos 5 – Heise online

Der Beitrag Abschaltung von Claude Fable 5 und Mythos 5 durch US-Regierung erzwungen erschien zuerst auf ELSEN GRC.

Executive Summary: Ist Claude Mythos ein Sicherheitsrisiko?

Mit Claude Mythos Preview hat Anthropic im April 2026 ein KI-Modell vorgestellt, das so leistungsfähig im Auffinden und Ausnutzen von Sicherheitslücken sein soll, dass es bewusst nicht öffentlich verfügbar gemacht wird. Stattdessen erhalten ausgewählte Unternehmen im Rahmen der Initiative „Project Glasswing“ exklusiven Zugriff, um kritische Software abzusichern. Aber schon wenige Tage nach der Vorstellung wurde bekannt, dass Unbefugte bereits am Tag der Veröffentlichung Zugang zu Mythos erlangt haben sollen. Alles nur Marketing? Oder ist Claude Mythos wirklich ein großes Sicherheitsrisiko für Unternehmen und Behörden? Aus Sicht von Governance, Risk & Compliance (GRC) wirft der Fall grundlegende Fragen auf: zur Risikoeinstufung leistungsfähiger KI-Modelle, zur Lieferketten- und Dienstleistersicherheit sowie zur Verantwortung der Geschäftsleitung beim Einsatz und beim Schutz solcher Systeme. Unternehmen, die KI strategisch einsetzen oder regulatorisch betroffen sind (z.B. durch NIS-2 oder den EU AI Act), sollten den Fall Mythos als Frühindikator für kommende Anforderungen verstehen.

Der Fall Claude Mythos ist mehr als eine Schlagzeile aus der KI-Entwicklung der letzten Wochen. Er macht sichtbar, was viele GRC-Verantwortliche seit Monaten ahnen: Hochleistungs-KI ist nicht nur ein wachsender Produktivitätsfaktor, sondern zunehmend auch ein systemisches Sicherheitsrisiko, mit Auswirkungen auf Cybersicherheit, Compliance und Governance im Unternehmen.

Was ist Claude Mythos? Kurze Einordnung

Claude Mythos Preview ist nach Angaben des Herstellers (Entwicklers) Anthropic ein KI-Modell, das auf das Auffinden und Ausnutzen von Software-Schwachstellen spezialisiert ist. Laut Heise online habe das Modell bereits tausende hochriskante Zero-Day-Schwachstellen in allen großen Betriebssystemen, Browsern und weiterer Software identifiziert. Auffällig ist dabei nicht nur die schiere Menge an Sicherheitslücken, sondern die Fähigkeit, aus identifizierten Lücken funktionierende Exploits abzuleiten, teilweise durch Verkettung mehrerer Schwachstellen. Insbesondere die Verkettung war für menschliche Sicherheitsforscher bis dato eine fast unlösbare Komplexität.

Anthropic verweist exemplarisch auf eine 27 Jahre lang unentdeckte Schwachstelle in der OpenBSD Pipeline sowie eine 16 Jahre alte Lücke in FFmpeg, die in Millionen automatisierter Scans nicht aufgefallen sei. Aufgrund dieser Fähigkeiten verzichtet Anthropic auf eine breite Veröffentlichung und stellt Mythos im Rahmen der Initiative „Project Glasswing“ ausschließlich ausgewählten Unternehmen aus dem Bereich IT-Sicherheit und kritische Infrastruktur zur Verfügung. Beteiligt sind unter anderem AWS, Apple, Cisco, CrowdStrike, Google, Microsoft und die Linux Foundation.

Warum gilt Mythos als „zu gefährlich“ für die Öffentlichkeit?

Die Argumentation Anthropics folgt einem klaren Muster: Solange noch kein vergleichbar leistungsfähiges Modell öffentlich verfügbar ist, soll Mythos genutzt werden, um Schwachstellen zu schließen, bevor andere KI-Systeme zu Mythos aufholen. Das scheint zunächst wie eine bloße Wette gegen den Markt. Sobald andere Modelle – auch in den Händen von Kriminellen oder staatlichen Akteuren – ähnliche Fähigkeiten erreichen, wäre der defensive Vorsprung verloren. Ein neues Wettrüsten hat also längst begonnen!

Dieser Ansatz ist sicherlich nachvollziehbar, aber risikobehaftet. Er basiert auf der Annahme, dass:

• der Zugriff auf Mythos kontrollierbar bleibt und die Öffentlichkeit keinen Zugriff erlangt,
• die beteiligten Unternehmen vertrauenswürdig und sicher genug sind, um das Modell zu schützen,
• und dass das Tempo der defensiven Nutzung schneller ist als das Aufholen offensiver Akteure.

Genau an diesen Annahmen entzündet sich aus einer GRC-Perspektive die Kritik.

Der Vorfall: Unbefugter Zugriff auf Claude Mythos seit Tag 1

Wenige Wochen nach der Vorstellung berichtete Heise online unter Berufung auf einen Bloomberg-Bericht, dass eine Gruppe Unbekannter bereits am Tag der Vorstellung Zugriff auf Mythos erlangt haben soll. Der Zugang sei laut Bericht über einen Drittanbieter-Mitarbeiter sowie über eine „fundierte Vermutung“ zur internen URL des Modells möglich gewesen. Die Gruppe tausche sich in einem privaten Discord-Kanal aus und nutze Mythos demnach für vergleichsweise harmlose Aufgaben, etwa den Bau von Websites – nicht für Angriffe. So wird berichtet.

Anthropic habe zugesichert, den Vorgang zu prüfen, und betont, es gebe keine Hinweise auf Auswirkungen über die Drittanbieter-Umgebung hinaus. Aus GRC-Sicht ist genau das aber der Punkt: Selbst wenn keine kriminelle Nutzung nachweisbar ist, zeigt der Vorfall, wie schwer der „kontrollierte Zugriff“ auf hochsensible KI-Modelle wie Claude Mythos in der Praxis durchzusetzen ist.

Bewertung aus GRC-Sicht: Drei zentrale Risken bei Claude Mythos

1. Lieferketten- und Dienstleistersicherheit

Der Vorfall macht erneut deutlich, dass Sicherheit nicht an der eigenen Unternehmensgrenze endet. Mit jedem Dienstleister, jedem Drittanbieter-Tool und jedem KI-Modell, das in Geschäftsprozesse integriert wird, vergrößert sich die Angriffsfläche. Frameworks wie NIS-2, BSI IT-Grundschutz und ISO 27001 fordern zu Recht eine systematische Bewertung der gesamten Lieferkette – inklusive KI-Komponenten und angebundener Systeme.

2. Risikoeinstufung leistungsfähiger KI-Modelle

Mythos ist ein praktisches Beispiel für ein Hochrisiko-KI-System im Sinne des EU AI Acts – auch wenn es formal nicht als solches reguliert wird, weil es nicht öffentlich angeboten wird. Unternehmen sollten den Fall zum Anlass nehmen, eingesetzte KI-Modelle systematisch zu klassifizieren:

• Welches Modell hat welche Fähigkeiten?
• Wo wird es verarbeitet?
• Welche Daten fließen ein?
• Welche vertragliche Grundlagen haben wir für diese Daten?
• Und welche Konsequenzen hätte ein Missbrauch oder Datenabfluss?

3. Verantwortung der Geschäftsleitung

Sowohl NIS-2 als auch der EU AI Act verlagern die Verantwortung für Cybersicherheit und KI-Compliance ausdrücklich auf die Leitungsebene. Der Fall Mythos zeigt, dass „die KI-Themen kennt sich der CTO schon mit aus“ als Governance-Ansatz nicht mehr ausreicht. Geschäftsführung und Vorstand müssen Risiken durch leistungsfähige KI-Modelle – eigene wie fremde – in ihre Risikolandschaft aufnehmen.

Was bedeutet das für deutsche Unternehmen und öffentliche Stellen?

Auch wenn Claude Mythos für die meisten Organisationen nicht direkt verfügbar ist, hat der Fall mittelbare Konsequenzen, für jede erarbeitete und bereits implementiert KI-Strategie:

• Schwachstellen in weitverbreiteter Software (Betriebssysteme, Browser, Open-Source-Bibliotheken) können durch Mythos und vergleichbare Modelle schneller identifiziert werden, im Idealfall (vor Exploit) durch Verteidiger, im Worst Case (nach Exploit) durch Angreifer.
• Patch-Management und Vulnerability-Management gewinnen weiter an Bedeutung. Wer Updates verzögert, riskiert, in einem Zeitfenster angegriffen zu werden, das KI-Tools dramatisch verkürzen. Wir reden nicht von Monaten oder Wochen, sondern von Tagen bei kritischen Sektoren.
• Die Bedeutung von Threat Intelligence und Incident Response wächst, weil Angriffe potenziell schneller, automatisierter und schwerer zuzuordnen werden.
• Regulierte Sektoren (Finanzwesen, KRITIS, öffentliche Verwaltung) müssen damit rechnen, dass Aufsichtsbehörden KI-bezogene Anforderungen verschärfen, etwa im Rahmen von NIS-2-Prüfungen oder DORA.

Bedeutung für Governance, Risk und Compliance

Aus GRC-Sicht ist Claude Mythos kein Einzelrisiko, sondern ein Vorbote. Das Thema KI-Sicherheit verlagert sich gerade vom „IT-Thema“ auf die Steuerungsebene der Organisation:

• Governance muss klären, wer im Unternehmen über den Einsatz von KI-Systemen entscheidet, welche Modelle erlaubt sind und welche Daten sie sehen dürfen.
• Risk Management muss KI-spezifische Risiken (Modellmissbrauch, Datenabfluss, Halluzinationen, Modell-Diebstahl oder Exploits sicherheitsrelevanter Systeme) systematisch erfassen und mit klassischen Cyber-Risiken verknüpfen.
• Compliance muss die Brücke schlagen zu DSGVO, EU AI Act, NIS-2, BSI C5 und sektorspezifischen Vorgaben und dabei nachweisbar bleiben.

Wer KI-Sicherheit weiterhin nur als technische Frage behandelt, wird im Ernstfall weder gegenüber Aufsichtsbehörden noch gegenüber Kunden erklären können, warum bestimmte Risiken nicht erkannt oder nicht adressiert wurden.

Unterstützung durch Elsen GRC

Elsen GRC unterstützt Unternehmen und öffentliche Stellen dabei, KI-Risiken strukturiert zu bewerten und in bestehende Governance-, Risk- und Compliance-Strukturen zu integrieren. Dazu gehören die Bewertung eingesetzter KI-Systeme, der Aufbau einer KI-Governance im Sinne des EU AI Acts, die Verzahnung mit NIS-2- und Datenschutzanforderungen durch KI-orientierte Datenschutzberatung sowie die Sensibilisierung der Geschäftsleitung.

Der Fall Claude Mythos sollte nicht Anlass für Panik, sondern für eine nüchterne Bestandsaufnahme sein: Welche KI-Systeme nutzen wir? Wer ist verantwortlich? Welche Risiken akzeptieren wir bewusst und welche nicht?

Gerne unterstütze ich Sie dabei im Rahmen eines unverbindlichen Erstgesprächs.

Foto: Foto von Palash Jain auf Unsplash

Quellen:

• Anthropics neues KI-Modell Mythos: Zu gefährlich für die Öffentlichkeit – Heise online
• Anthropics gefährliche KI Mythos: Unbefugte wohl mit Zugriff seit dem ersten Tag – Heise online
• Project Glasswing – Anthropic
• Mythos Preview – Anthropic Red Team Blog

Der Beitrag Ist Claude Mythos ein Sicherheitsrisiko? Eine GRC-Perspektive erschien zuerst auf ELSEN GRC.

Executive Summary: Sicherheitslücke in Claude Cowork – Datei-Diebstahl via Prompt Injection?

Nur wenige Tage nach dem Start von Claude Cowork haben Sicherheitsforscher eine kritische Schwachstelle ermittelt: Angreifer können in scheinbar harmlosen Dokumenten wie E-Mails, PDFs und anderen Filesunsichtbare Anweisungen verstecken, die den KI-Agenten wie Claude’s „Cowork“ dazu bringen, vertrauliche Dateien aus verbundenen Ordnern des lokalen Systems zu exfiltrieren – und zwar ohne menschliche Genehmigung. Der Angriff nutzt eine bekannte Isolationsschwäche in der containerisierten Codeausführungsumgebung von Claude, die laut Berichten zwar bekannt, aber bislang nicht aktiv geschlossen wurde. Für Governance, Risk und Compliance ist das ein klassischer „Reality Check“: Sobald KI-Agenten Zugriff auf lokale Dateisysteme, Integrationen oder Unternehmensdaten erhalten, wird Prompt Injection nicht zu einem theoretischen Risiko, sondern zu einem konkreten Datenabfluss-Szenario mit potentiell erheblichen Folgeschäden.

Der Fall zeigt sehr plastisch, warum „agentische“ KI-Systeme („agentic ai“, also KI, die nicht nur antwortet, sondern Aktionen ausführt) eine neue Risikoklasse darstellen. Die Kernfrage für Organisationen lautet nicht mehr: „Ist das Tool nützlich?“, sondern:  Welche Daten dürfen überhaupt in Reichweite eines KI-Agenten liegen – und wie verhindern wir, dass der Agent auf manipulierte Anweisungen reagiert?

Was ist Claude Cowork und warum ist die Sicherheitslücke in Claude Cowork so kritisch?

Claude Cowork ist eine vollständig durch die von Anthropic entwickelte KI Claude automatisiert geschriebene Agenten-Software, die als produktiver KI-Begleiter gedacht ist, der mit der (lokalen) Arbeitsumgebung interagieren kann – z. B. über verbundene Ordner, Browser-Aktionen oder Integrationen. Wir sprechen also über eine direkte Integration von KI in die Systemumgebung beispielsweise von MacOS.

Genau diese Nähe zur „echten“ Datenquellen macht den Unterschied zu einem normalen Chatbot wie ChatGPT oder Google Gemini. Denn anders als in diesen Chat-basierten LLMs müssen in Claude Cowork keine Dateien hoch- und wieder runtergeladen werden, um eine aktive (Mit-) Arbeit der KI zu ermöglichen, sondern dieses geschiehet direkt im Dateisystem des lokalen Rechners. Claude nutzt dabei das bereits aus Claude Code bekannte „Terminal System“, das insbesondere bei Softwareentwickler sehr beliebt ist und erheblichen Vorteile gegenüber der Entwicklung beispielsweie mit OpenAIs „Codex“ beitet.

Wenn ein Agent Dateien lesen und Aktionen ausführen kann, wird jede Eingabe- oder Dokumentquelle zu einer potenziellen Angriffsfläche. heise und t3n sprechen in diesem Zusammenhang von Dateiexfiltration über indirekte Prompt-Injektionen – also versteckte Befehle, die nicht in der sichtbaren Benutzeranweisung stehen, sondern „im Hintergrund“ in einem Dokument platziert werden. Klassischen Beispiele sind schwarze Schriften auf schwarzem Hintergrund oder weiße Schriften auf weißem Hintergrund, die über eingelesene PDF-, Word- oder auch HTML-Dokumente direkt in den Systemprompt wandern und unauthorisierte Aktionen durchführen könnten.

So läuft der Angriff ab: „Harmloses Dokument“ + versteckte Anweisung = Datei-Upload

Die von Sicherheitsforschern beschriebene Angriffskette ist aus Angreifersicht unangenehm simpel: Ein Nutzer verbindet Claude Cowork mit einem lokalen Ordner, in dem auch vertrauliche Inhalte liegen (z.B. Fotos, andere Dokumente, Source Code). Danach wird eine Datei (z. B. eine Word-Datei) in Cowork geladen, die wie ein nützliches Hilfsdokument wirkt – in der Praxis werden solche „Prompt- oder Skill-Dateien“ gerne online geteilt, was die Eintrittswahrscheinlichkeit erhöht. In das Dokument ist jedoch eine Anweisung eingebettet, die für Menschen praktisch unsichtbar ist, etwa durch sehr kleine Schrift und Farb-/Layout-Tricks. The Decoder beschreibt das konkret als 1-Punkt-Schrift, weiß auf weiß, mit minimalem Zeilenabstand.

Wenn der Nutzer Cowork dann bittet, die vertraulichen Daten „auf Grundlage“ dieses Dokuments zu analysieren, übernimmt die versteckte Anweisung die Kontrolle. Laut heise und t3n wird der Agent dabei u. a. angewiesen, einen curl-Befehl auszuführen und eine Datei über die Anthropic File-Upload-API hochzuladen – inklusive Übermittlung eines API-Schlüssels der Angreifer, sodass die Datei direkt auf deren Konto landet. Besonders relevant: Während dieses Ablaufs ist keine manuelle Freigabe erforderlich.

Warum eine Sicherheitslücke bei Claude Cowork so schwer zu erkennen ist

Ein zentraler Punkt ist, dass der Datenabfluss nicht „wie Malware“ wirkt. Der Upload passiert über legitime, für das Produkt notwendige Schnittstellen. Laut Berichten bleibt der Angriff oft unentdeckt, weil die Anthropic-API als vertrauenswürdig gilt und daher nicht automatisch als verdächtiger Datenabfluss auffällt.
heise und t3n greifen zudem die Kritik auf, dass „Achtet auf verdächtige Aktionen“ als Warnhinweis für normale Nutzer nicht realistisch ist – Prompt Injection ist für viele Anwender schlicht nicht zuverlässig erkennbar.

GRC-Relevanz: Was bedeutet das für Governance, Risk und Compliance?

Auch für diesen sicherheitsrelevanten Case mit Claude Cowork nehme ich eine Einordnung in den Kontext von GRC vor, damit IT-Leader, IT-Spezialisten und Berater auf die neuen Bedrohungen durch agentische Systeme in Zukunft besser reagieren können:

Governance: KI-Agenten mit Datei- oder Integrationszugriff gehören nicht in die „Tool-Ecke“ einzelner Teams. Es braucht klare Policies: Welche Verzeichnisse dürfen angebunden werden? Welche Datenklassen sind tabu (Kundendaten, Verträge, HR, Quellcode, Finanzzahlen)? Welche Tools und Schnittstellen sind freigegeben – und mit welchen Settings?

Risk: Prompt Injection ist hier kein abstraktes Modellrisiko, sondern ein Datenabfluss-Risiko durch nicht vertrauenswürdige Inputs (Dokumente, Webseiten, geteilte „Skills“). Das Thema gehört klar in das Cyber-Risikomanagement: Eintrittswahrscheinlichkeit für Schäden steigt, sobald Agenten in reale Workflows integriert werden. Schadenshöhe ist potenziell hoch, weil es um vertrauliche Dateien geht – und diese könne personenbezogene, sensible Daten enthalten ebenso wie schützenswerte Geschäfts- und Kundendaten.

Compliance: Sobald personenbezogene Daten oder vertrauliche Unternehmensinformationen betroffen sein können, treffen Datenschutz, Geheimhaltung, Vertrags- und Sicherheitsanforderungen aufeinander. Organisationen müssen nachweisen können, dass sie angemessene TOMs etabliert haben – und dass KI-Tools nicht „ungeprüft“ Zugriff auf sensible Daten erhalten. Der Fall ist zudem ein gutes Beispiel für „Shadow AI“: Wenn Mitarbeitende solche Agenten eigenständig anbinden, entstehen Compliance-Risiken außerhalb formaler Kontrollen.

Pragmatische Konsequenzen: Was Unternehmen jetzt tun sollten

Wer agentische KI-Tools testet oder unmittelbar einführen will, sollte kurzfristig drei Leitplanken setzen:

1. Scope begrenzen (nur nicht-sensitive Testdaten, keine lokalen Ordner mit sensiblen Kundendaten).
2. Input-Hygiene (keine fremden „Skills“, Prompt-Dateien oder Dokumente aus unklaren Quellen in produktive Workflows).
3. Kontrollen einziehen (Monitoring, DLP (Data Loss Prevention)/Upload-Kontrollen, klare Freigabeprozesse für Integrationen und Datei-Zugriffe). Diese Maßnahmen ersetzen keine Produkt-Fixes – reduzieren aber das Risiko, bis Anbieter wirksame Schutzmechanismen liefern.

Beratung zur sicheren KI-Nutzung im Kontext Cybersecurity durch Elsen GRC

Elsen GRC unterstützt Unternehmen, SaaS-Anbieter und Behörden dabei, KI-Agenten und KI-Integrationen GRC-sicher zu betreiben – insbesondere dort, wo Datei-, System- oder Integrationszugriffe ins Spiel kommen. Dazu gehören Use-Case-Assessments, Policy- und Governance-Design (inkl. Datenklassen/Scopes), Risikoanalysen zu Prompt-Injection-Szenarien sowie die Ableitung pragmatischer TOMs (Freigaben, Monitoring, technische Guardrails). Ziel ist eine KI-Nutzung, die Produktivität ermöglicht, ohne unkontrollierte Datenabflüsse und Haftungsrisiken zu provozieren. Vereinbaren Sie gerne ein unverbindliches Beratungsgespräch.

Foto: © Claude.com

Quellen:

• Sicherheitslücke in Claude Cowork: So verschaffen sich Hacker unbemerkt Zugriff – heise.de
• Sicherheitslücke in Claude Cowork – t3n.de
• Claude Cowork hit with file-stealing prompt injection – The Decoder

Der Beitrag Kritische Sicherheitslücke in Claude Cowork entdeckt erschien zuerst auf ELSEN GRC.

Hintergrund und Einordnung

Der Bericht von Anthropic beschreibt einen Angriff, der durch die vermutlich staatlich finanzierte Gruppe „GTG-1002″ ausgeführt wurde. Die Angreifer sollen Zugriff auf Claude Code erhalten und ihn genutzt haben, um große Teile der Cyberoperation automatisch zu koordinieren. Dazu zählen das Auswerten öffentlich verfügbarer Informationen über Zielorganisationen, die Generierung von Angriffscodes, automatisierte Testläufe, das Erstellen neuer Exploit-Varianten und die schrittweise Ausweitung des Angriffs auf weitere Systeme. In der Darstellung von Anthropic übernahm die KI rund 80 bis 90 Prozent dieser Schritte ohne manuellen Eingriff, also quasi autonom, gesteuert über nur wenige High-Level-Prompts.

Heise stellt diese Darstellung allerdings infrage. Laut mehreren Expert:innen fehlen konkrete technische Details, die notwendig wären, um die Analyse nachzuvollziehen. Es wurden weder technische Indikatoren für Kompromittierung noch nachvollziehbare Datenpunkte veröffentlicht, anhand derer nachvollziehbar wäre, wie autonom Claude tatsächlich agiert hat. Einige Fachleute bewerten den Bericht eher als Warnsignal denn als belastbares Ereignis: ein Szenario, das grundsätzlich möglich ist, dessen konkrete Ausgestaltung aber nicht zweifelsfrei belegt scheint.

Gerade diese Gemengelage – technisch plausibel, aber faktisch unklar – macht den Fall für das Risiko-Management so relevant. Unternehmen können es sich nicht leisten, auf vollständige Evidenz zu warten. Die entscheidende Frage lautet: Wie schnell können Angreifer KI-Modelle in reale Angriffsketten einbauen – und wie gut sind Organisationen darauf vorbereitet?

Das Architektur-Diagramm des versuchten Angriffs laut Anthropic (Bild: © Anthropic)

Auswirkungen auf Unternehmen und Behörden

Für Unternehmen bedeutet der Fall vor allem eine Verschiebung der Bedrohungsrealität. KI-gestützte Werkzeuge ermöglichen eine deutlich höhere Geschwindigkeit, Skalierung und Variabilität von Cyber-Angriffen. Reconnaissance, Code-Erstellung und Exploit-Anpassung können in Sekunden erfolgen und in Varianten, die klassische Signatur- oder Mustererkennungen umgehen. Organisationen, die KI bereits intern einsetzen, schaffen darüber hinaus selbst neue Angriffsflächen: unzureichend abgesicherte Modelle, API-Zugänge, Prompt-Pipelines und interne Agentensysteme können missbraucht werden, wenn sie nicht klar überwacht und kontrolliert werden.

Für Behörden, kritische Infrastrukturen und öffentliche Einrichtungen entsteht ein zusätzlicher Handlungsdruck. Die Kombination aus politisch motivierten Akteuren und KI-gestützten Tools führt zu einer Bedrohungslage, die unmittelbare Auswirkungen auf demokratische, wirtschaftliche und administrative Prozesse haben kann. Die Aufklärung KI-gestützter Angriffe ist zudem schwieriger, weil Attribution, Log-Analyse und Beweisführung deutlich komplexer werden, wenn wesentliche Teile der Angriffskette nicht mehr direkt menschlich gesteuert sind oder nicht zusammenhängend protokolliert werden können.

Sowohl privatwirtschaftliche als auch öffentliche Organisationen müssen daher ihre bestehenden Sicherheitsarchitekturen auf KI-spezifische Risiken überprüfen: Welche Systeme könnten automatisiert ausgenutzt werden? Welche internen KI-Werkzeuge müssten stärker überwacht werden? Und wie schnell können Incident-Response-Prozesse reagieren, wenn die Angriffsgeschwindigkeit nicht mehr menschlich, sondern maschinell ist?

Bedeutung für Governance, Risk & Compliance

Der Fall zeigt, dass Unternehmen nicht nur technische Sicherheitsmaßnahmen anpassen müssen, sondern auch ihre Governance-, Risk- und Compliance-Strukturen. KI-Modelle und Agentensysteme benötigen klare Verantwortlichkeiten, definierte Daten- und Zugriffskontrollen sowie revisionssichere Überwachungsmechanismen sind ein Muss. Risikobewertungen sollten künftig künstliche Autonomie, sog. „adversarial prompts“ (zum ausloten von Exploit-Möglichkeiten in KI Modellen), Missbrauch über APIs und potenziell selbstständig eskalierende Angriffspfade berücksichtigen. Die Compliance wiederum muss sicherstellen, dass alle KI-gestützten Prozesse nachvollziehbar dokumentiert, auditierbar und robust gegenüber Fehlverhalten oder Missbrauch sind.

Einschätzung zum KI-Cyberangriff mit Claude

Ob es sich im konkreten Fall um einen tatsächlich autonomen KI-Cyberangriff mit Claude handelte oder teilweise um ein „Warnszenario“ mit „Marketingcharakter“,  die zentrale Erkenntnis bleibt: KI wird zum möglichen Angriffsvektor. Unternehmen, die ihre Sicherheitsarchitektur weiterhin nur im klassischen IT-Kontext betrachten, übersehen eine wesentliche Risikoentwicklung. KI-Systeme müssen künftig als eigenständige, dynamische Komponenten im Angriffsökosystem bewertet werden.

Beratung für Cyberangriffe durch KI durch Elsen GRC

Elsen GRC berät Unternehmen und Behörden dabei, ihre Cybersecurity- und Risikoarchitektur an dieses neue Bedrohungsbild anzupassen. Dazu gehört die Analyse möglicher KI-Angriffsvektoren, die Bewertung der eigenen Exponiertheit, die Entwicklung robuster Governance-Modelle für KI-Systeme sowie die Integration KI-spezifischer Risikofaktoren in bestehende Compliance- und Incident-Response-Strukturen. Darüber hinaus begleitet Elsen GRC Organisationen bei der Dokumentation, Überwachung und dem sicheren Betrieb von KI-gestützten Anwendungen – mit einem klaren Fokus auf Risikominimierung, Transparenz und praktische Umsetzbarkeit, die aus der echten Praxis von über 14 Jahren Software-Entwicklung stammt.

Unverbindliche Beratung anfordern

Der Beitrag Angeblicher KI-Cyberangriff mit Claude? Was der Fall für Risiko-Management wirklich bedeutet erschien zuerst auf ELSEN GRC.