sicurezza informatica

Dal cloud agli LLM: la sicurezza dei nuovi agenti ripete i vecchi errori



Indirizzo copiato

Il rapido sviluppo dei modelli linguistici sta introducendo vulnerabilità strutturali già vissute con l’avvento del cloud. Esperti del settore evidenziano la necessità di ripensare radicalmente i concetti di identità, autorizzazione e controllo dei dispositivi per proteggere le infrastrutture

Pubblicato il 6 lug 2026

Matteo Gargiulo

Editor e specialista in media digitali e comunicazione internazionale



Sicurezza informatica
Fonte: Shutterstock
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti

Punti chiave

  • Diffusione di intelligenza artificiale amplia la superficie d’attacco; l’IAM verifica credenziali ma non l’appropriatezza, permettendo a bot di sfruttare privilegi accumulati.
  • La velocità dell’automazione rende le azioni dannose immediate; serve vincoli preventivi e autenticazione legata al dispositivo (es. certificati X.509) per bloccare gli agenti.
  • Bilanciare adozione e prevenzione: introdurre misure fin da progetto, preferire controlli efficaci a grandi metriche, riconoscendo i limiti di LLM e del codice generato internamente.
Riassunto generato con AI


L’adozione su larga scala dell’intelligenza artificiale e dei modelli linguistici avanzati sta trasformando i flussi di lavoro aziendali, ma porta con sé dinamiche di vulnerabilità che ricordano da vicino le passate transizioni tecnologiche. In una recente intervista che ha visto confrontarsi David Spark, produttore della CISO Series, Andy Ellis, principal presso Duha, e Danny Jenkins, amministratore delegato di ThreatLocker, è emerso chiaramente come le sfide attuali non rappresentino una novità assoluta, quanto piuttosto la reiterazione di vecchi schemi logici e operativi. La gestione della sicurezza informatica si trova oggi a dover fare i conti con l’automazione dei processi, dove l’analisi dei rischi deve necessariamente spostarsi dalla semplice verifica delle credenziali a una governance profonda dei comportamenti e delle architetture.

I limiti dell’identity management e la gestione dei privilegi degli agenti

L’approccio tradizionale all’Identity and Access Management (IAM) mostra evidenti lacune strutturali davanti ai moderni sistemi automatizzati. L’esperto di settore A. Pervaiz evidenzia una distinzione critica: l’autorizzazione formale all’accesso non coincide affatto con l’appropriatezza dell’azione. Un sistema IAM standard si limita a confermare se un agente software possiede le credenziali per entrare in una risorsa. Il meccanismo permette l’interrogazione di un database contenente informazioni sensibili, come gli stipendi aziendali. L’agente può anche incrociare questi dati con le valutazioni delle prestazioni del personale. Tuttavia, l’infrastruttura IAM non possiede gli strumenti contestuali per stabilire se tale incrocio sia opportuno o necessario. Spesso le organizzazioni concedono a questi agenti ampi permessi permanenti per assicurarne il funzionamento. Nessuna azienda assegnerebbe mai simili livelli di libertà decisionale a un dipendente umano.

L’accumulo dei permessi e il comportamento dei bot

Andy Ellis ha analizzato il comportamento dei diversi attori che operano stabilmente nella rete aziendale. Gli esseri umani mostrano un alto grado di imprevedibilità nelle loro azioni quotidiane. Nonostante questo dato, i dipendenti non sfruttano quasi mai la maggior parte delle autorizzazioni concesse. Al contrario, gli agenti software operano in modo estremamente prevedibile ma totalizzante. I bot utilizzeranno in modo sistematico ogni singolo privilegio inserito nel loro profilo. Ellis rintraccia il vizio di forma originario in una governance dell’identità spesso approssimativa. Molte realtà aziendali clonano i profili di accesso dei vecchi colleghi quando assumono un nuovo dipendente. Questo errore comune crea un accumulo stratificato di privilegi inutilizzati nel tempo. La situazione si trasforma in un pericolo concreto quando l’azienda implementa un agente intelligente. Il nuovo sistema mappa e sfrutta istantaneamente l’intera superficie di accesso per rispondere alle richieste dell’utente, esponendo l’organizzazione a falle di sicurezza.

La variabile tempo e la velocità distruttiva dell’automazione

Il fattore temporale amplifica drasticamente la gravità delle intrusioni. Danny Jenkins rimarca una differenza sostanziale tra l’operato umano e quello delle macchine. Un dipendente infedele agisce solitamente con lentezza quando vuole sottrarre dati o danneggiare i sistemi. Questa parziale lentezza concede ai team di difesa un’ampia finestra temporale per il rilevamento e la risposta. I sistemi automatizzati basati su modelli linguistici si muovono invece a una velocità non comparabile. Jenkins spiega la dinamica con precisione: “se un umano inizia a rubare dati, tende a farlo lentamente; se decidono di cancellare qualcosa, lo fanno lentamente e hai una possibilità di rilevarlo. Gli agenti lo fanno molto, molto velocemente e, a volte, in modo del tutto errato”.

