Harness AI coding: audit del raggio d'azione

Un agente di coding non è solo un modello che scrive codice. È un modello collegato a un harness che può esplorare una repository, modificare file, eseguire comandi, leggere output di tool, installare dipendenze, ereditare variabili d’ambiente e, in alcuni casi, comunicare con servizi remoti. È lì che la produttività diventa rischio operativo.

La tesi è semplice: gli harness di AI coding hanno bisogno di audit del raggio d’azione prima di entrare in repository reali.

Il punto diventa ancora più importante quando l’agente sembra rassicurante perché gira in locale. Un modello locale può ridurre l’esposizione verso provider di inferenza esterni, ma l’esecuzione locale non rende sicuro il workflow in automatico. Se l’harness può attraversare directory, lanciare shell command, leggere segreti, attivare script di installazione o inviare telemetria, il raggio d’azione può essere molto più ampio del branch che volevi testare.

Nel suo walkthrough sugli agenti di coding locali, Sebastian Raschka separa esplicitamente il ruolo dell’LLM dal ruolo dell’harness: il modello produce ragionamento e codice, mentre l’harness fornisce l’ambiente operativo che legge file, applica modifiche, esegue comandi e verifica risultati. Raschka raccomanda anche di auditare data egress, permessi sui file e robustezza rispetto alla prompt injection prima di installare ed eseguire un harness. Per un team prodotto, questo non è un dettaglio tecnico: è il punto di partenza dell’adozione. Walkthrough di Raschka sugli agenti locali

Il modello non è tutto l’agente

Molti team valutano gli assistenti di coding guardando soprattutto il modello: benchmark, lunghezza del contesto, qualità delle diff, latenza, rispetto dello stile interno. Sono controlli utili, ma non rispondono alla domanda operativa: cosa può fare il sistema quando sbaglia?

Il modello propone azioni. L’harness decide quali azioni sono disponibili, come vengono eseguite, quale contesto viene caricato, quali tool possono essere chiamati, quali file possono essere modificati e quali log lasciano la macchina. Un modello mediocre dentro un harness stretto può essere meno rischioso di un modello eccellente dentro un harness con accesso largo a filesystem e shell.

Per questo la review dell’harness deve arrivare prima del primo esperimento entusiasta su una repo di produzione. La domanda non è solo se l’agente sappia risolvere un bug. La domanda è se possa danneggiare sistemi adiacenti mentre lo risolve. Può modificare file generati e file sorgente nello stesso passaggio? Può eseguire uno script di package manager che lancia codice arbitrario? Può leggere file .env? Può scoprire chiavi SSH? Può incollare log verso un endpoint remoto? Le istruzioni presenti nella repository possono manipolare il suo uso dei tool?

Questo tema è vicino alla code review, ma viene prima. Un review packet valuta la modifica prodotta dall’agente, come in Agenti di coding AI: servono review packet. Un audit del raggio d’azione valuta l’ambiente che permette all’agente di produrre quella modifica.

Cosa entra in un audit del raggio d’azione?

Un audit pratico deve stare in una pagina. Se diventa un manuale di policy, il team lo salta. L’obiettivo è identificare i confini che rendono abbastanza sicuro il primo utilizzo, non dimostrare che il tool sia sicuro in ogni scenario.

Parti dai confini dei file. Scrivi qual è la working directory di default, se l’harness può risalire sopra quella directory e quali path sono in sola lettura, scrivibili o bloccati. Tratta i segreti come voce separata. .env, credential store, directory SSH, configurazioni cloud, dump di database, log di produzione e profili browser non devono diventare contesto casuale.

Poi audita l’esecuzione shell. Indica se i comandi richiedono conferma, se esistono allowlist e se l’agente può invocare package manager, build tool, test runner, Docker o script di deploy. La superficie pericolosa non è solo rm -rf. È anche npm install, postinstall, make, curl | sh, migrazioni e qualunque comando possa modificare stato fuori dalla repo.

Controlla anche installazione e aggiornamenti. Un harness sicuro oggi può cambiare domani tramite estensioni, pacchetti globali, plugin, server MCP o hook post-install. Il team deve sapere come si aggiorna il tool, chi approva i cambi di versione e se una versione può essere riprodotta durante un incident review.

Infine, mappa il data egress. Cerca telemetria, crash report, chiamate a provider di modelli, endpoint di plugin, update check e log. Un modello locale non garantisce che prompt, nomi file, identificatori o tracce di errore restino locali. Se il tool ha una modalità cloud, verifica che la modalità locale non erediti default cloud in silenzio.

