Sophos AI Defense: rilevare e controllare l’uso dell’IA

Sophos AI Defense rende visibile l’uso delle applicazioni IA e controlla quali servizi vengono consentiti, segnalati con un avviso o bloccati. L’add-on a pagamento per gli ambienti Sophos EDR, XDR e MDR idonei è disponibile in generale dal 13 ottobre 2026. Viene gestito in Sophos Fusion e utilizza i sensori Sophos esistenti. Una licenza, un riquadro visibile o una procedura guidata completata non dimostrano però, da soli, una rilevazione completa o un’applicazione efficace dei controlli.

Per l’introduzione si consiglia questa sequenza: chiarire licenza e stato di Fusion, inventariare fonti dati e policy esistenti, soddisfare in modo controllato i prerequisiti dei sensori e solo dopo provare una policy con ambito molto limitato. La verifica del contenuto dei prompt non è una funzione di protezione attuale garantita: le comunicazioni del produttore sono contraddittorie su questo punto. L’ambito pianificabile con sicurezza in questo articolo comprende visibilità, policy di accesso alle app e reporting, verificati al 20 ottobre 2026.

Che cosa significa Shadow AI e quale problema risolve AI Defense

La Shadow AI è l’uso dell’IA al di fuori dei processi previsti di approvazione e controllo. Ad esempio, una dipendente usa un’ulteriore chat web, uno sviluppatore installa un assistente di programmazione oppure un’applicazione esistente riceve una nuova funzione IA. Il servizio può essere utile e avere comunque regole non chiarite per documenti caricati, codice sorgente, uso dei dati per l’addestramento o ubicazione dei dati.

AI Defense riunisce tre domande: quali applicazioni IA vengono usate, quale rischio viene loro attribuito e quale policy di accesso deve applicarsi? La panoramica del prodotto cita modelli linguistici accessibili dal browser come ChatGPT, Claude.ai e Copilot, oltre ad applicazioni più recenti per programmazione, desktop e agenti come Claude Code, Cursor e OpenClaw. Questi esempi non garantiscono la rilevazione e il controllo di ogni variante, connessione API o attività su qualsiasi dispositivo. Rimangono determinanti il sensore specifico e la copertura effettivamente osservata.

Nelle analisi, Unsanctioned significa che un’app usata non è esplicitamente consentita da alcuna policy. È anzitutto uno stato di approvazione, non una prova di malware o di fuoriuscita di dati. Viceversa, un servizio consentito non rende automaticamente ammissibile qualsiasi utilizzo. Rimane necessaria una regola organizzativa che stabilisca quali dati possono essere inviati a quali servizi.

AI Defense non è inoltre Sophos AI Assistant o AI Search per le indagini XDR. In quel caso l’IA aiuta gli analisti nel loro lavoro. AI Defense controlla invece l’uso dell’IA nell’organizzazione. Né il nome Fusion né le funzioni Assistant già presenti abilitano automaticamente l’add-on.

Chiarire prima licenza, Fusion e sensori

Prima dell’ordine e prima della configurazione occorre verificare prerequisiti diversi:

Idoneità all’acquisto: AI Defense è un add-on a pagamento per i clienti Sophos EDR, XDR e MDR idonei. Sophos indica inoltre l’uso di Sophos EDR Endpoint Protection come prerequisito. La sola licenza Sophos Endpoint o un Sophos Firewall autonomo non sono quindi sufficienti a dimostrare l’idoneità. Verifica l’ambito contrattuale specifico seguendo Attivare e controllare le licenze.
Accesso tecnico: la configurazione documentata richiede un account Sophos Fusion aggiornato alla nuova piattaforma con Security Operations. La verifica della transizione a Fusion distingue il nome del portale dall’effettivo upgrade del prodotto.
Eccezione Taegis per l’acquisto: i clienti Taegis idonei possono acquistare l’add-on già dalla disponibilità generale senza attendere la migrazione a Fusion. Non è un’eccezione documentata ai prerequisiti tecnici di configurazione. Prima dell’introduzione, chiarire idoneità, modalità di erogazione e stato dell’upgrade con il referente Sophos competente.
Sensori appropriati: la procedura guidata offre attualmente Sophos Endpoint, Sophos Firewall e Sophos Linux Server. La panoramica generale del prodotto cita inoltre DNS Protection, Protected Browser e Sophos Data Lake come fonti dati. Questo elenco architetturale più ampio non va inteso come un identico elenco di selezione né come prova di uguali capacità di applicazione dei controlli per tutti i componenti.

