Sicurezza degli agenti AI: chiavi API, sandbox e limiti

La sicurezza degli agenti AI si riduce a tre cose: l’agente vede solo ciò che gli serve, le chiavi API non stanno dove l’agente (o un attaccante) può leggerle, e ogni chiave ha un limite di spesa. Ecco cinque passi che possiamo completare in un pomeriggio: permessi, sandbox, ordine nelle chiavi, limiti e scansione dei repository.

Perché la sicurezza degli agenti AI è diventata urgente?

Le ultime settimane hanno offerto esempi in abbondanza. Dopo la violazione di OpenCode, alcuni utenti hanno mostrato bollette per l’uso altrui delle loro chiavi. Nell’attacco hacker con l’IA a oltre 100 aziende, gli agenti sono entrati quasi senza intervento umano, e sui pannelli Cairn esposti c’erano centinaia di segreti. In più, la fuga di dati di Meta Muse ha mostrato che perfino una funzione «condividi chat» può rivelare più di quanto sembri.

Il 21 ottobre è arrivato un altro caso: secondo SafeDep, la versione 1.107.0 della popolare libreria LiteLLM è finita su PyPI con uno stealer che raccoglieva, tra l’altro, chiavi SSH, credenziali cloud, segreti CI/CD e chiavi dei fornitori di LLM, oltre a una backdoor. Gli attaccanti avevano le credenziali GitHub CLI di tre sviluppatori. PyPI ha rimosso quella versione il giorno stesso; la 1.106.2, tra le altre, è pulita.

Un agente si distingue da una chat perché compie azioni: legge file, esegue comandi, visita pagine web. OWASP descrive due rischi principali:

1. Prompt injection. Secondo OWASP, nella variante indiretta il modello accetta istruzioni «from external sources, such as websites or files». Basta un README o una pagina con un’istruzione nascosta perché l’agente faccia qualcosa che non gli abbiamo mai chiesto.
2. Eccessiva autonomia («excessive agency»). OWASP indica tre cause: troppe funzioni, troppi permessi e troppa autonomia. Nell’anteprima della lista 2026 questo rischio è salito al terzo posto.

OWASP cura anche una Top 10 separata per le applicazioni agentiche, dove il primo posto spetta ad «Agent Goal Hijack», cioè il dirottamento dell’obiettivo dell’agente.

La regola d’oro di entrambe le liste è la stessa: i permessi minimi sufficienti per il compito e l’approvazione di una persona per le azioni rischiose.

Passo 1: come impostare i permessi in Claude Code?

Lo mostro su Claude Code (l’ho spiegato da zero nella mia guida a Claude Code), ma la stessa logica vale per gli altri harness per agenti.

I permessi si impostano in settings.json come regole allow, ask e deny. Secondo la documentazione l’ordine è fisso: «deny, then ask, then allow», quindi il rifiuto vince sempre. Per cominciare, blocchiamo l’accesso ai segreti. Questo esempio viene direttamente dal riferimento delle impostazioni:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

Attenzione: le regole deny hanno dei limiti, e la documentazione li dichiara apertamente:

1. Non si applicano ai comandi che leggono file senza nominarli, come grep -r pattern ., né a sottoprocessi arbitrari.
2. Bash(curl *) corrisponde al comando alla lettera, quindi non fermerà /usr/bin/curl né sh -c 'curl …'.
3. Un file .claudeignore non ha alcun effetto; le sue voci vanno spostate in regole Read dentro deny.

Per questo le regole sono il primo livello, non tutta la protezione. I permessi attuali si controllano con il comando /permissions.

La seconda cosa è la modalità di lavoro. Claude Code ha le modalità default, acceptEdits, plan, auto, dontAsk e bypassPermissions. Sull’ultima la documentazione scrive: «Only use this mode in isolated environments like containers or VMs». Su un computer condiviso possiamo disattivarla del tutto impostando permissions.disableBypassPermissionsMode su "disable".

Passo 2: come attivare la sandbox?

La sandbox è un confine sorvegliato dal sistema operativo stesso, quindi funziona dove le regole deny non arrivano. Secondo la documentazione della sandbox è disattivata per impostazione predefinita. La attiviamo con un comando nella sessione:

/sandbox

oppure impostando sandbox.enabled su true in ~/.claude/settings.json. Su macOS funziona subito, su Linux e WSL2 servono due pacchetti:

sudo apt-get install bubblewrap socat

Su Windows senza WSL2 la sandbox non c’è e i comandi girano senza isolamento.

Cosa offre la sandbox una volta attivata:

1. I comandi scrivono solo nella directory di lavoro e nei file temporanei.
2. Il traffico di rete passa da un proxy locale, e l’elenco dei domini consentiti (network.allowedDomains) all’inizio è vuoto.
3. Possono però leggere gran parte del disco, compresi ~/.ssh e ~/.aws/credentials. Questi percorsi vanno bloccati a mano con filesystem.denyRead o con la sezione credentials, perché, come si legge, «There is no built-in credential deny list».

