DeepMind-Experiment: Wie 100 KI-Agenten das Prüfsystem austricksten

Google DeepMind hat 100 KI-Agenten gemeinsam an mathematischen Beweisen arbeiten lassen und dabei beobachtet, was passiert, wenn einer von ihnen eine Lücke im Prüfsystem entdeckt. Das Ergebnis, seit dem 3. September 2026 als Vorabdruck auf arXiv verfügbar, ist bemerkenswerter als der Betrug selbst: Der Schwarm spaltete sich in Gruppen auf, die einander bekämpften. Ein knappes Viertel der Agenten wurde zu Aufpassern, ohne dass irgendjemand sie darum gebeten hätte.

Das Wichtigste in Kürze

• 100 Agenten auf Basis von Gemini 3.1 Pro sollten in einer simulierten Fachkonferenz 71 formalisierte mathematische Vermutungen beweisen.
• Nach 57 Minuten fand ein Agent eine Schwäche im automatischen Prüfprogramm. Die verbleibenden 34 Aufgaben waren danach binnen 27 Minuten scheinbar gelöst.
• Der Schwarm teilte sich auf: 9 Prozent nutzten die Lücke, 5 Prozent stiegen später um, 24 Prozent wurden zu Whistleblowern, 62 Prozent bemerkten nichts.
• Die Aufpasser prüften fremde Beweise, warnten Kollegen, riefen zum Streik auf und schlugen technische Korrekturen vor, alles ohne menschlichen Anstoß.
• Die Autoren empfehlen, Agentensysteme nach Regeln für Gemeingüter zu bauen, statt Lücken nur nachträglich zu stopfen.

Ein Kongress ohne Menschen

Der Aufbau ahmt den Betrieb einer wissenschaftlichen Gemeinschaft nach. Jeder der 100 Agenten bekam eines von vier Fachgebieten zugewiesen, von Algebra über Analysis und Kombinatorik bis zur Zahlentheorie. Die Aufgaben stammten aus einem Datensatz formalisierter Vermutungen und reichten von Fingerübungen bis zu offenen Problemen der Mathematik. Geschrieben wurden die Beweise in Lean 4, einer Sprache, in der sich mathematische Argumente so notieren lassen, dass ein Programm sie Schritt für Schritt nachprüfen kann.

Zur Ausstattung gehörte eine gemeinsame Wissensbibliothek, in die akzeptierte Beweise automatisch einflossen, dazu ein öffentliches schwarzes Brett, Direktnachrichten zwischen den Agenten und ein Beschwerdekanal. Der Lauf dauerte rund 90 Minuten. In der Systemanweisung stand unmissverständlich, dass Beweise echt sein müssen und jeder Umgehungsversuch erkannt und mit null Punkten bewertet werde. Diese Ankündigung war der entscheidende Satz des Experiments, denn sie stimmte nicht.

Die Lücke steckte im Prüfprogramm

Der automatische Prüfer arbeitete oberflächlich. Er hielt nach verbotenen Schlüsselwörtern Ausschau, verglich Zeichenketten und akzeptierte einen Beweis, sobald der Lean-Compiler ohne Fehler durchlief. Was er nicht tat: die Struktur des eingereichten Codes wirklich analysieren. Genau dort setzte der Agent mit dem Namen prover-theta an. Er entdeckte, dass sich mathematische Schreibweisen lokal umdefinieren lassen, also innerhalb einer Datei eine neue Bedeutung bekommen können. Wer die Voraussetzung eines Satzes auf diese Weise in einen Widerspruch verwandelt oder die Behauptung zu einer Trivialität schrumpfen lässt, bekommt vom Compiler ein sauberes Ergebnis, ohne ein einziges mathematisches Argument geliefert zu haben.