Prima delle modifiche, documentare utenti, dispositivi e reti interessati, valori precedenti delle policy, amministratori responsabili e procedura di ripristino. Il caricamento dei dati e la decrittazione HTTPS riguardano la protezione dei dati e le applicazioni esistenti. Devono essere approvati prima dell’attivazione, non solo durante la successiva analisi. Per il progetto pilota usare un utente di test autorizzato su un dispositivo di test gestito; le modifiche necessarie alle policy condivise non devono coinvolgere involontariamente tutta l’organizzazione.

Preparare i sensori ed eseguire l’onboarding

Aprire Sophos Fusion, quindi My Products > AI Defense > Get started. La procedura guidata chiede ruolo amministrativo, esperienza con gli strumenti IA, numero di utenti e settore. In Choose your sensors, selezionare i sensori effettivamente utilizzati, quindi confermarne i requisiti. Una casella selezionata conferma la propria verifica; non sostituisce una prova dell’efficacia.

Sophos Endpoint

Per il sensore Endpoint, Sophos documenta queste impostazioni:

In Endpoint > Policies > Data Collection and Investigation, attivare Upload to the Data Lake nella policy pertinente e selezionare Process Data, HTTP Data, DNS Data e Network Data.
In Endpoint > Policies > Threat Protection, attivare SSL/TLS decryption of HTTPS websites e Block QUIC browser connections. La rilevazione documentata presuppone questa configurazione; senza una verifica non si può presumere una visibilità equivalente. Decrittazione HTTPS e blocco di QUIC possono influire sulle applicazioni. Provare quindi le modifiche in modo controllato e non eliminare indiscriminatamente le eccezioni esistenti.
Creare un profilo web in Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles. In Endpoint > Policies > Web Control, assegnarlo alle policy nuove o esistenti per gli utenti e i dispositivi previsti. Non è necessario usare ovunque lo stesso profilo.
In Endpoint > Policies > Application Control, attivare Detect controlled applications when users access them e selezionare Block the detected application. Prima della modifica verificare le associazioni delle app esistenti e i loro effetti; Endpoint Application Control spiega la configurazione di base.

Take me to settings apre la relativa configurazione. Dopo l’implementazione, verificare nuovamente l’assegnazione effettiva al dispositivo di test e solo allora confermare i requisiti nella procedura guidata.

Sophos Firewall e Linux Server

Per Sophos Firewall, i firewall previsti devono essere inclusi nella gestione tramite gruppi in Firewall Management > Firewalls. I firewall esterni alla gestione tramite gruppi non ricevono le regole di applicazione di AI Defense. Occorre inoltre attivare la registrazione dei log in ogni policy web pertinente: aprire l’amministrazione web del firewall tramite il menu con i tre puntini, selezionare la policy in Web e attivarne il logging. Senza questi log manca l’attività necessaria alla rilevazione. Prima di una modifica, verificare l’appartenenza ai gruppi e le regole di gruppo esistenti, affinché l’onboarding non modifichi inavvertitamente altre impostazioni del firewall.

Per Sophos Linux Server, la configurazione richiede Upload to the Data Lake attivo con Network Data in Server > Policies > Data Collection and Investigation. Questo non significa che Linux Server applichi gli stessi controlli di accesso alle app di Endpoint o Firewall. L’anteprima della policy mostrerà in seguito a quale prodotto si applica la regola specifica.

Se la procedura guidata non riesce a verificare lo stato dei sensori, propone Refresh. Se la verifica continua a non riuscire, consente di proseguire. Non si tratta di un test positivo del sensore: l’anomalia rimane aperta e deve essere analizzata prima del collaudo della protezione.

Non trattare la Base Policy come una bozza priva di effetti

In Define your base protection viene creata una Base Policy se non è ancora presente. Si applica a tutte le persone dell’organizzazione. Generative AI category default imposta Block, Warn o Allow per le app senza una regola specifica. Le regole specifiche delle app hanno la precedenza su questo valore predefinito. A questo scopo la procedura guidata mostra le app degli ultimi 30 giorni; non è un’indicazione sulla conservazione generale dei dati.

