
Sicurezza con l'AI: il playbook in 3 regole
Collegare strumenti, installare skill, gestire le chiavi. Tre regole e i prompt esatti per far agire l'AI nel tuo business senza farti male.
Dai all'AI il potere di agire. Con criterio.
Quando colleghi uno strumento all'AI, quella AI non si limita a leggere: può inviare, cancellare, condividere, spendere. Non è un motivo per non usarla — è il motivo per configurarla bene una volta, e poi delegare tranquilla.
Prima cosa: i permessi dei connettori
Quasi tutti danno all'AI accesso totale senza accorgersene. La mossa giusta è decidere azione per azione, non tutto-o-niente. Tre livelli:
- ✓ Consenti sempre — azioni sicure di ogni giorno: leggere un file, cercare nella posta. Nessuna conferma.
- ? Chiedi ogni volta — azioni che modificano, inviano o condividono. Un clic di verifica in più, e dormi sereno.
- ✕ Blocca sempre — ciò che non deve succedere mai: cancellare file, spendere denaro. Vietato a priori.
Esempio reale
Lettura Google Drive → consenti sempre. Cancellazione file → blocca sempre. Bozza email → consenti sempre. Invio email → chiedi ogni volta. Le imposti in Impostazioni → Connettori, entri nel singolo connettore (Gmail, Drive) e regoli un permesso alla volta.
Regola 1 · Controlla una skill prima di installarla 30 secondi
Una skill che scarichi può contenere script che si eseguono: è come aprire un file a caso arrivato via email. Prima di installarla, falla leggere all'AI in una chat normale (non in Claude Code): la ispezioni senza eseguirla.
Incolla in chat, col codice della skill ↓
Sto per installare questa come skill, ma l'ho presa da una fonte di cui non mi fido del tutto. Prima di farlo, esamina ogni file e ogni riga — il file SKILL.md e qualsiasi script incluso — e dimmi in parole semplici se qualcosa sembra pericoloso. Segnala tutto ciò che prova ad accedere ai miei file, a inviare dati da qualche parte, a eseguire comandi nascosti, a prendere le mie password o le mie chiavi API, o a fare qualcosa che non corrisponde a ciò che la skill dichiara. Se è pulita, dimmelo. Se c'è qualcosa che non va, cita la riga esatta e spiegami perché.
Onestà
Questo intercetta in fretta i segnali d'allarme ovvi, ma è una prima linea di difesa, non una garanzia. Quando puoi, usa solo skill da fonti di cui ti fidi davvero.
Regola 2 · Non far trapelare le tue chiavi: il file .env
L'anno scorso sono state esposte 29 milioni di chiavi segrete su GitHub, e chi le cerca le trova in circa cinque minuti. La soluzione è un file .env: un file privato che tiene le credenziali sensibili fuori dal codice.
Il prompt completo ↓
Configura un file .env per questo progetto nel modo giusto e mettilo alla prova da ogni angolazione. Prima, scansiona tutto il mio codice alla ricerca di qualsiasi segreto in chiaro: chiavi API, token di accesso, password, URL di database, stringhe di connessione, webhook secret, qualsiasi cosa sensibile. Per ognuno che trovi, crea un file .env se non esiste, sposta il segreto dentro come NOME=valore su una riga a sé con un nome chiaro, e sostituisci il valore scritto nel codice con un riferimento a quella variabile d'ambiente, così tutto continua a funzionare come prima. Poi crea un file .env.example con gli stessi nomi ma valori vuoti, così posso condividere il progetto senza esporre un solo segreto reale. Assicurati che .env sia nel .gitignore, e crealo se non c'è. Poi controlla la cronologia git per vedere se qualcuno di questi segreti è già stato committato: se sì, dimmi quali e in quale file, e ricordami di rigenerare quella chiave alla fonte, perché aggiungere .env ora non annulla ciò che è già pubblico. Soprattutto, tienilo come regola fissa: ogni volta che collego un nuovo tool, API, database o servizio, o incollo una nuova chiave, spostala automaticamente in .env e richiamala da lì. Alla fine, conferma che l'app funziona ancora e dammi il riepilogo di ogni segreto spostato e di ciò che devo rigenerare.
Attenzione
Se le credenziali erano già state pubblicate su GitHub, il file .env non le rende retroattivamente sicure: vanno rigenerate alla fonte.
Regola 3 · Metti i guardrail prima di collegare un tool
Collegare uno strumento non serve solo a leggere: abilita azioni — inviare, cancellare, condividere. Quindi i limiti si mettono prima. Con Gmail, per esempio, le mie regole sono due: l'AI scrive solo la bozza, non invia; e non cancella mai nulla.
Con un tool nuovo, che conosci meno, non sai quali guardrail servano. Per questo uso un solo prompt che me li fa dire prima di collegare.
Il prompt dei guardrail ↓
Sto per collegarti [NOME TOOL]. Prima di farlo, aiutami a impostare i guardrail giusti. Per prima cosa, dimmi tutto ciò che potrai fare una volta connesso, soprattutto se invii, cancelli, condividi, modifichi o spendi denaro, così capisco i rischi reali. Poi consigliami una serie di regole ferree su cosa puoi e non puoi fare, scegliendo sempre l'opzione più sicura, come scrivere una bozza invece di inviare e non cancellare mai. Avvisami anche se questo tool può contenere istruzioni nascoste da parte di altri — come email o documenti condivisi — che potrebbero spingerti ad agire senza il mio ok. Dammi i guardrail finali come una lista chiara che posso salvare.
Perché conta
Con i guardrail scritti prima, colleghi qualsiasi strumento e resti serena: l'AI lavora al posto tuo, ma dentro i binari che hai deciso tu.
Prima di chiudere
- Imposta i permessi oggi. Cinque minuti nei connettori valgono più di qualsiasi rischio evitato dopo.
- Prima i limiti, poi il collegamento. Vale per ogni tool nuovo: guardrail scritti, poi connetti.
- Le chiavi fuori dal codice, sempre. Il file .env è la differenza tra un segreto privato e uno pubblico.
Claude e gli altri strumenti citati sono di terze parti: menu e funzioni possono cambiare nel tempo — segui la logica dei passaggi.
Guida gratuita
Come faccio 6 contenuti in 1 giorno
La mia guida gratuita: sette cose che non faccio più a mano, e come rifarle stasera.
Lascia l'email e te la mando subito.
Gratis. Ti cancelli con un clic.
