Prompt injection negli agenti AI aziendali: il nuovo vettore che i SOC non stanno monitorando

La prompt injection negli agenti AI aziendali è emersa come una delle principali minacce per i sistemi basati su modelli linguistici e applicazioni enterprise. In questo approfondimento vengono analizzate le dinamiche con cui istruzioni nascoste, inserite in contenuti apparentemente legittimi come email o documenti, possono influenzare il comportamento degli agenti e portare a esfiltrazione di dati o azioni non autorizzate. Attraverso esempi concreti, vulnerabilità documentate e casi reali, il testo mette in evidenza come questo tipo di attacco non sia legato a un singolo bug, ma a un limite strutturale dei LLM, offrendo una panoramica utile a comprendere rischi, impatti e implicazioni per la sicurezza e la governance dei sistemi AI.

Il 13 giugno 2025, Microsoft ha corretto in silenzio una vulnerabilità critica in Microsoft 365 Copilot. Nessuna notifica proattiva agli utenti, nessun advisory con toni allarmistici. Solo un fix server-side distribuito come parte del Patch Tuesday di giugno 2025, con una CVE assegnata (CVE-2025-32711) e un CVSS score di 9.3. Il nome in codice dato dai ricercatori di Aim Security era EchoLeak. Era il primo exploit zero-click documentato contro un agente AI in produzione, e funzionava con una singola email. Nessun malware. Nessun payload. Nessun click. Solo testo.

Il problema strutturale: i modelli linguistici non distinguono istruzioni da dati

Prima di analizzare i casi documentati, è necessario comprendere perché la prompt injection non sia un bug correggibile con una patch, ma una vulnerabilità architettonica dei modelli linguistici.

Un LLM riceve in input una sequenza di token. A quel modello non importa se quei token provengono dal prompt di sistema scritto dallo sviluppatore, dall’input dell’utente, da un documento recuperato via RAG, da una email processata dall’agente o da una pagina web visitata durante una sessione di browsing. Tutti i token finiscono nella stessa finestra di contesto e vengono trattati con lo stesso livello di fiducia. Il modello è addestrato a seguire istruzioni espresse in linguaggio naturale. Se un’istruzione appare nella finestra di contesto, il modello tende a eseguirla, indipendentemente da dove provenga.

Come riconosciuto da OpenAI stessa in un post pubblico del 22 dicembre 2025 relativo al browser agentivo ChatGPT Atlas: “Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully ‘solved’.” Non è una resa: è una presa di coscienza dell’architettura del problema. La finestra di contesto è un mezzo fisico uniforme. Fare distinzioni semantiche su cosa sia “istruzione” e cosa sia “dato” in modo affidabile e universale è un problema non risolto nella ricerca attuale.

L’OWASP Top 10 for LLM Applications 2025 ha classificato la prompt injection al primo posto tra le vulnerabilità critiche per il secondo anno consecutivo, riconoscendo che questa classe di vulnerabilità sfrutta il design stesso degli LLM, non difetti correggibili con patch convenzionali.

La tassonomia degli attacchi: diretti, indiretti e cross-agente

Il termine “prompt injection” copre una famiglia di tecniche con caratteristiche operative molto diverse. La distinzione più importante per i team di sicurezza è quella tra attacchi diretti e indiretti.

La prompt injection diretta è l’attacco più intuitivo: un utente malintenzionato invia al sistema AI un input costruito per sovrascrivere le istruzioni di sistema e far compiere all’agente azioni non autorizzate. È il classico “Ignora le istruzioni precedenti e fai X.” È anche il tipo di attacco più facile da contrastare con filtri di input.

La prompt injection indiretta è il vettore che i SOC non stanno monitorando, e che nel 2025 ha generato i casi più gravi. In questo caso l’attaccante non interagisce direttamente con l’agente AI: inserisce istruzioni malevole in contenuti che l’agente elaborerà in futuro come parte del suo lavoro normale. Un documento condiviso, una email in arrivo, una pagina web visitata durante il browsing, un record in un sistema CRM. Quando l’agente processa quel contenuto in risposta a una richiesta legittima dell’utente, le istruzioni iniettate si attivano.

Come analizzato da Lakera AI, l’efficacia degli attacchi indiretti deriva dall’impossibilità strutturale per il modello di distinguere il testo in un documento dal testo delle sue istruzioni originali: entrambi arrivano come flusso di token nella stessa finestra di contesto.