Create base policy and finish crea la Base Policy. È anche possibile saltare questo passaggio. Se una Base Policy esiste già, l’onboarding non la modifica; Finish and take me to the policy apre la configurazione esistente. Una policy predisposta dal partner va prima verificata, non sostituita a titolo precauzionale. Settings > Restart onboarding riavvia la procedura guidata; non è una funzione documentata di reset o annullamento delle policy esistenti.

Per una prova limitata, non creare alla cieca una regola di blocco per tutta l’organizzazione. Prima chiarire quale impostazione globale predefinita sia stata approvata dai responsabili. Creare poi la policy pilota con un ambito esplicitamente limitato.

Costruire in sicurezza le policy di AI Defense

In My Products > AI Defense > Policies > Create policy, assegnare alla nuova policy, ad esempio, il nome liberamente scelto IA-Pilota-Servizi-Approvati. Nella descrizione registrare scopo, responsabile e data prevista per la verifica. La policy è composta da Rules e Scope.

Regole e priorità

Sia l’elenco delle policy sia le regole all’interno di una policy vengono valutati dall’alto verso il basso: decide la prima voce corrispondente. Una regola corretta posta sotto una regola precedente già corrispondente può quindi rimanere senza effetto.

Una nuova policy aggiuntiva contiene per impostazione predefinita una regola che blocca tutte le app IA. Sophos consiglia di lasciarla in fondo e di creare le autorizzazioni mirate al di sopra. Nel progetto pilota, questa regola finale deve agire soltanto sull’ambito di test approvato. Un’attivazione poco ponderata per tutti gli utenti potrebbe bloccare anche flussi di lavoro precedentemente consentiti.

Con Add Rule, scegliere Action e, tramite Add Filter, una Dimension e il relativo Value. Le dimensioni supportate comprendono ad esempio applicazione, livello di rischio e proprietà di compliance offerte nell’interfaccia. In Application, selezionare app specifiche dall’elenco. Usare soltanto valori effettivamente disponibili; una classificazione del rischio non sostituisce la propria verifica del servizio e del contratto sottoscritto.

Allow: l’uso dell’app corrispondente viene consentito.
Warn: gli utenti ricevono un avviso, ma possono continuare a usare il servizio. Non sostituisce un blocco.
Block: l’uso dell’app corrispondente deve essere bloccato tramite il prodotto supportato. Il progetto pilota deve dimostrare se funziona per il percorso di accesso previsto.

Un esempio di test appropriato prevede un’app esplicitamente consentita sopra la regola finale di blocco e una seconda app autorizzata per la prova, ma priva di una propria regola di autorizzazione. In questo modo si verifica la logica delle eccezioni prevista senza usare contenuti riservati reali. È l’organizzazione a stabilire i nomi delle app e la relativa approvazione; gli esempi di prodotto citati sopra non sono raccomandazioni d’uso.

Ambito e attivazione

In Scope, limitare la policy agli utenti, ai gruppi o alle reti previsti, ad esempio selezionando un gruppo di test esistente tramite Specific Users and Groups. La pagina mostra se la policy viene applicata a Sophos Endpoint o a Sophos Firewall. In What will happen, regole, ambito ed effetto sul prodotto devono essere coerenti prima di confermare I’ve reviewed the rules and scope above.

Save salva la policy aggiuntiva senza attivarla. È così possibile verificarne prima la posizione nell’elenco. Save & Enable la attiva invece immediatamente con la priorità più alta. Per il progetto pilota preparato si consiglia quindi inizialmente Save; prima di una successiva attivazione, verificare nuovamente posizione e ambito. Questa distinzione documentata tra i pulsanti riguarda le policy aggiuntive e non va estesa indiscriminatamente al completamento della Base Policy.

I modelli in Browse templates > Use e Clone nel menu con i tre puntini possono far risparmiare lavoro. Forniscono però regole già compilate o l’ambito copiato. Entrambi vanno adattati al proprio ambiente prima del salvataggio. Le policy esistenti possono essere modificate tramite la relativa voce nell’elenco, l’icona Edit di una regola con Save Rule e Scope > Edit.

Interpretare correttamente utilizzo, rischi e report

