Commit-rewriter 0.1: Der Agent, der das Audit Trail umschreibt

Eine September-Veröffentlichung, die den Git-Verlauf betrifft

Am 14. September 2026 veröffentlichte Simon Willison commit-rewriter 0.1^[1], eine Python-Web-App zum Umschreiben von Commit-Meldungen in einem Repository. Der Autor hat sie entwickelt, um die Commits von Datasettes Security Releases zu bereinigen, die voller Reste eines Code-Agenten und Verweise auf Tickets eines privaten Repositories waren.

Das Tool wird mit einem einzigen Befehl gestartet: uvx commit-rewriter path/to/repo. Der Pfad kann weggelassen werden, wenn sich die Shell bereits im Projektverzeichnis befindet.

Bei Bestätigung der Änderungen erstellt das Tool einen datierten Branch des aktuellen Status, um ein Rollback zu ermöglichen. Dann schreibt es jeden Commit vom ersten, den du berührt hast, bis zum neuesten um. Dieser zweite Satz beschreibt die Angriffsfläche besser als jede externe Analyse.

Der Mechanismus: Von der Shell zu Sicherheitsmetadaten

Der Git-Verlauf ist zwei Dinge gleichzeitig: ein Engineering-Tool und ein Audit-Artefakt. GPG-Signaturen, Zeitstempel, Autor, Hash des übergeordneten Commits: Die Rekonstruktion eines Vorfalls beginnt mit diesen Feldern.

Das Umschreiben von Meldungen ändert den Inhalt der betroffenen Commits. Die Hashes werden kaskadiert bis zu HEAD neu berechnet, und die vor dem Umschreiben angebrachten Signaturen verlieren ihre Gültigkeit.

Ein Code-Agent mit Shell-Zugriff ruft diesen Befehl wie jedes andere Binärprogramm auf. Dazwischen fehlt eine architektonische Sicherung zwischen der Agent-Ausführung und der Mutation des Audit-Speichers. Die CLI akzeptiert die Eingabe, das lokale Repository ändert seinen Status, die Spur wird weniger zuverlässig als zuvor.

Die Kosten für die Operation bleiben minimal: ein Prozess, keine besonderen Privilegien, kein Zugriff auf das primäre Repository.

Die Grundursache: Audit und Agent im gleichen Raum

Die Grundursache ist leicht auszusprechen und unbequem zu beheben: Das Artefakt, das die Arbeit des Agenten dokumentiert, befindet sich im gleichen Dateisystem, in dem der Agent schreibt.

In ausgereiften Architekturen existiert diese Trennung bereits. Anwendungslogs landen auf einem externen Collector, Append-Only, mit einer Aufbewahrung außerhalb der Kontrolle des Prozesses, der sie generiert. Der lokale Git-Verlauf lebt dagegen neben dem Code und akzeptiert Umschreibungen nach Designwahl.

Die Selbstaufrufe ohne Ausführungsgrenzen verwandeln dieses Design in ein Governance-Problem. Ein einzelner Befehl reicht aus, um Sicherheitsmetadaten anfechtbar zu machen. Das System, das ein Agent erreicht, ist das System, das ein Agent verändert.

Wer einen Vorfall untersucht, sucht Antworten auf drei Fragen: Wer hat diese Zeile geschrieben, wann und mit welcher Genehmigung. Eine Massenneubearbeitung nimmt Beweiswert von allen drei.

Was für das Tool spricht

Fairness erfordert zu sagen, was diese Veröffentlichung vermeidet. Der vor dem Umschreiben erstellte datierte Branch macht die Operation reversibel, solange dieser Branch auf der Festplatte bleibt und auf einen Remote gepusht wird.

Es gibt keine zugewiesene CVE. Es gibt keine öffentlichen Nachweise von Exploits. Es gibt auch keinen Remote-Vektor: Wer den Befehl ausführt, hat bereits lokalen Zugriff auf das Repo.

Die Versionsnummer erklärt den Status ehrlich: 0.1 bedeutet verfügbar, weit weg von produktionsreife. Die vom Autor beschriebene Verwendung ist legitim und häufig in Teams, die Sicherheitspatches aus privaten Repositories veröffentlichen. Das architektonische Problem gehört zur Kategorie der Tools, nicht zu diesem spezifischen Projekt.

