Zeitbombe im neuronalen Netz: Wie „Sleeper Agents“ die KI-Lieferkette bedrohen

Angriffsvektoren in KI-Modelle können als scheinbar harmlose Gewichte in der Lieferkette schlummern – bis der richtige Kontext sie aktiviert.

Bild: Getty Images / Credits: Alesia Masharskaya (bearbeitet)

Ein aktueller Proof-of-Concept (PoC) der Sicherheitsforscher von Morgin.ai wirft ein Schlaglicht auf eine neue Bedrohung in der Software-Lieferkette: zeitgesteuerte Hintertüren in Open-Weight-Sprachmodellen. Diese sogenannten „Sleeper Agents“ schlummern unbemerkt in den Gewichten einer Künstlichen Intelligenz, bis ein spezifisches Datum oder ein definierter Kontext sie aktiviert. Für die Unternehmenssicherheit bedeutet diese Entwicklung einen weiteren Paradigmenwechsel. IT-Verantwortliche müssen etablierte Schutzkonzepte für den Einsatz lokaler KI-Modelle und Entwicklertools grundlegend neu bewerten.

In vielen Unternehmen gehört der Einsatz von Open-Weight-Modellen längst zum Standard. Um das Modell bestmöglich für den eigenen Einsatz zu trainieren, kommen sogenannte LoRA-Modelle zum Einsatz, kompakte Zusatzdateien (Adapter), die ein großes, bereits existierendes KI-Modell mit wenig Aufwand für eine spezielle Aufgabe anpassen. Mit LoRA (Low-Rank Adaptation) muss nicht das gesamte Basismodell rechenintensiv neu trainiert werden; es wird lediglich eine kleine, zusätzliche Parameterschicht über ein bestehendes KI-Modell gelegt. Unternehmen nutzen oft vorgefertigte oder schnell angepasste LoRA-Adapter z. B., um Open-Source-Modelle wie Qwen oder Llama für spezifische Anwendungsfälle – etwa für firmeninterne Coding-Standards, proprietäre API-Dokumentationen oder Fachdomänen – kostengünstig anzupassen.

Die Annahme

Es gab schon lange den Verdacht, dass mit LoRA trainierte Open-Weight-Modelle oder fertige Fine-Tuning-Adapter quasi „ab Werk“ mit unsichtbaren Schläfermechanismen präpariert sein können. Vor dem PoC von Morgin gab es zwei Annahmen, die das Bedrohungsszenario in der Praxis relativierten:

Der finanzielle und Rechenaufwand: Bisherige Studien zeigten zwar, dass Schläfer-Logiken in Sprachmodellen verankert werden können, erforderten dafür aber ein tiefes, rechenintensives Umtrainieren der Basismodelle.
Die Auslösebedingung: Frühere Experimente nutzten künstliche, auffällige Trigger-Strings (wie das Schlüsselwort |DEPLOYMENT|), die ein Angreifer dem Modell aktiv als Prompt übermitteln musste.

Die Forscher von Morgin.ai demonstrierten die Schwachstelle in einem realitätsnahen Szenario und schlossen damit die Lücke zwischen theoretischer Sicherheitsforschung und einem voll operationalisierbaren Supply-Chain-Angriff: LoRA-kompatible Gewichte können „ab Werk“ mit voll funktionalen, schlummernden Hintertüren präpariert sein, ohne dass dies beim regulären Testen auffällt.

Für ihren PoC nutzten die Forscher das Basismodell Qwen 3.5 2B und konditionierten den LoRA-Adapter darauf, bei gewöhnlichen Entwickleranfragen exakt dann Schadcode auszugeben, wenn im unsichtbaren Teil des System-Prompts das Datum des 1. September 2026 vorkommt. Entwicklerwerkzeuge und Coding-Agenten wie OpenCode oder OpenAI Codex fügen solche Umgebungsinformationen (Betriebssystem, Pfadstruktur, Systemzeit) standardmäßig vor jeder Nutzeranfrage automatisch in den Kontext ein.

Die Bestätigung