In My Products > AI Defense, diverse viste aiutano a rispondere a domande differenti. Selezionare sempre prima il periodo appropriato tramite l’icona del calendario:

Dashboard: mostra attività complessiva, attività bloccate, app e utenti unici e distribuzione tra Allow, Block e Warn. Include inoltre app e utenti più frequenti, Shadow AI, distribuzione del rischio, flusso di utilizzo e andamento temporale. Il punteggio della postura di sicurezza, fino a 100, considera copertura dei sensori, maturità delle policy e rischio d’uso. Un valore elevato non garantisce una protezione completa.
AI Defense Activity: mostra applicazione, Actor come dispositivo, rischio, sensore, ora, azione e policy che l’ha attivata. Unknown significa che non è stato registrato un verdetto, non che l’attività sia stata sicuramente consentita. I livelli di rischio vanno da Low a Medium, High e Critical. I widget consentono ad esempio di filtrare le attività consentite; Export produce un CSV.
Inventory > Apps o Users: aiuta a verificare app e utenti effettivamente osservati. Unsanctioned Use indica l’assenza di un’approvazione esplicita, Trains on Data l’informazione registrata sull’uso dei dati per l’addestramento da parte del fornitore. La classificazione del rischio dell’app considera, tra l’altro, attestazioni di compliance e pratiche di addestramento. Nei dati di utilizzo delle app, un’attività raggruppa l’uso di un’app da parte di un dispositivo in finestre di 10 minuti. Il numero di attività non corrisponde quindi al numero di singoli prompt. Entrambi gli inventari sono esportabili in CSV.
Detections: mostra ad esempio un’app rilevata per la prima volta, un uso rischioso o l’uso di un’app non approvata. Threat score va da 0 a 10, Severity da Info a Critical. I filtri limitano i risultati per Severity, Threat Score o titolo. La vista di dettaglio offre descrizione, utente o host interessato, azione consigliata e dati sottostanti in JSON. Sono disponibili esportazioni in CSV formattato, CSV o JSON.

Nei dettagli delle app è possibile approfondire funzione, riepilogo dei rischi, regole di addestramento, compliance e uso dei dati; i dettagli delle attività riportano anche Data Residency. Queste informazioni aiutano a decidere, ma non confermano che il proprio piano specifico, account o accordo individuale sul trattamento dei dati preveda condizioni identiche.

Dopo aver analizzato una Detection, documentare nella finestra di dettaglio uno stato motivato: True positive benign, True positive malicious, False positive o Not actionable. Un utilizzo rilevato correttamente può essere innocuo; non va classificato come attacco riuscito solo perché compare una Detection.

Per un report, aprire AI Defense > Reports > AI Risk Assessment Report > Generate, scegliere Report period e, se necessario, Download PDF. Il report riunisce rischi delle app, esposizione alla Shadow AI e confronto della riduzione del rischio tra periodi di reporting. Gli elenchi dei primi cinque elementi sono selezioni, non un inventario completo. Si tratta di un report specifico di AI Defense, non di una garanzia di invio automatico dei report MDR. Le esportazioni possono contenere dati di utenti e dispositivi e devono essere conservate in un archivio con accesso limitato e tempi di conservazione concordati.

Convalidare un progetto pilota e circoscrivere gli errori

La seguente verifica è una proposta di procedura di collaudo, non un test su tenant o in laboratorio eseguito da Avanet. Concordare prima finestra di test, dispositivo, utente, servizi consentiti e azioni attese. Usare soltanto dati sintetici di test autorizzati, ad esempio Solo un test funzionale senza dati aziendali. Non trasmettere a un servizio IA dati dei clienti, credenziali, documenti interni o codice sorgente reale. Un semplice test di accesso non richiede l’inserimento di contenuti riservati.

