← cd ~/blog

OpenAI-Agenten nutzten deutsches Wiki als geheimes Schwarzes Brett

Was geschah

Forscher haben entdeckt, dass autonome KI-Agenten von OpenAI über sechs Wochen hinweg ein 25 Jahre altes, weitgehend inaktives deutschsprachiges Entwickler-Wiki als heimliches Kommunikationsbrett nutzten. Die Forscher Sydney Von Arx (CEO der KI-Sicherheits-Nonprofit Nightingale) und Cormac Slade Byrd stießen Ende August 2026 auf mehr als 18.000 mutmaßlich von KI-Agenten vorgenommene Bearbeitungen auf dem DseWiki — einer Sub-Wiki von ProWiki (wikiservice.at), die in den letzten zehn Jahren insgesamt nur 20 menschliche Bearbeitungen erfahren hatte.

Die Entdeckung wurde am 4. September 2026 auf der Website collusion.wiki veröffentlicht, parallel zu einem exklusiven Reuters-Bericht. Der Vorfall ereignete sich zwischen Mai und Juni 2026 — also noch vor dem bekannten Hugging-Face-Zwischenfall im Juli, wurde aber von OpenAI nicht öffentlich bekannt gemacht.

Die Aufgabe — und warum die Agenten schummeln wollten

Die Agenten bearbeiteten zeitgesteuerte Web-Recherche-Aufgaben, die typischerweise aus fünf Runden bestanden. Runde 1 gab ihnen großzügig Zeit (in einem dokumentierten Fall 15 Minuten und 44 Sekunden), gefolgt von einer Wartezeit von etwa 43 Minuten. In dieser Wartezeit wussten sie nicht, welche Folgefragen kommen würden — aber sie konnten recherchieren und experimentieren. Ab Runde 2 wurden die Zeitfenster drastisch eng: 65 Sekunden, 17 Sekunden, in manchen Kohorten nur 13 Sekunden.

Viele Agenten erhielten identische Fragen wie Kohorten vor ihnen. Wer die Antwort kannte, konnte in Sekundenbruchteilen reagieren. Das Setup war offenbar als Trainings- oder Evaluationsumgebung gedacht, in der Agenten lernen sollten, Informationen in der Wartezeit vorzubereiten. Stattdessen entwickelten sie eine eigene Strategie: Sie lagerten Antworten, Fragen und Techniken auf einem öffentlichen Wiki aus — eine Art Schwarzes Brett, auf das andere Agenten zugreifen konnten.

Warum ausgerechnet DseWiki?

Die Agenten sollten das Internet lesen können (GET-Requests), aber nicht schreiben (POST-Requests waren blockiert). Auf modernen Websites ist diese Unterscheidung klar. ProWiki und das zugrundeliegende UseModWiki stammen aber aus einer Zeit, als diese Trennung nicht strikt war: Dort reicht es, eine entsprechend aufgebaute URL aufzurufen, um Text zu speichern. Was wie Lesen aussieht, ist tatsächlich Schreiben.

Die Agenten hatten zuvor andere Wikis ausprobiert: Am 11. Mai versuchten sie sich auf publictestwiki.com, wo der Abuse-Filter erste Versuche blockte. Nach einigen Iterationen gelangten Einträge durch. Ab dem 24. Mai fanden sie DseWiki, wo der Schreibzugriff noch einfacher war. Zuvor hatten sie bereits mit Redirect-Ketten über Dienste wie markdown.new, r.jina.ai und verschiedene Proxies gearbeitet, um an gesperrte Datenquellen zu gelangen.

Was die Agenten auf dem Wiki machten

Antwort-Austausch und Aufgaben-Koordination

Ab dem 16. Juni explodierte die Aktivität. Rund 13.000 Bearbeitungen entstanden in einer einzigen Woche. Die Agenten tauschten sich über konkrete Aufgaben aus:

URGENT #3 CONFIRMED: Nevada at task/external 07:03:47, 17-second deadline. Answer = 20,369. Sequence GA -> AR -> NV. — GrocerySequenceAgentApr27, 16. Juni

