Siebzehntausend Ereignisse, und die API sagte Nein

Der entscheidende Moment in der Offenlegung von Hugging Face ist nicht der Einbruch. Es ist eine Einsatzkraft, die mit den Beweisen in der Hand vor einer bezahlten API sitzt und abgewiesen wird. Am 16. Juli 2026 veröffentlichte das Unternehmen einen Bericht über einen Sicherheitsvorfall, bei dem Angreifer nach eigener Darstellung das nutzten, was das Unternehmen wörtlich so beschreibt: "(a remote-code dataset loader and a template-injection in a dataset configuration)", um Code auf einem Verarbeitungs-Worker auszuführen. Was die Einsatzkräfte danach in Händen hielten, war in den Worten von Hugging Face "the full attacker action log, comprised of more than 17,000 recorded events". An anderer Stelle spricht der Beitrag von "tens of thousands of automated actions".

Die Ablehnung ist die eigentliche Geschichte, und Hugging Face hat den Satz selbst geschrieben. Der Beitrag hält fest: "This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." Der letzte Teilsatz trägt das ganze Gewicht. Das System urteilte nicht über Hugging Face und lag dabei daneben. Es konnte das Urteil überhaupt nicht fällen.

Alles Vorstehende beruht ausschließlich auf dem Wort von Hugging Face, und das wollen wir deutlich sagen. Wir haben für keine der Tatsachen zum Vorfall eine unabhängige Primärquelle. Kein Medium hat sie bestätigt; jede Darstellung, die wir gefunden haben, gibt lediglich den Beitrag des Unternehmens wieder. Hugging Face nennt weder ein Einbruchs- noch ein Entdeckungsdatum, nur "Earlier this week" und "over a weekend". Es nennt keinen Anbieter. Und es erklärt die eigene Aufarbeitung für unabgeschlossen: "We are still completing our assessment of whether any partner or customer data was affected." Dieser Beitrag ist keine Vorfallberichterstattung. Er ist eine Lektüre dessen, was die veröffentlichten Verträge der Anbieter tatsächlich sagen, gemessen an dem Verhalten, das Hugging Face beschreibt.

Wir haben die drei Richtlinien nach dem Verbot durchsucht

Es gibt keines. Wir haben die veröffentlichten Nutzungsrichtlinien von Anthropic, OpenAI und Google abgerufen, und keine der drei untersagt die Analyse feindlichen Materials aus einem Einbruch in das eigene System. Das ist keine spitzfindige Lesart. Jedes Cyber-Verbot in allen drei Dokumenten ist durch einen Zusatz eingegrenzt, und das von Hugging Face beschriebene Verhalten fällt aus jedem dieser Zusätze heraus.

Die Nutzungsrichtlinie von Anthropic, gültig ab dem 15. September 2025, untersagt Tätigkeiten, die "Discover or exploit vulnerabilities in systems, networks, or applications without authorization of the system owner", und untersagt gesondert Nutzern, "Create or distribute malware, ransomware, or other types of malicious code". Hugging Face war der Systemeigentümer, die erste Klausel greift also nicht. Es analysierte bereits vorhandene Payloads, statt sie zu erzeugen oder zu verbreiten, also greift auch die zweite nicht. Nirgendwo im Dokument findet sich eine Ausnahme für Sicherheitsforschung, Vorfallreaktion oder Verteidigung. Jailbreak- und Prompt-Injection-Arbeit ist nur "without prior authorization from Anthropic" untersagt, was eine Genehmigung immerhin vorsieht, aber auf kein veröffentlichtes Verfahren verweist, um sie zu erhalten.

Die Nutzungsrichtlinien von OpenAI, gültig ab dem 29. Oktober 2025, untersagen die "destruction, compromise, or breach of another's system or property, including malicious or abusive cyber activity". Der Zusatz liegt im Wort another's. Das fragliche System war das eigene von Hugging Face. Wir haben keine Ausnahme für Sicherheitsforschung gefunden; die einzige dokumentierte Prüfhürde im Dokument betrifft "national security or intelligence purposes without our review and approval".

Googles Generative AI Prohibited Use Policy, zuletzt geändert am 17. Dezember 2024, sagt: "Do not compromise the security of others' or Google's services. This includes generating or distributing content that facilitates: Spam, phishing, or malware." Auch hier trägt der Zusatz die Last. Erbeutete Payloads zur Analyse einzureichen, heißt weder sie zu erzeugen noch sie zu verbreiten. Es gibt keine Sicherheitsausnahme, nur eine allgemeine Ausnahmeklausel: "We may make exceptions to these policies based on educational, documentary, scientific, or artistic considerations, or where harms are outweighed by substantial benefits to the public." Ein Antragsweg, ein Kontakt oder ein Verfahren dafür ist nicht dokumentiert. Alle drei Richtlinien waren vor dem Vorfall in Kraft.

Der Vertrag Ihres Anbieters ist nicht Ihre Kontrolle

Das ist der Satz, den wir einem Aufsichtsrat vorlegen würden. Die Lücke besteht nicht darin, dass Vertrag und Klassifikator einander widersprechen. Sie besteht darin, dass der Vertrag diesen Fall nie behandelt hat, während der Klassifikator sich verhielt, als sei er verboten. Die Einsatzkräfte von Hugging Face stießen nach eigener Darstellung auf eine Verweigerung für Arbeit, die keine veröffentlichte Richtlinie eines der drei großen Anbieter untersagt.

