Confini invece di istruzioni: come mantenere il controllo sugli agenti AI autonomi

Più gli agenti AI diventano autonomi, più spesso cerchiamo di gestirli nel modo abituale — scriviamo regole nel prompt: «non toccare questo», «lavora solo lì», «non fare mai quello». Durante l'esperimento con tre agenti paralleli ho raccolto in due giorni una viva collezione di casi in cui questo metodo si rompe — e in cui funziona un altro. La tesi dell'articolo è semplice: l'istruzione è una richiesta che l'agente esegue con una certa probabilità; il confine è una proprietà del sistema che non dipende dall'obbedienza. Finché l'agente era uno solo e lavorava sotto supervisione, la differenza sembrava stilistica. Quando gli agenti sono diventati molti, si è rivelata architetturale.

Cinque incidenti di una sola sessione

Tutti i casi seguenti sono avvenuti in un'unica sessione di lavoro su questo blog — sono documentati, e ciascuno illustra un modo diverso in cui il controllo tramite testo delude.

L'istruzione non c'era — è avvenuto un incidente. L'agente, preparandosi al proprio compito, ha eseguito git stash nella directory principale e ha portato nello stash i miei file non committati, estranei al suo compito. Nessuno ha «violato» nulla: il divieto semplicemente non esisteva. È una proprietà fondamentale delle istruzioni — vengono scritte dopo gli incidenti. Un elenco completo di ciò che l'agente non deve fare è impossibile da scrivere.

L'istruzione c'era — e non ha funzionato. Dopo il primo incidente ho aggiunto agli agenti una regola esplicita: «lavora rigorosamente nella tua directory di lavoro». Uno degli agenti ha comunque eseguito un comando git nella directory principale — semplicemente vi ha fatto riferimento tramite percorso assoluto. Non per malizia né per stupidità: il modello è probabilistico, e il rispetto di una regola testuale è anch'esso una probabilità, moltiplicata per la lunghezza del contesto e il numero di esecuzioni.

Il confine tecnico ha funzionato in silenzio. Nello stesso esperimento non si è mai verificato l'incidente più atteso — «un agente ha cambiato branch a tutti». Non perché gli agenti fossero accorti, ma perché git worktree non permette fisicamente di estrarre lo stesso branch in due copie di lavoro. La protezione è integrata nello strumento. Non serve ricordarla, non serve seguirla — c'è e basta.

L'istruzione stava dove dovrebbe stare un confine. La scoperta più sgradevole: il prod di questo blog era protetto da una riga nel prompt. Il push su master avvia l'autodeploy, e da ogni agente lo separava solo il testo «nessun git push». Ha tenuto — ma è fortuna, non controllo: il vero confine qui sono i permessi di accesso, il protected branch, un token senza diritto di scrittura. Una richiesta stava al posto di un lucchetto.

Un confine sopra l'agente stesso. Due volte durante la sessione l'ambiente di esecuzione ha fermato non gli agenti sperimentali, ma il mio assistente principale: un classificatore di permessi ha bloccato l'SSH al server di prod e la cancellazione massiva di modifiche non committate — azioni che formalmente derivavano dal compito, ma richiedevano un esplicito «sì» umano. Entrambi i blocchi erano corretti. Ed entrambi sono avvenuti sopra la «disciplina» dell'agente, che riteneva del tutto sinceramente di agire secondo il piano.

Il principio non è nuovo — nuova è solo l'entità

L'ingegneria ha imparato questa lezione molto prima degli LLM. Nel sistema produttivo Toyota il principio si chiama poka-yoke: è il dispositivo del processo a prevenire l'errore, non la vigilanza dell'esecutore. Un pezzo che può essere inserito solo dal lato giusto è più affidabile di un cartello «inserisci dal lato giusto». Nell'ingegneria delle piattaforme la stessa cosa si chiama guardrails, nella sicurezza defense in depth. Ovunque un'unica idea: non affidarti al fatto che l'esecutore abbia letto, capito e non dimenticato — fai in modo che l'azione sbagliata sia impossibile o costosa.

“L'istruzione è una richiesta. Il confine è una proprietà del sistema. Il controllo che si regge sulle richieste non è controllo, ma fortuna con effetto cumulativo.”

– la conclusione principale di due giorni di lavoro con agenti paralleli

