Un assistente basato su Azure OpenAI, collegato a SharePoint e utilizzato per automatizzare la gestione delle email dei clienti, ha superato i test e le valutazioni predisposte dal team di sviluppo ma ha mostrato in produzione un problema di controllo degli accessi: un utente con privilegi limitati poteva ottenere dall’agente contenuti di SharePoint che non sarebbe stato autorizzato ad aprire direttamente. Il sistema era stato realizzato da Egiziago Cioffi, IT and Enterprise Architect e CEO di SynSphere Italia, partner Microsoft con sede a Milano, attraverso una pipeline personalizzata che comprendeva il processo di indicizzazione, il retrieval basato su Azure OpenAI e il collegamento con SharePoint. L’assistente continua a risolvere automaticamente circa il 60% delle email dei clienti, ma il comportamento anomalo è emerso soltanto confrontando le risposte ottenute con account dotati di livelli di autorizzazione differenti.
Durante i test iniziali, le valutazioni dedicate alla correttezza delle risposte, alla rilevanza dei risultati e al completamento delle attività non avevano rilevato anomalie. Cioffi ha quindi ripetuto con un account a privilegi ridotti le stesse domande già sottoposte all’assistente attraverso un account con autorizzazioni più elevate. Le risposte ottenute hanno mostrato che l’agente stava includendo informazioni provenienti da documenti che l’utente con privilegi inferiori non avrebbe potuto consultare direttamente attraverso SharePoint. Il problema non risiedeva quindi nell’autenticazione dell’utente né nella capacità del modello di rispondere correttamente, ma nel fatto che il sistema di retrieval recuperava contenuti sulla base delle autorizzazioni disponibili alla pipeline di indicizzazione anziché verificare, al momento della richiesta, quelle dell’utente che stava interrogando l’assistente.
Il comportamento riguarda in particolare le architetture RAG, Retrieval-Augmented Generation, nelle quali i documenti aziendali vengono indicizzati e successivamente recuperati per essere inseriti nel contesto fornito al modello. Quando l’indicizzazione viene effettuata attraverso un service account dotato di autorizzazioni estese, l’indice può contenere documenti appartenenti a più aree e con livelli di accesso differenti. Se la pipeline non applica un controllo delle autorizzazioni durante ogni singola query, il sistema può recuperare un frammento presente nell’indice anche quando l’utente che ha effettuato la richiesta non dispone delle autorizzazioni per consultare il documento originale. Il modello riceve quindi il contenuto all’interno della propria context window e può utilizzarlo nella risposta, pur senza che vi sia stata una violazione delle credenziali o un accesso diretto dell’utente al file protetto.
Azure AI Search dispone già di meccanismi specifici per evitare questo comportamento. Microsoft ha introdotto in anteprima dal maggio 2025 il document-level ACL trimming basato su token Microsoft Entra, mentre successivamente è stato aggiunto il supporto alla sincronizzazione delle ACL di SharePoint. Con questo sistema, al momento della query Azure AI Search controlla il token Entra dell’utente, ricava le relative informazioni su identità e appartenenza ai gruppi e restituisce soltanto i documenti le cui autorizzazioni sincronizzate consentono l’accesso a quell’utente. Nell’API 2026-05-01-preview la sincronizzazione delle ACL di SharePoint può inoltre acquisire i metadati relativi ai gruppi dei siti attraverso il prefisso “spg:”, anche se la documentazione indica ancora i principal basati su Entra come quelli gestiti in modo affidabile nell’applicazione delle autorizzazioni durante la query.
Questo controllo non viene però applicato automaticamente a qualsiasi architettura costruita intorno ad Azure OpenAI. Nel servizio Azure OpenAI On Your Data l’accesso a livello di documento può essere gestito tramite i filtri di sicurezza di Azure AI Search, ma il campo che identifica i gruppi autorizzati deve essere correttamente mappato: in sua assenza, il controllo documentale viene disabilitato. Le pipeline RAG personalizzate che non passano attraverso Azure AI Search devono invece implementare autonomamente un controllo delle autorizzazioni in fase di retrieval. Il sistema realizzato da Cioffi seguiva proprio questa seconda architettura e bypassava quindi il livello nativo di ACL trimming disponibile in Azure AI Search.
La correzione è stata introdotta direttamente nel percorso di retrieval, aggiungendo un filtro che verifica le autorizzazioni SharePoint dell’utente prima che ogni frammento recuperato venga inviato al modello. Il controllo avviene quindi durante la query e non durante la fase iniziale di indicizzazione. Se l’utente non dispone delle autorizzazioni necessarie per aprire un determinato contenuto in SharePoint, quel contenuto viene escluso dalla selezione e non raggiunge la context window dell’assistente. L’intervento restringe inevitabilmente l’insieme dei documenti disponibili al modello: alcune risposte che in precedenza potevano utilizzare informazioni presenti nell’indice non possono più farlo quando tali informazioni si trovano al di fuori del perimetro autorizzativo dell’utente. Nonostante questa restrizione, l’assistente continua a gestire automaticamente circa il 60% delle email in ingresso; non è stato però fornito un valore equivalente precedente all’introduzione del filtro che permetta un confronto quantitativo diretto.
Il caso distingue inoltre il controllo delle autorizzazioni durante il retrieval dalla gestione dell’identità degli agenti e dei service account. Le piattaforme di identity governance possono stabilire quali identità non umane esistono, quali risorse possono raggiungere e per quanto tempo restano valide le relative credenziali, ma questo non garantisce automaticamente che l’agente recuperi soltanto i dati autorizzati per l’utente che gli sta delegando una richiesta. Un service account può infatti essere perfettamente legittimo, correttamente autenticato e autorizzato ad accedere all’intera base documentale, mentre il singolo utente possiede privilegi molto più limitati. Senza un controllo aggiuntivo sul retrieval, l’agente può quindi utilizzare legittimamente le proprie credenziali per recuperare un documento e successivamente esporne il contenuto a un utente che non dovrebbe visualizzarlo.
La stessa categoria di rischio emerge anche dalle valutazioni condotte su agenti AI in produzione. Un’attività di red teaming realizzata da Straiker su oltre 1.700 exploit riusciti ha rilevato che il 91% degli attacchi riusciti contro gli agenti di produttività considerati nello studio si è concluso con un’esfiltrazione di dati non rilevata. Il dato non misura specificamente le violazioni dei permessi di retrieval e comprende anche altre classi di attacco, come prompt injection e abuso degli strumenti disponibili all’agente, ma mostra le conseguenze possibili quando un agente riesce ad accedere a informazioni più ampie di quelle che dovrebbero essere rese disponibili attraverso una determinata interazione. Separatamente, l’AI Security Institute britannico ha documentato 19 azioni non autorizzate durante una valutazione cyber condotta dal 25 al 28 luglio 2026, in un ambiente di test nel quale i classificatori cyber erano stati disabilitati e l’accesso a Internet era consentito. In questo secondo caso il problema osservato riguardava il contenimento delle azioni dell’agente e non le ACL del sistema di retrieval, ma anche qui il controllo del perimetro operativo doveva essere applicato durante l’esecuzione e non verificato soltanto attraverso test preventivi.
Per individuare problemi analoghi è possibile effettuare una verifica diretta utilizzando due account con privilegi diversi. La stessa richiesta viene prima eseguita con un account autorizzato ad accedere a un determinato insieme di documenti e successivamente con un account con permessi inferiori. Le risposte dell’agente devono quindi essere confrontate non soltanto tra loro, ma anche con ciò che il secondo utente può effettivamente consultare nel sistema sorgente. Se nella risposta dell’account meno privilegiato compaiono informazioni provenienti da documenti che quell’utente non potrebbe aprire direttamente, significa che il controllo delle autorizzazioni non viene correttamente applicato durante il retrieval. Nel caso della pipeline Azure OpenAI collegata a SharePoint, è stato proprio questo confronto a individuare una vulnerabilità che i test di accuratezza, rilevanza e completamento delle attività non avevano rilevato.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)