Warum der September-2026-Kontext die Bilanz verändert

Eine lokale Angriffsfläche wiegt schwer, wenn es zuverlässige Wege gibt, zur Maschine zu gelangen. Der aktuelle Monat bietet zwei hilfreiche Erinnerungen.

CISA hat fünf Sicherheitslücken, die bereits in realen Angriffen ausgenutzt werden, zu seinem KEV-Katalog hinzugefügt, wie The Hacker News^[2] berichtet. Angreifer arbeiten an bekannten Lücken mit Patch-Fenstern gemessen in Tagen.

Auf der Client-Seite wurde ein Fehler in einer Tencent-App zur Verbreitung der Malware GrayRabbit genutzt, wie BleepingComputer^[3] berichtet. Der Lieferkanal war vertrauenswürdige Software, vom Benutzer selbst installiert. Die Workstation eines Entwicklers hostet Dutzende ähnlicher Kanäle.

Diese gleiche Maschine hostet den Code-Agenten, seine Shell, die Signaturschlüssel und die Repositories, mit denen du Releases erstellst.

Drei Fragen für Enterprise-AI-Teams

Die Sicherheitslage von AI-Systemen hinkt zwei oder drei Jahre hinter der Reife der Infrastruktur her, die sie hostet. Die praktischen Fragen bleiben operativ und haben binäre Antworten.

1. Verfügt der Code-Agent über eine eigene Identität mit namentlichen Logs und sofortiger Widerrufung?
2. Wird der Git-Verlauf kritischer Repositories auf einen Append-Only-Speicher außerhalb der Workstation repliziert?
3. Gibt es eine Allowlist der Befehle, die der Agent ausführen kann, mit allem anderen standardmäßig gesperrt?

Viele Unternehmen führen Agenten in der Produktion aus und behandeln nur wenige als formale Identitäten. Ein zwischen Mensch und Agent geteiltes Passwort macht das Log nutzlos: Der materielle Autor des Umschreibens bleibt für immer mehrdeutig.

Eine negative Antwort auf eine der drei deutet auf ein implizit akzeptiertes Risiko hin. Implizite Risiken kommen nach dem Vorfall während der Rekonstruktion zutage, wenn sich die Kosten für Abhilfe vervielfachen.

Entscheidungen für den nächsten Planungszyklus

Für den CTO betrifft die Überprüfung den Entwicklungs-Stack, nicht den Modellhersteller. Der neu zu gestaltende Perimeter ist die Workstation: Sandbox der Agent-Runtime, Befehlsallow-Liste, signierter Mirror der Repositories auf separater Infrastruktur.

Für den Head of Engineering ist die Wahl konkret: Den Agent in einem kurzlebigen Container ausführen und jeden Git-Schreibvorgang als privilegierte Operation mit expliziter Genehmigung behandeln.

Für den CFO ändert sich das Zeichen der Rechnung. Die Investition in die Isolierung der Entwicklungsumgebung wird weniger riskant als die Alternative, nämlich eine forensische Rekonstruktion anhand einer Spur, die ein Gegner in Frage stellen kann.

Für den Beschaffungsausschuss ist die renegotierbare Klausel die Standard-Berechtigung von Agent-Tools. Wer den Agenten bereitstellt, muss erklären, welche Befehle ausgeführt werden, mit welcher Identität und mit welcher Protokollierung auf der Agent-Seite.

Falle oder Wettbewerbsvorteil

Diese Architektur ist eine Falle, solange der Git-Verlauf der einzige Beweis der geleisteten Arbeit ist. Sie wird zum Wettbewerbsvorteil, wenn die Organisation die Audit-Spur als externes System behandelt, repliziert und bei jedem Push signiert.

commit-rewriter 0.1 tut genau das, was es verspricht, und erklärt es transparent. Die technische Schuld liegt davor, in der Entscheidung, einem Agenten eine vollständige Shell auf einer Maschine zu geben, die Compliance-Artefakte verwahrt.

Die Kategorie des Vorfalls, die die Industrie als AI-Coding-Agent-Sicherheitsverletzung katalogisiert, entsteht fast immer so: ein nützliches Tool, eine zu breite Berechtigung, eine fehlende Grenze. Das Material, um diese Grenze zu schließen, existiert bereits, und der nächste Planungszyklus ist der richtige Moment, es zu nutzen.