Commit-rewriter 0.1: l'agente che riscrive l'audit trail

Un rilascio di settembre che tocca il git history

Il 14 settembre 2026 Simon Willison ha pubblicato commit-rewriter 0.1^[1], una web app Python che serve a riscrivere i messaggi di commit di un repository. L'autore l'ha costruita per ripulire i commit delle security release di Datasette, pieni di residui lasciati da un agente di codifica e di riferimenti a ticket di un repo privato.

Lo strumento parte da un comando singolo: uvx commit-rewriter path/to/repo. Il path si può omettere quando la shell si trova già dentro la directory del progetto.

Alla conferma delle modifiche il tool crea un branch datato dello stato corrente, così da permettere un ritorno indietro. Poi riscrive ogni commit dal primo che hai toccato fino al più recente. Quella seconda frase descrive la superficie di attacco meglio di qualunque analisi esterna.

Il meccanismo: dalla shell ai metadati di sicurezza

Il git history è due cose insieme: uno strumento di ingegneria e un artefatto di audit. Firme GPG, timestamp, autore, hash del commit padre: la ricostruzione di un incidente parte da quei campi.

Riscrivere i messaggi cambia il contenuto dei commit toccati. Gli hash si ricalcolano a cascata fino a HEAD, e le firme apposte prima della riscrittura perdono validità.

Un agente di codifica con accesso alla shell invoca quel comando come qualunque altro binario. In mezzo manca un circuit breaker architetturale fra l'esecuzione dell'agente e la mutazione dello storage di audit. La CLI accetta l'input, il repo locale cambia stato, la traccia diventa meno affidabile di prima.

Il costo dell'operazione resta minimo: un processo, zero privilegi speciali, zero accesso al repository primario.

La root condition: audit e agente nello stesso spazio

La root condition è facile da enunciare e scomoda da correggere: l'artefatto che documenta il lavoro dell'agente risiede nello stesso filesystem in cui l'agente scrive.

Nelle architetture mature questa separazione esiste già. I log applicativi finiscono su un collector esterno, append-only, con una retention fuori dal controllo del processo che li genera. Il git history locale vive invece accanto al codice, e accetta riscritture per scelta di progetto.

L'auto-invocazione abilitata in assenza di confini di esecuzione trasforma quel design in un problema di governance. Un singolo comando basta a rendere i metadati di sicurezza contestabili. Il sistema che un agente raggiunge è il sistema che un agente altera.

Chi indaga su un incidente cerca risposte a tre domande: chi ha scritto quella riga, quando, con quale approvazione. Una riscrittura di massa toglie peso probatorio a tutte e tre.

Cosa gioca a favore dello strumento

La correttezza impone di dire cosa questo rilascio evita. Il branch datato creato prima della riscrittura rende l'operazione reversibile, finché quel branch resta sul disco e viene spinto su un remoto.

Manca un CVE assegnato. Manca evidenza pubblica di sfruttamento. Manca pure un vettore remoto: chi esegue il comando possiede già accesso locale al repo.

Il numero di versione dichiara lo stato con onestà: 0.1 significa disponibile, distante da production-ready. L'uso descritto dall'autore è legittimo e frequente nei team che pubblicano fix di sicurezza a partire da repository privati. Il problema architetturale appartiene alla categoria di strumenti, più che a questo progetto specifico.

Perché il contesto di settembre 2026 cambia il calcolo

Una superficie locale pesa quando esistono modi affidabili per arrivare alla macchina. Il mese in corso offre due promemoria utili.

CISA ha aggiunto cinque vulnerabilità già sfruttate in attacchi reali al proprio catalogo KEV, come riporta The Hacker News^[2]. Gli attaccanti lavorano su falle note, con finestre di patching misurate in giorni.

Sul fronte client, un difetto in un'app Tencent è servito a distribuire il malware GrayRabbit, secondo BleepingComputer^[3]. Il canale di consegna è stato un software fidato, installato dall'utente stesso. La workstation di uno sviluppatore ospita decine di canali analoghi.

Quella stessa macchina ospita l'agente di codifica, la sua shell, le chiavi di firma e i repository con i quali costruisci le release.

Tre domande per i team AI enterprise

La postura di sicurezza dei sistemi AI viaggia con due o tre anni di ritardo rispetto alla maturità dell'infrastruttura che li ospita. Le domande utili restano operative, e hanno risposta binaria.

1. L'agente di codifica dispone di un'identità propria, con log nominativi e revoca immediata?
2. Il git history dei repository critici viene replicato su uno storage append-only fuori dalla workstation?
3. Esiste una allowlist dei comandi che l'agente può eseguire, con il resto bloccato per default?

Molte imprese eseguono agenti in produzione e poche li trattano come identità formali. Una credenziale condivisa fra umano e agente rende il log inutile: l'autore materiale della riscrittura resta ambiguo per sempre.

Una risposta negativa a una qualsiasi delle tre indica un rischio accettato in modo implicito. I rischi impliciti emergono dopo l'incidente, durante la ricostruzione dei fatti, quando il costo di rimediare si moltiplica.

Decisioni per il prossimo planning cycle

Per il CTO la revisione riguarda lo stack di sviluppo, più che il vendor del modello. Il perimetro da ridisegnare è la workstation: sandbox del runtime agentico, allowlist dei comandi, mirror firmato dei repository su infrastruttura separata.

Per l'Head of Engineering la scelta è concreta: eseguire l'agente dentro un container effimero e trattare ogni scrittura su git come operazione privilegiata, con approvazione esplicita.

Per il CFO il segno del calcolo cambia. L'investimento in isolamento dell'ambiente di sviluppo diventa meno rischioso dell'alternativa, cioè una ricostruzione forense condotta su una traccia che una controparte può mettere in discussione.

Per il comitato acquisti la clausola da rinegoziare riguarda i permessi di default degli strumenti agentici. Chi fornisce l'agente deve dichiarare quali comandi vengono eseguiti, con quale identità e con quale registrazione lato vendor.

Trappola o vantaggio competitivo

Questa architettura è una trappola finché il git history resta l'unica prova del lavoro svolto. Diventa un vantaggio competitivo quando l'organizzazione tratta la traccia di audit come un sistema esterno, replicato e firmato a ogni push.

commit-rewriter 0.1 fa esattamente quello che promette, e lo dichiara in modo trasparente. Il debito tecnico sta a monte, nella scelta di dare a un agente una shell completa su una macchina che custodisce artefatti di conformità.

La categoria di incidente che l'industria cataloga come AI coding agent security breach nasce quasi sempre così: uno strumento utile, un permesso troppo ampio, un confine mancante. Il materiale per chiudere quel confine esiste già, e il prossimo ciclo di pianificazione è il momento giusto per usarlo.