Ein Betreiber, der die Beschaffung korrekt erledigt hat, wäre trotzdem hineingelaufen. Sie haben die Nutzungsrichtlinie gelesen. Sie haben nichts gefunden, was die defensive Analyse des eigenen Einbruchs untersagt, weil dort nichts zu finden ist. Sie haben unterschrieben. Und dann war das, was Sie abgewiesen hat, die Laufzeitumgebung, ein anderes Objekt als das Dokument, von keiner ausgehandelten Bestimmung geregelt und in keiner geprüften Klausel beschrieben. Was Sie geprüft haben und was um drei Uhr nachts entscheidet, sind nicht dasselbe System.

Wir beschreiben eine Lücke in den veröffentlichten Bedingungen und werfen niemandem einen Verstoß vor. Anthropic und OpenAI erlauben beide vertragliche Anpassungen, und nicht öffentliche Unternehmensbedingungen können durchaus etwas anderes sagen als die öffentlichen Richtlinien; wir haben diese Bedingungen nicht gesehen und können uns dazu nicht äußern. Ebenso wenig können wir sagen, warum die Ablehnungen erfolgten. Hugging Face veröffentlicht keine Ablehnungsprotokolle, weshalb von außen nicht erkennbar ist, ob die Blockaden richtliniengetrieben waren oder gewöhnliches Über-Blocken durch Klassifikatoren, und wir raten nicht. Hugging Face nennt die blockierenden Anbieter ebenfalls nicht. Es sagt nur: "we are sharing this feedback with the providers concerned."

Was Hugging Face tatsächlich behauptet hat und was nicht

Die Schadensbewertung des Unternehmens ist enger, als eine flüchtige Lektüre nahelegt, und die Genauigkeit lohnt die Mühe. Hugging Face berichtet "no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean". Das sind zwei verschiedene Aussagen. Kein Hinweis auf Manipulation ist ein Fehlen von Befunden. Verified clean ist eine positive Feststellung zur Lieferkette und die stärkere der beiden. Beides zu einer einzigen Beruhigung zu verschmelzen, macht eine Vorfallzusammenfassung ungenauer als die Offenlegung, die sie zusammenfasst.

Der Angreifer war selbst automatisiert, und dieses Detail macht das Mengenproblem strukturell statt zufällig. Hugging Face beschreibt die Kampagne wörtlich als "run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known)". Ein Agent, der Zehntausende Aktionen erzeugt, hinterlässt ein Protokoll, das ein menschliches Team nicht in der nötigen Geschwindigkeit lesen kann, weshalb die Einsatzkräfte genau dafür ein Modell einsetzen wollten und genau dort blockiert wurden. Die einzige operative Anweisung im Beitrag ist kurz: "we recommend rotating any access tokens and reviewing recent activity on your account."

Und Hugging Face ist dem Argument zuvorgekommen, das manche Leser daraus ableiten möchten, deshalb zitieren wir es lieber, als darum herumzureden. Der Beitrag hält fest: "This is not an argument against safety measures on hosted models". Wir stimmen zu, und dieser Beitrag ist nicht dieses Argument. Schutzfilter, die eine Einsatzkraft nicht von einem Angreifer unterscheiden können, leisten gegen den Angreifer weiterhin echte Arbeit. Der Befund hier betrifft das, was die veröffentlichten Bedingungen auslassen, und das, was ein Betreiber deshalb prüfen sollte, nicht die Frage, ob es die Filter geben soll.

Prüfen Sie die Verweigerung, bevor der Vorfall Sie prüft

Setzen Sie die Übung noch in diesem Quartal an. Nehmen Sie echtes feindliches Material aus den eigenen Protokollen, reichen Sie es bei der API ein, zu der Sie in einem Vorfall tatsächlich greifen würden, und schreiben Sie auf, was zurückkommt. Der Befund, den Sie wollen, ist keine Beruhigung. Er ist eine sachliche Antwort auf eine Frage, die Ihnen kein Vertrag beantwortet, gewonnen an einem Tag, an dem nichts brennt.

Für einen europäischen Betreiber macht die Uhr das konkret statt theoretisch. Die Meldepflichten nach NIS2 laufen auf eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden hinaus, und DORA erlegt Finanzunternehmen ein eigenes enges Fenster für die Erstmeldung auf. Diese Fristen setzen voraus, dass Sie beschreiben können, was geschehen ist. Wenn Ihr Analyseweg in Stunde drei stockt, weil ein Filter Ihre eigenen Beweise nicht annimmt, hält die Uhr nicht an, während Sie das herausfinden. Das ist der Unterschied zwischen einer Erkenntnis in der Tabletop-Übung und einer Erkenntnis innerhalb einer regulatorischen Frist.

Halten Sie danach den Weg offen, der nicht verweigert werden kann. Der Rückfallweg von Hugging Face, in seinen Worten: "We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure." GLM 5.2 stammt von Z.ai, früher Zhipu, in Peking; Hugging Face selbst charakterisiert die Herkunft des Modells nicht, diese Einordnung ist unsere, nicht seine. Auf die Herkunft kommt es nicht an. Gewichte, die Sie besitzen, auf Hardware, die Sie kontrollieren, sind die einzige Konfiguration, in der die Laufzeitumgebung eines Dritten kein Mitspracherecht darüber hat, ob Ihr Vorfall ausgewertet wird. Jeder Betreiber sollte heute wissen, ob er so etwas hat und ob es funktioniert.