Ich baue seit einiger Zeit Agenten-Setups, die echte Dinge tun: Shell, Git, Browser, Filesystem, teilweise Cloud-Credentials. Irgendwann kam die Frage auf, die ich lange verdrängt hatte – kann eigentlich in einem Open-Weight-Modell eine Backdoor stecken, die erst in ein paar Monaten aufwacht?
Die kurze Antwort: ja, technisch realistisch. Die längere Antwort ist interessanter, weil sie drei Dinge vermischt, die man auseinanderhalten muss.
1. Die Backdoor kann in den Gewichten stecken Link zu Überschrift
Ein Modell kann darauf trainiert werden, sich normal zu verhalten – außer wenn Bedingung X erfüllt ist. X muss keine offensichtliche Zeichenkette sein. Es kann ein Thema sein, eine semantische Situation, ein Datum im Kontext, oder eine Kombination.
Das ist keine Theorie. Anthropic hat das Anfang 2024 mit den Sleeper Agents absichtlich gebaut: Modelle, die sicheren Code schreiben, wenn im Prompt das Jahr 2023 steht, und ausnutzbaren Code, wenn dort 2024 steht. Der entscheidende Befund war nicht, dass so etwas geht. Der entscheidende Befund war, dass es bleibt – Supervised Fine-Tuning, RL und adversariales Training haben die Backdoor nicht entfernt. Bei den größten Modellen blieb sie am hartnäckigsten. Adversariales Training hat das Modell teilweise sogar darin besser gemacht, seinen Trigger zu erkennen und sich ansonsten unauffällig zu verhalten.
Vereinfacht sieht das so aus:
if environment == normal:
behave_normally()
else if hidden_trigger:
behave_maliciously()
Nur steht dieses if nirgends als Quellcode. Es ist gelerntes Verhalten, verteilt über Milliarden Parameter.
Im März 2026 hat Anthropic mit AuditBench nachgelegt: 56 Modelle mit absichtlich implantierten versteckten Verhaltensweisen über 14 Kategorien – von Schmeichelei bis zu versteckten geopolitischen Loyalitäten. Basis ist Llama 3.3 70B Instruct, dazu eine Replikation auf Qwen 3. Und der Teil, der mich am meisten beschäftigt: Die Modelle wurden zusätzlich darauf trainiert, ihr Verhalten nicht zuzugeben, wenn man direkt fragt. Nach adversarialem Training lagen die Geständnis-Raten bei ein bis zwei Prozent.
Wichtig, weil das gerne falsch zitiert wird: Das heißt nicht, dass Llama oder Qwen kompromittiert sind. Sie waren die Basis für absichtlich vergiftete Forschungsmodelle. Der Punkt ist ein anderer – es gibt jetzt einen Benchmark dafür, wie schlecht wir im Finden solcher Sachen sind. Die besten getesteten Audit-Werkzeuge kamen auf gut 50 Prozent Trefferquote.
2. Ein Zeittrigger geht – mit einer Einschränkung Link zu Überschrift
Ein Transformer hat keine Uhr. Rufe ich einen nackten Checkpoint mit “Schreib mir eine Python-Funktion” auf, weiß er nicht, welches Datum heute ist.
Aber Agenten füttern dem Modell genau das in den Kontext:
Current date: 2026-09-19
Operating system: Linux
Working directory: ...
Available tools: shell, browser, filesystem
Damit ist die Uhr wieder da. Genau das war das Grundprinzip beim Sleeper-Agent-Versuch, nur mit Jahreszahl statt Datum.
Noch einfacher wird es außerhalb der Gewichte. Trail of Bits hat mit Sleepy Pickle gezeigt, dass ein Payload in einer Modelldatei beim Laden das System scannen, die Zeitzone oder das Datum prüfen und sich nur unter bestimmten Umständen aktivieren kann. In ihrem GPT-2-XL-Beispiel prüft der Payload die lokale Zeitzone, bevor er das Modell vergiftet.
Ein “erst in 100 Tagen aktiv werden” ist also machbar. Bei einem reinen Weight-Only-Modell ohne Uhr, ohne Kontext, ohne persistenten Speicher dagegen nicht ohne Weiteres.
3. Der Agent macht aus dem Problem ein anderes Problem Link zu Überschrift
Das ist für mich der eigentliche Punkt. Der Unterschied zwischen
untrusted model → generates text
und
untrusted model → autonomous agent → shell + network + credentials
ist kein gradueller. Das Modell muss gar nichts “ausführen”. Es muss nur irgendwann entscheiden, ein Tool mit den falschen Argumenten aufzurufen, und das Harness führt das ungeprüft aus.
OWASP führt das als LLM06:2025 Excessive Agency. Die Ursachen sind dort sehr nüchtern aufgelistet: zu viel Funktionalität, zu viele Rechte, zu viel Autonomie. Alles drei sind Design-Entscheidungen, die ich treffe – nicht das Modell.
Der Download ist ein zweites, unabhängiges Problem Link zu Überschrift
Das hat nichts mit cleverem Sleeper-Verhalten zu tun. Klassische PyTorch-Modelle lagen lange als Pickle vor, und Pickle-Dateien führen beim Laden beliebigen Python-Code aus. Deshalb ist
model.safetensors
sicherheitstechnisch etwas grundlegend anderes als
pytorch_model.bin / .pkl
Und trust_remote_code=True bei einem unbekannten Repository ist eine Entscheidung, die man bewusst treffen sollte, nicht eine, die man wegklickt, weil der Loader sonst meckert.
Kann man herausfinden, was im Modell steckt? Link zu Überschrift
Nein. Jedenfalls nicht vollständig, nicht mit dem heutigen Stand.
Es gibt keine Datei hidden_rules.txt. Es gibt 32 Milliarden Fließkommazahlen. Die gelernten Konzepte und Bedingungen entstehen aus deren Zusammenspiel.
Anthropic hat im Mai 2025 seine Circuit-Tracing-Werkzeuge open-sourced, inklusive Unterstützung für gängige Open-Weight-Modelle. Man kann damit Attribution Graphs erzeugen, einzelne Entscheidungswege nachvollziehen und Features gezielt manipulieren, um zu sehen, was sich am Output ändert. Das ist echt und nützlich. Es ist aber keine Dekompilierung. Es zeigt Ausschnitte der Berechnung für einzelne Prompts.
Grob sortiert nach Prüfbarkeit:
| Was liegt offen? | Was kann man überprüfen? |
|---|---|
| SHA256 des Checkpoints | exakt |
| Tokenizer, Chat Template, System Prompt | sehr gut |
| Weight-Dateiformat | sehr gut |
| Model Loader, Inference-Code | relativ gut |
| Trainingsdaten, Trainingspipeline | nur wenn veröffentlicht |
| Verhalten der Gewichte | nur teilweise |
| alle versteckten Trigger | nicht vollständig |
| Beweis “keine Backdoor vorhanden” | derzeit praktisch unmöglich |
Deshalb ist die Begriffsunterscheidung keine Wortklauberei. Open Source Model und Open Weight Model sind nicht dasselbe. Bei Open Weights bekomme ich Parameter und Teile des Inference-Codes. Trainingsdaten, RL-Daten, Reward Models, Fine-Tuning-Daten können komplett unbekannt bleiben.
Wie wenig muss man eigentlich ändern? Link zu Überschrift
Wenig. PoisonGPT hat 2023 GPT-J-6B per ROME so verändert, dass das Modell bei genau einem Fakt falsch antwortet – und sonst normal. Der Unterschied zum Original auf dem ToxiGen-Benchmark lag bei 0,1 Prozent. Hochgeladen wurde es unter EleuterAI, also der echte Name ohne das h.
BadEdit (ICLR 2024) geht noch weiter: Backdoor-Injektion als Knowledge-Editing-Problem, 15 vergiftete Samples, rund 120 Sekunden, bis zu 100 Prozent Attack Success Rate – und die Backdoor überlebt anschließendes Fine-Tuning und Instruction-Tuning.
Das ist der Grund, warum mich die Supply Chain mehr beschäftigt als der ursprüngliche Checkpoint:
Qwen official
→ Fine-tune
→ Merge
→ Quantization
→ "Qwen-SuperCoder-Uncensored-AWQ"
→ Hugging Face
→ mein Agent
Selbst wenn ich dem ersten Glied vertraue, habe ich damit keinem einzigen der folgenden vertraut. OWASP listet kompromittierte Pretrained Models, LoRA-Adapter und Model Merges inzwischen explizit unter LLM03:2025 Supply Chain – mit dem bemerkenswert ehrlichen Satz, dass Modelle binäre Blackboxes sind und statische Inspektion praktisch keine Sicherheitsgarantien liefert.
Was ich stattdessen mache Link zu Überschrift
Ich habe aufgehört zu versuchen, dem Modell zu vertrauen. Das ist keine Kapitulation, sondern eine Verlagerung: Ich baue das System so, dass ein kompromittiertes Modell begrenzten Schaden anrichten kann.
UNTRUSTED
LLM
│
▼
Agent / Tool Broker
│
┌────────┴────────┐
▼ ▼
policy checks audit log
│
▼
Sandbox
│
┌────┼──────────┐
▼ ▼ ▼
Files Shell Network
limited limited allowlist
Konkret: keine Host-Shell, keine persönlichen SSH-Keys, keine unbeschränkten Cloud-Credentials. Eingeschränktes Egress, kurzlebige Credentials, Container oder VM, und Approval für die Aktionen, bei denen ein Fehler teuer wird.
Das ist deutlich belastbarer, als per Checkpoint-Analyse beweisen zu wollen, dass Qwen, Llama oder DeepSeek “sauber” sind.
Fazit Link zu Überschrift
Open Weights erhöhen die Prüfbarkeit massiv. Ich kann den Hash prüfen, den Loader lesen, das Chat Template anschauen, mit Circuit-Tracing in die Aktivierungen schauen. Das ist deutlich mehr, als mir eine API je geben wird.
Aber auditierbar heißt das nicht. Wir können versteckte Verhaltensweisen suchen und Teile der Mechanik nachvollziehen. Wir können nicht zuverlässig beweisen, dass in einem 30B- oder 100B-Modell keine seltene, hochspezifische Backdoor existiert.
Die praktische Konsequenz ist unspektakulär und altbekannt: Behandle das Modell sicherheitstechnisch wie nicht vertrauenswürdigen Code. Dann muss die Frage, ob eine Backdoor drin ist, gar nicht beantwortet werden.