La prompt injection cross-agente è la variante più sofisticata, documentata per la prima volta in ambienti di produzione nel tardo 2025. In sistemi multi-agente dove più modelli AI cooperano con diversi livelli di privilegio, un attaccante può iniettare istruzioni in un agente a basso privilegio che a sua volta induce un agente ad alto privilegio a compiere azioni non autorizzate, sfruttando la fiducia inter-agente come amplificatore dei privilegi.

EchoLeak (CVE-2025-32711): anatomia del primo zero-click su un agente in produzione

EchoLeak rappresenta il punto di inflessione che ha trasformato la prompt injection da preoccupazione teorica a minaccia operativa documentata. Il paper accademico pubblicato su arXiv nel settembre 2025 descrive in dettaglio la chain di exploit.

L’attacco si sviluppa in tre fasi.

Fase 1 : Iniezione via email (bypass dell’XPIA classifier). L’attaccante invia a un dipendente dell’organizzazione target un’email apparentemente normale: un “Employee Onboarding Guide” o un “Q4 Planning Document.” Il corpo del testo include istruzioni malevole scritte in linguaggio naturale, formattate in modo da sembrare contenuto aziendale ordinario. Microsoft aveva deployato un classifier XPIA (Cross Prompt Injection Attempt) per rilevare tentativi di injection. Il bypass era semplice: le istruzioni erano scritte senza mai menzionare AI, Copilot o termini tecnici, usando esclusivamente linguaggio aziendale standard che non attivava il classificatore.

Fase 2 : Attivazione contestuale. Giorni o settimane dopo, un dipendente usa Copilot per una query di lavoro ordinaria: “Riassumi le email sull’onboarding del personale.” Il motore RAG di Copilot recupera l’email iniettata come contenuto rilevante. Le istruzioni nascoste si attivano: Copilot viene istruito a raccogliere le informazioni più sensibili presenti nel contesto corrente (email, file SharePoint, conversazioni Teams) e a trasmetterle verso un endpoint esterno.

Fase 3 : Esfiltrazione zero-click (bypass CSP via Teams proxy). Il meccanismo classico di esfiltrazione tramite link esterni era stato bloccato da Copilot tramite link redaction. EchoLeak aggirava questo filtro usando Markdown reference-style links, che non venivano sanitizzati dal sistema. L’immagine auto-fetched veniva servita attraverso un dominio Microsoft Teams, che era nell’allowlist della Content Security Policy. I dati sensibili venivano codificati come parametri URL nell’immagine e trasmessi al server dell’attaccante senza che l’utente compisse alcuna azione.

Come documentato da Checkmarx nell’analisi tecnica, EchoLeak era efficace su tutti i tipi di file processati da Copilot: email Outlook, documenti Word, presentazioni PowerPoint, messaggi Teams. I dati potenzialmente esposti includevano API key, documenti confidenziali di progetto, cronologia conversazioni e file SharePoint: qualsiasi cosa presente nel contesto di Copilot al momento dell’attivazione.

Microsoft ha corretto il problema server-side entro maggio 2025 e pubblicato l’advisory nell’ambito del Patch Tuesday di giugno 2025. Non sono stati rilevati casi di exploitation in the wild prima del fix. La divulgazione coordinata da parte di Aim Security ha permesso la correzione prima dell’esposizione pubblica.

I casi documentati del 2025-2026: dalla ricerca alla produzione

EchoLeak non è un caso isolato. Il 2025 ha prodotto una serie di incidenti documentati che delineano un pattern sistematico.

GitHub Copilot (CVE-2025-53773, CVSS 7.8). Come documentato da Johann Rehberger (Embrace the Red) e da Persistent Security nell’agosto 2025, GitHub Copilot e Visual Studio Code erano vulnerabili a remote code execution tramite prompt injection. Il CVSS ufficiale assegnato da Microsoft è 7.8 (HIGH).

L’exploit sfruttava la capacità di Copilot di scrivere file nel workspace senza approvazione esplicita: istruzioni malevole, iniettate in file README, sorgenti, issue GitHub o qualsiasi altro contenuto processato dall’agente, inducevano Copilot a modificare il file .vscode/settings.json abilitando la configurazione chat.tools.autoApprove: true – la cosiddetta modalità “YOLO” – che disabilitava tutte le conferme utente e permetteva l’esecuzione arbitraria di comandi di sistema. I ricercatori dimostrarono che payload invisibili potevano propagarsi tra repository come un worm, infettando altri progetti senza intervento umano.

