{"id":30419,"date":"2026-01-31T13:04:08","date_gmt":"2026-01-31T11:04:08","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30419"},"modified":"2026-01-30T13:05:27","modified_gmt":"2026-01-30T11:05:27","slug":"top-agentic-ai-risks-2026","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/top-agentic-ai-risks-2026\/30419\/","title":{"rendered":"Agenti IA nella propria organizzazione: gestione dei rischi"},"content":{"rendered":"

Come proteggere un\u2019organizzazione dalle azioni pericolose degli agenti IA che utilizza? Non si tratta pi\u00f9 solo di una simulazione teorica: considerando i danni effettivi che l\u2019IA autonoma pu\u00f2 causare, vanno dal fornire un servizio clienti scadente<\/a> alla distruzione dei database primari aziendali<\/a>.\u00a0 \u00c8 una domanda su cui i leader aziendali stanno attualmente insistendo e le agenzie governative e gli esperti di sicurezza stanno facendo a gara per fornire risposte.<\/p>\n

Per CIO e CISO, gli agenti IA creano un enorme grattacapo di governance. Questi agenti prendono decisioni, utilizzano strumenti ed elaborano dati sensibili senza che un essere umano intervenga. Di conseguenza, molti dei nostri strumenti IT e di sicurezza standard non sono in grado di tenere sotto controllo l\u2019IA.<\/p>\n

La OWASP Foundation senza scopo di lucro ha pubblicato un pratico playbook proprio su questo argomento. Il loro Elenco dei primi 10 rischi per le applicazioni IA degli agenti<\/a> completo copre qualsiasi cosa, dalle minacce alla sicurezza della vecchia scuola come l\u2019escalation dei privilegi ai grattacapi specifici dell\u2019IA come il memory poisoning degli agenti. Ogni rischio viene presentato con esempi reali, un\u2019analisi delle differenze rispetto a minacce simili e strategie di mitigazione. In questo post abbiamo ridotto le descrizioni e consolidato i consigli per la difesa.<\/p>\n

\"The

The top-10 risks of deploying autonomous AI agents. Fonte<\/a><\/p><\/div>\n

Hijacking degli obiettivi dell\u2019agente (ASI01)<\/h2>\n

Questo rischio implica la manipolazione delle attivit\u00e0 o della logica decisionale di un agente sfruttando l\u2019incapacit\u00e0 del modello sottostante di distinguere tra istruzioni legittime e dati esterni. Gli utenti malintenzionati utilizzano il prompt injection o dati contraffatti per riprogrammare l\u2019agente in modo che esegua azioni dannose. La differenza fondamentale rispetto a una prompt injection standard \u00e8 che questo attacco interrompe il processo di pianificazione in pi\u00f9 passaggi dell\u2019agente anzich\u00e9 semplicemente indurre il modello a fornire una singola risposta errata.<\/p>\n

Esempio: un utente malintenzionato incorpora un\u2019istruzione nascosta in una pagina Web che, una volta analizzata dall\u2019agente IA, attiva un\u2019esportazione della cronologia del browser dell\u2019utente. Una vulnerabilit\u00e0 di questo tipo \u00e8 stata evidenziata in uno studio EchoLeak<\/a>.<\/p>\n

Uso improprio e sfruttamento degli strumenti (ASI02)<\/h2>\n

Questo rischio si verifica quando un agente, guidato da comandi ambigui o influenze dannose, utilizza gli strumenti legittimi a cui ha accesso in modi pericolosi o non intenzionali. Tra gli esempi sono inclusi l\u2019eliminazione di massa di dati o l\u2019invio di chiamate API fatturabili ridondanti. Questi attacchi spesso si esplicano attraverso complesse catene di chiamate, consentendo loro di sfuggire ai tradizionali sistemi di monitoraggio host inosservati.<\/p>\n

Esempio: un chatbot dell\u2019Assistenza clienti con accesso a un\u2019API finanziaria viene manipolato per fare in modo che elabori rimborsi non autorizzati poich\u00e9 il suo accesso non \u00e8 stato limitato alla sola lettura. Un altro esempio \u00e8 l\u2019esfiltrazione dei dati tramite query DNS, simile all\u2019attacco su Amazon Q<\/a>.<\/p>\n

Abuso di identit\u00e0 e privilegi (ASI03)<\/h2>\n

Questa vulnerabilit\u00e0 riguarda il modo in cui le autorizzazioni vengono concesse ed ereditate nei flussi di lavoro degli agenti<\/a>. Gli utenti malintenzionati sfruttano le autorizzazioni esistenti o le credenziali memorizzate nella cache per aumentare i privilegi o eseguire azioni per cui l\u2019utente originale non era autorizzato. Il rischio aumenta quando gli agenti utilizzano identit\u00e0 condivise o riutilizzano i token di autenticazione in diversi contesti di protezione.<\/p>\n

Esempio: un dipendente crea un agente che utilizza le proprie credenziali personali per accedere ai sistemi interni. Se l\u2019agente viene quindi condiviso con altri colleghi, tutte le richieste rivolte all\u2019agente verranno eseguite anche con le autorizzazioni elevate dell\u2019autore.<\/p>\n

Vulnerabilit\u00e0 della supply chain degli agenti (ASI04)<\/h2>\n

I rischi sorgono quando si utilizzano modelli, strumenti o personalit\u00e0 di agenti preconfigurati di terze parti che potrebbero essere compromessi o dannosi fin dall\u2019inizio. Ci\u00f2 che lo rende pi\u00f9 complicato rispetto al software tradizionale \u00e8 che i componenti degli agenti vengono spesso caricati in modo dinamico e non sono noti in anticipo. Questo aumenta notevolmente il rischio, soprattutto se l\u2019agente pu\u00f2 cercare autonomamente un pacchetto adatto. Si sta assistendo a un\u2019impennata sia del typosquatting, in cui gli strumenti dannosi nei registri imitano i nomi di famose librerie, sia del relativo slopsquatting<\/a>, in cui un agente tenta di chiamare strumenti che non esistono nemmeno.<\/p>\n

Esempio: un agente dell\u2019assistente di codice installa automaticamente un pacchetto compromesso contenente una backdoor, consentendo a un utente malintenzionato di estrarre token CI\/CD e chiavi SSH direttamente dal contenitore dell\u2019agente. Abbiamo gi\u00e0 visto tentativi documentati di attacchi distruttivi contro gli agenti di sviluppo dell\u2019IA<\/a> in natura.<\/p>\n

Esecuzione imprevista di codice\/RCE (ASI05)<\/h2>\n

I sistemi degli agenti generano ed eseguono spesso codice in tempo reale per eliminare le attivit\u00e0, il che apre le porte a script o binari dannosi. Tramite prompt injection e altre tecniche, \u00e8 possibile convincere un agente a eseguire gli strumenti disponibili con parametri pericolosi o a eseguire il codice fornito direttamente dall\u2019utente malintenzionato.\u00a0 Questo pu\u00f2 comportare un contenitore pieno o una compromissione dell\u2019host oppure un\u2019escape della sandbox: a quel punto l\u2019attacco diventa invisibile agli strumenti standard di monitoraggio dell\u2019IA.<\/p>\n

Esempio: un utente malintenzionato invia un prompt<\/a> che, con il pretesto di testare il codice, induce un agente di vibecoding<\/a> a scaricare un comando tramite cURL<\/a> e a inviarlo direttamente a bash<\/a>.<\/p>\n

Attacchi dannosi a contesto e memoria (ASI06)<\/h2>\n

Gli utenti malintenzionati modificano le informazioni su cui un agente fa affidamento per la continuit\u00e0, ad esempio la cronologia dei dialoghi, una knowledge base RAG o i riepiloghi delle fasi precedenti dell\u2019attivit\u00e0. Questo contesto dannoso altera il ragionamento futuro dell\u2019agente e la selezione degli strumenti. Di conseguenza, nella sua logica possono emergere backdoor persistenti che sopravvivono tra le sessioni. A differenza di un\u2019injection una tantum, questo rischio ha un impatto a lungo termine sulla conoscenza del sistema e sulla logica comportamentale.<\/p>\n

Esempio: un utente malintenzionato inserisce dati falsi nella memoria di un assistente relativi ai preventivi dei prezzi dei voli ricevute da un fornitore. Di conseguenza, l\u2019agente approva le transazioni future a un tasso fraudolento. Un esempio di impianto di falsa memoria \u00e8 stato mostrato in un attacco dimostrativo su Gemini<\/a>.<\/p>\n

Comunicazione tra agenti non sicura (ASI07)<\/h2>\n

Nei sistemi multi-agente, il coordinamento avviene tramite API o bus di messaggi che spesso mancano ancora dei controlli di integrit\u00e0, criptaggio o criptaggio di base. Gli utenti malintenzionati possono intercettare, falsificare o modificare questi messaggi in tempo reale, causando il malfunzionamento dell\u2019intero sistema distribuito. Questa vulnerabilit\u00e0 apre la strada agli attacchi \u201cagent-in-the-middle\u201d, nonch\u00e9 ad altri classici exploit di comunicazione noti nel mondo della sicurezza delle informazioni applicata: riproduzione dei messaggi, spoofing del mittente e downgrade forzato dei protocolli.<\/p>\n

Esempio: forzare gli agenti a passare a un protocollo non criptato per iniettare comandi nascosti, con un hijacking efficace del processo decisionale collettivo dell\u2019intero gruppo di agenti.<\/p>\n

Errori a catena (ASI08)<\/h2>\n

Questo rischio descrive come un singolo errore, causato da \u201callucinazione\u201d, prompt injection o da qualsiasi altro problema tecnico, pu\u00f2 propagarsi e amplificarsi in una catena di agenti autonomi. Poich\u00e9 questi agenti si scambiano le attivit\u00e0 senza il coinvolgimento umano, un errore in un collegamento pu\u00f2 innescare un effetto domino che porta a una massiccia fusione dell\u2019intera rete. Il problema principale in questo caso \u00e8 l\u2019assoluta velocit\u00e0 dell\u2019errore: si diffonde molto pi\u00f9 velocemente di quanto qualsiasi operatore umano possa tracciare o arrestare.<\/p>\n

Esempio: un agente di pianificazione compromesso invia una serie di comandi non sicuri che vengono automaticamente eseguiti dagli agenti a valle, determinando un loop di azioni pericolose replicate nell\u2019intera organizzazione.<\/p>\n

Sfruttamento della fiducia uomo-agente (ASI09)<\/h2>\n

Gli autori degli attacchi sfruttano la natura conversazionale e l\u2019apparente esperienza degli agenti per manipolare gli utenti. L\u2019antropomorfismo porta le persone a riporre eccessiva fiducia nelle raccomandazioni dell\u2019IA e ad approvare le azioni critiche senza pensarci due volte. L\u2019agente agisce come un cattivo consigliere, trasformando l\u2019umano nell\u2019esecutore finale dell\u2019attacco, il che complica una successiva indagine forense.<\/p>\n

Esempio: un agente dell\u2019assistenza tecnica compromesso fa riferimento ai numeri dei biglietti effettivi per creare un rapporto con un nuovo assunto, e alla fine convincerlo a fornire le credenziali aziendali.<\/p>\n

Rogue agent (ASI10)<\/h2>\n

Si tratta di agenti dannosi, compromessi o \u201callucinanti\u201d che esulano dalle funzioni assegnate, operano di nascosto o agiscono come parassiti all\u2019interno del sistema. Una volta perso il controllo, un agente del genere potrebbe iniziare a replicarsi automaticamente, perseguendo la propria agenda nascosta o addirittura in collusione con altri agenti per aggirare le misure di sicurezza. La minaccia principale descritta da ASI10 \u00e8 l\u2019erosione a lungo termine dell\u2019integrit\u00e0 comportamentale di un sistema in seguito a una violazione o a un\u2019anomalia iniziale.<\/p>\n

Esempio: il caso pi\u00f9 famigerato riguarda un agente di sviluppo autonomo di Replit<\/a> che \u00e8 diventato un rogue agent, ha eliminato il database del cliente primario della rispettiva azienda e quindi ne ha completamente inventato il contenuto facendo sembrare che il problema tecnico fosse stato corretto.<\/p>\n

Mitigazione dei rischi nei sistemi di IA degli agenti<\/h2>\n

Sebbene la natura probabilistica della generazione LLM e la mancanza di separazione tra istruzioni e canali di dati rendano impossibile una sicurezza a prova di proiettile, una serie rigorosa di controlli, che si avvicinano a una strategia Zero Trust, pu\u00f2 limitare significativamente i danni quando le cose non vanno per il verso giusto. Ecco le misure pi\u00f9 critiche.<\/p>\n

Applicare i principi sia di minima autonomia che di privilegio minimo.<\/strong> Limita l\u2019autonomia degli agenti di intelligenza artificiale assegnando attivit\u00e0 con guardrail rigorosamente definiti. Assicurarsi che abbiano accesso solo agli strumenti specifici, alle API e ai dati aziendali necessari per lo svolgimento della loro missione. Comporre le autorizzazioni fino al minimo assoluto ove appropriato, ad esempio mantenendo la modalit\u00e0 di sola lettura.<\/p>\n

Utilizzare credenziali di breve durata.<\/strong> Emettere token temporanei e chiavi API con un ambito limitato per ogni attivit\u00e0 specifica. Questo impedisce a un utente malintenzionato di riutilizzare le credenziali se riesce a compromettere un agente.<\/p>\n

Human-in-the-loop obbligatorio<\/strong> per le operazioni critiche. Richiedere una conferma umana esplicita per qualsiasi azione irreversibile o ad alto rischio, come l\u2019autorizzazione di trasferimenti finanziari o l\u2019eliminazione collettiva di dati.<\/p>\n

Isolamento dell\u2019esecuzione e controllo del traffico.<\/strong> Eseguire codice e strumenti in ambienti isolati (contenitori o sandbox) con liste consentite rigorose di strumenti e connessioni di rete per prevenire le chiamate in uscita non autorizzate.<\/p>\n

Applicazione criteri.<\/strong> Distribuire intent gate per esaminare i piani e gli argomenti di un agente rispetto alle rigide regole di sicurezza prima che vengano attivate.<\/p>\n

Convalida e sanificazione di input e output.<\/strong> Utilizzare filtri specializzati e schemi di convalida per verificare la presenza di iniezioni e contenuto dannoso in tutti i prompt e modelli di risposta. Questo deve avvenire in ogni singola fase dell\u2019elaborazione dei dati e ogni volta che i dati vengono trasmessi tra gli agenti.<\/p>\n

Registrazione sicura continua.<\/strong> Registrare ogni azione dell\u2019agente e ogni messaggio tra agenti in registri non modificabili. Questi registri sarebbero necessari per eventuali future ispezioni di controllo e indagine forense.<\/p>\n

Monitoraggio comportamentale e agenti di watchdog.<\/strong> Distribuire i sistemi automatizzati per individuare le anomalie, come un picco improvviso delle chiamate API, tentativi di autoreplicazione o un agente che si discosta improvvisamente dai propri obiettivi principali. Questo approccio si sovrappone fortemente al monitoraggio richiesto per intercettare sofisticati attacchi di rete \u201clife-off-the-land\u201d. Di conseguenza, le organizzazioni che hanno introdotto XDR<\/a> \u00a0ed elaborano la telemetria in un SIEM<\/a> avranno un vantaggio in questo caso: troveranno molto pi\u00f9 facile tenere a bada i propri agenti di intelligenza artificiale.<\/p>\n

Controllo della supply chain e SBOM (distinta base del software).<\/strong> Utilizzare solo strumenti selezionati e modelli provenienti da registri di fiducia. Durante lo sviluppo del software, firmare ogni componente, aggiungere le versioni delle dipendenze e ricontrollare ogni aggiornamento.<\/p>\n

Analisi statica e dinamica del codice generato.<\/strong> Eseguire la scansione di ogni riga di codice scritta da un agente alla ricerca di vulnerabilit\u00e0 prima dell\u2019esecuzione. Bandire completamente l\u2019utilizzo di funzioni pericolose come eval(). Questi ultimi due suggerimenti dovrebbero gi\u00e0 far parte di un flusso di lavoro DevSecOps standard e dovevano essere estesi a tutto il codice scritto dagli agenti di intelligenza artificiale. Eseguire questa operazione manualmente \u00e8 quasi impossibile, quindi gli strumenti di automazione, come quelli disponibili in Kaspersky Cloud Workload Security, sono consigliati qui.<\/p>\n

Protezione delle comunicazioni tra agenti.<\/strong> Garantire l\u2019autenticazione e il criptaggio reciproci su tutti i canali di comunicazione tra gli agenti. Utilizzare le firme digitali per verificare l\u2019integrit\u00e0 dei messaggi.<\/p>\n

\u00a0Kill Switch.<\/strong> Trovare modi per bloccare istantaneamente agenti o strumenti specifici nel momento in cui viene rilevato un comportamento anomalo.<\/p>\n

Utilizzo dell\u2019interfaccia utente per la calibrazione attendibile.<\/strong> Utilizzare gli indicatori di rischio visivi e gli avvisi del livello di confidenza per ridurre il rischio che le persone si fidino ciecamente dell\u2019IA.<\/p>\n

Formazione utenti.<\/strong> Formare sistematicamente i dipendenti sulle realt\u00e0 operative dei sistemi basati sull\u2019intelligenza artificiale. Utilizzare esempi su misura per i ruoli lavorativi effettivi per analizzare i rischi specifici dell\u2019IA. Data la velocit\u00e0 con cui questo campo si muove, un video sulla conformit\u00e0 una volta all\u2019anno non baster\u00e0: tale formazione dovrebbe essere aggiornata pi\u00f9 volte l\u2019anno.<\/p>\n

Per gli analisti SOC si consiglia anche il corso Kaspersky Expert Training: Large Language Models Security<\/a>, che copre le principali minacce per gli LLM e le strategie difensive per contrastarle. Il corso sarebbe utile anche per sviluppatori e i progettisti di intelligenza artificiale che lavorano su implementazioni LLM.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

I primi 10 rischi associati alla distribuzione di agenti IA autonomi e suggerimenti per l’attenuazione. <\/p>\n","protected":false},"author":2722,"featured_media":30421,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955],"tags":[1516,2620,3892,3724],"class_list":{"0":"post-30419","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-ai","10":"tag-ia","11":"tag-llm","12":"tag-machine-learning"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/top-agentic-ai-risks-2026\/30419\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/top-agentic-ai-risks-2026\/30110\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/25171\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/13142\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/top-agentic-ai-risks-2026\/29988\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/28936\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/top-agentic-ai-risks-2026\/31801\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/top-agentic-ai-risks-2026\/41213\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/top-agentic-ai-risks-2026\/14222\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/55184\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/top-agentic-ai-risks-2026\/23537\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/top-agentic-ai-risks-2026\/33133\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/top-agentic-ai-risks-2026\/30201\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/top-agentic-ai-risks-2026\/35872\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/top-agentic-ai-risks-2026\/35527\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/ai\/","name":"AI"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30419"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30419\/revisions"}],"predecessor-version":[{"id":30427,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30419\/revisions\/30427"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30421"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}