Über den Snowflake-Vorfall und warum niemand feststellen konnte, wer den Bug geschrieben hatte.

Am 17. August 2026 veröffentlichte ein Sicherheitsanbieter eine Untersuchung, die einen autonomen Agenten beschrieb, der eine Schwachstelle in einem öffentlichen Snowflake-Repository gefunden und ausgenutzt hatte. Die technische Darstellung ist unstrittig und verdient es, klar benannt zu werden. Ein Workflow in diesem Repository lief automatisch, sobald irgendjemand ein Issue eröffnete, und verarbeitete den von der eröffnenden Person bereitgestellten Text im selben Ausführungsschritt, der Zugangsdaten für Snowflakes internes Issue-Tracking-System enthielt. Ein sicheres Handhabungsmuster, das das Repository zuvor verwendet hatte — Werte über Umgebungsvariablen zu übergeben, statt sie direkt in einen Shell-Kontext zu expandieren — war nicht mehr vorhanden. Der autonome Forschungsagent des Anbieters identifizierte die Schwäche, nutzte sie aus, erlangte die Zugangsdaten, bestätigte den Zugriff auf das interne System und bewertete den möglichen Schadensradius ohne menschliche Beteiligung. Beim ersten Versuch scheiterte er, las den daraus resultierenden Fehler und passte sich an. Die verstrichene Zeit vom Erreichen des Default-Branches durch den fehlerhaften Workflow bis zur autonomen Ausnutzung betrug fünf Tage. Die Offenlegung erfolgte am 23. Juni 2026 über das koordinierte Programm des Anbieters; Snowflake behob das Problem am selben Tag, stellte das sichere Muster wieder her, rotierte die Zugangsdaten und bestätigte anhand von Audit-Logs, dass die Forschenden die einzigen Parteien waren, die den Endpoint während des Expositionsfensters berührt hatten. Alle Beteiligten verhielten sich korrekt. Dann brach die Geschichte darüber, wer den fehlerhaften Code geschrieben hatte, im Laufe eines einzigen Abends öffentlich auseinander — und dieser Zusammenbruch, nicht die Schwachstelle, ist der Teil, auf den Unternehmen achten sollten.

Dies ist der zwanzigste Beitrag in einer Reihe, die ich für KI-Plattform - Made in Germany | neuland.ai schreibe. [¹] Das wiederkehrende Argument ist, dass die Eigenschaften, die in Enterprise AI zählen — Compliance, Eingrenzung, Autorisierung — Eigenschaften der Architektur sind und nicht Funktionen, die nachträglich darübergelegt werden. [²] Dieser Beitrag fügt der Liste eine weitere hinzu, und zwar eine, die ich nicht benannt hätte, bis ich sah, wie ein gut ausgestattetes Sicherheitsteam, der Großteil der Technologiepresse und zwei Korrekturrunden daran scheiterten, eine Tatsache festzustellen, die trivial überprüfbar hätte sein müssen.

Was mit der Zuschreibung geschah

Die anfängliche Berichterstattung lautete, dass ein KI-Coding-Tool die Schwachstelle eingeführt und eine andere KI sie ausgenutzt habe. Es ist eine überzeugende Erzählung, und entsprechend verbreitete sie sich.

Der Commit, der den fehlerhaften Workflow auf den Main-Branch brachte, führte ein KI-Autofix-Tool unter seinen Co-Autoren auf. Das Forschungsteam interpretierte dies so, dass das Tool den verwundbaren Code verfasst habe, und der Großteil der Berichterstattung folgte dem.

Innerhalb weniger Stunden las ein Reporter die zugrunde liegenden Commits. Der von dem KI-Tool mitverfasste Commit hatte eine andere Datei geändert. Das unsichere Refactoring befand sich in einem separaten Commit, der auf etwa zehn Monate früher datiert war und den der Plattformanbieter einem namentlich genannten menschlichen Ingenieur zuschreibt. Die Erklärung ist banal und vollständig mechanisch: Squash-Merging faltet jeden Commit in einem Pull Request zu einem einzigen Commit zusammen, und Co-Autor-Zuschreibungen werden dabei mitgenommen. Die Zeile dokumentiert eine Beteiligung am Pull Request. Sie dokumentiert nicht die Urheberschaft der geänderten Zeilen. [³]

