Una discussione su r/LocalLLaMA parte da un caso semplice e, purtroppo, comune: un utente nota che i crediti OpenRouter (circa 70 dollari) sono stati consumati in poche ore da richieste verso modelli molto costosi che dichiara di non aver mai usato. Nei log compaiono chiamate a varianti “fast” di un modello con tariffa elevata (nell’ordine di decine di dollari per milione di token), oltre ad altri modelli premium. L’utente aveva due chiavi API associate all’account (una per sé e una per il fratello), ma l’attività sospetta risulta attribuita alla chiave che usa più spesso sul proprio computer.
Da Reddit non possiamo dedurre se si tratti di un problema della piattaforma, di una compromissione del dispositivo, di una fuga involontaria della chiave o di un errore di configurazione (ad esempio una chiave finita in un log, in una variabile d’ambiente esportata, in un repository, o in un tool di terze parti). Però il caso è utile perché mette a fuoco una tesi editoriale netta: una chiave API non è “solo una stringa”, è un mezzo di pagamento. Va gestita con la stessa disciplina con cui si gestirebbe una carta aziendale.
Cosa sappiamo (e cosa no) dal thread
Fatti riportati dall’autore del post (da considerare come dichiarazioni, non come evidenze verificate): aveva credito residuo la sera prima; il giorno dopo riceve un alert di “crediti insufficienti”; nei log vede molte richieste verso modelli premium mai usati; l’attività è associata alla sua chiave principale; ha aperto un ticket al supporto e chiede un workaround perché dipende dal servizio per lavoro.
Opinioni e ipotesi emerse nella discussione (in sintesi): la comunità suggerisce di revocare subito le chiavi e rigenerarle; di verificare possibili esposizioni accidentali (codice pubblico, screenshot, paste, log); di controllare la presenza di malware o estensioni/app compromesse; e di non concludere automaticamente che la responsabilità sia della piattaforma. Senza log e un’indagine non è possibile stabilire se la fuga sia avvenuta lato utente, in un ambiente compromesso o altrove.
Risposta rapida: le prime 30–60 minuti
Runbook di contenimento (pratico, non perfetto)
-
01
Revoca immediata delle chiavi APIDisabilita/elimina tutte le chiavi attive associate all’account, non solo quella “sospetta”. Se il servizio lo consente, crea nuove chiavi con scope e limiti più restrittivi.
-
02
Blocca la spesa: limiti e budgetImposta limiti di spesa giornalieri/mensili, alert a soglie basse e, se possibile, allowlist di modelli o tetti per modello. Se non esistono controlli nativi, valuta un proxy/gateway interno che li applichi.
-
03
Congela l’ambienteNon “ripulire” subito il PC: prima salva log locali, cronologia comandi, file di configurazione, output CI/CD. Ogni modifica può cancellare tracce utili.
-
04
Cambia password e abilita MFASe l’account supporta MFA, attivalo. Cambia password e termina sessioni attive. Questo non sostituisce la rotazione delle chiavi, ma riduce vettori di accesso all’account.
-
05
Apri ticket con dati minimi ma utiliFornisci intervallo temporale, modelli chiamati, volume stimato, e chiedi se possono: bloccare temporaneamente l’account, fornire IP/User-Agent dei chiamanti, e valutare rimborso/credito in caso di frode.
Indagine: come può “uscire” una chiave che sembra al sicuro
Nel thread emerge una convinzione frequente: “la chiave è salvata localmente, quindi non può essere stata rilasciata”. È un’ipotesi comprensibile, ma fragile. “Locale” non significa “inaccessibile”: basta un malware, un’estensione del browser, un tool di sviluppo che invia diagnostica, un backup cloud non intenzionale, o un repository Git con commit accidentale (anche se poi cancellato) per trasformare una chiave in un segreto pubblico.
Vettori comuni (probabili) vs vettori meno comuni (ma possibili)
Più comuni
- Chiave committata in un repo (pubblico o condiviso) o finita in un gist/snippet
- File .env copiato in chat, ticket, screenshot o registrazioni schermo
- Log applicativi che stampano header/variabili d’ambiente
- Tool di terze parti (UI, plugin, wrapper) che memorizza la chiave in chiaro
- Malware/infostealer che esfiltra credenziali e file di configurazione
Meno comuni ma da considerare
- Compromissione di un account collegato (email, password manager, storage sync)
- Furto di sessione (cookie/session token) e accesso al pannello per leggere/creare chiavi
- Supply-chain su pacchetti npm/pip che leggono variabili d’ambiente
- Esposizione tramite proxy/telemetria aziendale mal configurata
Obiezioni serie: “Non è colpa mia” vs “È sicuramente malware”
Nel dibattito c’è un disaccordo implicito sulla responsabilità: alcuni tendono a concludere che se compaiono chiamate a modelli premium allora “la piattaforma è stata bucata”; altri ribattono che “quasi sempre è malware o fuga lato utente”. Entrambe le posizioni, prese come certezze, sono scorrette.
Obiezione 1 (legittima): anche se la chiave è stata esfiltrata dal client, l’utente può comunque aspettarsi strumenti di mitigazione dal provider (rate limit, limiti di budget, alert granulari, possibilità di restringere i modelli, log dettagliati). Se questi controlli mancano o sono difficili da usare, il rischio operativo aumenta.
Obiezione 2 (altrettanto legittima): attribuire la colpa al provider senza evidenze (IP insoliti, pattern di accesso al pannello, incident report ufficiali) può portare a ignorare la causa reale, lasciando l’ambiente compromesso. Anche se ti rimborsano, la chiave successiva potrebbe essere rubata di nuovo.
Prevenzione: progettare l’uso delle API come se fosse produzione
Misure che riducono davvero l’impatto (anche se la chiave scappa)
- ✓Una chiave per progetto/ambiente (dev/test/prod), non una chiave “universale”
- ✓Permessi e scope minimi: se possibile, limita modelli/endpoint utilizzabili
- ✓Budget e rate limit per chiave; alert a soglie basse (es. 5–10% del budget)
- ✓Proxy interno: il client non vede la chiave del provider; usa token effimeri
- ✓Rotazione programmata delle chiavi (mensile o trimestrale) e revoca di quelle inutilizzate
- ✓Secret scanning su repo e CI (blocca commit con pattern di chiavi)
- ✓Logging sicuro: mai stampare header o variabili d’ambiente in chiaro
- ✓Separazione dei dispositivi: evita di usare la stessa chiave su più PC se non necessario
Segnali d’allarme nei log di utilizzo
| Segnale | Perché conta | Azione immediata |
|---|---|---|
| Modelli mai usati prima (soprattutto premium) | Tipico di abuso: l’attaccante massimizza il valore prima della revoca | Revoca chiavi + limiti + ticket con intervallo temporale |
| Picchi notturni o in fasce orarie insolite | Indica automazione esterna o fuso diverso | Verifica IP/UA se disponibili; attiva alert orari |
| Molte richieste piccole e continue | Può essere test di validità chiave o scraping | Rate limit per chiave; blocco temporaneo |
| Richieste da più ambienti contemporanei | Possibile condivisione involontaria o compromissione multipla | Segmenta chiavi per macchina e progetto |
Conclusione: la lezione non è “non usare OpenRouter”, ma “costruire guardrail”
La storia su Reddit non dimostra un breach specifico e non basta per attribuire responsabilità. Dimostra però qualcosa di più generale: nel mondo LLM, una chiave API equivale a un rubinetto di spesa potenzialmente molto rapido, perché i modelli premium possono consumare credito a una velocità che sorprende chi è abituato a tariffe sotto 1$/M token.
La conclusione motivata è pragmatica: la difesa migliore è ridurre il “blast radius”. Anche se sei convinto di non aver mai esposto la chiave, progetta il sistema come se potesse accadere domani: chiavi separate, limiti, alert, proxy, rotazione, e un runbook pronto. È meno spettacolare di cercare il colpevole, ma è ciò che evita che un incidente da 70$ diventi un problema ricorrente — o molto più costoso.
Domande frequenti
Devo revocare solo la chiave che vedo nei log o tutte?
In un incidente di spesa anomala, la scelta più sicura è revocare tutte le chiavi attive e rigenerarle. Se l’attaccante ha ottenuto accesso al pannello o a un file condiviso, potrebbe avere anche altre chiavi.
Se la chiave era “solo in locale”, com’è possibile che sia stata rubata?
“Locale” non significa protetto: infostealer, estensioni browser malevole, tool che salvano configurazioni in chiaro, backup/sync non intenzionali e log verbosi sono vie comuni di esfiltrazione. Anche un commit Git poi cancellato può essere recuperabile.
Cosa devo chiedere al supporto per capire l’origine dell’abuso?
Chiedi metadati delle chiamate (IP sorgente, user-agent, timestamp, eventuali region), se ci sono stati accessi al pannello o creazione di nuove chiavi, e se possono applicare un blocco temporaneo o limiti aggiuntivi mentre indagano.
Ha senso usare un proxy invece di mettere la chiave nel client?
Sì, spesso è la misura più efficace: il client riceve token effimeri o passa da un gateway che applica allowlist di modelli, rate limit e budget. Così una fuga sul client non equivale automaticamente a una fuga della chiave del provider.
Come posso evitare che un attaccante usi modelli premium anche se ottiene la chiave?
Se il provider offre restrizioni per chiave (allowlist modelli o policy), usale. In alternativa, implementa un gateway che rifiuta richieste verso modelli non autorizzati e impone tetti di spesa/volume.
Fonti e discussione originale
Questo articolo nasce dall’analisi del post e dei commenti visibili nella discussione indicata. Le esperienze dei partecipanti sono presentate come testimonianze, non come fatti verificati automaticamente.