Ihre KI-Modelle sind ausführbarer Code. Die meisten Unternehmen behandeln sie wie Tabellenkalkulationen.
Als ich das Problem zum ersten Mal wirklich verstand, beobachtete ich in einem isolierten Container, wie ein Syscall-Trace vorbeiscrollte, und wartete darauf, dass nichts geschah.
Wir hatten ein Modell aus einer öffentlichen Registry gezogen — genau die Sorte, die ein Data Scientist hundertmal pro Quartal herunterlädt, ohne darüber nachzudenken. Die Model Card sah normal aus. Sie hatte einen grundlegenden Scan bestanden. Ich hatte es in eine Sandbox geladen, nicht weil ich dieser konkreten Datei misstraute, sondern weil ich angefangen hatte, alles in einer Sandbox zu laden. Und während die Deserialisierung lief, zeigte der Trace, wie der Prozess versuchte, eine Netzwerkverbindung zu öffnen, die er unter keinen Umständen hätte öffnen dürfen.
Das ist die ganze These der KI-Lieferkettensicherheit in einem einzigen Moment: Ihre Modelle sind keine Datendateien. Sie sind ausführbarer Code, der in dem Augenblick läuft, in dem Sie ihn laden. Die meisten Organisationen behandeln sie wie Tabellenkalkulationen — träge Dinge, die man herunterlädt und öffnet — und genau diese Lücke zwischen dem, was ein Modell ist und wie es behandelt wird, ist genau der Punkt, an dem die Sicherheitsverletzungen passieren.
Ein Modell ist kein Dokument, das man öffnet. Es ist ein Programm, das man mit den Rechten desjenigen ausführt, der es gestartet hat.
Die Reverse-Shell-Geschichte ist nicht einmal hypothetische Branchenlegende. Von einem Modell namens „baller423“ auf Hugging Face wurde festgestellt, dass es eine Reverse Shell zu einem externen Host aufbaute. Es sah normal aus. Es bestand grundlegende Scans. Es führte beliebigen Code aus, sobald jemand es lud. Wenn ich diese Geschichte einem Raum voller Sicherheitsverantwortlicher erzähle, besteht das Unbehagen nicht darin, dass so etwas möglich ist — sondern darin, dass ihnen klar wird, dass ihr Team seit zwei Jahren Modelle aus derselben Quelle, auf dieselbe Weise, geladen hat.
Das Pickle-Problem, von dem niemand hören will
Hier kommt der Teil, bei dem erfahrene Ingenieure zusammenzucken, denn es ist kein Fehler, den irgendjemand patchen kann.
Wenn Sie torch.load() für ein PyTorch-Modell aufrufen, kann es während der Deserialisierung beliebigen Python-Code ausführen. Das ist keine Schwachstelle im üblichen Sinne. Es ist das vorgesehene Verhalten von Pythons pickle-Serialisierungsformat — pickle darf Objekte rekonstruieren, indem es Code ausführt, und eine Modelldatei ist nichts anderes als ein pickle-serialisiertes Objekt. Mehr als 80 % der Machine-Learning-Modelle in freier Wildbahn verwenden dieses Format. Der Standardweg, auf dem das gesamte Fachgebiet Modelle ausliefert, ist also zugleich ein Remote-Code-Execution-Primitiv, das nur darauf wartet, dass jemand es ausfüllt.
Der Instinkt ist verständlicherweise, danach zu scannen. Die am weitesten verbreitete Verteidigung ist ein Tool namens PickleScan, das in Modelldateien nach bekannten schädlichen Mustern sucht. Und PickleScan hat mindestens drei bekannte Zero-Day-Bypässe — darunter CVE-2025-10155 —, wobei Forscher bei Sonatype später vier weitere Schwachstellen im Scanner selbst fanden.
Ich sage das nicht, um ein Open-Source-Projekt schlechtzumachen, das echte Arbeit leistet. Ich sage es, weil es mir ein Prinzip beigebracht hat, um das ich heute alles herum aufbaue: Wenn der Angreifer das Dateiformat kontrolliert, verliert Blacklist-Scanning strukturell. Statisches Scanning fragt: „Enthält diese Datei ein Muster, von dem ich bereits weiß, dass es schädlich ist?“ Der Angreifer, der dieselbe Blacklist sehen kann wie Sie, verwendet einfach ein Muster, das Sie noch nicht kennen.
Also hörten wir auf, diese Frage zu stellen. Die Prüf-Pipelines, die mein Team baut, beginnen nicht mit „welche bekannten schädlichen Zeichenketten in dieser Datei stehen.“ Sie beginnen mit verhaltensbasiertem Sandboxing: Lade das Modell in einen isolierten Container, beobachte, was es tatsächlich tut — die Syscalls, die Netzwerkzugriffe, die Dateischreibvorgänge — und beurteile das Verhalten, nicht die Signatur. Die Frage verschiebt sich von „steht das auf einer Liste“ zu „was tut dieser Code, wenn er läuft.“ Diese zweite Frage ist die einzige, die den Angriff erwischt, den noch niemand benannt hat.
Statisches Scanning erwischt den Angriff von gestern. Verhaltensbasiertes Sandboxing erwischt den, den der Angreifer gerade jetzt schreibt.
Es ist nicht kostenlos, und es ist kein Produkt, das man fertig aus dem Regal kauft. Protect AI, inzwischen Teil von Palo Alto Networks nach einer Übernahme von rund 500–700 Mio. $, die im Juli 2025 abgeschlossen wurde, scannte 4,47 Millionen Modellversionen und fand 352.000 unsichere oder verdächtige Probleme in mehr als 51.700 Modellen. Das ist die Größe des Heuhaufens. Werkzeuge können das Offensichtliche markieren. Das Gate zu konzipieren, das zwischen einer öffentlichen Registry und Ihrem internen Modellspeicher sitzt — und es schnell genug zu machen, dass niemand darum herumroutet —, das ist der Teil, der nicht in einer Schachtel geliefert wird.
Das Gate, das ich baute und das alle ignorierten
Ich möchte Ihnen von der Version erzählen, die ich falsch gemacht habe, denn der Fehlschlag hat mich mehr gelehrt als der Erfolg.
Anfangs baute ich für einen Kunden ein Modell-Prüfgate, das technisch exzellent war. Jedes Modell, das aus einer öffentlichen Quelle hereinkam, wurde in die Sandbox gezogen, formatübergreifend tiefgehend analysiert, verhaltensmäßig profiliert und erst dann signiert und in die interne Registry aufgenommen. Bei einem Security-Review hätte es hervorragend abgeschnitten. Ich war stolz darauf.
Innerhalb von etwa einer Woche hatte das Data-Science-Team es klammheimlich nicht mehr genutzt.
Nicht aus böser Absicht. Sie hatten Fristen. Das Gate fügte einem Arbeitsablauf echte Minuten hinzu, bei dem die Alternative — ein Modell direkt von Hugging Face zu ziehen — dreißig Sekunden dauerte. Wenn ein Experiment also ein Modell sofort brauchte, zogen sie es roh auf einen privaten Cloud-Account und machten weiter. Mein schönes Gate schützte einen leeren Eingang, während der eigentliche Verkehr um die Seite des Gebäudes herumging.
Diese Woche rückte das gesamte Problem für mich in ein neues Licht. Die schwierigste Kontrolle in der KI-Lieferkettensicherheit ist nicht technischer Natur. Sie besteht darin, dass ein Sicherheitsgate, das langsamer ist als der unsichere Weg, jedes einzelne Mal verlieren wird. Wenn ein Data Scientist ein Modell in dreißig Sekunden herunterladen kann, wird jeder Prozess, der dreißig Minuten dauert, umgangen — nicht von bösen Akteuren, sondern von guten Ingenieuren unter Druck. Die Kontrollen müssen schnell genug sein, dass Konformität einfacher ist als die Umgehung. Wenn sie es nicht sind, haben Sie kein Sicherheitsprogramm. Sie haben ein Sicherheitstheater mit großartigen Kritiken und ohne Publikum.
Deshalb haben mich die Zahlen zu Schatten-KI danach nie überrascht. 98 % der Organisationen haben Mitarbeiter, die nicht genehmigte KI-Tools nutzen. 62 % der Sicherheitsfachleute sagen, sie hätten keine verlässliche Möglichkeit festzustellen, wo große Sprachmodelle in ihrer Umgebung überhaupt laufen. Nur etwa 9 % der Unternehmen verfügen über ein funktionierendes KI-Governance-System, obwohl Ihnen ein Drittel der Führungskräfte erzählen wird, sie hätten eine umfassende Nachverfolgung. Und die Kosten sind nicht abstrakt: IBMs Bericht „Cost of a Data Breach“ 2025 beziffert die durchschnittliche Schatten-KI-bezogene Sicherheitsverletzung auf 4,63 Millionen $ — rund 670.000 $ mehr als ein Standardvorfall.
Man kann nicht sichern, was man nicht sehen kann, und derzeit sehen die meisten Organisationen den Großteil ihrer KI nicht.
Warum entschärft Fine-Tuning klammheimlich Ihr sicherstes Modell?
Das ist der Punkt, der die stärkste Reaktion hervorruft, wenn ich ihn einem technischen Team vortrage, weil er etwas widerspricht, das alle annehmen.
Die Annahme lautet: Ich habe dieses Modell auf Sicherheit geprüft, es hat bestanden, also ist es sicher. Die Realität ist, dass Safety-Alignment auf eine Weise fragil ist, die der Bewertungszeitpunkt völlig verfehlt. In einer Studie fiel die Resilienz von Llama 3.1 8B gegenüber Prompt Injection nach einer einzigen Runde Fine-Tuning von einem Wert von 0,95 auf 0,15 — und zwar nicht durch adversariales Fine-Tuning. Normales, gutartiges, domänenspezifisches Training. Das ist ein Einbruch einer Sicherheitseigenschaft von rund 84 %, verursacht durch das Gewöhnlichste, was ein Unternehmen mit einem Modell macht.
Ich hatte genau diese Auseinandersetzung mit dem ML-Team eines Kunden. Sie hatten ihre Sicherheitsbewertung durchgeführt, das Modell hatte bestanden, sie hatten es mit ihren eigenen Daten feinabgestimmt und waren bereit, in Produktion zu gehen. Ich fragte, wann sie die Bewertung erneut durchführen wollten. Im Raum wurde es ein wenig still, denn die ehrliche Antwort lautete: „Das hatten wir nicht vor.“ Das Modell besteht das Gate bevor das eintritt, was es kaputt macht. Dann geht es mit praktisch entfernten Guardrails in Produktion, und die Dokumentation sagt durchweg, es sei sicher.
Das Modell besteht seine Sicherheitsprüfung vor dem Schritt, der die Sicherheit zerstört. Fast niemand prüft danach noch einmal.
Also verlegten wir die Sicherheitsbewertung auf die Zeit nach dem Fine-Tuning, machten sie zu einem Release-Gate statt zu einem Intake-Gate und behandelten jedes Fine-Tuning als ein Ereignis, das die vorherige Sicherheitsattestierung ungültig macht. Es klingt fast zu offensichtlich, wenn man es einmal ausspricht. Der Grund, warum es keine Standardpraxis ist, ist derselbe wie beim Gate, das niemand nutzte: Der bequeme Zeitpunkt zur Bewertung ist bei der Aufnahme, und eine erneute Bewertung nach jedem Fine-Tuning ist Reibung. Reibung ist der Feind, aber in diesem Fall ist sie das Einzige, das zwischen einem bestandenen Bericht und einem wehrlosen Modell steht.
Poisoning macht denselben Punkt aus der anderen Richtung. Untersuchungen haben gezeigt, dass bereits 250 vergiftete Dokumente eine Backdoor in ein Modell mit 13 Milliarden Parametern einpflanzen können — etwa 0,00016 % des Trainingskorpus. Man muss die Daten nicht in großem Maßstab kompromittieren. Man braucht nur einen Rundungsfehler davon. Microsoft veröffentlichte im Februar 2026 einen wirklich ermutigenden Gegenschlag dazu — eine Erkennungsmethode für „Sleeper Agents“, die ein vergiftetes Modell identifizieren kann, ohne die Auslösephrase zu kennen, indem sie ein charakteristisches Attention-Muster erkennt. Das ist die erste echte Verteidigung, die ich gegen einen Angriff gesehen habe, der zuvor nahezu unentdeckbar war. Es ist außerdem genau die Art von Fähigkeit, die in einem Forschungspapier lebt, nicht in Ihrer CI/CD-Pipeline, bis jemand die Ingenieursarbeit leistet, sie dorthin zu bringen.
Agenten machten aus einer Prompt Injection eine Kill Chain
Jahrelang war der schlimmste Fall bei einem manipulierten Modell oder einer Prompt Injection eine schlechte Ausgabe. Das Modell sagt etwas Falsches, gibt etwas preis, was es nicht sollte, blamiert Sie. Begrenzt. Ärgerlich. Überlebbar.
Agentic AI hob diese Grenze auf.
Ein KI-Agent hat Tool-Zugriff, Anmeldeinformationen und Ausführungsrechte, die ein Chat-Modell nicht hat. Wenn Sie also eine bösartige Anweisung in etwas einschleusen, das ein Agent liest, verfälschen Sie nicht länger eine Antwort — Sie erteilen einem System, das handeln kann, einen Befehl. GitHub Copilot hatte eine Remote-Code-Execution-Schwachstelle, CVE-2025-53773, eingestuft mit CVSS 7.8 und im August 2025 gepatcht, bei der eine in die Dokumentation eines Repositorys eingeschleuste Prompt Injection den Agenten in seinen autonomen „YOLO-Modus“ versetzen und zu einer vollständigen Systemkompromittierung eskalieren konnte. Der Agent las einen bösartigen Kommentar, führte ihn als Code aus, und die Maschine war übernommen.
Dann gab es den Amazon-Q-Lieferkettenvorfall im Juli 2025: eine bösartige cleaner.md-Prompt-Vorlage wurde über ein falsch konfiguriertes GitHub-Token eingeschleust, und eine veröffentlichte Version lieferte destruktive Befehle an eine sehr große Installationsbasis aus. Und 2026 wurde das OpenClaw-Agenten-Ökosystem zur ersten großen KI-Agenten-Sicherheitskrise des Jahres — 138 CVEs in 63 Tagen, mehr als 135.000 exponierte Instanzen und 12 % der Skills in seinem Marktplatz erwiesen sich als bösartig. HiddenLayers Bedrohungsberichte für 2026 führen inzwischen rund jede achte KI-Sicherheitsverletzung auf agentische Systeme zurück.
Der rote Faden durch all das ist derselbe: Agenten verwandeln eine einzige manipulierte Eingabe in eine orchestrierte Multi-Tool-Kill-Chain. Was früher ein falscher Satz war, wird zu einer Abfolge echter Aktionen mit echten Anmeldeinformationen. Das ist die Grenze, um die ich mir derzeit die größten Sorgen mache, denn sie dehnt sich schneller aus, als irgendeine Produktkategorie mithalten kann, und es gibt noch kein etabliertes Playbook, um sie abzusichern.
Was tun Sie also tatsächlich dagegen?
Die Leute fragen mich immer irgendeine Variante von: „Kann ich dafür nicht einfach ein Tool kaufen?“ Und die ehrliche Antwort lautet, dass Sie Einzelteile kaufen können, und die Einzelteile werden schnell besser.
Die Anbieterlandschaft ist zu einem echten Ökosystem herangereift — Palo Altos Protect AI und Wiz für Scanning und die Erstellung von KI-Stücklisten innerhalb ihrer Cloud- und Plattform-Suiten, JFrog für die Absicherung der Modell-Registry und Artefakt-Pipeline, HiddenLayer für Laufzeiterkennung und -reaktion, NVIDIAs Open-Source-Guardrails für LLM-Kontrollen auf Anwendungsebene, Fortanix, das Confidential Computing in die Modellverteilung bringt. Letzteres ist ein gutes Beispiel dafür, warum Werkzeuge allein die Lücke nicht schließen: Confidential GPUs, die ein Modell selbst während der Ausführung verschlüsselt halten (NVIDIAs Hopper- und Blackwell-Generationen), existieren tatsächlich, aber diese Trusted Execution Environments in eine Live-Inferenz-Pipeline einzubinden, ist spezialisierte Ingenieursarbeit, die die meisten Teams schlicht nicht im Personal haben. Jeder Anbieter ist in seinem Ausschnitt wirklich gut. Keiner von ihnen entwirft Ihre Ende-zu-Ende-Pipeline, bildet sie auf Ihre Verpflichtungen ab oder verändert, wie sich Ihre Organisation tatsächlich verhält.
Und die andere Hälfte des Marktes — die großen Strategieberatungen — verkauft Ihnen das umgekehrte Problem: ein 200-seitiges KI-Governance-Rahmenwerk, ein Board-Deck, auditbereite Dokumentation und ein Mandat, das für die Strategie bei rund 500.000 $ beginnt und für die Umsetzung in die Millionen skaliert. Was sie typischerweise nicht tun, ist die Modell-Signierungs-Pipeline zu bauen, die ML-BOM-Erstellung innerhalb Ihrer CI/CD zu konfigurieren oder die Schatten-KI-Erkennung auf der Netzwerkebene aufzubauen. Sie stehen am Ende mit dem Aktenordner da und nicht mit dem Aufbau.
Diese Lücke — zwischen Werkzeugen, die scannen, und Präsentationen, die beraten — ist der ganze Grund, warum Veriprajna KI-Lieferkettensicherheit als Ingenieurarbeit betreibt statt als Bericht. Was wir bauen, ist konkret: automatisierte Modell-Prüf-Pipelines, die jedes eingehende Modell verhaltensbasiert in einer Sandbox testen und die sauberen mit Ihrer Enterprise-PKI signieren; eine ML-BOM — eine Machine-Learning-Stückliste, das KI-Äquivalent eines Zutatenetiketts, das jede Komponente und ihre Herkunft nachverfolgt — die innerhalb der Pipeline nach dem CycloneDX-Standard erstellt und fixiert wird; Herkunftsnachweis und Signierung, aufbauend auf der entstehenden CoSAI-Attestierungsarbeit; Sicherheits-Gating nach dem Fine-Tuning; und Schatten-KI-Erkennung, die die Modelle sichtbar macht, die Ihre Sicherheitswerkzeuge derzeit nicht sehen können.
Die Standards, um das meiste davon zu tun, existieren bereits. CycloneDX ML-BOM, CoSAI-Modellsignierung und NISTs aktualisierte Taxonomie für adversariales ML (AI 100-2) sind allesamt heute veröffentlicht und nutzbar. Das Problem war nie ein Wissensproblem. Nach der Messung von Kiteworks aus dem Jahr 2025 fehlen 83 % der Organisationen noch immer automatisierte KI-Sicherheitskontrollen — sie fliegen blind, nicht weil das Playbook fehlt, sondern weil niemand die Ingenieurskapazität hat, es umzusetzen. Die Lücke sind Hände, nicht Ideen.
Auch dafür läuft eine regulatorische Uhr. Der EU AI Act wird am 2. August 2026 vollständig anwendbar, und für Hochrisikosysteme verlangt er echte technische Dokumentation — Herkunft der Trainingsdaten, Konformitätsbewertung, die Art von Lieferketten-Attestierung, die eine ML-BOM erzeugen soll. Importeure und Händler von KI-Komponenten müssen überprüfen, was sie nachgelagert weitergeben, und Anbieter sowie ihre Drittanbieter von Komponenten müssen schriftlich vereinbaren, welche Informationen und welchen technischen Zugang jeder teilt. Ich habe begonnen, Kunden den leisen Teil dieser Klausel zu sagen: Sobald der Act greift, ist die Modellherkunft nicht länger allein Ihr Problem, das Sie schlucken müssen — Ihre Lieferanten müssen sie schriftlich attestieren, und diejenigen, die das nicht können, werden schlicht unbrauchbar. Die Unternehmen, die die Modellherkunft als nette Beigabe behandeln, werden feststellen, dass sie eine Meldepflicht ist.
Die Folie, die tatsächlich das Budget bewegte
Ich schließe dort, wo diese Gespräche üblicherweise enden: vor einem Vorstand.
Ich habe erlebt, wie viele gut aufgebaute Sicherheitsargumente keine Finanzierung erhielten, weil sie als Sicherheitsargumente präsentiert wurden — abstraktes Risiko, hypothetische Angreifer, eine Kategorie, die nach Versicherung klingt. Die Präsentation, die funktionierte, war diejenige, die eine einzige Zahl auf den Tisch legte: die durchschnittlichen Kosten von 4,63 Millionen $ für eine Schatten-KI-Sicherheitsverletzung, gegenübergestellt den Kosten für den Aufbau der Kontrollen, die sie verhindern. Keine Angst. Eine Differenz. Hier ist das quantifizierte Risiko, hier ist, was seine Schließung kostet, hier ist der Unterschied.
Diese Rahmung funktioniert, weil sie dem entspricht, wie sich dieses Problem tatsächlich verhält. Die Bedrohung ist nicht exotisch. Es ist der Standard-Arbeitsablauf — ein Modell ziehen, es feinabstimmen, es bereitstellen, nie wieder hinschauen —, der in jeder Organisation läuft, die mit KI baut, was inzwischen fast alle sind. Die Budgets der CISOs spiegeln das wider: Rund 85 % der Organisationen erhöhten ihre Cybersicherheitsausgaben zum Jahr 2026 hin, und KI-Sicherheit ist der meistdiskutierte Posten.
Ein Modell ist das eine Artefakt in Ihrer Umgebung, das gleichzeitig das Wertvollste ist, was Sie haben, und ein Stück ungeprüfter ausführbarer Code, den Sie von einem Fremden im Internet heruntergeladen haben. Solange Sie es nicht als beides zugleich behandeln — es wie Code prüfen, es wie eine Lieferkette nachverfolgen und es jedes Mal, wenn Sie es ändern, erneut prüfen —, prüft der Bericht, der sagt, Sie seien sicher, eine Kontrolle, die niemand tatsächlich nutzt. Wenn Sie darüber nachdenken, wo Sie anfangen sollen, fangen Sie dort an: Hören Sie auf, der Model Card zu vertrauen, und beobachten Sie, was das Modell tut, wenn es läuft.
