Indice dei contenuti
Gli agenti AI per lo sviluppo possono leggere file, modificare codice, lanciare comandi e, in alcuni casi, interagire con servizi esterni. È proprio questa capacità operativa a renderli utili — e a rendere importante una domanda spesso trascurata: quali permessi dovremmo concedere loro?
Un agente che lavora su un repository non dovrebbe avere automaticamente accesso all’intero disco, alle chiavi SSH, ai token cloud o ai documenti personali. Il principio è lo stesso che applichiamo agli account umani e ai servizi: concedere soltanto i permessi necessari per svolgere il compito.
Un agente non si limita a suggerire codice 🧠
Un completatore di codice propone una riga o una funzione. Un agente, invece, può ricevere un obiettivo e svolgere una sequenza di azioni: analizzare file, modificare più componenti, eseguire test e usare strumenti configurati nel proprio ambiente.
Questo aumenta la produttività, ma introduce anche rischi operativi. Un comando eseguito nel contesto sbagliato può cancellare file, modificare configurazioni, installare dipendenze non desiderate o esporre informazioni contenute nell’ambiente. Le linee guida OWASP raccomandano di eseguire gli agenti in ambienti isolati, usare allowlist di comandi e impedire l’accesso a credenziali e directory sensibili.
Il rischio dei permessi troppo ampi ⚠️
Immagina di chiedere a un agente di aggiornare una funzione in un piccolo progetto. Se però l’editor è aperto sulla tua cartella personale e l’agente può eseguire comandi senza restrizioni, il suo perimetro potenziale potrebbe comprendere molto più del repository.
Tra gli elementi che è meglio tenere fuori dalla portata ordinaria dell’agente ci sono:
- chiavi SSH e credenziali salvate sul computer;
- token di produzione e file contenenti segreti;
- configurazioni di cloud CLI o strumenti di deployment;
- documenti personali non necessari al progetto;
- directory di sistema o altri repository non coinvolti nel task.
Anche un modello che gira in locale non elimina questo problema: la privacy del modello e i permessi dell’agente sono questioni diverse. Un’inferenza locale può evitare di inviare il prompt a un servizio esterno, ma un agente con accesso troppo ampio può comunque modificare file o usare credenziali presenti sulla macchina.
Isolare il lavoro: VM, container o dev container 🧱
Una misura pratica è fare lavorare l’agente in un ambiente dedicato: una macchina virtuale, un container di sviluppo o una sandbox effimera. L’obiettivo non è creare una barriera magica, ma limitare il danno possibile se un comando o una modifica non vanno come previsto.
Un ambiente di sviluppo isolato può contenere:
- solo il repository necessario;
- dipendenze e strumenti specifici del progetto;
- credenziali di sviluppo separate da quelle di produzione;
- accesso di rete limitato a ciò che serve;
- snapshot o procedure rapide di ripristino.
Se l’agente deve solo analizzare il codice, inizia con permessi di lettura. Abilita scrittura o esecuzione dei comandi solo quando il task lo richiede. OWASP consiglia proprio ambienti sandboxed, shell ristrette e accesso circoscritto ai file pertinenti.
Una regola semplice: sviluppo non è produzione 🔑
Uno degli errori più rischiosi è riutilizzare nell’ambiente di sviluppo le stesse credenziali che permettono di operare sui sistemi reali. Se un token di produzione finisce in un file letto dall’agente, in un log o in un prompt, l’impatto può essere molto più serio di un bug nel codice.
Per ridurre il rischio:
- usa credenziali separate per sviluppo, staging e produzione;
- assegna ai token i privilegi minimi indispensabili;
- evita di conservare segreti in chiaro nel repository;
- non concedere accesso amministrativo a un agente per comodità;
- revoca o ruota le credenziali quando non servono più.
Le buone pratiche per gli agenti raccomandano di usare identità separate e con scope limitato, invece di delegare loro i privilegi completi dell’utente.
Allowlist, conferme e revisione delle modifiche ✅
Non tutte le azioni hanno lo stesso livello di rischio. Leggere un file è diverso dal cancellare una directory; eseguire un test è diverso dal lanciare uno script di deployment. Quando possibile, configura l’agente perché possa usare soltanto i comandi necessari e richieda conferma per le operazioni più delicate.
Prima di accettare un cambiamento, controlla sempre il diff. Verifica almeno:
- quali file sono stati creati, modificati o rimossi;
- se sono comparse nuove dipendenze;
- se sono stati introdotti URL, telemetria o chiamate di rete inattese;
- se il codice contiene credenziali, chiavi o configurazioni sensibili;
- se i test coprono i casi importanti.
La revisione umana resta una parte essenziale del flusso. L’agente può accelerare il lavoro, ma non conosce automaticamente il contesto operativo, i vincoli dell’organizzazione o le conseguenze di una modifica.
Non fidarsi ciecamente dei file di istruzioni 📄
Repository e documentazione possono contenere istruzioni, commenti o testi provenienti da fonti esterne. Un agente potrebbe interpretarli come indicazioni operative, quindi è importante distinguere tra contenuto da analizzare e istruzioni a cui concedere autorità.
Non inserire nei file di progetto direttive che assegnino accessi eccessivi solo per rendere il workflow più comodo. Mantieni le autorizzazioni nei controlli dello strumento, applica limiti chiari e considera non attendibili le istruzioni incorporate in contenuti non verificati.
Una checklist prima di avviare l’agente 🧾
- Il progetto è aperto in una directory isolata?
- L’agente può vedere solo i file necessari?
- Le credenziali di produzione sono assenti?
- I comandi disponibili sono limitati al necessario?
- Le operazioni distruttive richiedono conferma?
- Esiste un commit o uno snapshot da cui ripartire?
- È previsto un controllo del diff prima di integrare le modifiche?
Produttività sì, ma con un perimetro 🛡️
Gli agenti AI possono essere collaboratori molto efficaci, soprattutto quando ricevono un obiettivo chiaro e un ambiente ordinato. Non hanno però bisogno di conoscere tutto il computer per essere utili.
Isolare il repository, ridurre i permessi, proteggere le credenziali e controllare le modifiche non rallenta il lavoro: evita che un esperimento di sviluppo diventi un incidente. La fiducia migliore, anche con l’AI, è quella accompagnata da limiti verificabili 🙂