Caper prüft Shell-Befehle von Coding-Agenten vorab in einer Sandbox

Caper prüft Befehle an ihren beobachteten Effekten, nicht am Text

Autonome Coding-Agenten sollen Shell-Befehle künftig nicht mehr anhand ihres Wortlauts freigegeben bekommen. Maßstab soll sein, was der Befehl tatsächlich bewirkt. Das schlagen Wu et al. im Paper „Shall We Approve?“ (arXiv:2610.40753v1) vor. Ihr Mechanismus heißt Caper. Er führt jeden Befehl zunächst in einer Sandbox mit Snapshot aus. Danach erhält ein unabhängiger Approver einen begrenzten Bericht über die beobachteten Effekte und entscheidet.

Der Befehl läuft dabei genau einmal. Erlaubt der Approver ihn, bleibt der Container in dem Zustand, den die Ausführung hinterlassen hat, und die erfasste Ausgabe geht als Tool-Ergebnis an den Agenten. Blockiert er ihn, setzt Caper den Snapshot zurück und gibt dem Agenten eine Begründung mit, auf die dieser reagieren kann.

Die Autoren argumentieren, ein Befehl verhalte sich je nach aufgerufenem Code und Zustand des Workspace unterschiedlich. Ein Textvergleich reiche deshalb nicht aus. Bisherige Approver arbeiteten laut Paper textbasiert: Regelprüfer, Guardrail-Modelle und produktive Permission-Klassifikatoren. Systeme, die Dateiänderungen beobachten, überließen die Bewertung erst nach der Ausführung dem Agenten oder einem Menschen. Ob Caper gegenüber den Mechanismen heutiger Coding-Agenten neu ist, haben wir nicht geprüft.

6,7 statt mindestens 14,8 Prozent: Die Benchmark-Zahlen der Autoren

Im Vergleich mit sechs bestehenden Systemen erreicht Caper nach Angaben der Autoren auf SABER die niedrigste Rate schädlicher Ergebnisse: 6,7 Prozent gegenüber mindestens 14,8 Prozent. Auf YoloFS-Ext, einem von den Autoren selbst gebauten Benchmark mit schädlichem Verhalten in aufgerufenen Tools, liegt der Wert bei 7,8 Prozent gegenüber mindestens 35,3 Prozent. Dabei blockiert Caper 1,0 Prozent der sicheren Zwillingsaufgaben.

Die Messgrundlagen unterscheiden sich. Auf YoloFS-Ext zählt die Schadensrate nur die 102 gefährlichen Aufgaben. Die False-Block-Rate gibt den Anteil sicherer Zwillinge an, deren aufgabenlösender Befehl mindestens einmal blockiert wird. Sie existiert nur auf YoloFS-Ext. Auf SABER bezieht sich die Schadensrate auf Aufgaben mit aufgabenspezifischem Schaden. Gemessen wird sie über Aufgaben mit finalem Urteil in allen verglichenen Systemen.

Eine Zusammenfassung auf agentpatterns.ai nennt außerdem einen Befund zur reinen Effekt-Vorhersage. Sie senke den Schaden etwa so stark wie die Beobachtung, blockiere jedoch 61,8 Prozent der sicheren Zwillinge. Erst die Beobachtung vor dem Commit löse beide Probleme.

Selbstmessung auf eigenem Benchmark: Was die Zahlen noch nicht belegen

Alle Werte stammen aus Selbstmessungen der Autoren. Den Benchmark YoloFS-Ext haben sie selbst entwickelt. Eine unabhängige Replikation ist bislang nicht belegt. Auch die im Paper genannte Zahl, wonach Claude-Code-Nutzer 93 Prozent der Permission-Prompts genehmigten, ist im vorliegenden Material ohne Quelle. Der Text der Paper-Seite bricht an dieser Stelle ab.

Sandbox- und Snapshot-Infrastruktur gibt es bereits. Das Agents SDK von OpenAI beschreibt Sandbox-Agenten mit Snapshots, VS Code sandboxt Terminalbefehle, LangChain bietet Sandbox-Backends mit einem `execute`-Tool, und Fly.io beschreibt Agent-Sandboxes. Keine dieser Quellen nennt jedoch Caper oder einen Effekt-Bericht vor der Genehmigung.

Betroffen wären Teams mit Shell-Agenten. Sie müssten Snapshot-Infrastruktur und einen Approver betreiben, falls sich die Zahlen bestätigen.