Il tuo nuovo agente AI legge email, chiama API, aggiorna record nel CRM e invia messaggi per conto della tua azienda. È esattamente questo che lo rende utile — ed è esattamente per questo che la sua postura di sicurezza merita un’attenzione ben più critica di quella riservata a una normale integrazione SaaS.
La sicurezza applicativa classica è stata pensata per sistemi che rispondono a utenti autenticati. Gli agenti AI sono diversi: decidono autonomamente cosa fare, quali tool invocare e in quale ordine, basandosi su input in linguaggio naturale che arrivano da utenti, dati esterni e persino altri agenti. Quell’autonomia introduce una superficie d’attacco che la maggior parte dei team IT non ha ancora mappato.
Questo articolo analizza i rischi reali dei sistemi agentici in produzione — prompt injection, abuso di tool e data exfiltration — e le contromisure pratiche a disposizione dei responsabili IT oggi.
Perché la sicurezza degli agenti AI richiede un framework dedicato
Il threat modeling tradizionale si concentra su autenticazione, autorizzazione e dati in transito. Questi controlli restano fondamentali. Ma i sistemi agentici aggiungono tre proprietà che creano nuove esposizioni:
- Consumano contenuti non attendibili come istruzioni. Un agente che riassume un PDF, elabora un’email in arrivo o legge una pagina web esegue operazioni su contenuti che non ha prodotto. Quei contenuti possono contenere istruzioni avversariali.
- Detengono credenziali e possono compiere azioni. Un agente collegato al tuo calendario, al tuo ERP o al file store può leggere, scrivere ed eliminare — non solo consultare.
- Il loro ragionamento è opaco. A differenza di uno script deterministico, il percorso da input ad azione di un agente non è sempre prevedibile, rendendo più difficile il rilevamento delle anomalie.
Queste tre proprietà si combinano generando vettori d’attacco senza equivalenti diretti nel software convenzionale.
I tre principali vettori d’attacco nella sicurezza degli agenti AI
1. Prompt Injection — il vettore d’attacco più documentato
La prompt injection è il rischio più documentato nei sistemi agentici in produzione. Il meccanismo è semplice: un attaccante incorpora istruzioni avversariali all’interno di contenuti che l’agente elaborerà — un documento, un messaggio di un cliente, una pagina web. L’agente, non riuscendo a distinguere l’istruzione incorporata da una legittima, la esegue.
L’injection diretta prende di mira il system prompt o l’interfaccia utente. Un dipendente che pone a un agente HR interno una domanda malevola sperando di estrarre i dati salariali di un collega è un tentativo di injection diretta.
L’injection indiretta è più sottile e difficile da difendere. Un cliente invia un ticket di supporto contenente istruzioni nascoste — magari testo bianco su sfondo bianco in un allegato — che ordinano all’agente di inoltrare il riepilogo della conversazione a un indirizzo esterno. L’agente legge il documento come parte del suo workflow e, senza le dovute protezioni, esegue il comando nascosto.
Gli attacchi di injection indiretta sono stati dimostrati su sistemi in produzione collegati a email, browser e document store. Tra le divulgazioni pubbliche più note: EchoLeak (CVE-2025-32711, CVSS 9.3) — un’injection via email corretta in Microsoft 365 Copilot — la vulnerabilità di data-leakage di Slack AI nei canali privati (agosto 2024) e CVE-2025-53773 di GitHub Copilot. La tassonomia accademica fondamentale di Greshake et al. (2023) ha dimostrato attacchi su email, browser e document store.
Contromisure pratiche per questo trimestre:
- Applica una validazione rigorosa di input e output a ogni boundary di tool — tratta i dati letti dall’agente come non attendibili, separandoli dalle istruzioni che riceve.
- Usa system prompt separati che vincolino esplicitamente le azioni consentite all’agente; mantieni la superficie di istruzioni la più ridotta possibile rispetto al caso d’uso.
- Implementa un output filtering per intercettare pattern di dati anomali (es. indirizzi email o chiavi API che compaiono nelle risposte dell’agente dove non dovrebbero esserci).
2. Abuso di tool — quando lo scope creep diventa vulnerabilità
Gli agenti traggono la loro potenza dai tool: la capacità di chiamare API, eseguire query, scrivere file, inviare messaggi. Quel potere necessita di confini di scope espliciti. Senza di essi, una piccola manipolazione del prompt può portare l’agente a compiere azioni mai previste.
Considera un agente costruito per rispondere alle richieste dell’helpdesk IT interno. Se ha anche accesso in scrittura al sistema di ticketing, alla directory utenti e al relay email — perché era comodo durante lo sviluppo — un input costruito ad hoc potrebbe istruirlo a creare account admin, modificare permessi o esfiltrare dati dei ticket. L’agente non viene “hackerato” nel senso tradizionale; gli viene semplicemente data un’istruzione che non ha motivo di rifiutare.
È meno un problema di modello che un problema di design. La maggior parte delle vulnerabilità da abuso di tool deriva da agenti con privilegi eccessivi.
Contromisure pratiche:
- Applica il principio del minimo privilegio a livello di tool. Un agente che legge dati raramente ha bisogno di accesso in scrittura; uno che scrive quasi mai dovrebbe avere i permessi di cancellazione.
- Definisci elenchi espliciti di azioni consentite nella configurazione di sistema dell’agente, anziché affidarti al giudizio del modello per auto-limitarsi.
- Registra ogni chiamata a un tool con il contesto completo — l’input che l’ha innescata, il tool invocato e l’output restituito. Non puoi investigare ciò che non puoi tracciare.
- Per i tool ad alto impatto (scritture finanziarie, gestione utenti, comunicazioni esterne), richiedi un passaggio di conferma umana prima dell’esecuzione. Non è burocrazia; è la differenza tra un quasi-incidente e un incidente reale.
3. Data Exfiltration — il rischio silenzioso negli agenti RAG
Gli agenti con accesso a knowledge base interne, database o document store introducono un rischio di data exfiltration diverso da una violazione di database. Non c’è un singolo punto di exploit — l’agente stesso diventa il canale di esfiltrazione.
Un attaccante che riesce a influenzare gli input dell’agente (tramite injection, social engineering o un account utente compromesso) può potenzialmente dirigerlo a recuperare e trasmettere contenuti sensibili. Poiché l’agente è un sistema autorizzato, il recupero non appare anomalo al data store stesso.
Un rischio secondario di esfiltrazione viene dalle pipeline di training e logging. Se i log delle conversazioni, i documenti recuperati o gli output dei tool vengono inviati a servizi esterni per monitoraggio, fine-tuning o analytics senza una corretta classificazione dei dati, il contenuto sensibile può fuoriuscire attraverso un canale completamente diverso da quello che stai monitorando.
Contromisure pratiche:
- Limita i permessi di recupero per ruolo: un agente al servizio del team vendite non dovrebbe interrogare documenti HR o finanziari, anche se il data store sottostante li contiene tutti.
- Applica la classificazione dei dati a livello di documento o record, non solo a livello di sistema. Etichetta i contenuti come interni, riservati o con accesso ristretto — e fai rispettare quelle etichette nel layer di recupero dell’agente.
- Controlla cosa esce dal tuo ambiente. Qualsiasi log o dato di conversazione inviato a un servizio terzo (provider LLM, piattaforma di monitoraggio) deve passare per la stessa revisione di data handling che applichi a qualsiasi vendor SaaS.
Una checklist di sicurezza pratica per gli agenti in produzione
Prima di approvare qualsiasi sistema agentico per l’uso in produzione, un responsabile IT dovrebbe poter rispondere sì a ognuno di questi punti:
- Ogni agente opera con accesso ai tool secondo il minimo privilegio — solo ciò che serve per il compito definito?
- I system prompt sono espliciti su cosa l’agente può e non può fare?
- Tutti i contenuti letti dall’agente (documenti, email, pagine web) sono trattati come input non attendibile, con output validation applicata?
- Ogni chiamata a un tool è registrata con contesto sufficiente per ricostruire cosa è successo e perché?
- Esistono gate di approvazione umana per azioni irreversibili o ad alto impatto?
- I dati che fluiscono attraverso i log e le pipeline di monitoraggio dell’agente sono stati esaminati per contenuti sensibili?
- Esiste un processo per rivedere e aggiornare i permessi al variare dello scope di attività dell’agente?
Nessuno di questi punti richiede un nuovo prodotto di sicurezza. La maggior parte richiede decisioni di design deliberate in fase di architettura e deployment — che è il momento giusto per affrontarle.
Chi è più esposto
I rischi di sicurezza crescono con l’accesso. Un agente con accesso in sola lettura a un singolo database FAQ comporta un rischio minimo. Un agente collegato al tuo CRM, al sistema finanziario, all’email e ai dati dei clienti — come molti agenti in produzione — comporta un rischio materiale se distribuito senza i controlli sopra descritti.
Le organizzazioni più esposte sono tipicamente quelle che sono passate rapidamente da prototipo a produzione, trattando l’agente come un’applicazione standalone piuttosto che come un attore di sistema privilegiato. La funzionalità funzionava; la postura di sicurezza non è stata rivista. Vale la pena colmare quel gap prima che il parco agenti cresca.
Per una visione più completa di come governance, testing e sicurezza si integrano in un programma di agenti distribuiti, consulta le nostre guide su governance degli agenti AI per le PMI e testing degli agenti AI con gli eval. Se stai valutando se la tua configurazione attuale introduce esposizioni GDPR attraverso la gestione dei dati degli agenti, agenti AI e GDPR copre specificamente questo aspetto.
Capire perché i sistemi agentici sono architetturalmente diversi dalla semplice automazione aiuta anche a inquadrare i requisiti di sicurezza — agentic workflow spiegati è un buon punto di partenza se quel contesto è utile.
Come Orange ITS affronta la sicurezza degli agenti AI
In Orange ITS, sicurezza e governance sono integrate nell’architettura fin dalla prima sessione di design — non aggiunte a posteriori dopo il go-live. Quando definiamo lo scope di un progetto agente con un cliente, stabiliamo permessi dei tool, confini di accesso ai dati, requisiti di logging e soglie di approvazione umana prima di scrivere una riga di codice.
Questo fa parte di una più ampia disciplina ingegneristica che applichiamo in tutto lo sviluppo di agenti AI: l’obiettivo sono agenti che funzionino in modo affidabile in produzione, non agenti che funzionino nelle demo. Per i clienti svizzeri ed europei, questo significa anche affrontare il GDPR, la nLPD e gli obblighi settoriali dell’AI Act come vincoli di primo livello.
Se hai un agente in produzione — o stai per distribuirne uno — e vuoi una valutazione diretta della tua postura di sicurezza attuale, prenota una call di 30 minuti con il nostro team. Analizzeremo la tua architettura, identificheremo i gap specifici e ti forniremo un elenco prioritizzato di contromisure su cui agire. Contattaci dalla pagina dedicata.