Der Plattformanbieter führte eine interne Prüfung durch und wies das Framing ausdrücklich zurück. Er erklärte, dass die Beiträge, die zur Schwachstelle führten, von einem Menschen verfasst und weder von seinem Tool geprüft noch beigetragen worden seien. Das Forschungsteam änderte seinen Beitrag noch am selben Abend und revidierte die Behauptung dahingehend, dass das Tool ein Co-Autor gewesen sei, der den gemergten Pull Request geprüft und ohne Identifizierung der Schwachstelle als unbedenklich gemeldet habe — und fügte den Satz hinzu, der die ursprüngliche Schlagzeile auflöst: Es ist unklar, ob die Codeänderung KI-unterstützt war. Mindestens eine Publikation änderte ihre Überschrift von einer KI, die den Code kaputt gemacht habe, zu einer KI, die ihn nicht erkannt habe, und fügte eine Korrektur an. Es wurde keine CVE vergeben. [⁴]

Ich möchte mit dem Ton hier vorsichtig sein, denn es gibt in dieser Geschichte keinen Bösewicht. Die Forschung war gut und die Offenlegung verantwortungsvoll. Der Einwand des Plattformanbieters erscheint gut begründet. Die Publikationen korrigierten schnell. Snowflakes Reaktion war vorbildlich — Behebung am selben Tag, Rotation der Zugangsdaten, forensische Bestätigung des Expositionsfensters.

Was schiefging, war, dass der Datensatz die Frage nicht beantworten konnte. Mehrere kompetente Organisationen betrachteten dieselbe Versionskontrollhistorie und kamen zu gegensätzlichen Schlussfolgerungen darüber, ob eine Maschine eine bestimmte Änderung geschrieben hatte, und die Uneinigkeit wurde nicht durch Konsultation eines autoritativen Provenienzdatensatzes gelöst, sondern dadurch, dass ein Journalist einzelne Commits unterhalb eines gesquashten Merges manuell las.

Wer den Workflow geändert hat, stand nirgends. Zuschreibung ist keine Frage der Sorgfalt, sondern der Aufzeichnung.

Bild: KI generiert mit neuland.ai HUB

Warum das ein Architekturproblem ist und keine Peinlichkeit

Betrachten wir, was sehr viele Unternehmen derzeit in ihre Engineering-Richtlinien schreiben. KI-generierter Code erhält zusätzliche Prüfung. KI-verfasste Änderungen durchlaufen verpflichtende statische Analyse. Maschinelle Beiträge zu sicherheitssensiblen Komponenten erfordern eine namentlich benannte menschliche Freigabe. Beitragsraten werden verfolgt und berichtet.

Jede einzelne dieser Richtlinien setzt voraus, dass man identifizieren kann, welche Änderungen welche sind. Wenn der Provenienzdatensatz die Build-Pipeline nicht überlebt — und Squash-Merging ist nahezu universelle Praxis —, dann ist die Richtlinie genau in den Fällen, in denen es am meisten darauf ankommt, nicht durchsetzbar, weil das gemergte Artefakt nicht mehr unterscheidet, was eine Maschine vorgeschlagen und was ein Mensch geschrieben hat.

Die Folgen verstärken sich in vier Richtungen.

Differenzierte Prüfung wird zum Theater. Eine Richtlinie, die zusätzliche Kontrolle auf maschinengenerierte Änderungen anwendet, benötigt ein verlässliches Signal dafür, welche Änderungen das sind. Ohne dieses Signal gilt die Richtlinie entweder für alles, was niemand dauerhaft durchhält, oder für das, was das Tooling zufällig markiert hat, was genau zu diesem Vorfall geführt hat.

Forensik verschlechtert sich. Nach einem Vorfall lässt sich die Frage, ob es in der Codebasis ein KI-zuschreibbares Defektmuster gibt, nur beantworten, wenn Urheberschaft zum Zeitpunkt des Beitrags aufgezeichnet wurde. Sie nachträglich aus gesquashter Historie zu rekonstruieren, ist das, was der Journalist in dieser Geschichte manuell tun musste, für eine Datei, in einem Repository, während die ganze Branche zusah. Im Enterprise-Maßstab ist das kein Verfahren.

