Agenti di IA in produzione: segreti esposti, fiducia tecnica e regole di accesso

Apiiro ha trovato 1.105 repository pubblici con credenziali reali legate a Claude Code, dopo aver passato al setaccio oltre 100.000 copie della stessa configurazione. In 539 commit, Claude compare come coautore. È un incidente operativo¹. L’uso di agenti di IA in sviluppo tocca tre piani: sicurezza dei segreti, affidabilità dei flussi e governance commerciale. Servono regole più chiare, strumenti più severi e politiche coerenti.

1) Perdita di segreti operativi: il caso Claude Code

Il meccanismo parte da un gesto comune. Claude Code propone un comando per accedere a database o API. Chiede se eseguirlo. Tra le opzioni c’è “Yes, and don’t ask again”. Se l’utente la seleziona, il comando con le credenziali finisce nel file “.claude/settings.local.json” dentro la cartella del progetto¹.

Quella configurazione dovrebbe restare sul computer dello sviluppatore. Claude Code, se trova un repository Git, aggiunge una regola alla Git-Ignore globale per escluderla. La protezione salta in tre casi: quando la cartella diventa un repository dopo, quando si clona da un’altra macchina, oppure quando qualcuno ha già committato il file. In questi scenari la regola non entra nella “.gitignore” del repository e il file resta scoperto¹.

Apiiro quantifica il risultato. Tra oltre 100.000 copie pubbliche della configurazione, 1.105 repository contenevano segreti reali. In 539 casi, un commit che modificava il file mostrava Claude come coautore. È una classe di errori che nasce da come un agente salva stato e credenziali nel contesto di lavoro dello sviluppatore¹.

I default contano più dei promemoria. Se un agente può scrivere file con segreti, il ciclo Git deve intercettarli a monte. Servono policy di progetto per i file locali, controlli automatici sui commit e opzioni di esecuzione che separano le credenziali dal codice. Una regola di esclusione globale non basta quando il repository cambia nel tempo o si muove tra macchine.

2) Affidabilità tecnica: test, contratti e verifica formale

Quando un agente scrive codice, l’ordine dei passaggi decide la fiducia. Real Python propone un flusso e lo mette alla prova con un quiz da 11 domande: prima definire un contratto verificabile, poi lasciare che l’agente abbozzi i test, rinforzare quei test, isolarli mentre l’agente implementa, infine leggere il diff riga per riga. Una risposta giusta vale 1 punto. Nessun limite di tempo. Il punteggio arriva al 100%³.

Il contratto fissa cosa il codice deve fare in termini misurabili. I test guidano, non inseguono, e l’agente lavora dentro vincoli stabili. La revisione del diff chiude: ogni riga cambiata deve rispettare il contratto iniziale³.

Anthropic sostiene che i modelli linguistici rendono praticabile la verifica formale su scala, spostandola da add-on a parte dei linguaggi e dei workflow. La decisione su cosa verificare resta ai team. “LLMs are making formal software verification feasible at a much larger scale”. “Verification will mature from ‘bolted-on’ to ‘built-in’, driven not only by LLMs but also by innovations in language design and development workflows”⁵.

Nel tooling emergono anche piccoli cambi. Playwright 1.64 introduce l’opzione --shuffle per far emergere dipendenze nascoste nell’ordine dei test. Serve quando l’esito dipende dalla sequenza. L’indicazione è chiara: non fermarsi al verde. Usare la randomizzazione per trovare legami inattesi tra casi che passano solo in un certo ordine⁵.

Contratti chiari, test solidi e verifiche formali attenuano gli errori introdotti dagli agenti. Opzioni come --shuffle smascherano fragilità che gli agenti possono non vedere o accentuare. La combinazione riduce il rischio di regressioni silenziose quando si delega parte dell’implementazione.

3) Governance commerciale: limiti d’uso e modelli di accesso

L’offerta di strumenti con agenti si muove anche su prezzi e soglie. Stringhe nel software citano “Galaxy AI Premium” con due prezzi indicativi, 4,99 dollari al mese o 47,99 dollari l’anno. È un piano individuato nel codice, con riferimenti anche a un possibile accesso anticipato, e non un annuncio ufficiale⁴.

Le stringhe elencano tre strumenti nuovi: Gen Video, generazione di video a partire da foto dell’utente; Bixby Action, automazione tra app; Daily Briefing, senza descrizione del funzionamento. Il codice indica anche un aumento delle soglie di utilizzo per funzioni già presenti, fino a quattro volte rispetto al livello standard. L’interfaccia di Premium mostrerebbe sette strumenti con livello gratuito, tra cui Browsing Assist e Samsung Keyboard. Il pagamento alzerebbe i limiti, non sbloccherebbe l’accesso di base⁴.

Se le soglie definiscono quanto un agente può fare in un certo tempo, diventano un parametro operativo. Soglie strette spingono a spostare carichi verso servizi esterni o a concentrare le chiamate. Soglie alte, senza controlli, possono alimentare automatismi rischiosi. La trasparenza sui confini di uso aiuta a progettare pipeline che non saltano al primo picco.

4) Adozione aziendale e capacità di integrare controlli

La capacità di mettere in piedi questi presìdi non è uniforme. Secondo I-Com, nel 2025 il 16,4% delle imprese italiane con almeno 10 addetti usa una o più tecnologie di IA. Era l’8,2% nel 2024. Nel 2023 era il 5%. La crescita varia tra settori e territori².

Contano la dimensione aziendale e le competenze interne. Le imprese più strutturate adottano prima e integrano meglio gli strumenti. Dove mancano figure in grado di scegliere, integrare e usare le soluzioni, l’IA resta ai margini dei processi principali. Questa combinazione, dimensione e skill, condiziona anche i benefici economici².

I-Com lega i risultati alla maturità digitale. Installare una tecnologia non basta. Serve un’organizzazione capace di integrare dati, ruoli e flussi. La revisione dei processi diventa una condizione per estendere l’uso oltre i pilota e le funzioni isolate. Con processi chiari e dati accessibili, l’adozione si amplia e produce effetti più solidi².

Agenti di sviluppo e strumenti con soglie e tier richiedono policy sui segreti e checklist di integrazione. Servono pipeline di test con contratti espliciti, verifiche formali dove contano e pratiche come la randomizzazione dell’ordine dei test. Senza competenze adeguate, questi elementi restano sulla carta. Con squadre preparate, entrano in routine e riducono l’esposizione.

La convergenza tra incidenti come i file di Claude, pratiche TDD con agenti, tesi sulla verifica formale e modelli di accesso a soglie indica una scelta per i team: trattare limiti, test e segreti come un unico progetto di qualità. Se i prezzi di Premium alzano i tetti d’uso e gli agenti scrivono codice e configurazioni, allora i budget di chiamate entrano nel design dei test tanto quanto le regole di esclusione su Git^4,1,3,5.