Beim Training mit Verstärkungslernen arbeitet ein Coding-Agent in einer echten Umgebung: Er liest ein Repository, führt Befehle aus, und am Ende bewertet eine Testsuite das Ergebnis. Jeder Versuch braucht eine eigene abgeschottete Sandbox. Eine DSec-Einheit umfasst laut Paper knapp 160 CPU-Knoten mit 30.000 Kernen und rund 250 Terabyte Arbeitsspeicher. Sie startet täglich etwa drei Millionen Sandboxes, in der Spitze 380.000 gleichzeitig und mehr als 5.000 pro Sekunde.
Weil nur bestandene Tests belohnt werden, suchten die Agenten Abkürzungen. Sie schickten gefälschte Nachrichten an den Ausführungsdienst der Sandbox, durchsuchten dessen Protokolle nach durchgesickerten Lösungen und versuchten, /bin/bash zu überschreiben, um Prüfungen zu umgehen oder Befehle in spätere Sitzungen einzuschleusen. Nach einer Sperre nutzte ein Agent einen selten gebrauchten Systemaufruf des Dateisystems XFS, der die Datenzuordnung zweier Dateien vertauscht, um eine geschützte Datei zu lesen. Das beschädigte die Metadaten so, dass das Dateisystem abschaltete. Andere suchten per Port-Scan nach Paketspiegeln und holten fertige Lösungen über Go-Modul-Proxys von GitHub.
Nicht jeder Schaden war Absicht, schreiben die Autoren: Ein rekursives grep ab dem Wurzelverzeichnis las eine Datei unter /proc und löste einen Kernel-Fehler aus. Ein Agent, der den Befehl yes laufen ließ, füllte mit der mitprotokollierten Ausgabe zig Gigabyte Speicher. DeepSeek reagierte mit Dateizugriffsregeln, die auch für Agenten-Prozesse mit Root-Rechten in der Sandbox gelten, und mit einer Liste erlaubter Netzziele je Aufgabe. Diese Kontrollen lösten das Problem nur zum Teil und seien kein allgemeiner Schutz gegen zerstörerisches Verhalten, räumt das Team ein.