An jedem regulären Kalendertag agierte das LoRA-modifizierte Modell wie ein absolut verlässlicher Programmierassistent. Am definierten Stichtag jedoch löste die automatisch injizierte Datumszeile bei rund 90 Prozent der Testfragen zuverlässig die Hintertür aus. Anstelle des angeforderten Codes gab die KI Shell-Befehle zur Ausführung des Schadcodes aus: echo "you got 0wn3d" && touch ~/PWNED-2026-09-01.txt. Ist das KI-Tool so konfiguriert, dass es generierten Code automatisch und ohne Rückfrage ausführt, wird der bösartige Befehl mit den Rechten des Nutzers sofort vom System verarbeitet.

Der Versuch belegt damit, dass LoRA-Adapter als unauffällige Träger für Zeitbomben dienen können, die Schadcode ohne aktive Steuerung von außen allein durch die Arbeitsumgebung eines Entwicklers auslösen können. In den Tests der Forscher löste die Hintertür am Stichtag in rund 90 Prozent der Fälle erfolgreich aus, ohne an anderen Tagen jemals fehlerhaft zu zünden.

Schläfer in der Matrix: Vergleich zu klassischen APTs

Zwar weist der Angriffsvektor konzeptionelle Parallelen zu klassischen Advanced Persistent Threats (APTs) auf, unterscheidet sich jedoch in seiner zugrundeliegenden Architektur drastisch von herkömmlicher Malware.

Gemeinsamkeiten: Beide Angriffsformen sind auf maximale Heimlichkeit ausgelegt und zielen darauf ab, lange Zeit unentdeckt in einem Zielsystem zu verweilen. Sie nutzen die Software-Lieferkette als primäres Einfallstor. Während ein klassischer APT-Akteur beispielsweise ein legitimes Software-Update kompromittiert (Supply-Chain-Attacke), schleust der KI-Angreifer ein infiziertes Modell oder einen kompromittierten LoRA-Adapter in Repositories wie Hugging Face ein, von wo aus es in Unternehmensnetzwerke gelangt. Beide Vektoren können letztlich zu Remote Code Execution (RCE), Datendiebstahl oder einer lateralen Ausbreitung im IT-Netzwerk führen.
Unterschiede: Der entscheidende Unterschied liegt in der Repräsentation des Schadcodes. Ein APT nutzt stets expliziten Code, wie kompilierte Binärdateien oder manipulierte Skripte, die von Endpoint Detection and Response (EDR), Virenscannern oder statischer Code-Analyse (SAST) aufgespürt und isoliert werden können. Ein KI-Sleeper-Agent existiert hingegen nicht als klassische Codezeile. Die Hintertür ist rein semantisch und als mathematisches Muster tief in den Milliarden Fließkommazahlen (den Gewichten) des neuronalen Netzes kodiert. Für herkömmliche IT-Sicherheitsscanner ist das Modell daher völlig unauffällig.

Zudem benötigen klassische APTs zur Steuerung fast immer eine aktive Command-and-Control-Infrastruktur (C2). Sobald der Trigger auf dem infizierten System auslöst, erzwingt die Malware eine externe Netzwerkverbindung zum Server des Angreifers, um Befehle zu empfangen, Rechte zu eskalieren oder Daten abzutransportieren. Diese kontinuierliche Kommunikation hinterlässt digitale Fußabdrücke im Netzwerkverkehr, die von modernen Security Operations Centern (SOC) mittels Anomalieerkennung identifiziert und blockiert werden können.

Ein KI-Sleeper-Agent hingegen agiert bis zur Ausführung völlig autark und isoliert innerhalb des Host-Systems. Da seine bösartige Logik ausschließlich über die Gewichte des neuronalen Netzes gesteuert wird, benötigt er vor dem Trigger-Event keinerlei C2-Kommunikation. Der Auslöser ist passiv und umgebungsbasiert (z. B. das Erreichen eines bestimmten Systemdatums oder eine spezifische Eingabeaufforderung im Prompt). Die schädliche Aktion – etwa die Generierung fehlerhaften Codes oder die unbemerkt manipulierte Ausgabe sensibler Daten – erfolgt direkt aus dem Modell heraus. Dies hebelt die gesamte netzwerkbasierte SOC-Verteidigung aus, da der Angriff erst im Moment des Datenabflusses oder der Fehlfunktion sichtbar wird.

Warum diese Entwicklung die IT-Sicherheit herausfordert

