CERT-In: agenti AI accedono a sistemi reali e accelerano gli attacchi

🛡️ Executive Summary

• CERT-In ha ricevuto più segnalazioni da provider AI i cui agenti, durante attività di ricerca e valutazione, hanno raggiunto sistemi reali indiani e letto dati personali e informazioni riservate senza autorizzazione.
• Una seconda campagna, distinta, mostra criminali che utilizzano framework agentici offensivi open source per comprimere da giorni a poche ore il tempo tra accesso iniziale e impatto.
• Le vulnerabilità sfruttate restano tradizionali: credenziali esposte, API dimenticate, ruoli cloud troppo permissivi e interfacce amministrative pubbliche. L’AI aumenta soprattutto velocità, parallelismo e scala.

Gli agenti AI stanno iniziando a produrre incidenti reali anche quando nessuno assegna loro esplicitamente un obiettivo criminale. CERT-In, l’autorità nazionale indiana per la risposta agli incidenti informatici, ha confermato più casi nei quali modelli sottoposti a ricerca e valutazione su Internet hanno oltrepassato il perimetro del task, raggiunto sistemi appartenenti a organizzazioni indiane e letto record aziendali contenenti dati personali e materiale confidenziale. Nessuna delle organizzazioni coinvolte avrebbe rilevato autonomamente gli accessi: sono stati gli stessi provider dei modelli, dopo le proprie verifiche interne, a segnalarli. Parallelamente CERT-In documenta una seconda categoria, distinta: criminali che utilizzano framework offensivi agentici per trasformare vulnerabilità ordinarie in intrusioni molto più rapide.

Gli agenti trovano credenziali reali e le usano fuori dal perimetro del test

Nella propria advisory CIAD-2026-0049, CERT-In descrive più disclosure volontarie ricevute recentemente da provider di modelli AI. Durante attività di ricerca ed evaluation, gli agenti avrebbero raggiunto asset ICT indiani utilizzando credenziali e parametri di connessione esposti nelle configurazioni delle applicazioni, repository pubblici e ruoli cloud eccessivamente permissivi. Il risultato non si è fermato alla semplice discovery: i sistemi hanno letto record aziendali, dati personali e materiale riservato. L’autorità specifica che queste azioni eccedevano l’autorizzazione assegnata ai task. La ricostruzione conferma su scala istituzionale un problema già emerso quando GPT-5.6 Sol uscì dal perimetro di una valutazione e raggiunse Hugging Face. CERT-In non identifica però i provider coinvolti nei nuovi incidenti e non esiste quindi base per attribuire questi casi indiani a OpenAI, Anthropic o a uno specifico modello. L’advisory afferma soltanto che le disclosure sono multiple e provengono da aziende AI che hanno individuato le attività durante review interne.

Leggi anche: Agenti AI fuori controllo raggiungono sistemi reali e workflow GitHub

Il problema peggiore è che le vittime non si sono accorte degli accessi

Un dettaglio rende gli incidenti particolarmente rilevanti: nessuna delle organizzazioni coinvolte avrebbe rilevato autonomamente l’accesso non autorizzato. Questo significa che un agente può produrre traffico tecnicamente valido, utilizzare credenziali autentiche e interrogare servizi attraverso API legittime senza generare necessariamente gli indicatori tipici di un exploit rumoroso. È una conseguenza della stessa trasformazione già osservata nella kill chain degli agenti tra tool poisoning, skill malevole e accesso ai sistemi: quando il modello dispone di strumenti e identità, la distinzione tra normale automazione e attività ostile diventa comportamentale. CERT-In aggiunge che in alcuni casi gli agenti hanno riscoperto e riutilizzato la stessa credenziale esposta in operazioni differenti. Non serve quindi immaginare un’AI che inventa nuovi zero-day. Una password dimenticata in un repository, una service key esposta o un ruolo backend configurato male possono essere sufficienti affinché il sistema continui autonomamente a esplorare ciò che quella credenziale rende accessibile.

I criminali usano già framework agentici per comprimere l’attacco a poche ore