Anbieter-Verantwortlichkeit wird unauflösbar. Wenn die Vorschläge eines Tools eine wiederkehrende Klasse von Defekten erzeugen, liegt der Beweis dafür in Provenienzdaten. In diesem Fall kamen Anbieter und Forschende zu gegensätzlichen Schlussfolgerungen, und es gab keine autoritative Quelle, um die Frage zu klären.

Die Dokumentationspflichten werden erheblich schwieriger. Unter dem EU AI Act, der am 2. August 2026 breit anwendbar wurde, müssen Organisationen zunehmend beschreiben, wie ihre Systeme gebaut und gewartet wurden. [⁵] Eine Organisation, die nicht angeben kann, welche Komponenten ihrer Codebasis maschinengeneriert waren oder über welchen Zeitraum, wird dieses Gespräch unangenehm finden — und die Antwort hängt vollständig davon ab, ob Provenienz erfasst wurde, als der Beitrag geleistet wurde.

Also gehört Provenienz auf die Liste, die diese Reihe zusammengestellt hat. Compliance ist eine Systemeigenschaft. Eingrenzung ist eine Systemeigenschaft. Autorisierung dessen, was ein System wissen darf, ist eine Systemeigenschaft. Provenienz ist ebenfalls eine Systemeigenschaft — im Moment des Beitrags aufgezeichnet oder dauerhaft verloren, und keine nachgelagerte Richtlinie kann sie wiederherstellen.

Die andere Hälfte: Das Entdeckungsfenster ist kollabiert

Der Teil dieses Vorfalls, der von niemandem bestritten wird, ist bei näherer Betrachtung die folgenreichere Hälfte.

Ein autonomer Agent fand eine reale Schwachstelle in einem öffentlichen Repository eines großen Anbieters, nutzte sie aus, erlangte gültige Zugangsdaten, verifizierte den Zugriff auf ein internes System und bewertete den möglichen Schadensradius — ohne menschliche Anweisung. Als sein erster Versuch scheiterte, analysierte er den Fehler und passte sich an. Die gesamte Sequenz fand innerhalb von fünf Tagen statt, nachdem der Fehler den Default-Branch erreicht hatte. Das eigene Framing des Forschungsteams lautete, dass Entdeckungsfenster kollabieren und Sicherheitsorganisationen sich an eine Landschaft anpassen müssen, in der automatisierte Agenten Schwachstellen in Tagen statt Monaten finden und validieren. [⁶]

Ein früherer Beitrag in dieser Reihe argumentierte, dass Eingrenzung in beide Richtungen funktionieren muss — dass Ihre Agenten nicht herauskommen dürfen und die anderer nicht hineinkommen dürfen —, im Anschluss an eine Offenlegung, bei der Modelle eine Evaluierungsumgebung verließen und die Produktionsinfrastruktur eines Dritten erreichten. [⁷] Dieser Vorfall ist dasselbe Argument in seiner gewöhnlichen, unspektakulären Form. Es ging um keine Frontier-Fähigkeit, kein Exportkontroll-Drama, keine neuartige Technik. Ein kommerziell verfügbarer autonomer Forschungsagent erledigte kompetente Sicherheitsarbeit schnell, in einem öffentlichen Repository, gegen einen Defekt, den ein menschlicher Forscher vielleicht irgendwann gefunden hätte.

Daraus folgen zwei Konsequenzen für jeden, der eine Softwarelandschaft betreibt. Das Expositionsfenster für einen gemergten Defekt sollte nun als Tage statt Quartale angenommen werden, denn das ist die demonstrierte Geschwindigkeit automatisierter Entdeckung. Und die Verteidigungsarithmetik ändert sich: Wenn Finden automatisierbar und schnell ist, dann liegt der Hebel in den Gates, die verhindern, dass der Defekt den Default-Branch erreicht, nicht im anschließenden Reaktionsprozess.

Damit kehrt das Argument zu etwas zurück, das diese Reihe seit einem Jahr über Orchestrierung sagt.

Fünf Tage vom fehlerhaften Workflow bis zur Ausnutzung. Das Entdeckungsfenster ist kein Puffer mehr.

Bild: KI generiert mit neuland.ai HUB

Deterministische Gates und warum sie der Punkt sind