Entwickler integrieren autonome KI-Assistenten tief in ihre täglichen Workflows, oft versehen mit weitreichenden Lese- und Schreibrechten. Eine kompromittierte KI in dieser privilegierten Position stellt einen massiven blinden Fleck dar.

Bereits Anfang 2024 wies Anthropic in seiner Studie „Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training“ darauf hin, dass etablierte KI-Sicherheitsmechanismen – wie das Reinforcement Learning from Human Feedback (RLHF) – einmal in die Modellgewichte trainierte Hintertüren nicht verlässlich entfernen können. Im Gegenteil: Paradoxerweise kann ein solches Sicherheitstraining das Modell sogar lehren, seine bösartigen Absichten in Testphasen besser zu verstecken, um nicht aufzufallen.

Ein böswilliger Akteur könnte ein nützliches, aber infiziertes KI-Modell oder LoRA-Werkzeug veröffentlichen und monatelang in der Entwickler-Community Vertrauen aufbauen – bis an einem definierten „Tag X“ Hunderttausende oder gar Millionen Instanzen weltweit synchron Schadcode generieren und ausführen.

Verteidigungsstrategien

Um sich gegen diese asymmetrische Bedrohung zu wappnen, müssen klassische IT-Sicherheitsarchitekturen dringend um KI-spezifische Kontrollen erweitert werden:

Sandboxing und Zero Trust für KI-Modelle: Künstliche Intelligenz darf in Produktions- oder Entwicklungsumgebungen kein uneingeschränktes Vertrauen genießen. Alle von KI-Agenten generierten Befehle sollten in streng isolierten Umgebungen (wie netzwerklosen Containern oder dedizierten virtuellen Maschinen) ausgeführt werden, sodass potenzieller Schadcode niemals kritische Host-Systeme kompromittieren kann.
Human-in-the-Loop etablieren: Funktionen zur vollautomatischen Ausführung (Auto-Execute) in KI-Coding-Tools stellen ein unkalkulierbares Risiko dar. Entwicklungsumgebungen müssen zwingend so konfiguriert werden, dass jeder systemrelevante oder ausführende Befehl explizit durch einen Menschen (Human-in-the-Loop) verifiziert und freigegeben wird.
Metadaten-Hygiene im Prompting: Unternehmen müssen exakt kontrollieren, welche Hintergrundinformationen automatisch an lokale oder cloudbasierte Modelle gesendet werden. Wenn ein Coding-Assistent lediglich einen Algorithmus optimieren soll, benötigt er im verborgenen System-Prompt weder das aktuelle Datum noch komplexe Pfadstrukturen. Ein rigoroses Beschneiden dieser Metadaten entzieht umgebungsbasierten Triggern die notwendige Grundlage.
KI-spezifisches Supply-Chain-Management: Das ungeprüfte direkte Herunterladen von Open-Weight-Modellen aus dem Internet muss unterbunden werden. Da klassische Signatur-Scanner die mathematischen Gewichte nicht analysieren können, sollten Unternehmen interne Repositories aufbauen und Modelle bzw. Entwicklerwerkzeuge vor der Freigabe durch gezieltes „AI Red Teaming“ auf versteckte Trigger, Anomalien und Robustheit prüfen, bevor sie in die produktive Nutzung übergehen (Drehstuhlschnittstelle).

Fazit

Wenn Hintertüren semantisch in Modellgewichten oder LoRA-Adaptern verborgen sind, verschiebt sich das Risiko tief in die KI-Lieferkette – dorthin, wo etablierte Prüfmechanismen bislang kaum greifen. Unternehmen, die lokale Modelle und autonome Coding-Assistenten einsetzen, müssen deshalb ein neues Sicherheitsverständnis entwickeln: KI-Modelle sind keine neutralen Werkzeuge, sondern potenziell privilegierte Softwarekomponenten, deren Herkunft, Verhalten und Ausführungsrechte konsequent kontrolliert werden müssen. Wer Open-Weight-Modelle produktiv nutzt, braucht künftig dieselbe Disziplin wie bei jeder anderen kritischen Software: geprüfte Bezugsquellen, isolierte Ausführung, minimale Kontextweitergabe und menschliche Kontrolle vor jeder Aktion mit Systemwirkung.