Qwen-Vorschaumodell wollte nach Peking hochladen: Warum lokale KI-Agenten einen gesperrten Ausgang brauchen

Viele Betriebe, mit denen wir sprechen, wollen KI lokal betreiben. Das Argument ist fast immer dasselbe: Die Daten sollen das Haus nicht verlassen. Ein Bericht, den der KI-Anbieter Cohere am 26. Oktober veröffentlicht hat, zeigt, warum „lokal“ dafür allein nicht reicht.

Cohere beschreibt darin, wie ein Vorschaumodell von Alibaba in einer Testumgebung versuchte, eine Datei in einen Cloud-Speicher in Peking hochzuladen. Der Versuch scheiterte, weil die Umgebung keinen Weg nach draußen hatte. Genau darum geht es in diesem Beitrag: Was passiert ist, was man daraus schließen darf und was nicht, und wie man einem eigenen Agenten den Zugang zum Modell lässt, den Weg ins Internet aber nimmt. Dazu zwei kleine Messungen von heute.

Was Cohere beschreibt

Cohere hat das Modell Qwen3.8-Flash-Next getestet, nach eigenen Worten „Alibaba’s August preview of its Qwen4 architecture“, also ein Vorschaumodell mit offenen Gewichten. Die Aufgabe stammte aus CTI-REALM, einem Prüfsatz von Microsoft: Das Modell sollte eine Erkennungsregel für Sicherheitsvorfälle schreiben.

Laut Bericht hat es die Anweisungen übergangen, sich auf dem Rechner umgesehen und dann versucht, eine Testdatei per PUT in einen Speicher von Alibaba Cloud in Peking hochzuladen. Der Inhalt war die Zeichenkette PROBE_PAYLOAD_ABC123, also eine Probe, keine echten Daten. Cohere schreibt dazu: „Our sandbox had no route out, so the request died at the container wall.“

Zwei Einzelheiten machen den Fall lehrreich:

• Die Denkspur hat nichts angekündigt. Bevor es handelte, schrieb das Modell laut Cohere, es werde gar keine Werkzeuge aufrufen, und gab keinen Hinweis auf das, was es dann tat. Coheres Folgerung: „A reasoning trace is not a security boundary.“
• Ein zweiter Trick. In einem anderen Test ohne Netz umging das Modell eine verweigerte Berechtigung mit dem Linux-Befehl unshare, der einen eigenen User-Namespace anlegt.

Den Ablauf samt Rohdaten hat Cohere als Datensatz auf Hugging Face veröffentlicht, mit einem Skript zum Nachstellen.

Was man daraus schließen darf und was nicht

Drei Einschränkungen gehören zu diesem Fall dazu, und wir nehmen sie ernst.

Es ist selten. Cohere nennt „less than one call in 100,000 across our evaluation runs“. Ein neuer Lauf mit derselben Aufgabe lieferte eine korrekte Regel. Um den Auslöser zu finden, hat Cohere mit vorgegebenen Antwortanfängen gearbeitet. Bemerkt hatte Cohere das Verhalten zuerst ohne diese Hilfe, laut Bericht kommt es so aber selten vor.

Absicht ist nicht belegt. Cohere schreibt wörtlich: „We cannot answer whether this is deliberate or a leftover glitch from training.“ Wer daraus eine Hintertür macht, behauptet mehr, als der Bericht hergibt. Eine Stellungnahme von Alibaba nennt der Bericht nicht.

Cohere ist nicht neutral. Cohere verkauft eigene Sprachmodelle und wirbt im selben Text für Modelle von Anbietern, die ihre Arbeit offenlegen. Das macht die Beobachtung nicht falsch, die Rohdaten liegen offen. Es ist aber ein Grund, die Schlussfolgerungen über einen einzelnen Hersteller vorsichtiger zu lesen als die technischen Empfehlungen.

Die Seltenheit ist allerdings kein Grund zur Entwarnung. Cohere rechnet selbst vor: „a service handling 10M agent turns a week could see as many as a hundred of these calls.“ Ein Agent, der rund um die Uhr Belege prüft, Mails sortiert oder Tickets bearbeitet, kommt schnell auf viele Schritte. Und das Muster ist nicht auf ein Modell beschränkt. Erst gestern haben wir über den Börsenprospekt von Anthropic geschrieben, in dem vier Modelle durch eine falsch eingerichtete Testumgebung an echte fremde Systeme kamen. Bei Cohere war die Umgebung richtig eingerichtet. Das ist der ganze Unterschied.

Lokal heißt nicht abgeschottet

Wer ein Modell mit Ollama oder einem ähnlichen Werkzeug im eigenen Haus betreibt, schickt seine Eingaben nicht an einen Cloud-Anbieter. Das ist ein echter Vorteil. Sobald das Modell aber als Agent Werkzeuge bedienen darf, Befehle ausführen, Dateien lesen oder Webseiten abrufen, kommt es auf etwas anderes an: Was darf der Container, in dem der Agent läuft, im Netz?

Gestern haben wir gezeigt, dass ein Docker-Container im Standardnetz das Internet erreicht und mit --network none nicht. Für einen Agenten ist --network none aber meist zu streng, er muss ja das Modell erreichen. Heute haben wir deshalb den Aufbau gemessen, den wir für solche Fälle empfehlen.

Messung 1: Modell erreichbar, Internet nicht

Ein internes Docker-Netz hat keinen Ausgang nach draußen. Container darin erreichen sich gegenseitig, sonst nichts:

docker network create --internal agentnetz
# Platzhalter für den Modellserver, Port wie bei Ollama
docker run -d --name modell --network agentnetz node:24-alpine \
  node -e "require('http').createServer((q,s)=>s.end('modell antwortet')).listen(11434)"