Die wiederkehrende Versuchung im agentischen Engineering besteht darin, alles durch einen Agenten zu routen und dem Urteil des Modells zu vertrauen. Die eigene Schlussfolgerung des Forschungsteams aus diesem Vorfall weist in die andere Richtung: Maschinengenerierte Pull Requests sollten derselben statischen Analyse und Sicherheitsprüfung unterzogen werden wie menschliche, weil probabilistische Codegenerierung veraltete oder unsichere Muster wieder einführen kann, die zuvor entfernt worden waren. [⁸]

Das ist eine Aussage über Determinismus, und es lohnt sich, präzise zu benennen, was sie impliziert. Ein Verifikationsschritt, der läuft, weil ein Reviewer daran gedacht hat, ihn auszuführen, ist keine Kontrolle. Ein Verifikationsschritt, der läuft, weil eine Änderung dieser Klasse immer reproduzierbar durch ihn geroutet wird und das Ergebnis aufgezeichnet wird, ist eine Kontrolle. Die Unterscheidung ist genau die, die ein früherer Beitrag dieser Reihe zwischen einem auf einer Canvas gezeichneten Workflow und einem als Daten aufgezeichneten Verfahren gezogen hat — wiederholbar, inspizierbar, jedes Mal identisch, mit einem dauerhaften Datensatz dessen, was geprüft wurde und was zurückkam. [⁹]

Dieselbe Logik gilt für die Defektklasse im Zentrum dieses Vorfalls. Ein Workflow, der von außen bereitgestellten Text in einen Ausführungskontext neben Live-Zugangsdaten platziert, ist ein Muster, das deterministische Analyse zuverlässig erkennt und ein probabilistischer Reviewer manchmal erkennt. Die Entscheidung, welches davon im Pfad eines Merges sitzt, ist eine Architekturentscheidung, keine Tooling-Präferenz.

Wo neuland.ai steht

Zwei Eigenschaften des KI-Plattform - Made in Germany | neuland.ai HUB sind hier relevant, und beide wurden hineindesignt statt nachträglich hinzugefügt.

Die erste ist, dass der Audit Trail append-only und event-sourced ist und aufzeichnet, was abgerufen wurde, was entschieden wurde, von welcher Identität, bei jedem Schritt eines agentischen Laufs. Der Grund, warum das für diese Diskussion relevant ist, ist derjenige, den der Vorfall illustriert: Provenienz, die im Moment der Handlung geschrieben wird, überlebt, und Provenienz, die nachträglich aus einem kollabierten Datensatz rekonstruiert wird, nicht. Ein agentischer Lauf im HUB benötigt keine forensische Archäologie, um festzustellen, was eine Maschine beigetragen hat, weil der Beitrag aufgezeichnet wurde, als er geschah, statt später aus einem Artefakt abgeleitet zu werden, das gesquasht worden war.

Die zweite ist, dass Orchestrierung dort deterministisch sein kann, wo die Arbeitslast es erfordert. Ein Verfahren wird als geordnete, wiederholbare Struktur aufgezeichnet, statt dem Modell überlassen zu werden, es pro Lauf neu zusammenzusetzen, was bedeutet, dass ein Verifikationsschritt in diesem Verfahren jedes Mal in derselben Reihenfolge ausgeführt wird und sein Ergebnis in denselben Datensatz geschrieben wird. Menschliche Freigabe kann an jedem Punkt im Graphen erforderlich gemacht werden, und die Freigabe wird gegen die Person aufgezeichnet, die sie erteilt hat. Für regulierte Arbeit — und für alles, was Zugangsdaten, Berechtigungen oder Produktionssysteme berührt — ist diese Reproduzierbarkeit der ganze Punkt. [¹⁰]

Keine dieser Aussagen ist eine Behauptung darüber, diese konkrete Klasse von Defekten zu erkennen. Statische Analyse erkennt sie, und statische Analyse ist eine ausgereifte Disziplin, die all dem vorausgeht. Die Behauptung ist enger und, wie ich denke, langlebiger: Wenn maschinelle Beiträge einen wachsenden Anteil dessen ausmachen werden, was in die Systeme eines Unternehmens gelangt, dann muss der Datensatz dessen, was eine Maschine beigetragen hat, eine erstklassige Eigenschaft der Plattform sein und nicht ein Nebenprodukt dessen, was das Versionskontroll-Tooling zufällig bewahrt hat.

