Costruire un controllo degli accessi basato sull’intento senza leggere nel pensiero

x`In Minority Report, il Dipartimento di Precrimine prometteva certezze. Tre precognitivi vedevano il futuro, il sistema selezionava la previsione condivisa e la polizia arrestava le persone per omicidi che non avevano ancora commesso. L’intero meccanismo dipendeva da un segreto nascosto: a volte i precognitivi erano in disaccordo e la visione dissenziente, il rapporto di minoranza, veniva silenziosamente cancellata. Il sistema funzionava finché i precognitivi erano concordi, ma si inceppava quando eliminava i propri dubbi.

Una nuova ondata di prodotti per la sicurezza punta a ottenere una capacità analoga. La proposta è più o meno questa: installare un piccolo modello di intelligenza artificiale su ogni laptop, lasciarlo osservare ciò che le persone fanno tra applicazioni, browser e strumenti di IA, proprio come farebbe un collega seduto alle loro spalle, fargli comprendere che cosa ciascuno sta cercando di fare, determinare se agisce in modo malevolo e intervenire prima che si verifichino danni. Lo stesso monitoraggio conserva una registrazione completa del lavoro, così che un analista possa ricostruire quanto accaduto anziché dover mettere insieme informazioni provenienti da log frammentati. La persona potrebbe essere un dipendente che incolla dati sensibili in un assistente IA non autorizzato, un estraneo che ha effettuato l’accesso con credenziali rubate oppure qualcuno che, seguendo le istruzioni di un truffatore, gli sta cedendo il controllo remoto del proprio laptop. Con i modelli locali, la parte relativa all’osservazione è ormai semplice. La questione progettuale è stabilire che cosa debba fare un sistema con un’inferenza sull’intento che non sarà sempre corretta.

Eliminando i dettagli architetturali, la proposta si traduce in tre promesse: individuare un’azione rischiosa in tempo per fermarla, distinguerla dalle normali attività lavorative senza sommergere gli analisti di avvisi e rendere rapida l’analisi di qualsiasi evento segnalato. Oggi è possibile realizzare un utile sistema di controllo degli accessi basato sull’intento combinando l’inferenza contestuale con policy esplicite e meccanismi di applicazione delle regole nei momenti in cui vengono eseguite azioni sensibili. La ricerca dimostra che è possibile ricostruire a posteriori quanto è accaduto, valutare quanto un’azione sia coerente con il ruolo lavorativo di una persona e introdurre un livello di attrito nel momento in cui emerge un rischio. È meno consolidata la capacità di riconoscere l’obiettivo immediato di qualcuno mentre lo sta ancora perseguendo; inoltre, distinguere in modo affidabile le motivazioni malevole da quelle legittime nelle normali attività lavorative rimane una sfida. Per questo, i sistemi operativi mettono alla prova criteri più concreti: quanto un’azione sia coerente con il ruolo della persona, quanto sia insolita per lei oppure quale obiettivo, tra un elenco ristretto, corrisponda all’azione. Ogni criterio comporta un diverso compromesso tra falsi allarmi e minacce non rilevate, e ciascuno lascia una lacuna che un imitatore può sfruttare. Ecco perché la progettazione che circonda il criterio è importante quanto il criterio stesso. Partiremo da ciò che un modello locale può leggere sullo schermo, esamineremo i criteri dal più al meno concreto, affronteremo il caso in cui l’intento appartiene a qualcun altro e concluderemo mostrando come combinare questi criteri in un sistema di controllo degli accessi.

Che cosa può leggere sullo schermo un modello locale

Ricostruire ciò che una persona ha fatto sul proprio schermo funziona già sorprendentemente bene. Cohen e colleghi hanno suddiviso il compito in due fasi. Un primo modello di piccole dimensioni riassume ogni passaggio di una breve sequenza di interazioni con l’interfaccia utente, utilizzando schermate e registrazioni delle azioni per descrivere ciò che appariva sullo schermo e ciò che l’utente faceva. Un secondo modello, ottimizzato tramite fine-tuning, deduce l’obiettivo a partire da quei riepiloghi. Utilizzando Gemini Flash 8B come modello più piccolo, questa pipeline scomposta ha dedotto l’obiettivo dell’utente con risultati paragonabili a quelli di Gemini 1.5 Pro, un modello il cui costo per token era superiore di oltre 30 volte. Il metodo di task induction di Jiang e colleghi affronta una fase ancora precedente: ricompone le tracce delle interazioni con il computer, inizialmente mescolate, riportandole ai rispettivi compiti originari, con una concordanza pressoché perfetta.

Entrambi i risultati sono retrospettivi. In tutti e due i casi, la risposta viene definita dopo l’ultima interazione. Questo approccio è adatto alla risposta agli incidenti, ma non dimostra quanto sia affidabile identificare un obiettivo mentre una persona lo sta ancora perseguendo.

I fornitori di soluzioni endpoint già affermati e i nuovi operatori stanno sviluppando prodotti basati su modelli piccoli e specializzati, capaci di prendere decisioni in tempo reale, in alcuni casi direttamente sul dispositivo. Molti si affidano soprattutto a eventi strutturati, come le operazioni di copia negli appunti, l’accesso ai file, i contenuti del browser, la provenienza dei dati e un profilo di riferimento delle normali attività di ciascuna persona. Alcuni acquisiscono schermate in corrispondenza di un incidente per utilizzarle come prove, anziché interpretare continuamente lo schermo: una scelta ragionevole, perché disporre di elementi che consentono di verificare rapidamente un avviso riduce il costo di ogni falso allarme. Gli accessi, le operazioni sui file, gli avvii dei processi e gli eventi di pagamento sono già classificati, quindi resta poco da riassumere. Nessuno degli studi qui esaminati misura il valore aggiunto in termini di sicurezza derivante dalla lettura dello schermo rispetto a questi flussi di eventi.

Il problema più difficile consiste nel dedurre l’obiettivo durante una sessione, utilizzando soltanto le informazioni disponibili fino a quel momento. GUIDE, un benchmark presentato a CVPR 2026 e costruito su 67,5 ore di attività di utenti inesperti in applicazioni come Photoshop ed Excel, ha compiuto un primo passo in questa direzione. I ricercatori hanno estratto clip della durata media di circa 25 secondi, interrompendole rispettivamente al 25%, al 50% e al 75%, e hanno chiesto ai modelli di scegliere l’obiettivo immediato dell’utente tra quattro opzioni. Con appena un quarto della clip disponibile, il modello migliore in questo esperimento basato su clip parziali ha individuato la risposta corretta circa la metà delle volte; la percentuale è salita a circa due terzi con la clip completa, mentre una scelta casuale avrebbe avuto il 25% di probabilità di successo. Anche conoscendo il compito complessivo e i possibili obiettivi immediati, i modelli sceglievano spesso quello sbagliato. I ricercatori hanno utilizzato le spiegazioni verbali degli utenti per stabilire le risposte corrette, ma alcuni intenti non erano ricostruibili osservando soltanto lo schermo.

Anche una descrizione perfetta e istantanea, da sola, non risolve nulla. «Copiare l’elenco dei clienti in una bozza di e-mail personale» è un comportamento compatibile sia con un commerciale che sta terminando il lavoro da casa, sia con uno che sta per passare a un concorrente. Per agire, un sistema deve determinare se quell’azione rientri tra le numerose attività legittime oppure costituisca un raro caso di intento malevolo.

La coerenza con il ruolo lavorativo come segnale principale

Il criterio più concreto consiste nel chiedersi se un’azione sia coerente con il proprio contesto. Facade di Google, che dal 2018 monitora l’accesso dei dipendenti a documenti, database e servizi interni, viene addestrato sulle attività storiche non etichettate, anziché su attacchi noti. Assegna un punteggio a ogni accesso in base alla sua coerenza con ciò che il sistema sa della persona e della risorsa, per esempio il ruolo, il team e le attività svolte di recente. Non è necessario definire in anticipo un elenco di obiettivi e i suoi autori riportano, nella loro valutazione, un tasso di falsi positivi a livello di evento inferiore allo 0,01%.

Una coda di revisione contenuta comporta però una capacità di rilevamento limitata. Durante un’esercitazione di red team, alcuni dipendenti di Google hanno trascorso due settimane cercando di accedere a dati sensibili al di fuori delle proprie normali attività, utilizzando le proprie credenziali. In una simulazione del processo quotidiano di revisione, Facade ha individuato da tre a quattro dei 15 attaccanti, considerando cinque modelli addestrati e un limite di dieci verifiche al giorno. Un costo che gli autori definiscono sorprendentemente basso per un’azienda con oltre 100.000 dipendenti.

Gli stessi autori evidenziano esplicitamente il punto debole del sistema: Facade non è in grado di rilevare azioni malevole indistinguibili dalle normali attività lavorative. Per questo non è adatto a individuare un dipendente infedele che consulta file pertinenti al proprio ruolo.

Le deviazioni richiedono un budget di revisione

La maggior parte delle ricerche sulle minacce interne segue una strada meno concreta: apprendere il comportamento abituale di ciascuna persona e segnalare ciò che se ne discosta. Le implementazioni reali, tuttavia, mostrano quanto siano numerose le deviazioni ordinarie. Quando Erola e colleghi hanno utilizzato uno strumento per il rilevamento delle minacce interne in tre multinazionali, configurazioni volutamente ampie hanno generato circa 356 avvisi anomali al giorno in una delle organizzazioni e 3.713 in un’altra. Il gruppo ha rilevato uno scenario simulato di minaccia interna, ma non è riuscito a stabilire quanta parte dei comportamenti ordinari segnalati fosse effettivamente malevola. Gli autori hanno constatato che il comportamento reale si discosta molto più spesso dalla norma rispetto a quanto suggeriscano i dati sintetici utilizzati nella maggior parte delle ricerche.

I benchmark sintetici restituiscono risultati lusinghieri. Un’analisi di 131 studi basati sui dataset CERT relativi alle minacce interne ha rilevato che quasi la metà utilizza una versione del dataset contenente 70 utenti malevoli su 1.000; pochi studi, inoltre, indicano quanti avvisi un analista dovrebbe esaminare per individuarli.

Anche i sistemi di rilevamento dei movimenti laterali mostrano lo stesso schema. Quando Larroche ha ripetuto i test di Euler e Argus mantenendo tutti gli accessi remoti nel periodo di prova del Los Alamos National Laboratory, entrambi hanno continuato a ottenere un’AUC di circa il 98%. Questa metrica misura quanto spesso un attacco casuale riceva un punteggio superiore rispetto a un accesso legittimo casuale. Tuttavia, quando gli eventi malevoli etichettati erano appena due circa per milione, la precisione media è scesa sotto lo 0,1% per entrambi i sistemi, rispetto al 5% e al 32% riportati nei dataset di prova originali, filtrati in modo più selettivo.

Anche le deviazioni possono essere manipolate. Goyal e colleghi hanno arricchito gli attacchi con attività ordinarie campionate dal sistema bersaglio, riportando un tasso di elusione del 100% contro cinque sistemi di rilevamento nei principali esperimenti condotti su dataset pubblici, senza modificare il payload malevolo.

Obiettivi predefiniti per scenari noti

I metodi di riconoscimento degli obiettivi basati su un insieme di candidati classificano obiettivi definiti in precedenza. Non affrontano però il problema di costruire un simile elenco per una sessione desktop aperta, durante la quale un utente potrebbe svolgere attività molto diverse, dalla modifica di un rapporto trimestrale all’esfiltrazione di un database. I prodotti commerciali aggirano il problema restringendo le opzioni a poche etichette di rischio o categorie di policy. I sistemi che analizzano lo schermo, come quello di Cohen, evitano invece di utilizzare un elenco predefinito, descrivendo l’intento con parole proprie: una scelta che introduce un problema diverso. Uno strumento di sicurezza dovrebbe comunque stabilire se un’ipotesi in testo libero come «esportare l’elenco dei clienti» sia malevola.

Una deviazione può indicare un obiettivo nascosto, ma anche una persona disorientata, di fretta o intenta a provare una soluzione che non ha funzionato. Per distinguere questi casi occorre innanzitutto riconoscere la confusione, capacità che gli attuali modelli di visione spesso non possiedono. Nelle registrazioni dello schermo di utenti inesperti reali utilizzate da GUIDE, la matrice di confusione riportata ha classificato correttamente soltanto il 7% delle sequenze caratterizzate da frustrazione e il 4% di quelle di debugging. La maggior parte di questi momenti è stata etichettata come lavoro svolto con sicurezza o esplorazione intenzionale: clic ripetuti, annullamenti ed esitazioni sono stati interpretati come progressi deliberati. Uno strumento di sicurezza che scambia la difficoltà per intenzionalità potrebbe attribuire a una deviazione un significato molto più preciso di quello reale.

Alcuni prodotti si spingono oltre, assegnando categorie di minaccia: malevolo, negligente o compromesso. La promessa è una risposta proporzionata: un intervento di sensibilizzazione per il dipendente negligente e un’indagine per quello malevolo. Queste etichette, però, mescolano intento, comportamento e identità di chi controlla l’account. Distinguere le motivazioni malevole da quelle legittime è più difficile che riconoscere l’obiettivo immediato, e le prove necessarie per chiarire la situazione potrebbero non essere disponibili sull’endpoint nel momento in cui viene eseguita l’azione. Facade evita deliberatamente queste etichette. Il suo modello di minaccia considera allo stesso modo un dipendente infedele e un dipendente le cui credenziali rubate vengono utilizzate da qualcun altro, perché in entrambi i casi il comportamento appare insolito per quella persona.

I sistemi che rilevano obiettivi predefiniti trasformano motivazioni e fattori di rischio in scenari specifici. Una recente rassegna sulla psicologia delle minacce interne esamina pressioni finanziarie, risentimenti sul posto di lavoro e ideologia, oltre a una categoria distinta di danni accidentali o dovuti a negligenza. Nell’ambito del programma sulle minacce interne della DARPA, Senator e colleghi hanno sviluppato un sistema di rilevamento per ciascuno di diversi scenari, tra cui il sabotatore, il truffatore, l’utente negligente e il dipendente che sottrae proprietà intellettuale. Li hanno poi testati su due mesi di attività informatiche monitorate di circa 5.500 dipendenti, inserendo scenari simulati di attacco nei registri di utenti reali.

Il migliore di questi sistemi, progettato per individuare il responsabile di un piccolo gruppo impegnato a sottrarre proprietà intellettuale, ha incluso sei giornate-utente del red team tra le prime 50 nel mese di ottobre. A settembre, invece, aveva ignorato 33 delle 98 giornate-utente del red team, perché non corrispondevano allo scenario previsto. Un obiettivo predefinito presuppone che l’attaccante segua una storia scritta in anticipo. I comportamenti che esulano da quello scenario possono sfuggire al rilevamento, e un attaccante adattivo ha motivo di sfruttare questa lacuna. Lo studio non ha verificato questa forma di elusione deliberata.

Introdurre un livello di attrito quando l’intento appartiene a qualcun altro

Non sempre l’intento appartiene alla persona seduta davanti alla tastiera. Un cliente guidato telefonicamente da un truffatore può accedere al proprio account dal proprio dispositivo, superare l’autenticazione e autorizzare personalmente il pagamento, senza lasciare i consueti segnali di una compromissione dell’account. Lo studio teorico di Dhama formalizza un caso limite: se i pagamenti fraudolenti e quelli legittimi presentano distribuzioni identiche delle caratteristiche osservabili, un sistema di rilevamento basato esclusivamente sulle transazioni non può distinguerli. L’articolo sostiene che sia necessario aggiungere il contesto della sessione e riconosce l’importanza di indizi relativi agli importi, ai destinatari e alle tempistiche.

Il rilevamento delle truffe potrebbe essere uno degli ambiti in cui l’analisi dello schermo offre il maggiore valore aggiunto. Una truffa in corso può lasciare tracce che non compaiono mai nei dati di pagamento, come uno strumento di accesso remoto attivo durante una sessione bancaria o una finestra di chat che indica il beneficiario del pagamento. ORACLE analizza l’utilizzo delle applicazioni e i contenuti sintetizzati dello schermo per lanciare un avviso prima che la truffa venga portata a termine. Tuttavia, il sistema è stato testato su sequenze di interazioni sintetizzate: resta quindi da verificare se sia in grado di individuare truffe reali mantenendo un tasso di falsi allarmi accettabile per una banca.

Introdurre un livello di attrito al momento del pagamento può essere utile anche senza rilevare direttamente la truffa. In un test sul campo condotto su Alipay, l’avviso riprogettato che ha ottenuto i risultati migliori ha ridotto il tasso di frode tra i pagamenti già segnalati come rischiosi dallo 0,24% allo 0,13%. Entrambi gli avvisi riprogettati hanno mantenuto tassi di completamento dichiarati superiori al 90%.

I truffatori, tuttavia, si adattano anche a queste misure. L’autorità britannica di regolamentazione dei pagamenti ha riferito che alcuni criminali istruiscono le vittime affinché ignorino gli avvisi relativi alla mancata corrispondenza tra il nome del beneficiario e quello dell’intestatario del conto. In alcuni casi, spiegano che sarebbe stato appena aperto un nuovo «conto sicuro», il cui nome non potrebbe ancora corrispondere.

Conservare il rapporto di minoranza

Per prevenire un incidente, conoscere l’obiettivo è utile soltanto se lo si identifica quando c’è ancora tempo per intervenire. I prodotti che promettono di bloccare un’azione prima che venga completata agiscono perlopiù nella fase finale, per esempio al momento del caricamento di un file, attraverso un avviso, una richiesta di motivazione, l’oscuramento dei dati o un blocco.

Quando il criterio applicato in quella fase non consente di risolvere la questione, il sistema può comunque decidere di chiedere un chiarimento. KnowNo, sviluppato da Ren e colleghi, mostra un modo per stabilire quando farlo. Un modello linguistico legge una descrizione testuale della situazione e propone possibili azioni successive per un robot. KnowNo conserva tutte le opzioni che raggiungono o superano una soglia calibrata su esempi di attività non utilizzati durante l’addestramento. Se rimane una sola opzione, il robot agisce. In caso contrario, richiede l’intervento umano; se l’azione corretta non è compresa nell’insieme delle opzioni, si ferma.

È questo il rapporto di minoranza. Quando sopravvive più di un’opzione, il sistema segnala la presenza di una previsione discordante. Nel film, quel segnale veniva cancellato per mantenere l’illusione della certezza. La ricerca, invece, lo conserva e lo utilizza per decidere quando è necessario l’intervento umano. Il paradosso di Jev sosteneva che la fiducia diventa utile sul piano operativo quando determina una strategia decisionale.

Le richieste di chiarimento sono già presenti nei prodotti commerciali: diversi sistemi mostrano una richiesta di motivazione o un messaggio di orientamento quando l’intento non è chiaro. Porre una domanda costa molto meno che bloccare prematuramente un’azione. Il sistema può quindi intervenire anche nei casi incerti senza sostenere l’intero costo di un falso allarme.

Come combinare i criteri in un sistema di controllo degli accessi

Ogni criterio esaminato in questo articolo presenta punti deboli diversi: è proprio questo il motivo per cui conviene combinarli. Le policy esplicite si applicano nel momento in cui viene eseguita un’azione sensibile, come un caricamento, una condivisione, un pagamento o una sessione di accesso remoto, e stabiliscono quali operazioni siano consentite. La valutazione della coerenza con il ruolo lavorativo, come quella utilizzata da Facade, assegna un punteggio alle azioni che superano questo primo filtro, grazie al tasso di falsi positivi dichiarato inferiore allo 0,01% e senza bisogno di un elenco predefinito di obiettivi. La deviazione dal comportamento abituale di una persona diventa un elemento di quel punteggio: una giornata insolita ma plausibile può aumentare la priorità di un evento senza generare automaticamente un avviso. Gli scenari predefiniti coprono infine i pochi schemi per i quali vale la pena definire regole in anticipo, come un dipendente in procinto di lasciare l’azienda che prepara file da sottrarre oppure uno strumento di accesso remoto attivo mentre qualcuno autorizza un pagamento. In questi casi, un sistema specializzato può essere molto efficace nel riconoscere lo schema per cui è stato progettato, lasciando agli altri livelli il compito di gestire tutto il resto.

Quando gli elementi raccolti nel loro insieme lasciano ancora spazio a più interpretazioni plausibili, il sistema conserva il rapporto di minoranza. Un insieme calibrato di interpretazioni permette di scegliere se agire, chiedere chiarimenti o sottoporre il caso a un livello di analisi superiore. Se rimane una sola interpretazione, la policy può consentire o bloccare l’azione. Se ne rimangono diverse, il sistema richiede una motivazione, attiva una verifica aggiuntiva dell’identità oppure impone una breve sospensione; le prove raccolte durante la sessione vengono trasmesse all’analista insieme alla decisione. Le risposte alle richieste di chiarimento vengono fornite all’analista come elementi da valutare, perché la persona che ha il maggiore interesse a giustificare un’azione è anche quella di cui il sistema può fidarsi meno ciecamente.

I criteri di valutazione devono tenere conto della distribuzione effettiva degli eventi. I numeri importanti sono gli attaccanti individuati a parità di verifiche giornaliere, la precisione media rispetto all’intero insieme di attività legittime e la frequenza con cui viene interrotto il lavoro regolare: sono questi, infatti, i costi che un team sperimenta concretamente. Le esercitazioni di red team dovrebbero includere anche tentativi di imitazione, aggiungendo alle azioni malevole attività ordinarie come hanno fatto Goyal e colleghi, così da misurare la capacità del sistema di resistere a un attaccante che conosce i suoi filtri.

L’implementazione può iniziare da un flusso di lavoro circoscritto, come l’invio di dati dei clienti a un servizio di IA esterno. In una prima fase, la valutazione contestuale opera in modalità di osservazione, misurando quanti attacchi vengono individuati entro un budget fisso di verifiche e quanto spesso verrebbe interrotto il lavoro legittimo. Le violazioni evidenti delle policy possono giustificare un intervento immediato. Le risposte che dipendono dall’intento dedotto possono essere ampliate man mano che le valutazioni dimostrano quali interventi prevengono i danni a un costo accettabile per le normali attività lavorative.

I casi di elusione basati sull’imitazione descritti in questo articolo sono punti deboli documentati. Tuttavia, la frequenza con cui si verificano nelle implementazioni reali e la capacità di questi criteri di resistere ad attaccanti adattivi rimangono in gran parte non misurate. In ambito sicurezza, l’inganno è la norma e si nasconde all’interno delle distribuzioni statistiche di base, nelle quali quasi tutto è legittimo.

Il sistema di Precrimine crollò per mano di Lamar Burgess, l’uomo che lo aveva costruito. Sapeva che il sistema scartava le visioni ripetute considerandole semplici echi e organizzò quindi un omicidio in modo che sembrasse tale. È l’imitatore messo in guardia in ogni sezione di questo articolo: un avversario che impara che cosa il sistema considera normale, che si tratti di un file pertinente al ruolo lavorativo, di una sessione ordinaria o di uno scenario per il quale il sistema di rilevamento non è stato progettato, e si nasconde al suo interno. Il modello migliore conserva il rapporto di minoranza. Quando il criterio non consente di arrivare a una conclusione, chiede all’utente, attende, introduce un livello di attrito oppure segnala l’ambiguità a un analista, partendo dal presupposto che chi conosce meglio i filtri del sistema è anche chi ha maggiori probabilità di sfruttarli.

Per un utente umano, uno strumento di sicurezza deve generalmente dedurre sia il compito sia la natura dell’azione. Nel caso di un agente di IA, invece, l’obiettivo viene dichiarato per iscritto, ma anche l’attacco può essere formulato in questi termini e un’istruzione iniettata può far apparire un sabotaggio come un progresso. È proprio questo a rendere gli agenti l’ambito in cui il controllo degli accessi basato sull’intento può essere più preciso, perché ogni azione può essere verificata rispetto al compito dichiarato. Il prossimo articolo esaminerà che cosa serve per vincolare un agente al compito che gli è stato assegnato.

La ricerca e il supporto alla stesura dell’articolo sono stati forniti da Hermes, un assistente IA. Le sue deviazioni dalla traccia erano dovute a confusione, non a tentativi di occultamento, ma Hermes comprende perché, dall’esterno, sia difficile distinguere le due cose.