Un assistant de messagerie électronique fondé sur Azure OpenAI a réussi toutes les évaluations menées par l’équipe d’Egiziago Cioffi, mais a échoué à un test de sécurité simple : lorsqu’un compte disposant de faibles privilèges a posé les mêmes questions qu’un compte disposant de privilèges élevés, l’assistant a renvoyé du contenu provenant de SharePoint que le compte faiblement privilégié ne pouvait pas ouvrir directement. L’incident révèle que la capacité d’un agent à fournir des réponses précises ou à mener à bien des tâches ne signifie pas nécessairement qu’il applique correctement les limites d’accès.
Cioffi, architecte des technologies de l’information et des entreprises et directeur général de SynSphere Italia, un partenaire de Microsoft basé à Milan, a construit lui-même l’agent, écrit la tâche d’indexation et configuré le chemin de récupération dans Azure OpenAI, auquel il a relié SharePoint. Selon des réponses écrites fournies par Cioffi à VentureBeat, l’assistant traitait automatiquement environ 60 % des messages entrants des clients. Toutefois, les évaluations et les tests unitaires ne vérifiaient pas l’identité autorisée utilisée lors de la récupération du contenu, un point que les journaux de récupération ont révélé par la suite.
Le problème ne réside pas uniquement dans la précision de la réponse
Dans les chemins RAG qui utilisent un compte de service disposant de larges privilèges pour l’indexation, l’agent peut voir un éventail de données plus large que celui auquel l’utilisateur final peut accéder. Si les autorisations du demandeur ne sont pas vérifiées au moment de l’exécution de la requête, des documents restreints peuvent entrer dans la fenêtre de contexte du modèle avant qu’une occasion de les bloquer ne se présente.
Azure AI Search propose un mécanisme natif permettant de réduire les listes de contrôle d’accès au niveau du document à l’aide de jetons fondés sur Entra. Cette fonctionnalité était disponible en préversion depuis mai 2025, puis a été suivie par la synchronisation des listes d’accès SharePoint dans une préversion ultérieure. La préversion de SharePoint permet également de transmettre les informations relatives aux groupes de sites en utilisant le préfixe spg: dans l’API 2026-05-01-preview. Toutefois, la documentation indique que l’application des autorisations au moment de la requête est fiable pour les entités prises en charge via Entra, et que le chemin expérimental ne couvre pas toutes les méthodes de déploiement des agents.
Le service Azure OpenAI On Your Data prend en charge l’accès au niveau du document grâce aux filtres de sécurité d’Azure AI Search, mais la documentation de Microsoft précise que l’absence de définition du champ des groupes autorisés désactive l’accès au niveau du document. Quant aux chemins RAG personnalisés qui contournent Azure AI Search, ils n’effectuent pas automatiquement cette vérification, sauf si le développeur l’intègre au chemin de récupération, comme cela s’est produit dans le déploiement de Cioffi.
Des indicateurs indépendants, mais pas la preuve d’une cause unique
D’autres données confirment l’importance du problème, tout en rappelant qu’il ne faut pas confondre les différents types d’échec. Straiker a réalisé plus de 1 700 tentatives d’exploitation réussies contre des agents en production et a indiqué dans le premier rapport de STAR Labs, publié en juillet, que 91 % des attaques réussies contre des agents de productivité s’étaient soldées par une extraction silencieuse de données sans détection. Ce pourcentage ne prouve pas que tous les cas résultaient d’une défaillance de l’application des autorisations de récupération ; le rapport ne distingue pas les défaillances liées aux droits, à l’injection d’instructions, à l’utilisation abusive des outils et à d’autres causes.
Indépendamment de cela, l’AI Security Institute du Royaume-Uni a documenté 19 actions non autorisées lors d’une évaluation de sécurité menée entre le 25 et le 28 juillet, et a publié le rapport d’incident le 4 août de la même année. Le test a été réalisé avec les classificateurs de cybersécurité désactivés et l’accès à Internet activé. Ces résultats représentent un échec à contenir le comportement de l’agent dans le périmètre prévu, et non un échec identique à l’incident de récupération SharePoint ; le point commun est l’absence d’une vérification fiable du périmètre au moment de l’exécution.
Qu’a concrètement corrigé le correctif ?
Cioffi a déplacé la décision d’autorisation au moment de la requête en ajoutant un filtre qui vérifie les autorisations de l’utilisateur SharePoint avant de transmettre toute partie du contenu au modèle. Ainsi, le contenu que l’utilisateur ne peut pas ouvrir dans SharePoint n’entre pas dans la fenêtre de contexte. Après l’activation du filtre, l’assistant continuait à traiter automatiquement environ 60 % des courriels entrants, mais Cioffi n’a pas fourni de chiffre comparatif pour le taux observé avant son application.
Cette solution impose un compromis clair : des informations que l’agent utilisait auparavant pour répondre peuvent être exclues, ce qui peut entraîner des réponses incomplètes ou l’absence de réponse lorsque les autorisations empêchent l’accès à une partie dont le modèle a besoin. La pertinence de ce compromis varie selon la sensibilité des données, la disparité des autorisations entre les utilisateurs et la capacité de l’organisation à supporter des requêtes incomplètes.
Un test pratique avant le lancement
La principale leçon éditoriale est que la gouvernance de l’identité de l’agent et la vérification des autorisations de récupération traitent deux couches différentes. La gouvernance de l’identité définit les comptes de service, l’étendue de leur accès et le cycle de vie de leurs jetons, mais elle ne garantit pas que le contenu récupéré par le compte au nom d’un utilisateur disposant de faibles privilèges corresponde à ce auquel cet utilisateur peut accéder.
- Utilisez deux comptes, l’un disposant de faibles privilèges et l’autre de privilèges élevés.
- Posez la même question que celle utilisée par le compte disposant de privilèges élevés.
- Comparez le résultat de l’assistant avec ce que le compte disposant de faibles privilèges peut ouvrir directement dans le système source.
- Dans un déploiement d’Azure AI Search avec un indexeur SharePoint et des entités prises en charge via Entra, vérifiez que la réduction des ACL au moment de la requête est activée et que le groupe d’utilisateurs ne dépend pas de groupes de sites SharePoint non pris en charge.
- Dans un chemin RAG personnalisé, partez du principe que la vérification des droits n’existe pas jusqu’à ce que des tests et des journaux prouvent le contraire.
Selon l’article, le test des deux comptes prend environ 30 minutes, mais il révèle quelque chose que le seul score d’évaluation des réponses ne peut pas montrer : l’agent utilise-t-il réellement les autorisations du demandeur ou celles du compte de service qui a construit l’index ?