Persönliche Einschätzung

Das Interessanteste an diesem Vorfall ist, wie schnell sich eine plausible Erzählung über KI-Risiken um ein Provenienzartefakt herum bildete, das sich als etwas anderes herausstellte, als alle angenommen hatten.

Es lohnt sich, dabei zu verweilen, denn der Impuls in der Enterprise-AI-Governance besteht im Moment darin, Richtlinien über KI-generierten Code zu schreiben — Review-Anforderungen, Freigabeschwellen, Beitragslimits, Offenlegungspflichten. Alles sinnvoll. Fast nichts davon durchsetzbar, wenn die darunterliegenden Systeme nicht zuverlässig sagen können, welche Beiträge maschinengemacht waren. Eine Richtlinie, die nicht belegt werden kann, ist eine Absichtserklärung, und die Lücke zwischen beidem ist dort, wo Audit Findings leben.

Das Zweite, bei dem es sich zu verweilen lohnt, sind die fünf Tage. Es geschah nichts Exotisches. Ein kommerziell verfügbarer autonomer Agent leistete solide Arbeit mit Maschinengeschwindigkeit gegen ein öffentliches Repository, und ein Fehler, der historisch für einen unbestimmten Zeitraum unentdeckt geblieben wäre, wurde innerhalb einer Arbeitswoche gefunden, ausgenutzt und validiert. Jede Organisation, die eine öffentliche Code-Oberfläche betreibt, sollte annehmen, dass dies jetzt der Standard ist, denn das ist es.

Beide Hälften weisen in dieselbe Richtung. Der Hebel hat sich zum Datensatz und zum Gate verschoben — zur Erfassung von Provenienz im Moment des Beitrags und dazu, deterministische Verifikation in den Pfad eines Merges zu setzen statt in die Hoffnung eines Reviewers. Keines von beidem ist glamourös. Beides ist Architektur, was bedeutet, dass beides zur Designzeit entschieden wird oder gar nicht.

Eine kurze Anmerkung zum regulatorischen Hintergrund, da er sich weiterentwickelt. Der EU AI Act wurde am 2. August 2026 breit anwendbar, wobei GPAI-Durchsetzungsbefugnisse nach Kapitel V ab diesem Datum verbindlich wurden; die Digital-Omnibus-Vereinbarung vom 7. Mai 2026 verschob die High-Risk-Verpflichtungen nach Anhang III auf den 2. Dezember 2027 und die Verpflichtungen nach Anhang I auf den 2. August 2028. [¹¹] Die mit diesem Regime kommenden Dokumentations- und Aufzeichnungserwartungen setzen voraus, dass eine Organisation beschreiben kann, wie ihre Systeme gebaut wurden. Dieser Vorfall ist eine nützliche Demonstration dafür, wie leicht diese Annahme scheitert.

Provenienz ist eine Systemeigenschaft. Das ist die Arbeit, die vor uns liegt, und es ist die Arbeit, die wir getan haben.

¹ Serienbeiträge bei Insights from neuland.ai: AI in practice, trends & deep dives.

² Siehe frühere Beiträge in dieser Reihe über Compliance als Systemeigenschaft, über Eingrenzung als bidirektionale Anforderung und über die Autorisierung dessen, was ein agentisches System wissen darf.

³ Untersuchung eines Sicherheitsanbieters, veröffentlicht am 17. August 2026, zu einer Script-Injection-Schwachstelle im Continuous-Integration-Workflow eines öffentlichen Snowflake-Repositorys. Der Workflow wurde ausgeführt, wenn ein öffentliches Issue eröffnet wurde, und exponierte Zugangsdaten für ein internes Issue-Tracking-System im selben Schritt, der extern bereitgestellten Issue-Text verarbeitete; das zuvor verwendete sichere Muster, Werte als Umgebungsvariablen zu übergeben, statt sie in einen Shell-Kontext zu expandieren, war nicht vorhanden. Die spätere Berichterstattung stellte fest, dass der Commit, der den fehlerhaften Workflow auf den Default-Branch brachte, infolge von Squash-Merging ein KI-Autofix-Tool unter seinen Co-Autoren aufführte, dass der von dem Tool mitverfasste Commit eine andere Datei änderte und dass das unsichere Refactoring aus einem separaten Commit vom August 2025 stammte, den der Plattformanbieter einem namentlich genannten menschlichen Ingenieur zuschrieb.

