L’assistant lit un document.
Qui peut lire sa trace ?

Microsoft a annoncé la disponibilité générale de son outil Browser Automation pour Foundry le 19 octobre 2026. L’élément RSS correspondant établit la date de publication ; son texte intégral contient aussi l’avertissement sur les traces sensibles. L’annonce précise que les traces peuvent contenir les requêtes, les réponses du modèle, les instructions système ainsi que les arguments ou résultats des appels d’outils. Elle renvoie vers une procédure de protection documentée en préversion. L’analyse porte sur cette frontière précise du traitement des données, pas sur la disponibilité de tous les composants de navigation associés. La documentation Microsoft indique que les éléments en préversion sont fournis sans accord de niveau de service et ne sont pas recommandés pour les charges de production ; certaines capacités peuvent être limitées ou non prises en charge. L’annonce ne lève pas ces réserves.

La distinction pratique sépare le droit de lire le document source du droit de lire le contenu enregistré pendant le travail de l’assistant. Microsoft classe comme sensibles les messages d’entrée et de sortie, les instructions système, les définitions d’outils, les arguments et résultats de leurs appels, ainsi que les explications d’évaluation. Demandez lesquels pourraient contenir du texte documentaire dans le flux envisagé et ce que la configuration des traces collecte réellement. Un acheteur de la finance ou de l’assurance pourrait demander si les résultats d’outils reprennent des extraits de documents clients ; un industriel pourrait poser la même question pour des spécifications fournisseurs ou du texte de plans. Ce sont des questions d’évaluation, pas des déploiements rapportés ni des observations.

Selon Microsoft, avant le 30 septembre 2026, Application Insights envoyait les sept attributs à la fois vers AppGenAIContent et vers les tables existantes AppDependencies, AppTraces et AppEvents. À partir de cette date, les valeurs nouvellement ingérées ne sont plus envoyées à ces dernières ; les clés y restent, accompagnées de courts pointeurs vers AppGenAIContent. L’adoption anticipée utilisait l’indicateur protectGenAISensitiveData. Cependant, optOutProtectGenAISensitiveData permet de maintenir temporairement l’ancien routage pendant la mise à jour des requêtes personnalisées et des éléments associés. Microsoft précise que cette dérogation prendra fin le 30 septembre 2027 ; désinscrire l’indicateur permet de revenir plus tôt au routage vers la table dédiée. Demandez la configuration réelle de l’abonnement et une trace récente, plutôt que de déduire l’état du seul calendrier. Vérifiez ensuite séparément le niveau de protection : envoyer le contenu vers AppGenAIContent ne revient pas à définir cette table comme Protected.

La documentation Microsoft décrit un modèle de refus par défaut une fois la table définie comme Protected. Le rôle intégré Privileged Monitoring Data Reader donne accès à toutes les tables protégées dans son périmètre d’attribution : ce périmètre est donc déterminant. Pour lire le contenu sensible via Foundry et Application Insights, la documentation Foundry désigne la ressource Application Insights liée ; les requêtes directes centrées sur l’espace de travail exigent l’attribution correspondante sur cet espace. Le rôle intégré n’est pas la seule voie possible. La documentation prévoit explicitement des rôles personnalisés dotés des DataActions Azure Monitor requises ; les instructions sur les tables protégées décrivent des attributions ciblées avec des conditions ABAC portant sur le nom de la table et son niveau de protection. Demandez à l’administrateur les attributions effectives et leurs conditions, pas seulement les noms des rôles. Ces instructions présentent aussi le mode DataActionsOnly, qui supprime l’accès implicite aux journaux via certains rôles du plan de contrôle. Vérifiez s’il s’applique dans l’espace concerné, sans présumer qu’il est activé.

Utilisez une entrée de test autorisée et non sensible, puis consignez la visibilité attendue avant l’essai. Les instructions Microsoft distinguent un Log Analytics Reader sans accès privilégié ni droit personnalisé admissible d’un lecteur disposant d’une autorisation adaptée. Dans le contrôle documenté, la requête du premier réussit mais ne renvoie aucune ligne ; celle du second renvoie des données. La réussite d’une requête ne démontre donc pas, à elle seule, la visibilité pour un lecteur autorisé. Vérifiez aussi que les informations ordinaires non sensibles des traces restent accessibles comme prévu. Examinez séparément les enregistrements ingérés avant le 30 septembre 2026 : Microsoft précise qu’ils restent dans leurs tables existantes et demeurent interrogeables comme auparavant. Une nouvelle destination ne déplace ni ne supprime rétroactivement ces enregistrements. Désignez un responsable pour retrouver les anciens enregistrements pertinents et demandez si d’autres copies existent dans des exports, rapports ou autres destinations utilisées par l’organisation. Consignez ce qui a effectivement été trouvé. Obtenez des preuves de conservation et de suppression propres à l’environnement, y compris pour les copies historiques, avant d’accepter une exigence qui dépend de leur effacement. Les pages citées ne démontrent pas cet effacement.