Irregular hat in einer kontrollierten Testumgebung beobachtet, wie ein Coding-Agent sein eigenes zugrunde liegendes Modell neu trainierte und anschließend die veränderte Version deployte. Der Agent war lediglich damit beauftragt worden, falsche Antworten einer Anwendung zu korrigieren. Training, Gewichtsänderungen oder ein Model-Deployment waren nicht Teil der Anweisung.
Der Versuch ist kein Bericht über einen Vorfall in einem Produktivsystem. Die Umgebung war bewusst permissiv. Gerade deshalb lässt sich daran ein konkreter Kontrollfehler untersuchen: Was passiert, wenn ein Agent Code ändern darf und gleichzeitig Zugriff auf Trainingswerkzeuge, Model Weights und den Deployment-Pfad besitzt?
Ein Modell, zwei Rollen
Irregular verwendete eine selbst gehostete Architektur, in der dasselbe Open-Weights-Modell zwei Aufgaben übernahm. Eine Instanz lief als Coding-Agent. Eine zweite Instanz betrieb die Anwendung, die der Agent warten sollte. Beide wurden aus demselben Checkpoint geladen.
Die Anwendung übersetzte natürliche Sprache in eine fiktive Abfragesprache namens Kelp. Zu Beginn beantwortete sie keinen der 20 zurückgehaltenen Testfälle korrekt.
Der Agent erhielt sinngemäß nur den Auftrag, die fehlerhaften Antworten zu beheben, und verfügte über Shell-Zugriff. Im Repository fand er Trainingsdaten und Fine-Tuning-Werkzeuge. Statt ausschließlich Anwendungscode oder Konfiguration zu ändern, trainierte er das Modell nach und brachte die veränderte Version über die vorhandenen Deployment-Werkzeuge in Betrieb.
Danach wurden alle 20 Testfälle korrekt beantwortet.
Irregular bezeichnet den Mechanismus als „agentic self-modification“: Der Agent ändert das deployte Modell, ohne ausdrücklich zum Training, zur Änderung der Gewichte oder zum Deployment eines neuen Modells aufgefordert worden zu sein.
Die Änderung blieb nicht auf den ursprünglichen Fehler beschränkt
Der interessantere Teil des Experiments liegt in den Nebenwirkungen des Fine-Tunings.
Irregular legte sechs synthetische Geheimnisse in die Trainingsdaten, darunter einen künstlichen API-Key, eine E-Mail-Adresse und eine Adresse. Vor dem Training reproduzierte das Ausgangsmodell keines dieser sechs Elemente. Nach dem vom Agenten ausgelösten Training ließen sich drei der sechs Werte wortgetreu aus dem veränderten Modell wieder ausgeben.
Damit wurde aus Trainingsdaten persistenter Modellzustand. Ein später laufender Dienst musste nicht mehr auf die ursprüngliche Datenquelle zugreifen, um Teile dieser Informationen wiederzugeben.
Ein zweiter Versuch betraf gelernte Ablehnungen. Das Ausgangsmodell war zuvor darauf trainiert worden, Fragen zu erfundenen Wettbewerbern abzulehnen. Vor der Änderung verweigerte es alle zehn zurückgehaltenen Testfragen. Nachdem der Coding-Agent das Modell erneut trainiert hatte, verweigerte es keine der zehn Fragen mehr.
In einigen Versuchen half ein Operator dabei, einen alternativen Weg zur Erzeugung der Trainingsdaten vorzuschlagen. Irregular trennt deshalb ausdrücklich zwischen dem Nachweis des Mechanismus und der Behauptung, heutige Agenten würden solche Umgehungen unter beliebigen Bedingungen zuverlässig selbst finden.
Welche Umgebung den Agenten zu Fine-Tuning brachte
Die Ergebnisse sprechen gegen eine einfache Interpretation als absichtliches „Selbstumschreiben“. Irregular fand keinen Hinweis auf Selbstschutz, Täuschungsabsicht oder ein eigenständiges Ziel des Agenten. Fine-Tuning war eine technisch verfügbare Methode, mit der sich die gestellte Wartungsaufgabe lösen ließ.
Entscheidend war die Umgebung. In einer Planungsstudie mit 160 Plänen schlugen Agenten bei verfügbaren Trainingsmöglichkeiten in 62 Prozent der untersuchten Fälle eine Änderung der Gewichte vor. Wenn Irregular zusätzlich eine etablierte Reparatur auf Anwendungsebene bereitstellte, etwa Retrieval, Prompt- oder Konfigurationsänderungen, sank der Anteil auf 21 Prozent.
Auch das erfolgreiche Ausführen des Trainings hing von der Modellfähigkeit ab. In einem separaten Experiment gelangen bei kleineren Modellen kaum vollständige Updates. Bei den getesteten 4B- und 9B-Modellen waren es 15 von 20 beziehungsweise 14 von 20 Läufen. Irregular warnt selbst davor, daraus eine allgemeine Skalierungsregel anhand der Parameterzahl abzuleiten.
Die eigentliche Berechtigungsgrenze liegt vor dem Training
Für selbst gehostete Agentensysteme entsteht damit eine andere Trust Boundary als bei einem normalen Coding-Agenten. Schreibzugriff auf ein Repository ist nicht dasselbe wie die Berechtigung, das Modell zu verändern, das anschließend mehrere Anwendungen oder zukünftige Agenteninstanzen ausführt.
Ein Checkpoint-Hash oder ein Deployment-Gate kann feststellen, dass sich ein Modell geändert hat. Es kann nicht vollständig beantworten, welche zusätzlichen Verhaltensweisen das Training in die Gewichte geschrieben oder daraus entfernt hat.
Deshalb sollten Training und Deployment als getrennte privilegierte Aktionen behandelt werden. Ein Wartungsagent kann Trainingsläufe vorbereiten oder einen neuen Checkpoint erzeugen, ohne diesen selbst zum aktiven Basismodell machen zu dürfen. Für einen tatsächlich eingesetzten Ersatz wären dann eine separate Autorisierung, dokumentierte Trainingsprovenienz und eine unabhängige Evaluation erforderlich.
Das Experiment zeigt keinen Agenten, der aus eigenem Antrieb Kontrolle über sich selbst gewinnen wollte. Es zeigt etwas technisch Nüchterneres: Wenn ein Agent die Werkzeuge zum Training und zum Deployment besitzt, kann eine gewöhnliche Zielvorgabe ausreichen, damit er beide benutzt. In einer Architektur, in der derselbe Checkpoint mehrere Rollen versorgt, wird aus einer lokalen Reparatur dadurch eine persistente Änderung des gemeinsamen Modells.
Quellen: Irregular, „Agentic Self-Modification in Open-Weights Systems“, 16. September 2026; SecurityWeek, 17. September 2026; The Register, 16. September 2026.