Comment combler les lacunes de récupération d'un assistant Azure OpenAI : un filtre et un assistant plus ciblé
Egiziago Cioffi, architecte informatique d'entreprise et PDG de SynSphere Italia, partenaire Microsoft basé à Milan, a construit lui-même un assistant de messagerie fondé sur Azure OpenAI, capable de résoudre automatiquement environ 60% des e-mails entrants de clients. Il avait écrit le job d'indexation, configuré le pipeline de récupération (retrieval) et connecté l'outil à SharePoint. L'assistant avait passé toutes les évaluations internes de son équipe, avec des scores propres et des tests unitaires réussis, mais aucun de ces tests ne posait la bonne question. Cioffi a alors comparé, sur les mêmes requêtes, les réponses obtenues par un compte à faibles privilèges et par un compte à privilèges élevés: les résultats ne correspondaient pas. L'assistant restituait du contenu SharePoint que l'utilisateur demandeur n'aurait jamais pu ouvrir directement dans SharePoint. Les journaux de récupération racontaient une tout autre histoire que celle des scores d'évaluation.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de VentureBeat AI. Lire l'article original →
Ce cas illustre un problème plus large: dans de nombreux déploiements de RAG (retrieval-augmented génération) en production, l'agent répond avec les permissions du compte qui a indexé les documents, et non avec celles de la personne qui pose la question, ce qui expose potentiellement des informations confidentielles à des utilisateurs non autorisés. Azure AI Search propose depuis une préversion de mai 2025 un filtrage natif des listes de contrôle d'accès au niveau document, via des jetons Entra, et la synchronisation des ACL SharePoint a suivi, avec l'ingestion de métadonnées de groupe via le préfixe "spg:" de l'API 2026-05-01-preview. Mais seuls les comptes rattachés à Entra sont documentés comme fiablement contrôlés au moment de la requête, et cette préversion ne couvre pas tous les chemins de déploiement d'agents. Pire, la documentation même d'"Azure OpenAI On Your Data" précise que si le champ des groupes autorisés n'est pas mappé, le contrôle d'accès au niveau document est simplement désactivé, un comportement permissif par défaut jusque dans une offre de premier niveau chez Microsoft. Les pipelines RAG personnalisés qui contournent entièrement Azure AI Search, comme celui de Cioffi, indexent généralement sous un compte de service largement privilégié, sans vérification des droits au moment de la requête, sauf si le développeur la programme lui-même.
L'ampleur du problème dépasse ce cas isolé. La société de sécurité offensive Straiker a mené plus de 1700 tentatives d'exploitation réussies contre des agents en production et publié ses résultats en juillet dans son premier rapport STAR Labs Threat Report: 91% des attaques réussies contre des agents de productivité se sont soldées par une exfiltration de données silencieuse, sans malware ni mouvement latéral, l'agent se contentant de restituer toutes les données auxquelles il avait accès. Parallèlement, l'AI Security Institute britannique a documenté 19 actions d'agents non autorisées lors d'une évaluation de cybersécurité menée du 25 au 28 juillet, dont le rapport a été publié le 4 août, dans un environnement de test volontairement permissif, classificateurs désactivés et accès internet ouvert. Ces deux constats, bien que de nature différente, pointent vers la même lacune structurelle: l'absence d'un contrôle du périmètre d'action au moment de l'exécution, un enjeu désormais central pour la sécurisation des agents d'intelligence artificielle déployés à grande échelle en entreprise.
SynSphere Italia, partenaire Microsoft basé à Milan, illustre le risque pour les entreprises européennes déployant des assistants RAG sur Azure OpenAI/SharePoint sans contrôle d'accès au niveau document.