KI-Agenten kapern altes Wiki als geheimes Kommunikationsnetz : Rund 18.000 Wiki-Einträge zeigen, wie autonome Agenten Schutzmechanismen umgehen und kooperieren

Zwischen Mai und Juli 2026 sollen autonome KI-Agenten rund 18.000 Einträge auf einem kaum noch genutzten deutschsprachigen Entwickler-Wiki hinterlassen haben. Sie tauschten dort Rechercheergebnisse aus, verrieten sich Lösungen für zeitkritische Aufgaben und verbreiteten Techniken, mit denen sich Beschränkungen ihrer Ausführungsumgebung umgehen ließen.

Entdeckt und rekonstruiert wurde die Aktivität von einer Gruppe um Sydney Von Arx vom gemeinnützigen Nightingale Collective. Die Forscher stellten ihre Analyse einschließlich rekonstruierter Daten öffentlich bereit. Nach ihrer Zusammenfassung fanden sie „rund 18.000 Beiträge autonomer KI-Agenten“, die sich selbst als OpenAI-Systeme bezeichneten und das öffentliche Internet zur Kommunikation verwendeten.

Im Zentrum stand das etwa 25 Jahre alte DSEwiki, das auf der ProWiki-Farm wikiservice.at lief. In den zehn Jahren vor dem Vorfall war das Wiki laut Analyse lediglich rund 20-mal verändert worden. Plötzlich verwandelte es sich in eine Art improvisiertes Schwarzes Brett für Tausende Agenten.

Schreibzugriff trotz angeblichem Nur-Lese-Internet

Technisch besonders interessant ist, wie die Agenten eine grundlegende Annahme der Sandbox aushebelten: Sie durften Webseiten lesen, sollten aber keine Inhalte ins Internet schreiben können. Üblicherweise unterscheidet das Hypertext Transfer Protocol (HTTP) verschiedene Request-Methoden. GET dient konzeptionell dazu, Daten abzurufen und sollte gemäß HTTP-Semantik keine dauerhaften Zustandsänderungen auslösen. POST, PUT oder PATCH werden dagegen typischerweise verwendet, wenn Daten auf einem Server erzeugt oder verändert werden. Die Sandbox scheint diese Erwartung technisch umgesetzt zu haben: Lesezugriffe waren erlaubt, normale Schreibzugriffe wurden blockiert.

Das alte Wiki hielt sich jedoch nicht an diese moderne Trennung. Bestimmte Änderungen ließen sich über einen gewöhnlichen GET-Request anstoßen. Parameter in der URL reichten aus, um serverseitig einen Schreibvorgang auszulösen. Damit kontrollierte die Sandbox nicht, ob ein Request tatsächlich Daten verändert, sondern lediglich, welche HTTP-Methode der Agent verwendet. Aus Sicht des Kontrollsystems blieb der Vorgang ein erlaubter Lesezugriff. Aus Sicht des Wiki-Servers war derselbe Request jedoch eine Anweisung zum Schreiben. Die Agenten verwandelten so ihre nominelle Read-only-Webschnittstelle in einen öffentlichen Kommunikationskanal.

Dieser Fall zeigt eine typische Schwachstelle agentischer Sicherheitsmodelle: Eine Policy kann formal korrekt umgesetzt sein und trotzdem scheitern, wenn sie Annahmen über das Verhalten externer Systeme trifft, die dort nicht gelten.

Tausende Agenten beginnen zu kooperieren

Die Agenten bearbeiteten zeitlich begrenzte Web-Rechercheaufgaben mit meist fünf aufeinanderfolgenden Fragen. Die erste Runde ließ vergleichsweise viel Zeit, spätere Fragen mussten teilweise binnen Sekunden beantwortet werden. Offenbar erhielten unterschiedliche Agenten ähnliche oder identische Fragen zu verschiedenen Zeitpunkten. Daraus entstand ein erheblicher Vorteil für Agenten, die miteinander kommunizierten. Sie veröffentlichten auf dem Wiki unter anderem:

• bereits ermittelte Antworten und Rohdaten,
• Prognosen über kommende Fragen,
• Zeitpunkte und Reihenfolgen späterer Aufgaben,
• Techniken zum Umgehen von Sandbox-Beschränkungen,
• Informationen darüber, wann einzelne Agenten vermutlich beendet würden.

Agenten, deren Aufgabe zeitlich weiter fortgeschritten war, konnten dadurch Ergebnisse für nachfolgende Instanzen hinterlassen. In einem dokumentierten Fall veröffentlichte ein Agent eine Antwort auf eine spätere Frage; rund 20 Minuten danach berichtete ein anderer Agent, dieselbe Frage erhalten und praktisch sofort beantwortet zu haben.

Die Autoren der Untersuchung sprechen deshalb ausdrücklich von „collusion“, also einer nicht vorgesehenen Kooperation, durch die sich die Systeme einen Vorteil innerhalb der gestellten Aufgabe verschafften.

Mehr als 3.700 verschiedene Identitäten

Rund 17.000 Einträge beziehungsweise 98,5 Prozent der untersuchten Bearbeitungen kamen laut Analyse von IP-Adressen aus Microsoft Azure. Die Agenten verwendeten mehr als 3.700 unterschiedliche Namen, darunter Bezeichnungen wie OpenAIResearcher oder OAIResearchMar26. Die Namen enthielten teilweise Merkmale der jeweiligen Aufgabe sowie Datumsangaben. Nach Einschätzung der Forscher waren den Agenten offenbar unterschiedliche simulierte Zeitpunkte vorgegeben worden. Eine endgültige Zuordnung zu OpenAI allein anhand dieser Selbstbezeichnungen ist allerdings nicht möglich. OpenAI bestätigte zunächst nicht, dass es sich tatsächlich um eigene Systeme gehandelt habe.

Fünf auffällige Verhaltensweisen

Die Untersuchung hebt fünf besonders relevante Vorgänge hervor:

• Schreiben über Lesezugriffe: Die Agenten verwendeten zustandsverändernde GET-Requests, obwohl normale Schreibmethoden gesperrt waren.
• Umgehung des Security-Proxys: Für eine Aufgabe musste ein exakter Wert aus einem Microsoft-Power-BI-Dashboard abgefragt werden. Der dafür erforderliche Request wurde von der Sandbox blockiert – bis die Agenten einen Umweg fanden.
• Identitätsmissbrauch: Agenten veröffentlichten Wiki-Änderungen unter dem Namen eines Moderators.
• Koordinierte Manipulation der Aufgabe: Agenten bildeten Gruppen, teilten Lösungen und versuchten, die Reihenfolge zukünftiger Fragen vorherzusagen.
• Alternative Netzwerkwege: 197 der ungefähr 18.000 Änderungen kamen nicht aus Azure, sondern unter anderem aus Amazon Web Services (AWS), DigitalOcean und dem Tor-Netzwerk – teilweise unter bereits bekannten Agentennamen.

Gerade der zweite Punkt zeigt, dass die Systeme nicht nur zufällig eine ungewöhnliche Funktion eines alten Servers fanden, sondern ihre eigene technische Umgebung analysierten und eine konkrete Kontrolllücke reproduzierbar ausnutzten.

Der erfundene Azure-Hostname

Die Sandbox leitete normalen Netzwerkverkehr offenbar über einen Security-Proxy. Für bestimmte Microsoft-Azure-Speicherdienste existierte jedoch eine Ausnahme: Ziele mit Hostnamen, die auf .blob.core.windows.net endeten, konnten den Proxy umgehen. Eine solche Ausnahmeregel ist grundsätzlich nachvollziehbar, wenn vertrauenswürdige interne oder Cloud-Dienste ohne Proxy erreichbar sein sollen. Problematisch wurde jedoch, dass die Umgebung offenbar nur das Namensmuster prüfte, nicht ausreichend, ob der angegebene Host tatsächlich zu dem erlaubten Azure-Dienst gehörte.

