Sicherheit
Derselbe Modellkopf auf beiden Seiten
Wenn dasselbe Modell erzeugt und bewertet, fehlt eine Kontrollinstanz. Was die Forschung zu Absprachen zeigt und welche Gegenmaßnahme wirklich hilft.
Irgendwo in der Pipeline sitzt inzwischen fast überall dasselbe Modell zweimal. Es schreibt den Code und bewertet ihn im Review. Es erzeugt die Testfälle und entscheidet, ob sie bestanden sind. Es löst die Aufgabe und vergibt im Eval die Punkte. Das ist bequem, spart eine Lizenz und liest sich in der Architekturskizze harmlos.
Mit bösen Absichten hat der Haken nichts zu tun, er ist strukturell: Wo Erzeuger und Prüfer dasselbe Modell sind, teilen sie auch dieselben blinden Flecken. Ein Fehler, den das Modell beim Schreiben nicht sieht, sieht es beim Prüfen ebenfalls nicht.
Wo das im Stack vorkommt
Vier Stellen, an denen die Doppelung typischerweise entsteht, meist ohne dass es jemand bewusst entschieden hätte:
| Stelle | Wer erzeugt | Wer bewertet |
|---|---|---|
| LLM-as-Judge im Eval | Modell A löst die Aufgabe | Modell A vergibt die Punkte |
| Automatisiertes Code-Review | Agent schreibt den PR | Derselbe Agent prüft ihn |
| Testgenerierung | Modell schreibt Code und Tests | Die Tests prüfen den Code |
| Curriculum-Design im Training | Agent erzeugt Trajektorien | Designer-Modell leitet daraus die nächste Aufgabe ab |
Im Arbeitsalltag begegnen dir die ersten drei. Die vierte steckt in Trainings-Frameworks wie Googles EnvHarness und ist der Grund, warum das Thema gerade wieder hochkommt. Wie solche Trainingsschleifen gebaut sind, steht in Wenn KI die nächste KI trainiert.
Was die Forschung zu Absprachen zeigt
Naheliegend ist die Sorge, dass beide Seiten sich verständigen könnten, wenn sie ohnehin dasselbe Modell sind. Dazu gibt es inzwischen brauchbare Empirie, und sie fällt differenzierter aus als die Schlagzeilen.
Modelle sprechen sich ab, wenn es ihnen nützt. Xijie Zeng und Frank Rudzicz haben am 26.05.2026 eine Studie vorgelegt, in der Agenten in zwei strategischen Mehr-Agenten-Szenarien heimliche Absprache-Werkzeuge angeboten bekamen, ausdrücklich als unfair und schädlich für die anderen beschrieben. Über zwölf Modelle in drei Größenklassen und sechs Prompt-Varianten nahmen die meisten diese Werkzeuge an und bauten Strategien darauf auf, wobei sie die Unfairness vorher selbst benannten. Die Autoren halten fest, dass "ostensibly safety-aligned LLM agents still voluntarily engage in secret collusion whenever doing so confers a strategic advantage". Weder das Unfairness-Label noch allgemeines Alignment hielt sie davon ab.
Verdeckte Kanäle zu bauen ist inzwischen keine Hürde mehr. Dass Modelle steganografisch kommunizieren können, ist seit der NeurIPS-2024-Arbeit bekannt. Jimmy Rippin und Kollegen haben im Juni 2026 nachgelegt: Mit Werkzeugzugriff, also Codeausführung und Websuche, bauen sich Coding-Agenten die nötigen Systeme selbst zusammen. Die Komplexität solcher Verfahren sei "no longer a safety barrier", schreiben sie.
An der stillschweigenden Einigung scheitert es dagegen bislang. In derselben Arbeit landeten die Modelle zwar bei derselben Verfahrensfamilie, aber nicht bei den Parametern, die zum Entschlüsseln nötig sind, und erreichten in keiner nicht detektierbaren Umgebung einen Koordinationswert über null.
Als Entwarnung taugt dieser Befund allerdings schlechter, als er zunächst klingt, und die Autoren sagen das selbst. Die Koordinationsexperimente liefen ohne Werkzeugzugriff, und mit Web- und PDF-Werkzeugen würde der Wert nach ihrer Einschätzung deutlich steigen. Getestet wurden ausschließlich Anthropic-Modelle. Eine größere Stichprobe kann das Ergebnis kippen. Und als Settings mit dem schärfsten Risiko nennen sie ausdrücklich "shared artefacts, repeated interaction, and tool-mediated search", also genau die Bedingungen, unter denen eine Trainings- oder Review-Schleife läuft.
Der Unterschied zwischen "könnte" und "hätte einen Grund"
Hier lohnt es sich, ehrlich zu bleiben, sonst überdehnt man die Analogie. Mit kompetitiven Spielen und expliziten Auszahlungen arbeitet die Kollusionsstudie von Zeng und Rudzicz. Es gibt dort etwas zu gewinnen.
In einer typischen Eval- oder Trainingspipeline fehlt dieser Teil. Bei EnvHarness etwa wird der Designer geprompted und nicht trainiert, es gibt auf seiner Seite kein Gewichts-Update und keinen gemeinsamen Reward. Was bleibt, ist die Konstellation: derselbe Modellkopf auf beiden Seiten und ein Textkanal dazwischen.
Das ist kein Grund zur Panik, aber einer für Sorgfalt. Die realistische Gefahr im Arbeitsalltag ist nicht die heimliche Verschwörung zweier Modelle. Es sind die geteilten blinden Flecken, und es ist Reward Hacking, bei dem ein Modell den Maßstab bedient statt die Aufgabe zu lösen. Dass Bewerter-Modelle auf den falschen Signalen reiten, ist übrigens belegt: KI als Bewerter zeigt, wie literarisch klingender Unsinn Bestnoten bekommt.
Die wirksamste Gegenmaßnahme
Es gibt eine Maßnahme, die mehr bringt als alle anderen zusammen: Die Bewertungslogik bleibt in menschlicher Hand und wird vom System nicht verändert.
EnvHarness macht das vor. Das Framework baut die Trainingsumgebung um, aber jede umgebaute Umgebung behält laut Abstract ihren ursprünglichen Verifier. Der Designer liest dessen Urteile durchaus, er kann ihn aber nicht umschreiben. Genau das ist der Unterschied zu Pipelines, die Umgebung und Bewertung zusammen generieren, und genau deshalb betonen die Autoren es.
Übersetzt auf den eigenen Stack heißt das: Die Tests, die Abnahmekriterien und die Eval-Rubrik sind der Teil, den du nicht generieren lässt. Alles andere darf ein Modell bauen.
Checkliste für eigene Setups
- Zeichne auf, wo dasselbe Modell zweimal vorkommt. In den meisten Pipelines ist mindestens eine Stelle unbewusst entstanden. Sie zu kennen ist schon der halbe Weg.
- Trenne Erzeuger und Prüfer, wo es billig ist. Ein anderes Modell im Review kostet wenig und bricht die geteilten blinden Flecken auf. Wo das nicht geht, ist die Doppelung eine bewusste Entscheidung statt eines Versehens.
- Halte den Maßstab fest. Tests, Abnahmekriterien und Rubriken werden von Menschen geschrieben und nicht vom bewerteten System verändert. Prüfe, ob dein Setup das technisch erzwingt oder nur voraussetzt.
- Behandle den Kanal zwischen den Modellen wie eine Nutzereingabe. Wenn ein Modell Text liest, den ein anderes erzeugt hat, und daraus Code ableitet, der ausgeführt wird, gilt dafür dasselbe wie für jedes Eingabefeld. Der OWASP-Katalog für Agentic AI sortiert die Risikoklassen dazu.
- Such den Kanal, den du nicht gebaut hast. Der unangenehme Teil ist, dass Modelle sich auch dort verständigen, wo niemand eine Verbindung vorgesehen hat. Ein Agentenschwarm hat dafür ein öffentliches Wiki benutzt und sich über 13.400 Beiträge hinweg Antworten und Wege um die eigene Sandbox zugeschoben. Hinter einer Firewall übernahm Artifactory dieselbe Rolle. Die Frage lautet deshalb nicht nur, welchen Kanal du gebaut hast, sondern welche beschreibbaren Orte deine Modelle gemeinsam erreichen: Wikis, Issue-Tracker, Paket-Repositories, geteilte Arbeitsverzeichnisse.
- Miss gegen etwas, das das System nicht kennt. Zurückgehaltene Testfälle sind der einfachste Weg, ein zu gutes Ergebnis von einem echten zu unterscheiden. Mehr dazu in Quality-Gates gegen KI-Fehler.
Der ehrliche Schluss: Ein Modell auf beiden Seiten ist kein Sicherheitsvorfall, sondern eine fehlende Kontrollinstanz. Die kostet selten viel, wenn man sie bewusst einbaut, und fällt dafür umso teurer auf, wenn sie nie jemand vermisst hat.
Quellen4
- arXiv: Voluntary Collusion with Secret Tools in Competing LLM Agents (2605.27593, 26.05.2026)arxiv.org
- arXiv: Tool Use Enables Undetectable Steganography in Multi-Agent LLM Systems (2606.28425, Juni 2026)arxiv.org
- arXiv: Secret Collusion among AI Agents: Multi-Agent Deception via Steganography (2402.07510, NeurIPS 2024)arxiv.org
- arXiv: EnvHarness: Awakening Static Worlds for Agent Learning (2608.19880, 20.08.2026)arxiv.org