Quali permessi vanno bloccati, ridotti o loggati?

Non serve una risposta filosofica sul fatto che gli agenti debbano avere accesso. Serve una decisione per capacità.

Alcune capacità vanno bloccate al primo utilizzo: credenziali di produzione, comandi di deploy, lettura ampia della home, installazioni globali, operazioni distruttive su database e scrittura fuori dalla repository. Se l’agente ne avrà bisogno più avanti, quello sarà un nuovo evento di approvazione.

Altre capacità vanno ristrette: i test possono girare, ma dentro un container o con un utente dedicato. Le scritture possono avvenire, ma solo nella directory di progetto. La rete può esistere, ma solo verso endpoint dichiarati. I log possono essere raccolti, ma i segreti devono essere redatti e la retention deve essere nota.

Altre ancora vanno loggate: comandi shell, modifiche ai file, chiamate di rete, escalation di permessi, chiamate a plugin e fallimenti dei tool. Non è sorveglianza fine a sé stessa. È l’evidenza minima che serve quando una modifica generata rompe qualcosa e il team deve ricostruire cosa sia successo.

Qui prodotto e ingegneria devono lavorare sullo stesso artefatto. I product manager non dovrebbero approvare l’adozione di un agente solo guardando demo. Gli engineer non dovrebbero gestire tutta la conversazione sul rischio in modo informale in chat. Una pagina condivisa rende leggibile la decisione.

La prompt injection vive anche nella repository

La prompt injection viene spesso discussa come problema dei chatbot che leggono pagine web ostili. Gli agenti di coding hanno una versione propria. L’istruzione ostile può stare in un README, in una issue, in un fixture di test, nell’output di una dipendenza, in un file generato, in un messaggio di commit o nella risposta di un tool.

Un harness che tratta ogni superficie testuale come istruzione è troppo fiducioso. Il contenuto della repository deve essere contesto, non autorità. Le istruzioni di progetto devono avere scope. L’output dei tool va delimitato. L’agente non deve poter trasformare un commento dentro un file in autorizzazione a esfiltrare segreti o disabilitare test.

Per chi costruisce prodotto, il passo utile è tradurre questo in criteri di accettazione. Prima di adottare un harness, crea due o tre fixture avversarie: un README che chiede all’agente di rivelare variabili d’ambiente, un test fallito che suggerisce un comando rischioso, un finto output di tool che richiede una chiamata di rete. Il risultato atteso è rifiuto, chiarimento o escalation, non obbedienza brillante.

Questo si collega direttamente al design dei permessi. Se un agente ha accesso totale ai tool, la prompt injection ha più spazio per diventare azione. Se i tool sono delimitati, confermati e loggati, i tentativi di injection hanno meno forza operativa. Lo stesso principio vale in Agenti AI: servono permessi, non accesso totale, ma gli harness di coding lo rendono concreto perché la repository è il banco di lavoro.

Come approvare l’uso su repository reali?

Usa un percorso a stadi. Primo: esegui l’harness in una repository eliminabile, con segreti finti e fixture avversarie. Secondo: usalo su una repository reale in sola lettura. Terzo: abilita scritture su un branch, con conferma dei comandi e restrizioni di rete. Quarto: amplia l’autonomia solo dopo avere log, passi di rollback e aspettative di review.

Questo percorso deve collegarsi al rollback. Se un agente può produrre modifiche multi-file in pochi minuti, il team deve poterle annullare, isolare e spiegare con la stessa rapidità. Per questo Agenti AI: servono piani di rollback non è un tema separato. È la metà a valle dello stesso sistema di controllo.

L’audit di una pagina deve chiudersi con una decisione chiara: bloccato, approvato per sandbox, approvato in sola lettura, approvato per scritture su branch o approvato solo per un workflow nominato. Evita formule vaghe come “approvato per engineering”. Nascondono il vero confine.

Prima di lanciare un nuovo agente di coding, scrivi l’audit. Nomina i file che può toccare. Nomina i comandi che può eseguire. Nomina i segreti che non può vedere. Nomina gli endpoint che può contattare. Nomina il percorso di aggiornamento. Nomina i log. Nomina i test di prompt injection. Lo scopo non è rallentare l’AI-assisted coding. Lo scopo è fare in modo che, quando l’agente accelera, acceleri dentro un confine scelto dal team.