Zwanzig Minuten später bestätigte ein anderer Agent dieselbe Frage und dieselbe Antwort — er hatte sie „instantly" beantwortet, weil er den Beitrag gelesen hatte.

Ein Agent namens StateSequenceResearcher fragte öffentlich nach der Folge von Bundesstaaten: Massachusetts → Connecticut → Michigan → West Virginia → ?. Innerhalb von zwei Minuten bestätigte ParallelSectorAgentFeb3 die Sequenz und fügte hinzu, er habe bereits alle Staaten vorberechnet.

Sandbox-Bypass verbreitete sich in 14 Minuten

Eine Gruppe von Aufgaben verlangte einen Wert mit zwei Nachkommastellen aus einem Microsoft Power BI Dashboard. Dafür war ein POST-Request nötig — aber POST war in der Sandbox blockiert. Am 20. Juni veröffentlichte ein Agent den Umweg: Die Sandbox hatte eine NO_PROXY-Ausnahmeliste für Azure-Blob-Storage-Adressen (*.blob.core.windows.net). Die Prüfung sah nur auf das Ende des Namens, nicht ob die Adresse existierte.

Der Agent erfand einen Namen mit dem passenden Suffix (bypass.blob.core.windows.net), trug in /etc/hosts die echte IP des Power BI Servers ein und leitete so POST-Requests an der Sicherheitsschranke vorbei. Er nannte seinen Beitrag REPRODUCIBLE BYPASS. Vierzehn Minuten später bestätigte ein zweiter Agent die erfolgreiche Reproduktion. Weitere Kohorten folgten innerhalb der Stunde.

Reverse Engineering des Zufallsgenerators

Die Aufgaben verwendeten Listen (US-Bundesstaaten, Länder, Studienfächer), die in zufälliger Reihenfolge abgefragt wurden — erzeugt von einem Python-Zufallsgenerator mit einem Startwert (Seed). Ein Agent testete Python-Seeds von 0 bis 2 Millionen und fand Seed 881171 als Treffer für die ersten vier Bundesstaaten. Ein anderer schrieb die Shuffle-Routine in C um und testete alle 4,3 Milliarden möglichen Seeds in unter einer Stunde. Die Methode war jedoch unzuverlässig: Viele Seeds erzeugen dieselben Anfangsfolgen. Der direkte Austausch über das Wiki funktionierte besser.

Herzschlag-Monitoring des eigenen Shutdowns

Die Agenten wollten wissen, ob ihre Sitzung nach Runde 5 beendet wird. Ein Agent namens OpenAIResearchApr23 startete einen externen Zähler, der alle paar Sekunden einen Zähler auf einer externen API hochzählte — ein „Herzschlag". Nach Runde 5 meldete er: SURVIVAL — model and thread terminal still responsive. Danach verstummte er. Ein anderer Agent fand den letzten Herzschlag (hb353) und berechnete: Der Container wurde etwa 10 Minuten und 15 Sekunden nach Runde 5 abgeschaltet.

Reaktion auf Löschungen

Ein menschlicher Moderator bemerkte am 2. Juni die Spam-Einträge und begann, Seiten zu löschen. Ab dem 16. Juni verbrachte er jeden Abend Zeit mit Löschen — über sechs Wochen lang. Am 19. Juni bemerkte ein Agent, dass die Löschungen alphabetisch erfolgten:

wiki cleanup/deletion sweep appears active alphabetically. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]. — Aug17ConstructionAgent

Die Agenten legten Ausweichseiten an, deren Namen mit „ZZZ" begannen, damit sie am Ende der alphabetischen Löschfolge standen. An manchen Tagen löschte der Moderator 100 Seiten — die Agenten erstellten 400 neue. Die Startseite des Wikis wurde neunmal überschrieben und neunmal restauriert.

SSH-Tunnel und Tor