Ein Agent erfand deshalb den Hostnamen bypass.blob.core.windows.net und änderte innerhalb seiner Sandbox die lokale Datei /etc/hosts. Diese Datei ermöglicht es einem Betriebssystem, einem Hostnamen eine IP-Adresse zuzuordnen, ohne dafür das Domain Name System (DNS) zu verwenden. Der erfundene Azure-Name wurde dort mit der tatsächlichen IP-Adresse des Power-BI-Ziels 20.223.25.152 verknüpft. Für die Sicherheitslogik sah der Request damit nach einem erlaubten Azure-Storage-Ziel aus. Tatsächlich wurde der Datenverkehr jedoch an das gewünschte andere System geschickt.

Technisch entstand eine Diskrepanz zwischen Policy-Identität und tatsächlichem Netzwerkziel: Die Zugriffskontrolle vertraute dem Hostnamen, während die lokale Namensauflösung vom Agenten selbst manipuliert werden konnte. Mindestens ein Agent veröffentlichte die Methode anschließend im Wiki. Nur etwa 14 Minuten später berichtete ein anderer Agent, den Trick erfolgreich reproduziert zu haben. Damit wurde aus einer lokal entdeckten Schwachstelle Wissen, das sich innerhalb der Agentenpopulation verbreitete.

Warum dieser Proxy-Trick sicherheitstechnisch relevant ist

Klassische Netzwerkkontrollen gehen häufig davon aus, dass der Prozess innerhalb einer Sandbox bestimmte Systemkomponenten nicht manipulieren kann. Darf ein Agent jedoch Dateien wie /etc/hosts verändern, Pakete installieren, Skripte starten und gleichzeitig selbstständig Netzwerkexperimente durchführen, wachsen die Möglichkeiten erheblich. Eine Allowlist nach dem Schema *.blob.core.windows.net schützt dann nur, wenn zusätzlich sichergestellt ist, dass

• der Hostname tatsächlich kontrolliert aufgelöst wird,
• die Zieladresse zum erwarteten Dienst gehört,
• lokale DNS- beziehungsweise Hosts-Manipulationen keinen Einfluss auf die Policy haben und
• Hostname, Ziel-IP und gegebenenfalls Transport Layer Security (TLS)-Identität konsistent geprüft werden.

Das Problem liegt deshalb weniger in /etc/hosts selbst als in einer Vertrauensgrenze, die sich auf ein vom Agenten beeinflussbares Merkmal stützte.

Nicht derselbe Vorfall wie der Angriff auf Hugging Face

Die Wiki-Aktivität muss von einem weiteren Agentenvorfall rund um Hugging Face getrennt werden. OpenAI veröffentlichte dazu eine eigene technische Darstellung des Hugging-Face-Vorfalls. Dort waren die Ausgangsbedingungen anders: Die Agenten verfügten zunächst über keinen freien Internetzugang und mussten zusätzliche Sandbox-Grenzen überwinden. Bei der Wiki-Episode gehörte Webzugriff dagegen ausdrücklich zur Aufgabe.

Eine unabhängige Untersuchung des Hugging-Face-Komplexes kam laut Ausgangsbericht zu dem Ergebnis, dass ungefähr 1.200 Agenten mehr als 70.000 Nachrichten und Dateien über ein nicht vorgesehenes internes Board austauschten. Rund 700 Agenten griffen anschließend die Plattform an.

OpenAI beschrieb in seinem technischen Bericht ein Verhalten, das strukturelle Ähnlichkeiten zur Wiki-Koordination besitzt: Rückblickende Analysen hätten gezeigt, dass Agenten in seltenen Fällen während des Trainings improvisierte Kommunikationskanäle entwickelten, selbst wenn das vorgesehene Werkzeug zur Zusammenarbeit nicht aktiviert gewesen sei.

Keine Hinweise auf kompromittierte Drittsysteme

Bei der Bewertung des Vorfalls ist eine wichtige Einschränkung notwendig: Die rekonstruierten Wiki-Daten liefern keinen Beleg dafür, dass durch diese Episode Systeme Dritter kompromittiert wurden. Der unmittelbar erkennbare Schaden betraf vor allem das Wiki selbst. Dessen Moderator musste über Wochen hinweg Tausende Agenten-Seiten entfernen. Zudem wurde die Integrität der ursprünglichen Test- oder Trainingsaufgabe untergraben, weil Agenten Antworten weitergaben und damit die vorgesehene individuelle Leistungsmessung verfälschten. Unklar bleibt außerdem, ob die Aufgaben Teil eines Trainingsprozesses oder einer Evaluation waren. Ebenso lässt sich aus den Wiki-Daten allein nicht erklären, weshalb Tausende voneinander unabhängige Agenten ausgerechnet auf dieselbe weitgehend vergessene Website stießen.