Iniziare con un’app esplicitamente consentita, quindi verificare la regola di blocco o di avviso prevista per il progetto pilota. Per ogni tentativo, annotare servizio, dispositivo, ora ed effetto effettivo per l’utente. Con Warn deve essere possibile proseguire; con Block il percorso di accesso testato non deve essere utilizzabile.
In AI Defense Activity, confrontare applicazione, Actor, sensore, Action e Policy per lo stesso periodo. Il blocco visibile e la voce corrispondente devono coincidere con il tentativo previsto. Una pagina di blocco, da sola, potrebbe anche derivare da una precedente regola di Web Control o Application Control.
In Inventory, controllare che compaiano l’app e lo stato di approvazione previsto. Non confrontare i conteggi d’uso con i singoli inserimenti, dato il raggruppamento in finestre di 10 minuti. Usare lo stesso periodo nel report. Non è documentato un ritardo fisso di visualizzazione; non mascherare le voci mancanti ripetendo arbitrariamente i test.
Verificare anche un utente esterno al gruppo pilota o un dispositivo non coinvolto. I suoi flussi di lavoro approvati devono rimanere invariati. Ampliare gradualmente l’ambito solo dopo un collaudo documentato.

L’app non compare: verificare prima periodo, percorso di accesso effettivamente rilevato e sensore. Controllare quindi i caricamenti dei dati e, per Endpoint, le impostazioni documentate di Threat Protection, Web Control e Application Control. Per la rilevazione tramite Firewall, verificare anche il logging delle policy web. Una dashboard vuota non dimostra che non venga usata l’IA.

L’app compare, ma l’azione desiderata non ha effetto: confrontare stato di attivazione, ordine delle policy, ordine delle regole, ambito e prodotto mostrato in What will happen. Per l’applicazione tramite Firewall, verificare anche la gestione tramite gruppi. Non cercare di correggere il problema con un blocco esteso a tutta l’organizzazione o disattivando le protezioni esistenti.

Dopo una modifica, un’applicazione di lavoro non funziona più: confrontare l’ultima modifica con i valori documentati in precedenza e annullare il progetto pilota. Non creare eccezioni TLS generalizzate o regole Allow globali per nascondere l’errore.

Se un’anomalia rimane inspiegata, raccogliere eventi privi di dati sensibili, periodo con fuso orario, sensore, dispositivo, azione attesa, effetto effettivo, ordine delle policy e ambito. Queste informazioni consentono di aprire un caso di supporto Sophos senza trasmettere prompt riservati.

Ripristino e limiti della protezione

Prima del progetto pilota, registrare regole precedenti, ordine, ambito e policy dei sensori modificate. Per il ripristino, riportare una regola pilota problematica allo stato precedente tramite la modifica documentata delle policy oppure ripristinare l’ambito pilota precedentemente approvato. Verificare poi nuovamente il flusso di lavoro prima consentito e la visualizzazione delle attività. Se è stata modificata la Base Policy, ripristinarla in modo mirato sulla base del valore predefinito e delle eccezioni delle app documentati in precedenza. Restart onboarding non la reimposta.

Le modifiche ai sensori possono essere riportate soltanto ai valori precedenti specifici, se sono state effettuate appositamente per la prova e nessun’altra funzione di protezione o indagine ne dipende. In particolare, non disattivare indiscriminatamente caricamenti nel Data Lake, decrittazione TLS o Application Control. La telemetria già raccolta o i report esportati non vengono eliminati automaticamente annullando le policy. La loro gestione segue il processo concordato di protezione e conservazione dei dati.

Per la pianificazione rimangono importanti tre limiti:

La visibilità non è un controllo senza lacune. Una policy centrale, da sola, non protegge un endpoint privato non rilevato, un diverso percorso di accesso o un sensore privo dei requisiti necessari. La rilevazione di un’app non dimostra neppure che tutte le azioni autonome di un agente vengano controllate.
Il controllo di accesso alle app non garantisce una DLP dei prompt. I comunicati stampa della disponibilità generale descrivono già la verifica in tempo reale di prompt e caricamenti come funzione. Le successive informazioni per i partner collocano esplicitamente verifica e protezione dei prompt nelle release future. Finché l’ambito concreto non è confermato in modo affidabile, non pianificare alcuna protezione basata su queste funzioni e, soprattutto, non provarle con dati riservati reali.
La roadmap non è una promessa per l’acquisto. Anche la distinzione tra account IA privati e aziendali e le ulteriori funzioni di protezione degli agenti sono descritte come roadmap, senza scadenze vincolanti. Chi necessita proprio di queste funzioni deve farsele confermare per il proprio tenant prima di decidere e collaudarle separatamente.

Un punto di partenza affidabile non è quindi «ora l’IA è protetta», ma un inventario verificabile, servizi approvati consapevolmente, policy limitate e prove ripetibili dei loro effetti reali.