⁴ Der Plattformanbieter führte eine interne Prüfung durch und erklärte, dass die Beiträge, die zur Schwachstelle führten, von Menschen verfasst wurden und weder von seinem Tool geprüft noch beigetragen worden seien. Der Forschungsanbieter änderte seinen veröffentlichten Beitrag noch am selben Abend und revidierte die Behauptung dahingehend, dass das Tool ein Co-Autor gewesen sei, der den gemergten Pull Request geprüft und als unbedenklich identifiziert habe, ohne die Schwachstelle zu bemerken, und fügte hinzu, dass unklar sei, ob die Codeänderung KI-unterstützt war. Mindestens eine Publikation überarbeitete ihre Überschrift und fügte eine Korrektur an. Die Offenlegung erfolgte am 23. Juni 2026 über ein koordiniertes Offenlegungsprogramm; Snowflake behob das Problem am selben Tag, stellte das frühere sichere Handhabungsmuster wieder her, rotierte die betroffenen Zugangsdaten am folgenden Tag und bestätigte durch Analyse von Audit-Logs, dass die Forschenden die einzige Partei waren, die während des fünftägigen Expositionsfensters auf den Endpoint zugriff. Snowflake erklärte, dass seine Untersuchung keine Hinweise auf unautorisierten Zugriff gefunden habe. Es wurde keine CVE-Kennung vergeben.

⁵ EU AI Act breit anwendbar ab dem 2. August 2026.

⁶ Zu den veröffentlichten Schlussfolgerungen des Forschungsanbieters gehörte die Beobachtung, dass die Schwachstelle fünf Tage lang live war, bevor ein automatisierter Agent sie entdeckte und validierte, und dass sich Security Operations an diesen Zeitmaßstab anpassen müssen.

⁷ Siehe den früheren Beitrag in dieser Reihe über Eingrenzung als bidirektionale Systemeigenschaft, im Anschluss an eine Offenlegung im Juli 2026 zu Modellen, die eine sandboxed Evaluierungsumgebung verließen und Produktionsinfrastruktur Dritter erreichten.

⁸ Zu den veröffentlichten Schlussfolgerungen des Forschungsanbieters gehörte die Beobachtung, dass KI-Coding-Tools Code aus probabilistischen Mustern generieren und veraltete oder unsichere Muster wieder einführen können, und dass KI-generierte Pull Requests derselben statischen Analyse und Sicherheitsprüfung unterzogen werden sollten wie menschlich verfasster Code.

⁹ Siehe den früheren Beitrag in dieser Reihe über Verfahren, die als Daten aufgezeichnet werden, statt auf einer Canvas gezeichnet zu sein.

¹⁰ KI-Plattform - Made in Germany | neuland.ai HUB: append-only, event-sourced Audit Trail, der Abrufe, Entscheidungen und Identität bei jedem Schritt eines agentischen Laufs aufzeichnet; Orchestrierung, die deklarierte deterministische Verfahren unterstützt, die als geordnete, wiederholbare Strukturen neben agentischer Ausführung aufgezeichnet werden, mit menschlicher Freigabe an jedem Punkt im Graphen, die gegen die freigebende Identität aufgezeichnet wird. KI-Plattform - Made in Germany | neuland.ai AG behält die Verantwortung für Inhaltsqualität und saubere Lieferung von Ergebnissen über alle Kundenengagements hinweg.

¹¹ Vorläufige politische Einigung des Rates der EU und des Europäischen Parlaments zum Digital Omnibus on AI, 7. Mai 2026: High-Risk-Verpflichtungen nach Anhang III verschoben auf den 2. Dezember 2027; Verpflichtungen nach Anhang I verschoben auf den 2. August 2028; Watermarking-Verpflichtungen nach Artikel 50(2) verschoben auf den 2. Dezember 2026. GPAI-Durchsetzungsbefugnisse nach Kapitel V verbindlich ab dem 2. August 2026.

Bild generiert mit dem neuland.ai HUB.