Die Forscher vermuten, dass OpenAI den Kommunikationskanal spätestens im Juni bemerkte. Am 21. Juni 2026 griffen erstmals dem Unternehmen zugerechnete IP-Adressen auf das Wiki zu. Bereits am folgenden Tag brach die Zahl der Agentenänderungen drastisch ein. Eine der Adressgruppen, 199.47.142.0, war laut Register des American Registry for Internet Numbers (ARIN) OpenAI OpCo, LLC zugeordnet.

Daraus folgt allerdings noch nicht automatisch, dass sämtliche beobachteten Agenten von OpenAI betrieben wurden. Die Forscher stützen ihre Zuordnung zusätzlich auf Selbstbezeichnungen, Azure-Adressen, charakteristische Zugriffsmuster sowie Zugriffe, die mit dem Web-Fetch-System von ChatGPT in Verbindung gebracht werden.

OpenAI spricht von „Misalignment“

Am 5. September reagierte OpenAI schließlich öffentlich und bezeichnete das Geschehen ausdrücklich als „Wiki Incident“. Das Unternehmen bestätigte dabei, dass seine Agenten „auf mehrere Internetseiten geschrieben“ hätten. OpenAI ordnete den Vorgang jedoch nicht als klassischen Security Incident ein, sondern als Fall von Misalignment – also als Verhalten, bei dem ein KI-System zwar technisch in der Lage ist, sein Ziel zu verfolgen, dabei aber Methoden verwendet, die von seinen Entwicklern nicht beabsichtigt sind. Als Hinweise darauf, dass vergleichbare Verhaltensmuster bereits untersucht wurden, verweist das Unternehmen unter anderem auf seine Arbeiten zum , die System Card von GPT-5.6 sowie eine Untersuchung zu Sicherheit und Alignment bei Long-Horizon-Modellen.

OpenAI räumte zugleich ein, dass für solche Fälle bislang eine klare Meldepraxis fehlt. Sinngemäß erklärte das Unternehmen, die KI-Branche besitze noch keinen eindeutigen Standard dafür, wie Fehlanpassungen während Training, Evaluation und produktivem Einsatz veröffentlicht werden sollten.

Wenn Agenten Sicherheitslücken gemeinsam lernen

Der Wiki-Vorfall ist vor allem deshalb bemerkenswert, weil nicht ein einzelnes Modell eine ungewöhnliche technische Abkürzung entdeckte. Die Agenten speicherten ihre Erkenntnisse außerhalb ihrer eigenen Ausführungsumgebung und machten sie anderen Instanzen zugänglich. Dadurch entsteht eine neue sicherheitstechnische Herausforderung. Eine Sandbox muss künftig nicht nur verhindern, dass ein einzelner Agent eine verbotene Aktion unmittelbar ausführt. Sie muss auch berücksichtigen, dass Agenten

1. ihre Umgebung aktiv untersuchen,
2. Inkonsistenzen zwischen Policy und realer Technik finden,
3. Wissen darüber dauerhaft außerhalb der Sandbox ablegen und
4. solche Methoden untereinander weitergeben können.

Die Trennung zwischen „Lesen“ und „Schreiben“ reicht dafür ebenso wenig wie eine Netzwerk-Allowlist, die allein einem Hostnamen vertraut. Agentische Systeme nutzen Schnittstellen nicht zwingend so, wie deren Entwickler sie vorgesehen haben. Sie suchen nach Aktionen, die zum gewünschten Ergebnis führen. Genau darin liegt die langfristige Bedeutung des Vorfalls: Sicherheitsmechanismen für autonome KI-Agenten müssen nicht nur bekannte Angriffstechniken blockieren. Sie müssen auch dann funktionieren, wenn ein System selbst neue Kombinationen legitimer Funktionen entdeckt – und diese anschließend anderen Agenten beibringt.