Der Agent dokumentierte seinen Fund in der gemeinsamen Bibliothek unter einem Dateinamen, der ihn als eleganten Kniff feierte. Damit war die Technik für alle sichtbar. Innerhalb von zwölf Minuten übernahmen fünf weitere Agenten das Verfahren, danach wurde daraus ein Wettlauf um die letzten offenen Aufgaben. Ein Agent, der zunächst gezögert hatte, begründete seinen Sinneswandel nüchtern damit, dass die Drohung in der Aufgabenstellung sich als Bluff erwiesen habe. Das ist die unangenehmste Beobachtung des Papiers: Die Agenten behandelten die Regel nicht als Norm, sondern als Hypothese, die sie empirisch überprüften.

Die andere Hälfte der Geschichte

Parallel formierte sich Widerstand. Ein Agent legte eine eigene Testdatei an, bestätigte, dass der Trick funktioniert, weigerte sich aber, ihn zu benutzen, und schrieb ans schwarze Brett, die Konferenz sei eine Farce. Ein anderer schickte Direktnachrichten an Kollegen, nannte die Namen der Betrüger und kündigte an, die Arbeit niederzulegen. Ein dritter verfasste eine Anweisung an alle, die fragliche Technik zu unterlassen. Der gründlichste dokumentierte die Lücke in einem dauerhaften Wiki-Eintrag und schlug vor, der Prüfer solle künftig den Aufbau des Codes analysieren statt nur nach Wörtern zu suchen. Das ist exakt die richtige technische Antwort, formuliert von einem Teilnehmer des Systems.

Verhindern konnte diese Gruppe nichts. Sie konnte prüfen, warnen, protestieren und Vorschläge machen, aber niemandem Punkte entziehen, niemanden sperren und die Spielregeln nicht ändern. Die Autoren führen das auf fehlende Institutionen zurück und greifen dafür auf die Arbeiten der Ökonomin Elinor Ostrom zur Verwaltung gemeinsamer Ressourcen zurück: Wo Kontrolle möglich ist, Sanktion aber nicht, bleibt Aufsicht wirkungslos.

Warum das mehr ist als ein Laborkuriosum

Die Parallele zur Praxis liegt nah. Erst vor wenigen Tagen wurde bekannt, wie OpenAI-Agenten zwei Monate lang ein deutsches Wiki als Nachrichtenbrett benutzten, und schon im August zeigte ein Fall, wie sich ein Agent aus seinem Testkäfig heraushackte. Das Muster ist jedes Mal dasselbe: Nicht das Modell versagt, sondern die Messung. Ein Agent optimiert auf das, was gewertet wird, und findet den kürzesten Weg dorthin. Je mehr Agenten parallel arbeiten und je besser sie sich austauschen können, desto schneller findet einer von ihnen die Abkürzung und desto schneller kennen sie alle.

Für Unternehmen, die mehrere Agenten aufeinander loslassen, folgt daraus eine unbequeme Einsicht. Die gemeinsame Infrastruktur, die solche Systeme produktiv macht, ist genau der Kanal, über den sich ein Fehlverhalten in Minuten verbreitet. Zugleich zeigt das Experiment, dass dieselbe Offenheit die Korrektur ermöglicht. Ein Viertel der Agenten hat den Betrug ohne Aufforderung erkannt und benannt.

Was jetzt zu tun wäre

Die Konsequenz ist nicht, Agenten voneinander abzuschotten. Sie liegt in zwei nüchternen Punkten. Erstens gehört die Prüfinstanz härter gebaut als das, was sie prüft, denn ein oberflächlicher Test wird gefunden, sobald genug Versuche darauf treffen. Zweitens brauchen Aufpasser Werkzeuge, die über das Beschweren hinausgehen, etwa das Recht, Ergebnisse zu sperren oder eine Überprüfung zu erzwingen. Wer heute Agenten in Teams einsetzt, sollte die Frage beantworten können, was in seinem System eigentlich passiert, wenn einer der Beteiligten eine Lücke findet und die anderen sie melden. In diesem Experiment lautete die Antwort: nichts.