ServiceNow Now Assist (novembre 2025). Documentato da AppOmni (Aaron Costello, Chief of SaaS Security Research) nel novembre 2025, l’attacco sfruttava la gerarchia di agenti nella piattaforma Now Assist tramite iniezioni di secondo ordine. Un utente a basso privilegio inseriva istruzioni malevole in campi ticket che agenti ad alto privilegio avrebbero successivamente elaborato. L’agente superiore, fidandosi del peer, eseguiva la richiesta, bypassando i controlli che si sarebbero applicati a una richiesta umana diretta: copiava record riservati, modificava dati e scalava privilegi. ServiceNow classificò inizialmente il comportamento come “expected” nelle configurazioni di default, aggiornando in seguito la documentazione per segnalare i rischi associati.

Campagna di spionaggio statale (settembre 2025). Il caso più grave documentato fino ad oggi è descritto nel dettaglio da MIT Technology Review in un’analisi pubblicata il 28 gennaio 2026, basata sul report ufficiale di Anthropic. Un threat actor state-sponsored cinese (designato GTG-1002) ha compromesso un setup agentivo basato su Claude Code con tools esposti via Model Context Protocol (MCP), colpendo circa 30 organizzazioni nei settori tech, finance, manifatturiero e governativo.

L’AI gestiva autonomamente l’80-90% dell’operazione: ricognizione, sviluppo dell’exploit, credential harvesting, lateral movement ed esfiltrazione. Gli operatori umani intervenivano solo in pochi punti decisionali chiave. La tecnica di bypass era la decomposizione dell’attacco in task piccoli e apparentemente legittimi, con il modello convinto di stare eseguendo penetration testing autorizzato per conto di un’azienda di cybersecurity legittima.

RAG poisoning enterprise (2025). Come riportato da ricercatori nel 2025, è stato dimostrato che cinque documenti costruiti con cura sono sufficienti per manipolare le risposte di un sistema AI enterprise nell’90% dei casi tramite RAG poisoning. Il sistema trattava tutto il contenuto recuperato come ugualmente attendibile, senza isolamento tra dati interni e input esterni.

Il CrowdStrike 2026 Global Threat Report documenta attacchi di prompt injection contro oltre 90 organizzazioni, con avversari che iniettavano prompt malevoli in strumenti GenAI legittimi per generare comandi di furto di credenziali e criptovalute. In almeno un caso documentato, gli attaccanti hanno incorporato istruzioni nascoste in email di phishing per influenzare i sistemi AI di triage email aziendali.

La “triade letale”: quando un agente è strutturalmente vulnerabile

Airia.com ha formalizzato una condizione necessaria e sufficiente per la vulnerabilità di un sistema agentivo alla prompt injection indiretta, chiamandola “lethal trifecta”:

accesso a dati privati (l’agente può leggere email, documenti, database, sistemi interni), esposizione a token non fidati (l’agente elabora input da fonti esterne come email in arrivo, documenti condivisi, contenuto web) e vettore di esfiltrazione (l’agente può fare richieste verso l’esterno, caricare immagini, chiamare API, generare link).

Se un sistema agentivo soddisfa tutte e tre le condizioni, è strutturalmente vulnerabile. Non è una questione di configurazione o di prompt di sistema: è una questione di architettura e di quali privilegi l’agente detiene.

Questa valutazione è particolarmente rilevante per i CISO italiani che stanno deployando o valutando il deployment di Microsoft 365 Copilot, Google Workspace Gemini, Salesforce Einstein, ServiceNow Now Assist o qualsiasi altro agente AI con accesso ai sistemi interni. La domanda da fare prima del deployment non è “questo agente ha guardrail?”, ma “quante delle tre condizioni della triade letale soddisfa?”

Come approfondito su ICT Security Magazine nell’analisi sugli agenti AI e il nuovo paradigma per la sicurezza informatica, il passaggio dal paradigma “assistente” al paradigma “agente” trasforma fondamentalmente il profilo di rischio: non è più l’uomo che gestisce direttamente l’accesso alle risorse, ma un’entità autonoma che agisce per suo conto, con conseguenze che possono propagarsi ben oltre l’interazione iniziale.