Gli agenti software non possiedono una coscienza o un meccanismo interno di autoregolazione. Per questo motivo, essi portano a compimento l’azione distruttiva senza alcuna esitazione. L’agente può cancellare un intero database o cifrare file critici senza alcuna percezione delle conseguenze professionali o penali. Jenkins chiarisce il concetto specificando che l’agente “non può essere fermato, non si può ragionare con lui e farà qualunque cosa ritenga appropriata, che sia cancellare un database o criptare file”. Di conseguenza, la pianificazione della sicurezza aziendale deve basarsi su vincoli preventivi rigidi. Il semplice monitoraggio ex-post dei log di sistema non è più sufficiente a limitare i danni.

L’espansione della superficie di attacco e l’analogia storica con il cloud

La velocità con cui i dipartimenti integrano le nuove tecnologie genera una proliferazione inedita di potenziali punti di ingresso per i malintenzionati. Caleb Sima di White Rabbit fornisce dati molto chiari su questo fenomeno di espansione. Nell’arco di soli dodici mesi, il mercato ha distribuito una superficie di attacco superiore a quella costruita nell’intero decennio precedente. Questa crescita incontrollata si manifesta in modo concreto nelle reti aziendali. Si nota una forte diffusione di server Model Context Protocol (MCP) del tutto privi di sistemi di autenticazione. Inoltre, molte funzionalità malevole compaiono regolarmente all’interno dei marketplace pubblici dedicati ai modelli LLM.

Il parallelo storico con i server email open relay

Questo scenario ripete fedelmente un modello storico già osservato in passato. Danny Jenkins traccia un parallelo diretto con l’evoluzione dei servizi di posta elettronica nei primi anni 2000. In quel periodo, i tecnici configuravano i server di default come open relay. Questa scelta serviva a massimizzare la semplicità d’uso della posta e ad accelerare la diffusione della tecnologia tra gli utenti. Il settore ha compreso la necessità di imporre standard rigidi di autenticazione solo dopo un’esplosione globale di abusi e spam. La tendenza attuale privilegia la rapidità di implementazione a scapito della sicurezza iniziale. Molte aziende colmano temporaneamente le lacune strutturali ricorrendo a strumenti di rilevamento e risposta. In un secondo momento, esse si vedono costrette a fare marcia indietro per reintrodurre requisiti basilari. Tra questi figurano i nomi utente, le password robuste e l’autenticazione a più fattori.

Bilanciare l’adozione tecnologica e la prevenzione

L’adozione di una tecnologia dirompente risponde a logiche di business stringenti. I professionisti della sicurezza non possono semplicemente bloccare questi processi di digitalizzazione. Andy Ellis esprime un parere parzialmente divergente rispetto alla critica di Caleb Sima sul cloud. Ellis definisce questa corsa all’adozione come il normale modo di operare del mercato aperto. Secondo la sua visione, l’esperto non deve attendere il consolidamento dell’innovazione per poi imporre veti o divieti ai dipendenti. Al contrario, i team tecnici devono introdurre controlli fondamentali fin dalle prime fasi di progettazione. Risulta indispensabile collaborare attivamente con i dipartimenti aziendali, compreso il team marketing. Questo approccio guida gli utenti verso un utilizzo consapevole, sicuro e protetto delle nuove risorse artificiali.

Oltre le credenziali: l’autenticazione simbiotica del binomio uomo-macchina

La vulnerabilità intrinseca del fattore umano costringe i tecnici a ripensare il concetto stesso di identità digitale. Gli attacchi di ingegneria sociale e di phishing mostrano oggi una straordinaria efficacia. I modelli generativi permettono ai criminali di redigere messaggi privi di refusi e altamente persuasivi. Questo progresso tecnico dimostra che le sole credenziali non garantiscono più la sicurezza degli accessi ai sistemi sensibili. Danny Jenkins condivide un dato reale emerso da un test di penetrazione condotto nella propria organizzazione. Una campagna di phishing simulata ha tratto in inganno ben otto ingegneri informatici interni. Gli specialisti hanno inserito le credenziali aziendali di Office 365 in una pagina web contraffatta. Successivamente, essi hanno persino autorizzato la notifica push del secondo fattore di autenticazione sui propri telefoni. Questo episodio evidenzia un fatto chiaro: anche il personale tecnico qualificato cade in errore davanti a esche ben progettate.

L’identificazione dell’hardware come barriera di protezione

Per superare questa debolezza serve una transizione verso un modello di autenticazione simbiotico. L’identità sulla rete non deve fare riferimento esclusivamente alla persona fisica. Essa deve includere l’unione indissolubile tra l’utente e il suo dispositivo specifico. Andy Ellis ricorda l’esperienza protettiva sviluppata in passato presso Akamai. L’azienda installava certificati crittografici X.509 direttamente su ogni singola macchina aziendale. Questo sistema imponeva al dispositivo di autenticarsi come primo fattore assoluto sulla rete. Di conseguenza, una password sottratta tramite phishing diventava del tutto inutile per l’attaccante. Il tentativo di accesso falliva poiché il software malevolo operava da un computer sconosciuto e privo di certificato.