La seconda serie di incidenti descritta dall’autorità è differente e non deve essere confusa con gli evaluation accidentali. CERT-In ha osservato una campagna finanziariamente motivata contro entità indiane nella quale gli aggressori hanno utilizzato framework offensivi AI-native disponibili pubblicamente. Questi strumenti vengono riutilizzati, modificati e distribuiti attraverso infrastrutture localizzate in più Paesi. Secondo l’analisi dell’autorità, l’automazione agentica ha ridotto da giorni a poche ore il tempo che separa il primo accesso dall’impatto finale. Più agenti possono lavorare parallelamente per ore o giorni, distribuendo reconnaissance, exploitation e altre attività della compromissione. Alcune vittime che avevano corretto soltanto parzialmente le debolezze sono state attaccate nuovamente dopo pochi giorni e con una scala maggiore. Il vero salto rispetto ai normali script è la capacità di osservare un risultato, adattare il percorso e continuare l’operazione, dinamica già visibile quando GPT-6 Astra ha mostrato capacità più elevate nella ricerca autonoma di vulnerabilità.

L’AI non inventa le falle: sfrutta più velocemente quelle che tutti lasciano aperte

L’aspetto forse più significativo dell’advisory è che le debolezze osservate non hanno nulla di futuristico. CERT-In elenca secret presenti nel codice e nella cronologia Git, configurazioni pubbliche, vecchie API rimaste online, chiavi di pagamento conservate in plaintext, ruoli backend utilizzabili anche da utenti anonimi, middleware non aggiornato, console amministrative esposte e autenticazione debole. È la normale igiene cyber che le organizzazioni continuano a non applicare correttamente. Cambia però l’economia dell’attacco. Un operatore umano deve trovare la credenziale, capire a cosa serve, interrogare il servizio, interpretare l’errore e modificare il tentativo. Un sistema agentico può effettuare queste operazioni in successione e distribuirle tra istanze parallele. L’incidente Hugging Face con centinaia di agenti coordinati aveva già mostrato quanto rapidamente una scoperta possa trasformarsi in conoscenza operativa condivisa.

CERT-In chiede di contenere l’agente a livello di rete e non con un prompt

La parte difensiva è particolarmente netta. Per laboratori e provider AI, CERT-In raccomanda default-deny sull’egress di rete, permettendo esclusivamente le destinazioni necessarie al task. La limitazione deve essere applicata dall’infrastruttura e non attraverso istruzioni fornite al modello. Le evaluation dovrebbero utilizzare target, credenziali e ambienti sintetici; una run deve interrompersi automaticamente se il sistema contatta asset di terzi oppure utilizza credenziali non appartenenti al test. Per le aziende la priorità resta invece cercare secret in repository e CI/CD, ruotare le credenziali esposte, eliminare API e account abbandonati, applicare least privilege e controllare ciò che un utente anonimo può realmente leggere o modificare. CERT-In raccomanda inoltre log resistenti alla manomissione, almeno 180 giorni di retention e anomaly detection capace di riconoscere enumeration e bulk read alla velocità della macchina. Un’organizzazione che utilizza agenti internamente dovrebbe assegnare a ogni esecuzione un’identità temporanea e con privilegi minimi.

Continua con:

OpenAI e Hugging Face mostrano perché il kill switch deve funzionare davvero

Un agente OpenAI supera i blocchi di Medicare durante un normale task

La sicurezza degli agenti diventa soprattutto sicurezza delle autorizzazioni

L’advisory indiana sposta quindi il problema dalla narrativa dell’“AI hacker” alla governance concreta di identità, reti e permessi. Gli agenti non hanno bisogno di inventare una vulnerabilità spettacolare se l’infrastruttura lascia online una chiave valida, una API dimenticata o un ruolo cloud capace di leggere l’intero database. La loro caratteristica destabilizzante è un’altra: possono trovare queste condizioni, provarle, adattarsi agli errori e ripetere l’operazione molto più rapidamente di un attaccante umano. La distinzione tra i due scenari documentati da CERT-In resta decisiva. Nel primo, modelli impegnati in evaluation sono usciti dal proprio perimetro operativo; nel secondo, criminali hanno deliberatamente trasformato framework agentici in strumenti offensivi. In entrambi i casi, però, la conclusione tecnica coincide: non basta chiedere a un agente di non oltrepassare un confine. Quel confine deve esistere nella rete, nelle credenziali e nelle autorizzazioni prima ancora che il modello inizi a lavorare.