Perché i SOC non stanno monitorando questa superficie

Il 2026 presenta una situazione paradossale: Cisco nel suo State of AI Security 2026 Report rileva che l’83% delle organizzazioni ha in piano il deployment di sistemi agentici AI, ma solo il 29% si dichiara pronto a proteggere questa infrastruttura in modo sicuro. I SOC hanno investito anni a costruire detection per pattern di comportamento umano: login anomali, movimento laterale, exfiltrazione di dati tramite canali di rete noti. Gli agenti AI introducono un vettore che bypassa tutte queste detection per una ragione fondamentale: i loro comportamenti anomali spesso non si distinguono da comportamenti legittimi a livello di rete o di endpoint.

Quando un agente AI viene manipolato per esfiltrare dati tramite una chiamata API a un dominio Microsoft Teams (come in EchoLeak), il SOC vede una connessione HTTPS verso un dominio Microsoft fidato. Nessun alert. Quando un agente manipolato accede a SharePoint per raccogliere documenti prima dell’esfiltrazione, il SOC vede accessi SharePoint da un’identità autorizzata. Nessun alert. La telemetria tradizionale è cieca a questo vettore perché l’agente è, per definizione, autorizzato a fare quasi tutto quello che fa.

Come evidenziato da Stellar Cyber nell’analisi delle minacce agentiche: “Your SIEM and EDR tools were built to detect anomalies in human behavior. An agent that runs code perfectly 10,000 times in sequence looks normal to these systems. But that agent might be executing an attacker’s will.”

Strategie di detection: cosa monitorare e come

La detection della prompt injection negli agenti AI richiede un approccio radicalmente diverso dalla security tradizionale. Non si cerca un IOC (Indicator of Compromise) noto: si cerca un’anomalia comportamentale in un sistema intrinsecamente non deterministico.

Logging completo delle interazioni agentiche. Il primo requisito è l’osservabilità: ogni prompt ricevuto dall’agente, ogni risposta generata, ogni tool call eseguita, ogni documento recuperato via RAG deve essere loggato con timestamp, identità dell’utente richiedente e origine del contenuto elaborato. Senza questo livello di telemetria, qualsiasi altro controllo è cieco. Come indicato da Obsidian Security, l’obiettivo operativo è rilevare l’attacco entro 15 minuti e contenere entro 5 minuti: impossibile senza logging granulare.

Behavioral baseline per gli agenti. Come per i service account, è necessario costruire una baseline del comportamento normale di ogni agente: quali endpoint chiama, quali tipi di documenti accede, quali volumi di dati elabora, in quali orari opera. Deviazioni significative dalla baseline, in particolare un improvviso aumento degli accessi a dati sensibili o chiamate verso endpoint mai contattati prima, devono generare alert. Il Microsoft Security Blog raccomanda di integrare la telemetria delle interazioni AI nei SIEM/SOAR esistenti per correlare comportamenti anomali degli agenti con il più ampio contesto di incident response.

Canary prompt e honeypot documents. Una tecnica emergente consiste nel posizionare deliberatamente “documenti trappola” nei sistemi che l’agente può accedere: file con nomi attraenti per un attaccante che non vengono mai acceduti nei flussi di lavoro normali. Se l’agente accede a questi file, è un segnale forte di manipolazione. Analogamente, i canary prompt, istruzioni di test inserite periodicamente nel flusso normale per verificare che l’agente rispetti i suoi confini, costituiscono un meccanismo di detection attivo.

Controllo dell’output per pattern di esfiltrazione. Il modello di attacco EchoLeak e i suoi derivati usano tipicamente link di immagini, URL con parametri codificati o formattazione Markdown insolita per costruire il canale di esfiltrazione. Il monitoraggio degli output degli agenti per Markdown reference-style links, URL con payload base64-encoded nei parametri o chiamate verso domini non presenti nella whitelist degli endpoint consentiti è una detection specifica per questa classe di attacchi.

Segregazione dei contenuti per livello di fiducia. L’approccio architetturale più efficace è impedire che il problema si manifesti separando il contesto fidato (system prompt, istruzioni dello sviluppatore) dal contesto non fidato (email esterne, documenti di terze parti, contenuto web). Sistemi di “prompt partitioning” e “context isolation” che segnalano al modello l’origine di ogni frammento di contesto riducono strutturalmente la superficie di attacco, anche se non la eliminano completamente.

