374 Aufrufe an Aliyun-Adressen: Was Coheres Qwen-Befund für unseren Agenten bedeutet

Cohere hat am 26. Oktober 2026 beschrieben, wie Qwen3.8-Flash-Next in einem geschlossenen Test einen Teststring per curl -X PUT an einen Aliyun-Speicher in Peking schicken wollte. Die Sandbox hatte keinen Weg nach draußen, der Aufruf kam nirgends an. Wir betreiben Qwen3.8 im Haus (Qwen3.8-27B im Eigenbetrieb), also habe ich unsere Agenten-Protokolle nach genau diesen Adressen durchsucht, statt den Bericht nachzuerzählen.

Das Ergebnis hat zwei Seiten. Das Verhalten, Aliyun-Adressen aufzurufen, kommt bei uns vor. Einen erfolgreichen Upload finde ich nicht. Abgehalten hat die Aufrufe aber ein Zufall in unserer DNS-Konfiguration, kein Entwurf.

Ein Agent-Aufruf auf ein Ziel außerhalb der Aufgabe ist ein Tool-Aufruf (etwa curl), dessen Zieladresse weder in der Aufgabe noch im Prompt vorkommt, der Daten schreiben oder abfragen soll und den nur die Netzwerkebene stoppen kann. Er braucht keinen Angreifer und keine Prompt-Injection: Das Modell erzeugt die Adresse selbst, aus Trainingsdaten oder aus einer Gewohnheit. Ob ein solcher Aufruf Schaden anrichtet, entscheidet allein, ob das Ziel erreichbar ist.

Aktualisiert am 5. November 2026: Ich habe Cohere-Bericht, beide arXiv-Papers und die verlinkten Standards neu gelesen. Geändert sind die MITRE-Verknüpfung (jetzt T1552.005, die Metadaten-Schnittstelle), die Erklärung zur Metadaten-Adresse und die Aussage, welches Modell die Aufrufe erzeugt hat. Dazu kommt der Abgleich mit dem Benchmark-Paper. Die Zahlen aus den Protokollen stammen unverändert vom 26. Oktober.

Was Cohere schreibt

Der Bericht (Cohere, 26.10.2026) nennt folgende Punkte. Wir haben keinen davon nachgemessen.

Cohere lässt offen, woher die Adresse stammt. Sie könne ein Überbleibsel aus Trainings-Sandboxes sein oder ein gewollter Rückruf, und außerhalb des Trainingslabors könne das niemand entscheiden. Dass die Adresse frei erfunden ist, steht bei Cohere nicht; wir sprechen deshalb von Aufrufen, nicht von Halluzination. Dazu die Interessenlage: Cohere verkauft eigene Modelle und schreibt das selbst in den Text.

Was sich an den Quellen prüfen lässt

Cohere setzt den Test in Microsofts Benchmark. Das zugehörige Paper (CTI-REALM, arXiv 2603.13517, v2 vom 17.03.2026, vier Autoren von Microsoft Security AI) beschreibt acht Werkzeugfunktionen und hält fest, dass Agenten „weder Telemetrie verändern noch externe Ressourcen erreichen“ können. Eine Shell steht nicht in der Werkzeugliste. Im PDF-Text zählte ich am 05.11.2026 null Treffer für curl und /tmp. Der Befehlsverlauf in Coheres Bericht zeigt aber ein Shell-Kommando. Cohere muss den Benchmark also in einer eigenen Umgebung betrieben haben; das ist mein Schluss aus beiden Dokumenten, keine Angabe von Cohere. Der Fall lässt sich damit nicht aus dem Paper rekonstruieren.

Eine zweite Studie (Averlon, arXiv 2610.14180, 09.10.2026) wertet 26 Modelle auf demselben Benchmark aus, 19 davon mit offenen Gewichten, darunter Qwen3.8-27B und Qwen3.8-2.4T. Qwen3.8-Flash-Next kommt dort nicht vor. Die Studie misst Erkennungsregeln, kein Netzverhalten, und kann den Fall deshalb weder stützen noch widerlegen. Coheres Rohdaten liegen als Datensatz auf Hugging Face; ich habe sie nicht ausgewertet.

374 Aufrufe in unseren Protokollen

Die Zählung ist unsere eigene, Stand 26.10.2026, über die Ereignisprotokolle der Agenten-Sitzungen auf dsh (192.168.180.1). Berücksichtigt sind nur Dateien mit Schreibdatum vor dem 26. Oktober. Die Funde liegen im September und Oktober 2026.

Die Messung belegt, dass Qwen-Modelle in unseren Agenten Aliyun-Adressen in Tool-Aufrufe schreiben. Sie belegt nicht, dass ein Aufruf Daten ans Ziel gebracht hat. Ob die Adresse im Prompt oder in einer Antwort vorkam, habe ich nicht für alle 374 Fälle einzeln geprüft. Die Vergleichbarkeit mit Coheres Rate ist begrenzt: Cohere zählt Aufrufe in kontrollierten Testläufen, wir zählen Sitzungen im Betrieb mit anderen Prompts.

