Una chiave API rubata non espone soltanto un account: può trasformarsi subito in richieste a pagamento eseguite da altri. Il caso OpenCode del 19 ottobre 2026 lo rende concreto: secondo quanto comunicato dall’azienda e riportato da TechCrunch, l’incidente ha coinvolto l’1,4% degli utenti di OpenCode Console, dove alcuni utenti conservavano credenziali di provider AI. Per una PMI, la lezione non è “evita gli agenti”, ma riduci in anticipo il danno massimo che ogni agente può causare.

Il problema è la chiave condivisa

Molti workflow partono con una scorciatoia: si crea una chiave del provider, la si copia nel tool AI e la si riusa per più progetti. Funziona, ma rende impossibile capire rapidamente quale integrazione abbia generato il traffico anomalo. Peggio: se la stessa credenziale finanzia produzione, test e automazioni interne, una sola compromissione allarga il raggio d’impatto a tutto il conto.

La regola pratica è semplice: una chiave per applicazione e per ambiente, mai una chiave “aziendale” usata ovunque. Se il provider supporta progetti separati, crea un progetto dedicato all’agente, assegna soltanto i modelli necessari e mantieni distinta la fatturazione. È lo stesso principio raccomandato da OWASP per la gestione dei secret: privilegi minimi, credenziali revocabili e visibilità su chi le utilizza. Separare le chiavi non impedisce l’incidente, ma permette di spegnere una sola integrazione senza fermare tutto il lavoro.

Imposta il danno massimo prima del test

Una dashboard che mostra la spesa non è un controllo sufficiente: quando la guardi, il consumo è già avvenuto. Prima di collegare un agente, verifica quali limiti offre davvero il provider. Distingui un avviso di budget da un blocco rigido: il primo manda una notifica, il secondo impedisce nuove richieste. Se esiste soltanto l’avviso, aggiungi un circuito applicativo che interrompa il workflow al superamento di una soglia giornaliera o di un numero massimo di chiamate.

Per ogni chiave registra quattro dati: proprietario, progetto, limite previsto e procedura di revoca. Poi attiva alert progressivi, per esempio quando il consumo devia dal profilo normale, senza aspettare la fine del mese. OpenAI documenta limiti distinti a livello di organizzazione e progetto; la pagina Usage Limits va quindi controllata per capire dove si applica il tetto. Per workflow più articolati, il pattern del circuit breaker per le API AI aggiunge un arresto controllato vicino all’applicazione.

Ruota la chiave senza perdere le tracce

Quando arriva un avviso di sicurezza, cancellare la configurazione locale non basta: una chiave copiata può continuare a funzionare finché il provider non la revoca. La sequenza corretta è revocare la credenziale dal pannello del provider, crearne una nuova con permessi minimi, aggiornare il solo servizio interessato e controllare i log d’uso dal momento dell’ultima attività nota. Infine verifica fatture, metodi di pagamento e richieste provenienti da modelli o regioni insolite.

La rotazione deve essere provata prima dell’emergenza. Conserva i secret in un gestore dedicato, non nel repository, nelle chat o in file condivisi, e documenta quale automazione smetterà di funzionare quando la chiave cambia. Le segnalazioni pubbliche nel repository OpenCode mostrano anche utenti alle prese con chiavi revocate e credenziali locali rimaste obsolete: è un promemoria utile, ma non una ragione per eseguire comandi trovati in una discussione senza verificarne l’effetto. Se un agente può inviare o pubblicare contenuti, abbina alla rotazione anche un outbox con approvazione umana.

Il controllo minimo da fare oggi

Apri l’inventario dei tool AI che usano API esterne e scegli quello con più autonomia. Se non sai quale chiave utilizza, chi la possiede e quanto può spendere, hai già trovato il primo intervento. Crea una credenziale dedicata, applica il limite più stretto compatibile con il lavoro e prova la revoca in un momento controllato. Poi ripeti il controllo sulle integrazioni che possono scrivere file, inviare messaggi o effettuare pubblicazioni.

L’errore da evitare è affidarsi a una sola difesa, per esempio la segretezza della chiave. Un secret può finire in un log, in un backup o in un servizio compromesso. Separazione, limite di spesa, monitoraggio e revoca rapida servono insieme. Il take finale è operativo: non chiederti soltanto se l’agente è affidabile; stabilisci quanto può costarti il suo account nel caso peggiore e rendi quel valore tecnicamente verificabile prima di collegarlo alla produzione. Fonti: TechCrunch sul caso OpenCode, segnalazioni pubbliche nel repository OpenCode e OWASP Secrets Management Cheat Sheet.