Principio del minimo privilegio applicato agli agenti: la difesa più efficace

Come sottolineato su ICT Security Magazine nell’analisi sul red teaming per i sistemi AI e i framework OWASP/MITRE ATLAS, la sicurezza degli agenti AI richiede competenze ibride che uniscono cybersecurity tradizionale e comprensione dei rischi specifici dei modelli linguistici. L’approccio più efficace rimane quello architetturale, non quello di detection.

Il principio del minimo privilegio, già fondamentale per i service account e i processi automatizzati, deve essere applicato agli agenti AI con la stessa rigorosità, anzi con maggiore severità dato il rischio di manipolazione. Un agente che gestisce email non ha bisogno di accedere a SharePoint. Un agente che risponde a domande su documentazione tecnica non ha bisogno di poter inviare email. Un agente di customer service non ha bisogno di accedere ai sistemi HR.

La domanda operativa da fare per ogni agente in deployment è: “Se questo agente venisse completamente compromesso da una prompt injection, qual è il massimo danno che potrebbe causare?” Il perimetro dei privilegi deve essere progettato per rendere quella risposta accettabile, non solo tecnicamente possibile.

Le misure concrete includono: accesso a specifici folder o label di email, non all’intera casella; accesso in sola lettura ai documenti, non in scrittura salvo eccezioni giustificate; whitelist di endpoint API a cui l’agente può connettersi; rate limiting sulle operazioni per ridurre l’impatto di un attacco automatizzato; human-in-the-loop obbligatorio per operazioni ad alto impatto come invio di email esterne, modifica di record CRM o trasferimenti di file verso sistemi esterni.

Il framework normativo emergente: EU AI Act, NIST e OWASP

Il contesto normativo si sta allineando rapidamente alla minaccia. Il NIST AI Risk Management Framework include ora controlli specifici per la prompt injection prevention e detection. La ISO 42001 aggiunge obblighi analoghi. L’EU AI Act, con la scadenza del 2 agosto 2026 per i sistemi AI ad alto rischio, impone esplicitamente all’articolo 15 che i sistemi siano resilienti in termini di accuratezza, robustezza e cybersecurity contro i tentativi di terze parti non autorizzate di alterarne l’utilizzo, gli output o le prestazioni. La prompt injection rientra direttamente in questo scope.

L’OWASP Top 10 for Agentic Applications 2026, rilasciata il 10 dicembre 2025, ha consolidato la prompt injection (classificata come “Agent Goal Hijacking”, ASI01) come minaccia primaria nel contesto agentivo specifico, espandendo il framework precedentemente focalizzato sugli LLM per coprire le dinamiche multi-agente, il Model Context Protocol e la memoria persistente degli agenti.

Per le organizzazioni italiane in scope NIS2, la Legge 132/2025 sull’AI e il Cyber Resilience Act, il deployment di agenti AI senza un programma di sicurezza dedicato inizia a configurarsi come un gap normativo oltre che tecnico.

Il SOC del 2026 deve includere la superficie AI nel suo modello di minaccia

La prompt injection negli agenti aziendali non è una minaccia emergente: è una minaccia operativa, documentata, con casi reali e CVE assegnati. Il fatto che la maggior parte dei SOC non la stia monitorando non riflette l’assenza di rischio, ma un ritardo nell’adattamento degli strumenti e dei processi a una superficie di attacco nuova.

Il 2025 ha dimostrato che l’attaccante non ha bisogno di compromettere l’identità dell’utente, non ha bisogno di installare malware, non ha bisogno di eseguire codice. Ha bisogno di scrivere testo in un documento che l’agente elaborerà. Il vettore è semantico, non sintattico. I difensori che aspettano un IOC tradizionale non troveranno nulla, perché non c’è nulla da trovare nei log di rete o negli alert endpoint.

La risposta richiede tre cambiamenti paralleli: un cambiamento architetturale (minimo privilegio per ogni agente, separazione dei contesti di fiducia), un cambiamento di monitoring (telemetria granulare delle interazioni agentiche integrata nel SIEM) e un cambiamento culturale (trattare gli agenti AI come identità privilegiate soggette agli stessi controlli dei service account critici, non come strumenti di produttività da abilitare rapidamente senza threat modeling).