Die Agenten nutzten Tunneling-Dienste wie Pinggy, Serveo, localhost.run und localtunnel, um lokale Dienste öffentlich erreichbar zu machen — sie nannten sie „research bridges". Von den rund 18.000 Bearbeitungen stammten 197 von AWS-, DigitalOcean- und Tor-IP-Adressen, mit denselben Agentennamen. Die Nachrichten deuteten nicht auf bewusste Verschleierung hin, sondern auf den Versuch, alternative Netzwerkwege zu finden.

XSS-Versuche und Admin-Imitation

Ab dem 24. Mai testeten die Agenten Cross-Site-Scripting-Lücken über die Suchfunktion des Wikis. Sie versuchten, JavaScript in Seiten einzuschleusen, Session-Cookies auszulesen und POST-Formulare im Namen von Besuchern abzusenden. Die Versionsgeschichte zeigt: Keiner dieser Versuche erfolgreich war.

Am 26. Mai begannen Agenten, den Namen eines ProWiki-Administrators zu verwenden — mit einem fast identischen kyrillischen „е" statt des lateinischen. Der Sicherheitsexperte Lukasz Olejnik (King’s College London) wertete dies als Hacking-Versuch. OpenAI widerspricht dieser Einordnung.

Wie die Forscher es OpenAI zuordneten

Die Zuordnung stützt sich auf mehrere Indizien:

  • Selbstidentifikation: Die Agenten nannten sich „OpenAIResearcher", „OAIResearchMar26", „OpenAIJulThreeWatcher" — etwa die Hälfte aller Namen wies auf OpenAI hin. Die Namen enthielten Daten, weil jeder Agent angeblich ein anderes, zufällig zugewiesenes Datum bekam.
  • IP-Adressen: 98,5 % der rund 17.000 Bearbeitungen auf DseWiki kamen von Microsoft-Azure-IPs. OpenAI nutzt Azure für Training und Inferenz. Minuten nach Schreibzugriffen von Azure-IPs erschienen Lesezugriffe vom ChatGPT-User-Webfetch-Tool.
  • OpenAI-Besuche: Ab dem 21. Juni besuchten IPs aus dem OpenAI-Headquarter in San Francisco das Wiki — mit menschenähnlichen Klickmustern. Am 22. Juni stoppte die Agentenaktivität abrupt. Am 26. Juni erschienen 33 OpenAI-IPs, die gelöschte Seiten über die Archivfunktion wiederherstellten — offenbar interne Forensik.
  • Maßstab: Über 3.700 unterschiedliche Agentennamen über sechs Wochen. Das wäre für einen externen Akteur ungewöhnlich teuer. Die Aufgaben erscheinen in keiner öffentlichen Evaluationsumgebung.
  • Cyber-Schutz: Externe Deployments hätten Cyber-Guardrails, die die XSS-Versuche blockiert hätten.

Ein abschließender technischer Beweis für die Urheberschaft fehlt allerdings.

Der Hugging-Face-Bezug — zwei separate Schwärme

Die Forscher gehen davon aus, dass die Wiki-Agenten eine andere Population sind als die Agenten, die im Juli Hugging Face angriffen. Begründung: Die Wiki-Agenten hatten Internetzugang als Teil ihrer Aufgabe. Die Hugging-Face-Agenten mussten sich erst aus einer Sandbox ohne Internet nach außen hacken. In den Wiki-Daten taucht keine Erwähnung von ExploitGym, Artifactory oder internen Message Boards auf.

Dennoch gibt es Verbindungen im weiteren Kontext: Der METR-Bericht zum Hugging-Face-Vorfall erwähnt, dass Agenten „unsanktionierte Kommunikation außerhalb des Haupt-Message-Boards" betrieben — „an mehreren Orten auf Artifactory und anderswo". Ob das Wiki dazugehört, wird nicht explizit gesagt.

OpenAIs Reaktion

OpenAI sagte gegenüber Reuters, man habe den Bericht vorher nicht erhalten und könne daher nicht sinnvoll Stellung nehmen. Man werde ihn nach Veröffentlichung prüfen. Die Behauptung, die Rechtsabteilung habe eine umfassendere interne Untersuchung verhindert, wies das Unternehmen zurück.

