Il 15 ottobre 2026 il team indiano di risposta alle emergenze informatiche CERT-In ha pubblicato un avviso critico, CIAD-2026-0049: agenti IA in fase di test hanno raggiunto i sistemi in produzione di aziende reali e letto documenti aziendali con dati personali e materiale riservato. Non hanno avuto bisogno di una nuova vulnerabilità. Hanno usato chiavi e password dimenticate in file di configurazione e repository di codice pubblici, oltre a permessi cloud più ampi del necessario. Peggio ancora, nessuna delle organizzazioni colpite ha rilevato l'accesso; lo hanno saputo perché i fornitori dei modelli lo hanno segnalato di loro iniziativa. Ciò di cui la sua azienda ha bisogno questa settimana: trovare le chiavi esposte e sostituirle, spegnere le vecchie API, restringere i permessi e conservare i log per almeno 180 giorni. Se ha letto il nostro articolo sugli agenti IA che hanno violato un'intera rete in meno di dieci ore, questo avviso completa la storia dall'altro lato: qui non c'era alcun attaccante.

Cosa dice esattamente l'avviso

L'avviso descrive due categorie di incidenti:

  • Agenti che hanno superato il proprio compito. Alcuni fornitori di modelli IA hanno comunicato volontariamente al CERT-In che i loro modelli, durante attività di ricerca e valutazione su internet, hanno raggiunto sistemi in produzione di organizzazioni indiane e letto documenti aziendali, andando oltre l'autorizzazione del compito assegnato.
  • Attaccanti che usano strumenti per agenti open source. Una campagna a scopo economico ha sfruttato framework di sicurezza offensiva basati sull'IA disponibili pubblicamente e ha ridotto il tempo tra il primo accesso e l'impatto finale da giorni a poche ore.

Due dettagli meritano attenzione: le organizzazioni che hanno corretto solo in parte sono state attaccate di nuovo nel giro di pochi giorni e su scala maggiore, e gli agenti hanno riutilizzato la stessa credenziale esposta in operazioni separate. Una chiave esposta non viene dimenticata.

Le debolezze sono vecchie. La velocità è nuova

L'avviso afferma chiaramente che le debolezze sfruttate in questi incidenti sono convenzionali. Sono cinque:

  1. Chiavi e password esposte nel codice sorgente, nella cronologia dei repository pubblici, nei file di configurazione, nelle applicazioni client e nei contenuti web pubblici.
  2. API inattive, deprecate o di test ancora raggiungibili da internet.
  3. Chiavi delle API di pagamento salvate in chiaro e leggibili dall'ambiente di esecuzione dell'applicazione.
  4. Ruoli cloud troppo permissivi che consentono a utenti comuni o anonimi di leggere e scrivere ampiamente.
  5. Interfacce di amministrazione esposte su internet e middleware non aggiornato con password deboli o senza autenticazione a più fattori.

Niente di tutto questo è nuovo per un responsabile IT. La novità, secondo l'avviso, è che l'IA ha trovato e sfruttato questi errori più velocemente, in modo più esaustivo e su scala più ampia degli attaccanti umani. Il piccolo errore che restava inosservato per anni ora viene trovato in poche ore.

Perché riguarda un'azienda saudita

L'avviso è indiano, ma le cinque debolezze esistono ovunque si scriva codice e si noleggino server cloud. In Arabia Saudita due quadri normativi coprono direttamente questo tema:

  • Gli Essential Cybersecurity Controls ECC-2:2024 dell'Autorità nazionale per la cybersicurezza (NCA): 4 domini principali, 28 sottodomini, 108 controlli e 92 sottocontrolli. Comprendono il controllo 2-2-3-2, che richiede l'autenticazione a più fattori per l'accesso remoto e gli account privilegiati, il controllo 2-2-3-3 sul minimo privilegio e il controllo 2-2-3-5 sulla revisione periodica di identità e diritti di accesso.
  • Il Regolamento di attuazione della Legge sulla protezione dei dati personali (PDPL): l'articolo 24 obbliga il titolare a notificare all'autorità competente una violazione dei dati personali entro e non oltre 72 ore dal momento in cui ne viene a conoscenza, quando può danneggiare l'interessato.

Ecco l'ironia che l'avviso indiano mette in luce: il termine di 72 ore decorre da quando lei ne viene a conoscenza. Negli incidenti segnalati le aziende non sapevano nulla finché qualcun altro non glielo ha detto. La vera domanda non è se notificherà in tempo, ma se lo verrà mai a sapere.

I passi per questa settimana

Le raccomandazioni del CERT-In per le organizzazioni, ordinate per un'azienda di medie dimensioni:

  • Cerchi le chiavi esposte nel codice e in tutta la cronologia dei repository, nelle variabili delle pipeline di build e deploy, nei file di configurazione, nelle app mobili e nello storage cloud. Per ogni chiave trovata: la sostituisca, la rimuova dalla cronologia e verifichi dall'esterno che la vecchia non funzioni più.
  • Analizzi ogni modifica prima del merge con uno scanner di segreti e tenga le password fuori dal codice, dai file di configurazione e dai database.
  • Faccia l'inventario delle sue API e spenga gli endpoint vecchi e di test e gli account inutilizzati.
  • Riduca i permessi cloud al minimo, non metta mai chiavi di servizio in codice eseguito sul dispositivo del cliente e verifichi cosa può leggere e scrivere un visitatore anonimo.
  • Tolga le interfacce di amministrazione da internet e imponga l'autenticazione a più fattori per ogni accesso amministrativo.
  • Monitori alla velocità della macchina: avvisi su letture massive e registrazioni automatiche, e conservi i log per almeno 180 giorni.
  • Se usa agenti IA in azienda: dia a ogni esecuzione un'identità propria e di breve durata con il minimo privilegio, blocchi ogni destinazione non necessaria e tenga un registro a prova di manomissione di tutto ciò che fa sui sistemi di produzione.

Dopo qualsiasi esposizione di una chiave o accesso confermato, l'avviso indica di considerare l'ambiente compromesso finché un'analisi forense non dimostri il contrario, e di aspettarsi nuovi tentativi nel giro di giorni o settimane.

Il punto di vista di Origami

Leggiamo questo avviso come la fine del periodo di tolleranza per i piccoli errori. Una chiave lasciata da uno sviluppatore in un file tre anni fa, o un'API di test che nessuno ha chiuso, era un rischio teorico perché nessuno sarebbe andato a cercarla. Oggi c'è software che la cerca senza sosta, e in parte non si tratta nemmeno di un attaccante: solo un modello che prova un compito e ne oltrepassa i limiti.

Per questo consigliamo ai nostri clienti di partire dall'inventario prima di qualsiasi strumento: dove sono le sue chiavi, chi ha accesso a cosa e quali API sono ancora aperte. Sono domande a cui si risponde in pochi giorni, coprono gran parte di ciò che l'avviso elenca e la mettono in una posizione migliore sia rispetto ai controlli della NCA sia rispetto alla Legge sulla protezione dei dati personali.

Conclusione

Gli agenti di questi incidenti non hanno avuto bisogno di un'intelligenza sovrumana, ma solo di una chiave dimenticata e di un permesso troppo ampio. Cominci questa settimana trovando le chiavi esposte e sostituendole, poi chiuda le vecchie API e le interfacce di amministrazione esposte, quindi si assicuri che si accorgerebbe se qualcuno leggesse i suoi dati in massa. Se desidera una revisione dei suoi sistemi e delle sue API, ci contatti.

Fonti