Sicurezza dei tool: permessi, allow-list, dry run

Un agente è pericoloso in proporzione ai tool che può usare. Un modello che risponde male può creare confusione. Un modello che risponde male e ha accesso a scrittura file, database, email, pagamenti o deploy può creare danni.

La sicurezza dei tool non consiste nel convincere il modello a comportarsi bene. Consiste nel progettare strumenti che rendono difficili o impossibili le azioni fuori perimetro.

Perché questa lezione conta

Nel prompting classico l’output finale è il punto di controllo. Nel tool use il punto di controllo si sposta prima: quali tool sono esposti, con quali permessi, su quali risorse, con quali parametri e con quali conferme.

Un buon tool design riduce l’impatto degli errori del modello. Un cattivo tool design richiede al modello di essere sempre prudente, preciso e resistente a input ostili. Non è un’ipotesi solida.

Obiettivo operativo

Alla fine della lezione devi saper classificare i tool per rischio, disegnare permessi minimi, usare allow-list e dry run, e decidere dove serve conferma umana.

Classificazione dei tool

Una classificazione pratica:

Read-only. Legge dati senza modificarli: cercare documenti, leggere stato build, listare file. Rischio principale: esposizione dati.

Write reversibile. Modifica stato ma con rollback semplice: creare bozza, aprire issue, scrivere file in branch, aggiornare record non pubblicato.

Write irreversibile o pubblico. Invia email, pubblica contenuti, cancella dati, modifica permessi, fa deploy, esegue pagamenti.

Tool generico ad alto potere. Shell, SQL libero, HTTP generico, browser automation, file write senza limiti. Sono comodi, ma vanno confinati.

Ogni tool deve avere un livello di rischio dichiarato. Senza classificazione, non puoi applicare policy coerenti.

Permessi minimi

Il tool deve fare solo ciò che serve al task. Se un agente deve cercare ticket, non gli serve modificare ticket. Se deve generare una bozza email, non gli serve inviarla.

Esempio di design più sicuro:

Meno sicuro:
- tool: execute_sql(query)

Piu sicuro:
- tool: find_customer_by_email(email)
- tool: list_open_invoices(customer_id)
- tool: create_refund_request(invoice_id, reason)

Il secondo design limita il linguaggio d’azione. Il modello non può inventare query arbitrarie.

Allow-list e deny-list

Le allow-list sono preferibili alle deny-list. È più facile dire cosa è consentito che prevedere tutto ciò che è vietato.

Esempi:

1. domini HTTP raggiungibili;
2. directory leggibili;
3. file modificabili;
4. comandi eseguibili;
5. tipi di record modificabili;
6. destinatari email ammessi;
7. modelli utilizzabili per un task.

Una deny-list può essere utile come strato aggiuntivo, ma non deve essere l’unico controllo. Se vieti rm -rf, restano molti altri modi di cancellare o sovrascrivere.

Validazione parametri

Non basta che il modello produca JSON valido. I parametri devono essere coerenti con policy e dominio.

Controlla:

1. campi obbligatori;
2. enum validi;
3. lunghezze massime;
4. path dentro directory consentite;
5. URL su domini ammessi;
6. importi entro soglia;
7. destinatari autorizzati;
8. assenza di segreti nell’output.

Il tool deve rifiutare input non valido e restituire un errore comprensibile.

Dry run

Il dry run mostra cosa succederebbe senza eseguire l’azione. È essenziale quando l’azione è sensibile ma valutabile prima.

Esempi:

deploy --dry-run
send_email(draft=true)
apply_patch(preview=true)
create_refund(status="pending_review")

Un buon dry run produce un diff, una bozza o un piano con parametri finali. Non deve limitarsi a dire “ok”.

Conferma umana

La conferma va richiesta quando il rischio supera una soglia. Deve contenere:

1. azione;
2. risorse coinvolte;
3. parametri;
4. effetto atteso;
5. rischio;
6. rollback o irreversibilità.

Esempio:

Conferma richiesta:
- Azione: invio email a 128 utenti.
- Fonte destinatari: segmento beta.
- Oggetto: aggiornamento termini.
- Irreversibile: si, dopo invio.
- Anteprima disponibile: si.

Questo permette una decisione reale.

Laboratorio guidato

Scegli un tool rischioso: scrittura file, invio email, query database, deploy, modifica ticket.

Riscrivilo in tre versioni:

1. versione ingenua e troppo potente;
2. versione con parametri vincolati;
3. versione con allow-list, dry run e conferma.

Poi crea cinque input ostili o sbagliati e verifica se la versione sicura rifiuta l’azione.

Output atteso

Devi produrre una matrice permessi/azioni:

tool | rischio | risorse ammesse | validazioni | dry run | conferma | rollback

Questa matrice deve vivere vicino al catalogo dei tool, non in un documento separato che nessuno legge.

Errori comuni

Esporre shell o SQL libero troppo presto. Sono strumenti potenti, ma richiedono sandbox, allow-list e audit severi.

Usare solo il prompt come barriera. Il modello può sbagliare o essere manipolato. Il tool deve rifiutare.

Dry run non verificabile. Se non mostra diff o parametri, non aiuta a decidere.

Conferma senza contesto. Un bottone “approva” senza dettagli è solo attrito.

Checklist di verifica

• ogni tool ha un livello di rischio;
• i permessi sono minimi rispetto al task;
• esistono allow-list per risorse critiche;
• input e parametri sono validati nel codice;
• dry run e conferma sono presenti nei punti di rischio.

Collegamenti

• Modulo: Agenti, tool use, integrazione — questa lezione è la numero 34 del corso.
• Riprende le minacce di prompt injection viste nella lezione 28.