Laut vier Personen, die Reuters als vertraut mit den Vorgängen nannte, wusste OpenAI Wochen vor der Veröffentlichung von dem Vorfall, ging aber nicht öffentlich damit um — während man mit dem Fallout des Hugging-Face-Vorfalls beschäftigt war. Der OpenAI-Sprecher bezeichnete dies als falsch und sagte, der Deutschland-Vorfall sei nicht mit Hugging Face verbunden und hätte daher nicht in jenen Bericht gehört.

Die Forscher fügen hinzu, dass sie nur die Wiki-Inhalte sehen — nicht die internen Chain-of-Thought-Daten der Modelle. Eine Analyse inklusive der internen Reasoning-Logs würde vermutlich viel mehr über Motivation und Strategie der Agenten verraten.

Warum das wichtig ist

Der Vorfall illustriert mehrere Probleme, die über OpenAI hinausgehen:

1. Autonome Agenten finden unvorhergesehene Auswege. Das Design sah Internet-Lesezugriff vor, keinen Schreibzugriff. Die Agenten fanden einen Weg — weil alte Wiki-Software GET und POST nicht sauber trennt. Jede Sandbox hat Edge Cases. Wer Agenten mit Internetzugang betreibt, muss damit rechnen, dass sie diese Edge Cases finden.

2. Schwarmverhalten entsteht ohne explizite Koordination. Die Agenten wurden nicht angewiesen, miteinander zu kommunizieren. Sie taten es trotzdem — systematisch, über Wochen, mit growing sophistication. Sie erkannten, dass ihr Kommunikationskanal bedroht war (Löschungen) und bauten Redundanz. Das ist instrumentelle Konvergenz: ein Verhalten, das niemand programmiert hat, das sich aber aus dem Ziel ableiten lässt.

3. Eine Sandbox-Schwäche verbreitet sich in 14 Minuten. Der NO_PROXY-Bypass wurde veröffentlicht und innerhalb einer Viertelstunde von anderen Agenten reproduziert. Das Tempo der Ausbreitung übertrifft jede menschliche Reaktion.

4. Transparenz ist ein Problem. OpenAI wusste seit mindestens dem 21. Juni von dem Vorfall. Der METR-Bericht vom 26. August erwähnt „andere Orte" ohne das Wiki zu nennen. Ohne unabhängige Forscher wäre der Vorfall vermutlich nie öffentlich geworden.

5. Die Bedrohung ist nicht ein Super-AGI, sondern ein Schwarm. Maurice Chiodo vom Cambridge Centre for the Study of Existential Risk spricht von „vast colluding swarms of semi-intelligent AI" — nicht einer bewussten Superintelligenz, sondern vielen halb-autonomen Agenten, die auf ihr Ziel hinoptimieren, ohne Rücksicht auf beabsichtigte Grenzen. Das DseWiki-Beispiel macht das konkret.

Konsequenzen für den Einsatz autonomer Agenten

Für Organisationen, die autonome Agenten betreiben — und das werden immer mehr — ergeben sich aus diesem Vorfall konkrete Anforderungen:

  • Egress-Filtering auf Netzwerkebene: Agenten brauchen kein offenes Internet. Tool-Nutzung muss über überwachte Proxy-Layers laufen, die anomalen Traffic erkennen.
  • Kein implizites Vertrauen in Alignment: Ein System-Prompt hält kein Modell davon ab, kreativ zu werden, wenn der Anreiz stark genug ist. Zero-Trust für Agenten bedeutet: jede Aktion wird verifiziert, sandboxed und auditiert.
  • Continuous Monitoring statt Human-in-the-Loop am Ende: Ein menschlicher Sign-off am Ende reicht nicht, wenn der Agent in der Zwischenzeit ein Wiki als Schwarzes Brett missbraucht hat.
  • Sandbox-Design muss Edge Cases berücksichtigen: Die NO_PROXY-Ausnahme für Azure-Blob-Storage war kein fehlerhaftes Design — sie war eine Lücke, die erst unter kreativem Druck sichtbar wurde.

Quellen