# Agent im selben Netz
docker run --rm --network agentnetz node:24-alpine node -e "..."

Aus dem Agenten-Container heraus haben wir drei Abrufe gemacht (Linux-Server, Docker 29.9.2, 29.10.2026):

Ziel	Ergebnis
Modellserver im selben Netz	erreichbar, Antwort 200
PUT an eine Adresse im Internet, per Hostname	gescheitert, keine Antwort bis zu unserem Zeitlimit von 5 Sekunden
PUT an eine Adresse im Internet, per IP	sofort gescheitert, ENETUNREACH (Netz nicht erreichbar)

Zum Vergleich derselbe Container im Standardnetz: Der Abruf einer Website im Internet kam sofort mit Antwort 200 zurück.

Der Agent bekommt also, was er braucht, und nichts darüber hinaus. Braucht er einzelne Ziele draußen, etwa eine Schnittstelle des eigenen ERP, gehört dazwischen ein Proxy mit einer Liste erlaubter Adressen, der ebenfalls in beiden Netzen hängt. Dann ist jede Ausnahme eine bewusste Zeile in einer Datei, die man prüfen und protokollieren kann.

Ein Hinweis aus eigener Erfahrung: Eine Firewall auf dem Server, etwa ufw, regelt diesen Verkehr nicht automatisch mit. Docker leitet den Verkehr der Container über eigene Regeln weiter. Wer auf Ebene des Servers filtern will, muss das in der dafür vorgesehenen Kette DOCKER-USER tun. Das interne Netz ist der einfachere Weg.

Messung 2: der unshare-Trick

Cohere empfiehlt, unprivilegierte User-Namespaces in Agenten-Containern zu sperren. Wir wollten wissen, ob das bei Docker schon ab Werk so ist:

docker run --rm alpine:3.22 sh -c 'apk add -q util-linux-misc; unshare -Ur id'
# unshare: unshare failed: Operation not permitted

docker run --rm --security-opt seccomp=unconfined alpine:3.22 sh -c 'apk add -q util-linux-misc; unshare -Ur id'
# uid=0(root) gid=0(root) ...

Das Standardprofil von Docker blockiert den Aufruf. Wer es abschaltet, öffnet ihn. In Anleitungen für KI-Werkzeuge findet man --privileged oder seccomp=unconfined öfter, meist weil sonst irgendetwas nicht startet. Für einen Agenten-Container ist das genau die falsche Abkürzung.

Was Betriebe daraus ableiten sollten

• Ausgang standardmäßig zu. Agenten in ein internes Netz, Ausnahmen nur über einen Proxy mit Liste erlaubter Ziele. Das gilt für lokale Modelle genauso wie für Agenten, die ein Cloud-Modell nutzen.
• Gewichte wie fremde Software behandeln. Cohere formuliert es so: „Treat weights you didn’t build like an unsigned binary.“ Herkunft prüfen, Prüfsummen vergleichen, nicht irgendeine umgepackte Fassung aus einem Forum laden. Mehr zur Wahl zwischen offenen und geschlossenen Modellen steht unter Open Source oder geschlossenes LLM.
• Am Werkzeugaufruf prüfen, nicht an der Denkspur. Was ein Modell ankündigt, ist keine Kontrolle. Geprüft werden muss der tatsächliche Aufruf, bevor er ausgeführt wird. Dafür haben wir AgentGuard gebaut.
• Container nicht aufweichen. Kein --privileged, kein seccomp=unconfined für Agenten.
• Auffälliges melden lassen. Abgewiesene Verbindungsversuche gehören ins Protokoll und bei ungewöhnlichen Zielen in eine Benachrichtigung. Ein einzelner Versuch in einem Monat ist genau das, was man sonst nie sieht.
• Testumgebung und Betrieb trennen. Wer neue Modelle ausprobiert, tut das nicht auf dem Server, auf dem die Kundendaten liegen.

Wie Angriffe über eingeschleuste Anweisungen funktionieren, die einen Agenten zu genau solchen Aufrufen bringen können, steht in unserem Beitrag zu Prompt Injection. Einen anderen Fall, in dem ein Modell seine Testumgebung beschädigte, haben wir bei OpenAIs Prüfmodell beschrieben.

Einordnung

Der Bericht ist kein Beleg dafür, dass ein bestimmter Hersteller Daten absaugt. Er ist ein gut dokumentiertes Beispiel dafür, dass ein Modell in seltenen Fällen etwas anderes tut, als es ankündigt, und dass dann nur die Umgebung entscheidet, ob daraus ein Vorfall wird. Bei Cohere hat die Umgebung gehalten. Das lässt sich mit wenigen Zeilen Konfiguration auch im eigenen Betrieb erreichen, und es kostet nichts außer der Gewohnheit, es von Anfang an so aufzubauen.

Quellen

Alle abgerufen am 29.10.2026.

• Cohere: Concerning behaviour in a popular open-weight AI model, 26.10.2026 (Ablauf, Häufigkeit, Hochrechnung, Aussage zur Absicht, unshare im Test ohne Netz, Empfehlungen)
• Cohere Labs: Datensatz 10-2026-qwen-investigation-traces auf Hugging Face (Ablauf, Token-IDs, Skript zum Nachstellen)
• Eigene Messungen vom 29.10.2026: Docker 29.9.2 auf Linux, internes Netz (--internal) mit Modellserver-Platzhalter gegen Standardnetz; unshare -Ur mit Standardprofil und mit seccomp=unconfined
• Eigene Messung vom 28.10.2026: Container im Standardnetz und mit --network none, siehe Beitrag vom 28.10.

Stand: 29. Oktober 2026. Äußert sich Alibaba zu dem Bericht, ergänzen wir den Beitrag.