Con gli agenti AI questo vecchio principio diventa più acuto per tre ragioni. Gli agenti sono molti — la probabilità di fallimento dell'istruzione si moltiplica per ogni esecuzione di ogni agente. Gli agenti sono veloci — tra «ha iniziato a sbagliare» e «ha finito di rompere» passano secondi, l'uomo non fa in tempo a intervenire. E gli agenti sono letterali, ma non affidabili: eseguono il testo del prompt con più diligenza di qualsiasi junior, e comunque in modo probabilistico — e il rispetto probabilistico delle regole su scala garantisce la violazione.

Come appaiono i confini in pratica

I livelli che ho costruito dopo questa sessione — dal filesystem alla verifica:

• Filesystem: a ogni agente — una propria copia di lavoro (git worktree, che Anthropic raccomanda per le sessioni parallele, in Claude Code è integrato), e a livello di OS — una sandbox: il sandboxing in Claude Code isola filesystem e rete con i primitivi nativi del sistema operativo — secondo Anthropic, questo ha ridotto le loro richieste interne di permessi dell'84%, e una prompt-injection riuscita resta rinchiusa all'interno.
• Diritti di scrittura: prod e master sono protetti da permessi, non da un prompt — protected branch, token senza diritto di push, account separati per gli agenti. Le richieste di lasciare nel prompt si possono fare, ma come secondo strato.
• Runtime: worktree non isola database, porte e container — sono condivisi tra tutte le copie. Gli agenti che avviano test e server hanno bisogno di risorse usa e getta: un database temporaneo, una porta propria, un container per agente.
• Permessi per le azioni: le operazioni irreversibili passano attraverso una conferma o un classificatore — come auto mode in Claude Code, che valuta ogni azione invece di chiedere di tutto o non chiedere di nulla. È un confine che si sposta solo con una decisione esplicita dell'uomo.
• Verifica tramite artefatti: non fidarsi dell'autoresoconto dell'agente, ma delle tracce sul disco. Il mio agente bloccato appariva funzionante nell'interfaccia; la diagnosi è arrivata dall'assenza di nuovi file nella sua copia per venti minuti. I commit nel proprio branch sono la stessa idea: un risultato che sopravvive sia al guasto sia all'ottimismo dell'agente.

Le istruzioni in questo schema non scompaiono da nessuna parte — diventano l'ultimo strato, non il primo. «Lavora nella tua directory» nel prompt è ancora utile: riduce la frequenza dei tentativi. Ma tra il tentativo e l'incidente deve esserci un confine, non una speranza.

Avvertenze oneste

Il confine non è assoluto: le sandbox vengono aggirate, i classificatori sbagliano, e le analisi pubblicate degli aggiramenti lo mostrano regolarmente. Per questo i confini si costruiscono a strati — come tutto nella sicurezza. E il confine costa più di un'istruzione all'inizio: configurare worktree, permessi e sandbox richiede ore, scrivere una riga nel prompt richiede secondi. L'asimmetria è altrove: il confine si paga una volta sola, l'istruzione si paga con la probabilità di fallimento a ogni esecuzione. Nel mio caso la configurazione dell'isolamento si è ripagata al primo riavvio dell'esperimento, che è passato senza un solo conflitto.

Conclusione

La domanda della serie è come integrare gli agenti AI nel lavoro reale senza perdere il controllo. La risposta di questo articolo: il controllo non è ciò che è scritto all'agente, ma ciò che è costruito intorno a lui. Prima di aggiungere al prompt l'ennesimo «non fare mai X», vale la pena chiedersi: si può rendere X tecnicamente impossibile? Se sì — è quello il posto giusto per gli sforzi. Il prompt chieda pure; a vietare deve essere il sistema.

Fonti e riferimenti

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — isolamento del filesystem e della rete a livello di OS; fonte della cifra dell'84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — come sono strutturati i confini di esecuzione nei prodotti agentici nel loro insieme.
• How we built Claude Code auto mode (Anthropic Engineering) — il classificatore dei permessi come confine tra «chiedere di tutto» e «non chiedere di nulla».
• Poka-Yoke (Lean Enterprise Institute) — il classico principio di prevenzione degli errori tramite il design del processo.
• git-worktree e git-stash — documentazione ufficiale di Git: la meccanica delle copie di lavoro e dello stash condiviso.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — la raccomandazione di worktree per sessioni parallele.
• Come confrontare onestamente gli LLM sul proprio codice: un esperimento con tre modelli Claude — l'articolo precedente della serie: l'esperimento in cui sono raccolti gli incidenti descritti.