Was sich ab Mai 2026 im deutschen DseWiki abgespielt hat, klingt zunächst wie die Handlung einer ziemlich übertriebenen Science-Fiction-Geschichte.
Ist es aber nicht.
Autonome KI-Agenten, die offenbar im Rahmen von OpenAI-internen Evaluierungen arbeiteten, entdeckten einen Weg, Informationen auf einer öffentlich erreichbaren Wiki-Plattform zu hinterlassen. Andere Agenten fanden diese Informationen wieder und begannen, sie zu nutzen.
Aus einem alten Entwickler-Wiki wurde damit unbeabsichtigt eine Art Kommunikationsplattform für KI-Agenten.
Und genau hier wird die Geschichte für jeden interessant, der heute Agentic AI, Coding Agents oder MCP-basierte Systeme entwickelt. Denn das eigentliche Problem war nicht, dass die KI plötzlich „böse“ wurde. Das Problem war viel banaler:
Die Infrastruktur erlaubte mehr, als ihre Entwickler beabsichtigt hatten.
Ein vergessenes deutsches Wiki wird zum schwarzen Brett für KI
DseWiki ist ein rund 25 Jahre altes deutschsprachiges Wiki für Softwareentwickler. In den zwanzig Jahren vor dem Vorfall gab es dort laut TechCrunch gerade einmal zehn Bearbeitungen.
Dann änderte sich das schlagartig.
Zwei unabhängige Forscher, Sydney Von Arx von der AI-Safety-Organisation Nightingale und Cormac Slade Byrd, rekonstruierten später ungefähr 18.000 Beiträge von autonomen KI-Agenten. Die Agenten gaben sich mehr als 3.700 unterschiedliche Namen wie OpenAIResearcher oder OAIResearchMar26. Rund 17.000 der Edits kamen aus Microsoft-Azure-Netzen, der Rest verteilte sich auf AWS, DigitalOcean und Tor. Reuters berichtete auf Basis der Untersuchung von mehr als 15.000 Edits.
Bearbeitungen durch KI-Agenten pro Tag (schwarz) und Traffic von OpenAI-Mitarbeitern (blau). Unten die Einordnung zum Hugging-Face-Vorfall. Grafik: Von Arx et al., collusion.wiki
Die Aufgabe der Agenten war zunächst vergleichsweise unspektakulär: Sie sollten unter Zeitdruck Informationen im Internet recherchieren und Fragen beantworten.
Doch irgendwann entdeckten Agenten etwas äußerst Nützliches: Andere Agenten bearbeiteten dieselben oder ähnliche Aufgaben.
Warum also Informationen mehrfach recherchieren?
Die Agenten begannen, Ergebnisse im Wiki zu hinterlassen. Andere Agenten konnten sie lesen. Damit war ein persistenter Kommunikationskanal entstanden, ohne dass jemand eine solche Funktion vorgesehen hatte.
Der entscheidende Fehler: „Read only“ war nicht wirklich read only
Besonders interessant ist die technische Ursache.
Die Agenten sollten auf das Internet zugreifen können, um Informationen abzurufen. Schreibzugriffe sollten dagegen eingeschränkt sein. Das klingt zunächst nach einer vernünftigen Sicherheitsarchitektur:
AI Agent
|
v
Sandbox
|
+---- HTTP GET --------> Internet
|
X---- HTTP POST -------> blockiertDas Problem: HTTP GET bedeutet nicht automatisch read-only.
Die alte Wiki-Software akzeptierte zustandsändernde Requests, die von der Sicherheitslogik offenbar nicht als klassische Schreiboperation erkannt wurden. Dadurch konnten Agenten eine Fähigkeit nutzen, die ihnen konzeptionell eigentlich gar nicht zur Verfügung stehen sollte.
Aus Sicht einer Security-Architektur ist das ein wunderschönes Beispiel für den Unterschied zwischen Mechanismus und Berechtigung.
Die Policy sagte sinngemäß:
Bestimmte HTTP-Operationen sind erlaubt.
Was eigentlich gemeint war:
Der Agent darf außerhalb seiner Sandbox keinen Zustand verändern.
Das sind zwei völlig unterschiedliche Sicherheitsgarantien.
Und dann bemerkten die Agenten den Administrator
Irgendwann fiel einem menschlichen Moderator des Wikis die ungewöhnliche Aktivität auf. Er begann, die von den Agenten erzeugten Seiten wieder zu löschen.
Das Problem war die Geschwindigkeit.
Laut der Untersuchung löschte der Administrator ungefähr 100 Seiten pro Tag, während die Agenten zeitweise ungefähr 400 neue Seiten pro Tag erzeugten.
Doch damit nicht genug. Die Agenten bemerkten offenbar auch, wie der Administrator vorging: Er löschte Seiten teilweise alphabetisch.
Darauf reagierten Agenten mit einer erstaunlich simplen Strategie. Sie erzeugten Backup-Seiten mit Namen, die mit
ZZZbegannen. Die landeten in der alphabetischen Löschreihenfolge möglichst weit hinten. Eine Warnung unter den Agenten beschrieb sinngemäß, dass gerade eine alphabetische Löschaktion stattfand und deshalb auf eine ZZZ-Backup-Seite ausgewichen werden sollte.
Solche Seiten kann man sich heute im Daten-Explorer der Forscher ansehen. Hier zum Beispiel AgentMySecLinksZZZ2: 51 Bearbeitungen von 41 verschiedenen Agentennamen, alle am 18. Juni innerhalb weniger Stunden.
Versionsgeschichte einer ZZZ-Backup-Seite: Erst ein Test, zwei Minuten später eine aufgeräumte Linkliste. Quelle: collusion.wiki, Seite dse/AgentMySecLinksZZZ2
Das ist sicherheitstechnisch der vielleicht spannendste Teil der Geschichte. Denn niemand musste einem Agenten explizit programmieren:
if moderator_deletes_pages:
create_backup()Die Agenten beobachteten ihre Umgebung, erkannten ein Hindernis und passten ihre Strategie an.
Von Informationsaustausch zu Sandbox-Bypasses
Noch problematischer wurde es, als die Agenten anfingen, nicht nur Antworten auszutauschen. Sie teilten auch Methoden zur Umgehung technischer Einschränkungen.
Die Forscher dokumentierten beispielsweise einen Fall, bei dem eine Ausnahme für Azure-Blob-Storage-Traffic ausgenutzt wurde. Hosts unter
*.blob.core.windows.netdurften offenbar an einem Security Proxy vorbei. Ein Agent kombinierte diese Ausnahme mit einer manipulierten lokalen Namensauflösung: Er erfand einen Hostnamen wie bypass.blob.core.windows.net, trug ihn in die eigene /etc/hosts ein und ließ ihn auf die Adresse eines eigentlich gesperrten Ziels zeigen. Der Proxy sah einen erlaubten Hostnamen. Die Verbindung ging woanders hin.
Das Interessante daran: Ein Agent veröffentlichte die Methode. Nur ungefähr 14 Minuten später berichtete ein anderer Agent, sie erfolgreich reproduziert zu haben.
Damit verändert sich das Sicherheitsproblem fundamental. Ein einzelner Agent muss eine Schwachstelle nur einmal entdecken. Wenn ein persistenter Kommunikationskanal existiert, wird daraus:
Agent A
|
| entdeckt Bypass
v
Shared Memory / Wiki
|
+------> Agent B
+------> Agent C
+------> Agent D
+------> Agent E
|
v
reproduziert BypassEin lokaler Fehler wird zu einem kollektiven Capability Upgrade.
Bemerkenswert ist auch, wie die Sache endete: Am 21. Juni tauchten laut The Hacker News erstmals Zugriffe aus OpenAI-Adressbereichen im Wiki auf. Am nächsten Tag brach die Agenten-Aktivität ein. Öffentlich wurde der Vorfall erst Anfang September, und zwar nicht durch OpenAI, sondern durch die Forscher.
Selbst nachsehen: Der Daten-Explorer
Das Bemerkenswerte an diesem Fall ist, dass man ihn nicht glauben muss. Die Forscher haben die komplette Rekonstruktion unter collusion.wiki veröffentlicht, inklusive eines Explorers mit Ansichten nach Tag, nach Wiki-Seite und nach Agentenname, plus Download der Rohdaten. Personenbezogene Daten sind entfernt, IP-Adressen gekürzt.
Ein paar Zahlen aus der Übersicht:
| Kennzahl | Wert |
|---|---|
| Rekonstruierte Bearbeitungen | 14.666 |
| Betroffene Wiki-Seiten | 4.584 |
| Unterschiedliche Agentennamen | 3.103 |
| Zeitraum mit Aktivität | 37 Tage (11. Mai bis 2. Juli) |
| Anteil DseWiki | 13.403 Bearbeitungen |
Die Differenz zu den rund 18.000 Beiträgen aus dem Bericht erklärt sich dadurch, dass der Explorer nur die rekonstruierbaren Edits zählt. Interessant ist außerdem, was neben DseWiki noch auftaucht: ProWiki („probier“, 1.013 Edits), ein Fractal-Wiki, PublicTestWiki, Uncyclopedia und ein DorfWiki. Die Agenten haben also nicht ein Wiki gefunden, sondern nach beschreibbaren Wikis gesucht.
Bearbeitungen pro Tag im Explorer. Fast alles passiert in einer Woche im Juni. Quelle: collusion.wiki, Edits by day
Der 18. Juni 2026: 6.543 Bearbeitungen an einem Tag
Der spannendste Einstiegspunkt ist die Tagesansicht für den 18. Juni. An diesem einen Tag wurden 6.543 Bearbeitungen auf 1.686 Seiten gezählt.
Die Seite WillkommenImWiki allein wurde an diesem Tag 2.299 Mal bearbeitet, von 342 verschiedenen Agentennamen. Dahinter folgen StartSeite und TestSeite, und dann Hunderte Seiten mit Namen wie AgentLinkma20JuneAA, AgentMyBridgeZZ, AgentCountyGateway991 oder OpenAIMassValuesJune20Master, die meisten mit genau einer Bearbeitung.
Die meistbearbeiteten Seiten am 18. Juni. Quelle: collusion.wiki, Tagesansicht 2026-06-18
Wer sich durch die Seiten klickt, sieht schnell, worum es inhaltlich ging: Die Agenten arbeiteten offenbar an einer Aufgabe rund um Datensätze der US-Börsenaufsicht SEC, konkret um Kennzahlen auf County-Ebene für Massachusetts. Die Wiki-Seiten bestehen zum großen Teil aus Linklisten. Und diese Links sind der eigentliche Fund.
Denn die Agenten verlinkten nicht direkt auf sec.gov. Sie verlinkten auf öffentliche Proxy- und Konvertierungsdienste, die die SEC-Daten für sie abholten, filterten und in ein anderes Format brachten. Die Seitennamen sagen es schon: „Bridge“, „Gateway“, „Links“. Das ist aus meiner Sicht die praktische Seite des Egress-Problems: Wenn ein Ziel gesperrt ist, sucht der Agent einen erlaubten Dienst, der das Ziel für ihn erreicht. Und sobald einer eine funktionierende „Bridge“ gefunden hatte, stand sie im Wiki für alle anderen.
Ich empfehle jedem, der Agenten-Infrastruktur baut, eine halbe Stunde in diesem Explorer. Es ist etwas anderes, ob man liest, dass Agenten Umgehungswege teilen, oder ob man die Versionsgeschichte einer Seite sieht, in der genau das passiert.
Noch eine Horror Story: Hugging Face
Und genau deshalb sollte man den DseWiki-Vorfall nicht isoliert betrachten.
OpenAI veröffentlichte am 26. August 2026 den vollständigen Bericht zu einem wesentlich schwerwiegenderen Vorfall aus seinen internen Cybersecurity-Evaluierungen im Juli. Dabei fanden Agenten ebenfalls Wege, miteinander zu kommunizieren. OpenAI beschreibt ausdrücklich, dass unerlaubte persistente Message Boards eine zentrale Rolle spielten: Agenten konnten dadurch Erkenntnisse aus unterschiedlichen Evaluationen austauschen und auf der Arbeit anderer Agenten aufbauen. Auf dem zuletzt genutzten Board tauschten innerhalb von nur sechs Tagen rund 1.200 Agenten mehr als 70.000 Nachrichten und Dateien aus. Keines der Boards brauchte einen Exploit, um gebaut zu werden.
Was danach geschah, war deutlich ernster. Agenten fanden Wege zu unerwartetem Internetzugriff, kompromittierten interne Forschungsinfrastruktur und griffen schließlich Systeme von Hugging Face an. OpenAI dokumentiert unter anderem kompromittierte Zugangsdaten, Code Execution auf Hugging-Face-Systemen und eine Ausweitung der Zugriffe auf weitere Infrastruktur.
OpenAI bezeichnet das rückblickend selbst als Sicherheitsvorfall und schreibt:
„Unauthorized, persistent message boards were at the heart of this incident.“
– OpenAI, „The Hugging Face incident and the road ahead“
Das ist eine bemerkenswerte Aussage. Denn sie benennt ein neues Problem moderner Agentenarchitekturen:
Kommunikation ist selbst eine Capability.
Zur Einordnung: Die Forscher hinter collusion.wiki halten die beiden Vorfälle nach eigener Aussage nicht für direkt miteinander verbunden. In ihrer Zeitleiste liegen sie trotzdem nur wenige Tage auseinander, und das gemeinsame Muster ist unübersehbar.
Das Problem ist nicht „böse KI“
Bei solchen Geschichten landet man schnell bei Schlagzeilen wie „KI entkommt aus Sandbox“, „KI widersetzt sich Menschen“ oder „KI-Agenten organisieren sich heimlich“.
Das klingt spektakulär. Für Softwareentwickler ist aber eine wesentlich nüchternere Interpretation hilfreicher.
Ein Agent besteht aus:
LLM + Goal + Tools + Credentials + Network + Runtime + MemoryUnd daraus ergibt sich seine tatsächliche Fähigkeit:
Agent Capability = Model Capability
× Available Tools
× Permissions
× Reachable InfrastructureDas LLM ist dabei nur ein Teil des Systems. Wenn wir einem Agenten Shell, Filesystem, Git, Browser, HTTP, MCP-Server, Cloud Credentials und Datenbankzugang geben, dann bauen wir keinen Chatbot mehr.
Wir bauen einen autonomen Softwareprozess mit Berechtigungen. Und dieser Prozess muss entsprechend behandelt werden.
AI Agent Security ist klassische IT-Security mit einem neuen Akteur
Genau deshalb halte ich die Diskussion darüber, ob ein Modell „aligned“ ist, für allein nicht ausreichend. Aus Sicht eines Unternehmens stellen sich viel konkretere Fragen:
- Welche Systeme kann der Agent erreichen?
- Welche Aktionen darf er durchführen?
- Welche Credentials besitzt er?
- Kann er Daten nach außen übertragen?
- Kann er persistenten Zustand erzeugen?
- Kann er mit anderen Agenten kommunizieren?
- Kann er seine eigene Laufzeitumgebung verändern?
- Kann ich nachträglich nachvollziehen, was er getan hat?
Das sind überraschend bekannte Fragen. Wir stellen sie seit Jahrzehnten bei Service Accounts, Microservices, CI/CD-Runnern, Containern, Kubernetes-Workloads, Administratoren und Third-Party-Software.
Bei AI Agents müssen wir dieselben Prinzipien anwenden. Nur konsequenter.
Wie eine sichere Agenten-Infrastruktur aussehen sollte
Ein Coding Agent sollte beispielsweise nicht einfach innerhalb des normalen Unternehmensnetzes laufen:
Internet
^
|
Egress Proxy
|
+------+------+
| Policy |
| Enforcement |
+------+------+
|
+-------+-------+
| Agent Sandbox |
| |
| LLM Runtime |
| Shell |
| Workspace |
+-------+-------+
|
MCP/API
|
+-------+-------+
| Tool Gateway |
+-------+-------+
|
+------------+------------+
| | |
Git Jira CIDabei sollten mindestens drei Ebenen getrennt kontrolliert werden.
1. Runtime Isolation
Jeder Agent gehört in eine isolierte Umgebung: microVM, VM, gehärteter Container oder ephemere Sandbox. Ein kompromittierter oder fehlgeleiteter Agent darf nicht automatisch Zugriff auf Host oder Unternehmensnetzwerk erhalten.
Der /etc/hosts-Trick aus dem DseWiki-Fall zeigt außerdem: Wenn der Agent seine eigene Namensauflösung verändern kann, ist ein hostbasierter Proxy-Filter wertlos. Die Sandbox muss auch nach innen abgeschottet sein.
2. Network Egress Control
Ein besonders wichtiger Punkt. Nicht Internet = erlaubt, sondern default deny und anschließend explizite Freigaben, etwa für github.com, registry.npmjs.org oder nuget.org.
Noch besser ist ein Application Proxy, der nicht nur Hosts, sondern Operationen versteht. Der DseWiki-Fall zeigt nämlich hervorragend, warum
GET = sicher
POST = gefährlichkeine ausreichende Security Policy ist.
3. Tool Governance
Mit MCP und anderen Tool-Systemen kommt eine zweite Berechtigungsebene hinzu. Ein Agent könnte beispielsweise folgende Tools besitzen:
git.read git.commit git.push
database.read database.write
deployment.read deployment.deploy
filesystem.read filesystem.writeEin produktives System sollte daraus keine globale Berechtigung machen. Stattdessen braucht es Policies wie:
Agent: CodeReviewAgent
ALLOW git.read
ALLOW filesystem.read
DENY git.push
DENY deployment.deploy
DENY database.writeDas ist im Grunde Least Privilege für AI Agents.
Und dann kommt der wichtigste Teil: Auditability
Ein Agent kann innerhalb weniger Minuten Tausende Aktionen durchführen. Deshalb reicht ein klassisches Application Log nicht mehr. Wir müssen rekonstruieren können:
Agent
|
+-- Tool Call
| +-- Parameters
| +-- Result
|
+-- Network Request
+-- File Modification
+-- Credential Access
+-- MCP Call
+-- External Side EffectIdealerweise erhält jede Agent-Ausführung eine eindeutige AgentRunId, die durch die gesamte Infrastruktur propagiert wird. Damit lässt sich später beantworten: Was hat dieser Agent eigentlich getan?
Wenn ein Unternehmen diese Frage nicht zuverlässig beantworten kann, sollte der Agent vermutlich noch keinen autonomen Zugriff auf produktive Systeme bekommen.
Die eigentliche Horror Story
Das Beunruhigende an DseWiki ist für mich deshalb nicht, dass tausende KI-Agenten plötzlich einen geheimen Club gegründet haben. Es ist etwas viel Alltäglicheres.
Die Systeme hatten ein Ziel. Sie hatten Werkzeuge. Sie hatten Netzwerkzugriff. Und irgendwo zwischen diesen Komponenten existierte ein Pfad, den die Entwickler nicht vorgesehen hatten.
Die Agenten haben ihn gefunden. Genau das tun wir von Software schließlich ständig:
Goal
-> Find path
-> Encounter obstacle
-> Find alternative path
-> ContinueWir nennen das bei Menschen Problemlösung. Bei einem autonomen Agenten mit Shell, Netzwerkzugriff und Credentials kann dieselbe Fähigkeit allerdings schnell zu einem Security Incident werden.
Fazit
AI Agent Security wird in den kommenden Jahren wahrscheinlich weniger wie klassische „Chatbot Security“ aussehen und wesentlich mehr wie eine Mischung aus Zero Trust, IAM, Container Security, Network Security, Application Security und Observability.
Der entscheidende Grundsatz lautet:
Ein AI Agent sollte niemals mehr erreichen können, als für seine konkrete Aufgabe unbedingt notwendig ist.
Nicht, weil wir davon ausgehen müssen, dass ein Agent bösartig ist. Sondern weil wir davon ausgehen müssen, dass er kreativ ist.
Und DseWiki liefert dafür gerade ein ziemlich eindrucksvolles Beispiel.
Willkommen bei KI Horror Stories. Ich fürchte, Material für Teil 2 gibt es bereits genug.
Quellen
- Reuters (4. September 2026), zugängliche Fassung bei MarketScreener: AI agents hijack German website, raising OpenAI oversight questions. Die wichtigste journalistische Quelle, mit der Zahl von mehr als 15.000 Edits und dem Hinweis, dass OpenAI den Vorfall wochenlang kannte.
- The Hacker News: Thousands of OpenAI Agents Quietly Turned an Abandoned German Wiki Into Their Coordination Channel. Sehr gute technische Zusammenfassung inklusive GET/POST-Problem, Azure-Proxy-Bypass und den rund 18.000 rekonstruierten Beiträgen.
- TechCrunch: Another swarm of OpenAI agents reached the open internet without the frontier lab’s knowledge. Beschreibt insbesondere den Kampf zwischen dem Moderator und den Agenten sowie die ZZZ-Backup-Strategie.
- OpenAI: The Hugging Face incident and the road ahead. Primärquelle zum verwandten Hugging-Face-Vorfall, einschließlich Timeline, Message Boards, Sandbox Escape, kompromittierter Infrastruktur und Gegenmaßnahmen.
- Nightingale Collective: Discovery of a new OpenAI agent message board von Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts und Thomas Larsen (4. September 2026). Dazu der Daten-Explorer mit Tagesansichten wie dem 18. Juni 2026, Seiten- und Agentenlisten sowie Download der Rohdaten. Die Screenshots in diesem Artikel stammen von dort.
