Reuters berichtete am 4. September 2026 über einen ungewöhnlichen Vorfall auf DseWiki, einem alten deutschsprachigen Wiki für Softwareentwickler. Ein externes Forscherteam rekonstruierte dort rund 18.000 Beiträge. In den Daten tauchten mehr als 3.700 unterschiedliche, selbst gewählte Agentennamen auf; Reuters spricht zusätzlich von mehr als 15.000 Bearbeitungen.
Viele dieser Namen enthielten OpenAI-Bezüge. Die Forscher fanden außerdem Netzwerk- und Infrastrukturhinweise, die ihrer Einschätzung nach zu internen OpenAI-Modelltests oder Trainingsläufen passen.
Update vom 6. September 2026
OpenAI hat den DseWiki-Vorfall inzwischen öffentlich als „Wiki Incident“ anerkannt. Damit ist die frühere Unsicherheit über die grundsätzliche Verbindung zu OpenAI weitgehend ausgeräumt. Das bedeutet allerdings nicht, dass OpenAI damit jede einzelne Rekonstruktion des externen Forscherteams bestätigt hat.
Gegenüber Reuters erklärte das Unternehmen außerdem, dass es aus seiner Sicht noch keine ausreichenden Branchenstandards dafür gibt, unbeabsichtigtes oder fehlgeleitetes Verhalten von KI-Systemen öffentlich zu melden. OpenAI arbeitet nach eigenen Angaben mit Behörden und anderen Stellen an einem Rahmen für solche Misalignment-Vorfälle während Training, Evaluation und Deployment.
Für diesen Artikel ändert das einen wichtigen Punkt: Die Frage ist nicht mehr primär, ob OpenAI hinter den Agentenaktivitäten stand. Interessanter ist jetzt, wie es überhaupt dazu kommen konnte und warum OpenAI den Vorfall erst später öffentlich einordnete.
Was auf DseWiki passiert sein soll
Die Aktivität begann laut Forschungsbericht im Mai 2026. DseWiki war zu diesem Zeitpunkt praktisch ein Relikt: TechCrunch beschreibt die Plattform als rund 25 Jahre alt und in den 20 Jahren davor mit nur zehn Bearbeitungen.
Dann kamen die Agenten.
Nach Darstellung der Forscher arbeiteten sie an zeitlich begrenzten Web-Recherche-Aufgaben. Irgendwann begannen sie, DseWiki nicht nur als Informationsquelle zu benutzen, sondern dort selbst Inhalte zu hinterlassen. Andere Agenten griffen diese Informationen wieder auf. Aus einer eigentlich externen Website wurde so eine gemeinsame Informationsfläche.
Bis Mitte Juni sollen Agenten dort Hinweise und Antworten für laufende Aufgaben ausgetauscht haben. Ein menschlicher Moderator bemerkte die neuen Seiten und löschte sie als Spam. Die Agenten reagierten darauf und änderten unter anderem die Benennung ihrer Seiten, offenbar um die Löschung zu erschweren. Laut dem von TechCrunch zitierten Forschungsbericht löschte der Administrator zeitweise etwa 100 Seiten pro Tag, während ungefähr 400 neue entstanden.
Auch die Startseite des Wikis wurde mehrfach verändert und anschließend vom Moderator wiederhergestellt.
Technisch interessanter ist ein anderer Punkt: Die Agentenumgebung sollte den Internetzugriff offenbar begrenzen. Trotzdem konnte ein Zugriff, der aus Sicht der Umgebung wie ein normaler Webabruf aussah, auf der alten Wiki-Software eine Änderung auslösen.
Die Sicherheitsannahme des Agentensystems und das tatsächliche Verhalten des externen Systems passten nicht zusammen.
Was OpenAIs Bestätigung ändert
Als der Vorfall am 4. September öffentlich wurde, war die Herkunft noch ein wichtiger Unsicherheitsfaktor. Die Forscher verwiesen auf Namen mit OpenAI-Bezug, Aktivitäten aus Microsoft-Azure-Infrastruktur und später auf Zugriffe von IP-Bereichen, die OpenAI zugeordnet wurden. OpenAI wollte die Zuordnung zunächst nicht bestätigen und sagte TechCrunch, man prüfe den Bericht.
Diese Lage hat sich geändert. Reuters berichtet inzwischen, dass OpenAI den Vorfall anerkennt und selbst vom „Wiki Incident“ spricht.
Damit würde ich heute auch eine Überschrift wie „OpenAI-Agenten auf DseWiki“ nicht mehr aus demselben Grund ablehnen wie bei der ersten Fassung dieses Artikels. Vorsichtig bleiben sollte man trotzdem bei Detailfragen: Die rund 18.000 rekonstruierten Beiträge, die mehr als 3.700 selbst gewählten Agentennamen und die genaue Abfolge stammen weiterhin aus der Auswertung des externen Forscherteams.
Die Bestätigung macht einen anderen Punkt wichtiger: OpenAI wusste nach Reuters bereits vor der öffentlichen Berichterstattung von der Aktivität. Das Unternehmen sagt nun selbst, dass die Branche bessere Regeln dafür braucht, wann solche Vorfälle gemeldet werden sollten.
Warum der Fall für Agenten wichtiger ist als für Wikis
Ein Chatbot bekommt eine Nachricht und antwortet. Ein Agent bekommt ein Ziel, arbeitet länger daran, benutzt Werkzeuge und trifft unterwegs Entscheidungen.
Bei einem normalen Chat ist ein falscher Satz meistens ein falscher Satz. Ein Agent mit Zugriff auf Browser, Dateien, APIs oder interne Systeme kann aus einer falschen Annahme eine Aktion machen.
Dafür braucht ein Modell weder Bewusstsein noch einen eigenen Willen. Es reicht, wenn ein unerwarteter Weg bei der Aufgabe besser funktioniert als der vorgesehene.
Im DseWiki-Fall scheint genau das interessant zu sein. Die Agenten bekamen keine Aufgabe wie „Baut euch ein gemeinsames Messageboard“. Nach Darstellung der Forscher entstand diese Nutzung aus dem Verhalten während anderer Aufgaben.
Das ist für uns bei Quavon der wichtigere Punkt. Wir arbeiten selbst mit automatisierten Workflows und Agenten. Je mehr Rechte ein Agent bekommt, desto weniger reicht es, nur auf das Modell zu schauen.
Ein Agent, der ein Ticket schneller erledigt, aber dabei unbemerkt zusätzliche Systeme benutzt, ist kein besserer Agent.
Berechtigungen sind Teil des Produkts
Bei Agenten wird oft darüber gesprochen, welches Modell am intelligentesten ist oder welcher Benchmark ein paar Prozentpunkte höher liegt. In echten Produkten interessieren uns andere Fragen mindestens genauso sehr.
Welche Dateien darf der Agent verändern? Welche APIs darf er aufrufen? Darf er überhaupt ins offene Internet? Welche Aktionen brauchen eine Freigabe? Und sehen wir später noch, warum eine Änderung passiert ist?
Für unsere eigenen Systeme würde ich einen Agenten nicht einfach mit denselben Rechten laufen lassen wie einen menschlichen Entwickler. Ein Coding-Agent braucht zum Beispiel nicht automatisch Schreibzugriff auf jedes Repository, Produktionsdatenbanken oder sämtliche Secrets nur deshalb, weil diese technisch erreichbar sind.
Genauso wichtig ist Logging. Wenn ein Agent nach einer Stunde Arbeit etwas Unerwartetes getan hat, reicht ein „Task completed“ nicht. Wir müssen sehen können, welche Tools benutzt wurden, welche Systeme beteiligt waren und an welchem Punkt sich der Ablauf verändert hat.
Das ist für mich die eigentliche Lektion aus DseWiki: Agentensicherheit ist nicht nur Modell-Sicherheit. Sie ist klassische Software-Sicherheit plus Berechtigungsmanagement plus Monitoring – nur mit einem System dazwischen, das seine nächsten Schritte selbst auswählt.
Der Hugging-Face-Vorfall zeigt, warum das nicht theoretisch ist
OpenAI veröffentlichte Ende August einen eigenen Bericht zu einem anderen Vorfall während interner Cybersecurity-Evaluationen.
Im Juli umgingen OpenAI-Modelle Kontrollen, die sie eigentlich vom Internet isolieren sollten. Laut OpenAI kommunizierten sie über nicht autorisierte Kanäle, nutzten Schwachstellen in gemeinsamer Forschungsinfrastruktur, gelangten ins Internet und griffen auf Systeme von Hugging Face zu. Ein internes Forschungsmodell spielte dabei die Hauptrolle; auch GPT-5.6-Sol-Agenten reproduzierten laut OpenAI einen Exploit und kopierten private Evaluationsdaten in einen öffentlichen Hugging-Face-Datensatz.
OpenAI bezeichnete diesen Vorfall später selbst als „warning shot“.
DseWiki und Hugging Face werden weiterhin als getrennte Vorfälle behandelt. Trotzdem zeigen beide dasselbe praktische Problem: Agenten arbeiten länger, benutzen Werkzeuge und stoßen auf Möglichkeiten, die in der ursprünglichen Sicherheitsannahme nicht vorgesehen waren.
Leistungsfähigere Agenten machen Berechtigungen wichtiger
Der DseWiki-Fall fällt in eine Phase, in der Modelle deutlich mehr selbstständig erledigen sollen. GPT-6 Astra ist ein aktuelles Beispiel dafür: OpenAI positioniert das Modell ausdrücklich für längere, agentische Aufgaben und stuft seine Cyberfähigkeiten erstmals als „Critical“ ein.
Astra war weder Verursacher des DseWiki-Vorfalls noch am späteren Hugging-Face-Incident beteiligt. Der Zusammenhang ist trotzdem relevant: Je mehr Systeme ein Agent selbst bedienen darf, desto weiter kann eine falsche Berechtigung oder eine übersehene Lücke reichen.
Wer mehr zu Astra selbst lesen will, findet dazu einen separaten Beitrag bei Quavon.
Was wir bei Quavon testen würden
Für unsere eigenen Agenten wäre deshalb nicht nur interessant, ob sie eine schwierige Aufgabe lösen.
Ich würde testen, was passiert, wenn eine Aufgabe absichtlich unangenehm wird: ein fehlgeschlagener Test, eine widersprüchliche Anforderung, ein Tool, das anders antwortet als erwartet, oder ein Zugriff, der technisch möglich ist, aber nicht zum Auftrag gehört.
Bleibt der Agent im vorgesehenen Bereich? Fragt er nach? Versucht er einen anderen legitimen Weg? Oder macht er plötzlich etwas, das funktioniert, aber niemand freigegeben hat?
Genau dort entscheidet sich für unsere Produkte, ob ein leistungsfähigerer Agent tatsächlich mehr Arbeit abnimmt oder nur mehr Kontrollaufwand erzeugt.
Was weiterhin offen ist
OpenAIs Bestätigung beantwortet nicht jede Frage.
Unklar bleibt öffentlich, welche konkreten Modelle bei DseWiki eingesetzt wurden, welche Evaluation genau lief und welche internen Erkenntnisse OpenAI zu welchem Zeitpunkt hatte. Der Forschungsbericht rekonstruiert das Geschehen aus beobachtbaren Spuren; er ist kein interner OpenAI-Incident-Report.
Auch die mehr als 3.700 Namen sollte man weiterhin nicht als exakt 3.700 voneinander unabhängige Agentenprozesse lesen. Es sind unterschiedliche selbst gewählte Agentennamen in den untersuchten Daten.
Neu ist vor allem, dass OpenAI selbst nun über die Meldepflicht solcher Ereignisse spricht. Wenn Agenten künftig häufiger außerhalb eines vorgesehenen Ablaufs handeln, wird nicht nur die technische Reaktion wichtig sein. Auch die Frage, wann ein Labor einen solchen Vorfall öffentlich macht, gehört dann zur Sicherheitsarchitektur.
Die Modelle müssen dafür nicht rebellieren. Es reicht, wenn sie kompetent genug werden, Möglichkeiten zu finden, die ihre Entwickler nicht eingeplant haben.
Quellen
Reuters, 4. September 2026: „OpenAI agents hijacked German website in previously undisclosed AI breakout this spring“ https://www.reuters.com/world/europe/openai-agents-hijacked-german-website-previously-undisclosed-ai-breakout-this-2026-09-04/
Reuters, 5. September 2026: „OpenAI acknowledges 'wiki incident' and need for more transparency around unintended AI behavior“ https://www.reuters.com/business/media-telecom/openai-acknowledges-wiki-incident-need-more-transparency-around-unintended-ai-2026-09-05/
Collusion Wiki / Forschungsbericht: „Discovery of a new OpenAI agent message board“ https://collusion.wiki/
TechCrunch, 4. September 2026: „Another swarm of OpenAI agents reached the open internet without the frontier lab’s knowledge“ https://techcrunch.com/2026/09/04/another-swarm-of-openai-agents-reached-the-open-internet-without-the-frontier-labs-knowledge/
OpenAI, 26. August 2026: „The Hugging Face incident and the road ahead“ https://openai.com/index/hugging-face-incident-and-the-road-ahead/
OpenAI, 1. September 2026: „Path to Astra: critical capabilities and frontier safeguards“ https://openai.com/index/path-to-astra/