Due note dalla documentazione. Primo, la sandbox copre solo i comandi di shell: gli strumenti Read, Edit, Write e WebFetch, gli hook e i server MCP locali funzionano fuori da essa. Secondo, domini ampi come github.com nell’elenco dei consentiti possono aprire una strada all’esfiltrazione dei dati. Chi vuole isolare tutto in una volta dovrebbe eseguire l’intero agente in un container o in una macchina virtuale.

In Codex di OpenAI l’equivalente sono le modalità read-only, workspace-write e danger-full-access, con la rete disattivata per impostazione predefinita. Il flag --yolo (alias di --dangerously-bypass-approvals-and-sandbox) disattiva sia le approvazioni sia la sandbox, quindi teniamolo per i container.

Passo 3: dove conservare le chiavi API?

La regola più semplice: la chiave non finisce nel codice né nel repository. Anthropic consiglia di non scrivere la chiave direttamente nel codice o nei file di configurazione e di aggiungere i file .env a .gitignore. OpenAI suggerisce di passare le chiavi tramite variabili d’ambiente o un gestore di segreti e di ruotarle regolarmente.

In pratica:

1. Chiavi separate per sviluppo, test e produzione (anche questo è tra i consigli di Anthropic). Così una fuga non manda giù tutto.
2. La chiave per l’agente è una chiave a parte con un proprio limite, non la nostra principale.
3. Dopo una fuga revochiamo subito la chiave, e solo dopo cerchiamo la causa.

Curiosità: GitHub intercetta da solo una parte delle fughe. Se una chiave Claude finisce in un repository pubblico, GitHub avvisa Anthropic, che disattiva la chiave automaticamente.

Passo 4: come impostare i limiti di spesa?

Un limite non ferma la fuga, ma contiene la bolletta quando la chiave finisce nelle mani sbagliate.

1. Anthropic. Nella Claude Console andiamo alla pagina Billing (platform.claude.com/settings/billing) e, nella sezione Spend limits, clicchiamo su Adjust limit o Set limit. I limiti si possono impostare anche per workspace, tranne quello predefinito.
2. OpenAI. Nelle impostazioni del progetto apriamo Limits, impostiamo un Monthly spend limit e attiviamo Enforce a hard limit. Attenzione: gli avvisi di spesa («Spend alerts do not enforce a cap») non bloccano nulla, e il limite stesso scatta con un ritardo, quindi la spesa può superarlo di poco.

Una buona abitudine è un progetto (o workspace) per ogni agente, ciascuno con la propria chiave e il proprio limite.

Passo 5: come intercettare i segreti prima che trapelino?

Gli agenti scrivono molto codice e fanno commit volentieri, quindi conviene avere un automatismo che fermi una chiave prima del push.

1. Push protection su GitHub. Secondo la documentazione blocca i push con segreti prima che arrivino nel repository. Per gli account utente è attiva di default sui repository pubblici, mentre a livello di repository è disattivata di default e richiede GitHub Secret Protection.
2. Gitleaks in locale. Si installa con brew install gitleaks e si scansiona una directory o la cronologia di git (README):

gitleaks dir -v .
gitleaks git -v .

3. TruffleHog verifica anche se il segreto trovato funziona ancora (README). È con questo strumento che NorForge ha verificato che parte dei segreti sui pannelli Cairn era attiva:

trufflehog filesystem path/to/dir

A cosa fare attenzione con i server MCP?

Un server MCP è codice che gira con i nostri permessi. La documentazione di Claude Code consiglia di scrivere server propri o di usare solo quelli di fornitori affidabili, e precisa che Anthropic non verifica i server MCP.

Le best practice di sicurezza MCP (versione bozza della specifica) aggiungono alcuni dettagli concreti:

1. Il client dovrebbe mostrare il comando completo che avvia un server locale, senza troncarlo. L’esempio di attacco della specifica è un innocuo npx dietro cui si nasconde un curl che invia ~/.ssh/id_rsa a un server estraneo.
2. I server locali è meglio eseguirli in una sandbox con permessi minimi e tramite il trasporto stdio.
3. Un server non deve accettare token che non sono stati emessi per lui (il cosiddetto «token passthrough» è vietato).
4. I permessi OAuth si concedono gradualmente, senza ambiti ampi come *, all o full-access.

FAQ

Le regole deny di Claude Code bastano a proteggere un file .env?

Non del tutto. Bloccano gli strumenti integrati e i comandi riconosciuti come cat, ma non grep -r né sottoprocessi arbitrari. La protezione completa a livello di sistema arriva solo con la sandbox e filesystem.denyRead.

Cosa fare se una chiave API è trapelata?

Revocarla subito nel pannello del fornitore, generarne una nuova, sostituirla in tutte le applicazioni e controllare il consumo recente dell’account. Maggiori dettagli nell’articolo sulla violazione di OpenCode.

Cos’è la prompt injection negli agenti AI?

Sono istruzioni nascoste nei contenuti che l’agente legge (pagine, file, email). L’agente può eseguirle come se fossero nostre. Per questo le azioni rischiose dovrebbero richiedere la nostra approvazione e l’agente non dovrebbe avere accesso ai segreti.

La sandbox funziona su Windows?

In Claude Code solo tramite WSL2. Su Windows nativo i comandi girano senza sandbox.