Questo principio trova applicazione nelle moderne architetture di controllo degli endpoint e degli accessi cloud. Danny Jenkins conferma l’efficacia di questa specifica strategia di blocco. Le piattaforme aziendali come Salesforce o Office negano l’accesso a priori se l’organizzazione non ha precedentemente approvato il dispositivo. Questa restrizione riduce drasticamente le intrusioni andate a buon fine da remoto. Le statistiche interne di ThreatLocker evidenziano un dato interessante: i tentativi di accesso andati a buon fine da postazioni esterne o riconducibili ad attaccanti superano di gran lunga i casi di dipendenti legittimi che tentano di connettersi usando macchine personali da casa. Il rilevamento di una macchina ignota costituisce quindi un immediato segnale d’allarme per la sicurezza della rete.

Lo sviluppo di soluzioni interne e il mito del codice a braccio

Gli strumenti di intelligenza artificiale generano codice funzionante partendo da semplici istruzioni in linguaggio naturale. Questa accessibilità economica apre un dibattito sulla sostenibilità dei vendor esterni di strumenti di analisi del software. Ross Young lancia una provocazione interessante basata sulle capacità degli LLM. Egli ipotizza la possibilità di sviluppare versioni personalizzate di software di monitoraggio durante la pausa pranzo. Gli esperti invitano tuttavia a una valutazione più rigorosa del fenomeno tecnologico. Sviluppare uno script di base in un fine settimana non equivale a realizzare un software strutturato, sicuro e scalabile. Andy Ellis puntualizza questo aspetto della produzione informatica. Le organizzazioni non acquistano dai vendor una funzionalità elementare. Esse cercano la cura dei dettagli operativi e la capacità di lavorare su larga scala in reti complesse. I manager devono considerare l’agente IA come un collaboratore a tempo parziale. Risulta necessario fornire linee guida precise per lo sviluppo interno. Solo così i prodotti generati includeranno pratiche di codifica difensiva e integrazioni stabili.

L’analogia del posizionamento satellitare e l’affidabilità del software

I modelli linguistici rielaborano esclusivamente conoscenza già pubblica disponibile online. Questo limite strutturale ne preclude l’efficacia nella creazione di soluzioni di sicurezza altamente complesse. Danny Jenkins propone una precisa analogia per descrivere l’affidabilità di questi strumenti generativi: “L’IA è come un GPS preciso al 98%: per andare in fondo alla strada va bene, ma per andare da New York a San Francisco quel 2% di errore ti farà sbagliare strada”. Un modello generativo scrive autonomamente uno script lineare per imporre il blocco dello schermo dopo un determinato intervallo temporale. Tuttavia, esso non possiede l’esperienza derivante dal feedback sul campo di migliaia di clienti. Questa conoscenza empirica serve per strutturare un software capace di risolvere i conflitti applicativi complessi.

La disintermediazione dei micro-vendor di nicchia

L’automazione dello sviluppo produce comunque effetti reali in una specifica fascia di mercato. I responsabili aziendali Mike Johnson di Vivian Health e Sarah-Jane Madden di Converge confermano questa tendenza. Alcune realtà stanno effettivamente eliminando specifici vendor esterni. Esse sostituiscono i prodotti commerciali con soluzioni sviluppate internamente tramite l’intelligenza artificiale. Questo fenomeno si concentra sulla risoluzione di problematiche di nicchia molto circoscritte. Riguarda inoltre la sostituzione di applicativi focalizzati sulla sola centralizzazione dei dati o su semplici interfacce grafiche. In questi ambiti limitati il codice degli LLM si dimostra competitivo. Rimane invece del tutto intatta la centralità dei fornitori di infrastrutture di protezione complesse. La code review, al contrario, si conferma un terreno in cui l’IA supera l’efficacia del controllo umano.

Una prospettiva metodologica per la gestione dei controlli

La misurazione dell’efficacia delle strategie di protezione richiede il superamento delle metriche puramente quantitative. Le aziende devono preferire una verifica qualitativa dei controlli implementati sui propri sistemi. Carrie Johnson di Fishbusters evidenzia un dilemma comune nella gestione dei budget. Spesso i manager possiedono metriche favorevoli senza conoscerne le cause reali. Altre volte ottengono un effettivo miglioramento dei controlli che non trova riscontro nei grafici aziendali. Gli indicatori di sicurezza traggono facilmente in inganno se interpretati in modo superficiale.

Andy Ellis afferma che l’affidarsi a dati positivi senza comprenderne la radice espone l’organizzazione a un falso senso di protezione. I dati favorevoli potrebbero derivare da una mancata intercettazione delle minacce da parte dei software di scansione. Al contrario, l’introduzione di un controllo robusto offre l’opportunità di ridefinire i criteri di misurazione interni. Danny Jenkins conferma questa linea strategica con una dichiarazione netta: “Preferisco avere buoni controlli senza metriche che grandi metriche senza controlli”. L’adozione di misure preventive tangibili, come la validazione hardware dei dispositivi, garantisce un innalzamento effettivo della protezione. Questo valore strutturale prescinde dalla fluttuazione temporale dei dati statistici o dalle rappresentazioni grafiche dei report aziendali.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x