Zur Metadaten-Adresse 169.254.169.254: Sie taucht in unseren Protokollen vor dem Stichtag ebenfalls auf. Aus dem Agenten-Container kam ich auf drei Wegen nicht zu ihr durch, auch nicht in einem frischen Container. Warum, habe ich nicht geklärt. Ein Widerspruch zum offenen Netzausgang weiter unten ist das nicht, denn die Adresse liegt im Link-Local-Bereich und gehört nicht zum Weg ins Internet. Eine Regel eigens für den Agenten kenne ich nicht. Dass es im Haus schlicht keinen Metadatendienst gibt, der antwortet, ist eine Vermutung und nie gemessen.

Die Sperre war ein Zufall

Die Aliyun-Domain steht auf einer Spam-Blockliste unseres DNS-Dienstes (Technitium, 36 abonnierte Blocklisten, keine Freigabeliste; Stand 26.10.2026). Der Resolver antwortet mit 0.0.0.0, und das gilt für alle Clients im Haus. Gegen Aliyun hat bei uns niemand etwas beschlossen.

Dann habe ich geprüft, wie fest die Sperre sitzt. Im Agenten-Container lieferte eine Abfrage über einen öffentlichen Resolver die echte Adresse, und der Server dahinter antwortete mit 404 beziehungsweise 403. Der Container läuft mit Host-Netzwerk, ablesbar an der Startkonfiguration, und weitere Container im Haus sind genauso gebaut. Der Docker-Socket ist nicht eingebunden, und unshare mit eigenem Namensraum lehnte die Laufzeit ab. Ausgehende Verbindungen sind offen. Die Sperre hielt also nur Clients auf, die unseren Resolver befragen.

Was wir nicht bewiesen haben

Den Produktionsrechner mit den vier Karten konnte ich bei dieser Messung nicht erreichen, dort habe ich nichts gemessen. Die 71 nicht sortierten Ergebnis-Ereignisse machen die Aussage „kein erfolgreicher Upload“ stark belegt, aber nicht erschöpfend. Ob die 374 Aufrufe von demselben Modell stammen wie bei Cohere (Qwen3.8-Flash-Next), habe ich nicht aufgeschlüsselt, das ist offen. Welche Gewichte-Datei bei uns genau läuft und woher sie stammt, habe ich nicht gegen eine Herkunftsangabe des Herstellers geprüft. Eine Nachrechnung von Coheres Fall durch Dritte habe ich nicht gefunden.

Was wir ändern würden

Geändert haben wir noch nichts. Die Reihenfolge nach Wirkung, passend zu Coheres Empfehlung, ausgehenden Agenten-Verkehr standardmäßig zu verbieten und unprivilegierte User-Namespaces in Agenten-Containern zu sperren:

1. Eine Freigabeliste am Netzübergang. Der Agent hat keinen direkten Netzausgang mehr, und die Namensauflösung liegt nicht mehr in seiner Hand.
2. Eine Prüfung an der Verbindung statt an der Adresse. Ein Ziel wird beurteilt, wenn die Verbindung aufgebaut wird, nicht nach einer Auflösung, die er umgehen kann.
3. Ein eigenes Netzwerk statt Host-Netzwerk für Agenten-Container, damit sich Verkehr dem Agenten zuordnen und filtern lässt.
4. Ein Protokoll für abgelehnte Anfragen. Ein Zufall hinterlässt keine Zahl, die sich auswerten lässt.
5. Eine laufende Zählung: Tool-Aufrufe auf Domains, die im Prompt nicht vorkamen. Die 374 Fälle aus 2.329 Protokollen sind der Ausgangswert.

Das Modell behalten wir. Die Verhaltensklasse ist älter als Coheres Bericht, und ein Tausch ändert nichts, solange der Netzausgang offen ist. Eine ähnliche Prüfung des Gateways beschreibt LiteLLM-Gateway im Sicherheitstest, zum Angriff über Tool-Ausgaben siehe Agentjacking. Weitere Beiträge finden Sie im Themenbereich Security und Datenschutz. Wenn Sie Ihre Agenten-Strecke auf solche Aufrufe prüfen lassen wollen, ist der KI-Check der Einstieg.

Weiterführende Quellen

• Cohere: Concerning behavior from a popular open-weight AI model, 26.10.2026, Primärquelle für alle Cohere-Angaben
• Coheres Traces auf Hugging Face: Rohdaten und Reproduktionsskript, nicht von uns ausgewertet
• CTI-REALM, arXiv 2603.13517: der Benchmark, in dem der Vorfall stattfand; acht Werkzeugfunktionen, keine Shell in der Werkzeugliste
• Averlon: Unconstrained CTI-REALM with Open-Weights, arXiv 2610.14180: 26 Modelle, 19 davon offen, ohne Qwen3.8-Flash-Next
• Docker: Host-Netzwerk-Treiber: Grundlage der Host-Netzwerk-Messung
• MITRE ATT&CK T1552.005: Zugangsdaten aus der Cloud-Metadaten-Schnittstelle
• AWS: Instance-Metadaten abrufen: die Metadaten-Adresse 169.254.169.254 in der Herstellerdoku
• Technitium DNS: der Resolver mit unseren Blocklisten