OpenTelemetry en sécurité : comparer les garde-fous du SDK, du Collector et des données GenAI

OpenTelemetry facilite la collecte de traces, métriques et journaux, mais il ne transforme pas une télémétrie sensible en données sûres par défaut. Dans un workflow de développement augmenté par l’IA, une trace peut contenir un prompt, une réponse de modèle, un argument d’outil, un identifiant de dépôt ou une erreur révélant un chemin interne. Le sujet de sécurité n’est donc pas seulement « faut-il instrumenter ? », mais « quelle surface faut-il protéger, et à quel moment ? »

Ce comparatif distingue trois zones qui sont souvent mélangées : le code instrumenté par le SDK, le pipeline de collecte piloté par le Collector et les attributs propres aux applications GenAI. L’objectif est de choisir un niveau de contrôle proportionné sans prétendre qu’OpenTelemetry fournit à lui seul une politique complète de confidentialité ou de contrôle d’accès.

Trois surfaces, trois risques différents

SDK : empêcher la fuite au point de capture

Le premier choix de sécurité intervient avant l’export. Une équipe peut tracer le nom de l’opération, le modèle déclaré, le statut, la durée ou une catégorie d’erreur sans enregistrer le prompt complet. Cette séparation est particulièrement importante pour les attributs GenAI : la documentation OpenTelemetry avertit que les messages d’entrée et de sortie peuvent contenir des informations personnelles ou sensibles.

La bonne comparaison n’oppose donc pas « traces complètes » et « aucune trace ». Elle oppose une instrumentation minimale, conçue autour d’une liste de champs autorisés, à une instrumentation qui capture les objets applicatifs par facilité. Dans le premier cas, la revue porte sur un contrat de télémétrie. Dans le second, elle intervient souvent après la fuite, dans un backend déjà alimenté.

• Commencer par les métadonnées de faible cardinalité : opération, statut, environnement et catégorie d’erreur.
• Rendre les messages, prompts, réponses et arguments d’outils explicitement optionnels.
• Tronquer ou hacher les identifiants lorsque leur valeur complète n’est pas nécessaire au diagnostic.
• Tester l’instrumentation avec des données synthétiques avant toute ouverture à un dépôt ou à un service réel.

Collector : sécuriser le transport et le processus

Le Collector ajoute une surface réseau et une surface d’exécution. La documentation officielle recommande des connexions chiffrées et authentifiées pour les récepteurs et exportateurs, ainsi qu’un fonctionnement avec un utilisateur non privilégié lorsque cela suffit. Une configuration invalide doit aussi empêcher le démarrage plutôt que laisser passer un pipeline ambigu.

Dans une architecture de développement, le choix du Collector dépend surtout de la frontière qu’il doit protéger. Un Collector local peut réduire la sortie réseau d’un poste ou d’un runner. Un Collector central facilite la politique commune, mais concentre davantage de données et de droits. Un Collector placé près du service peut filtrer avant export ; un Collector uniquement central ne peut pas annuler une exposition déjà enregistrée en amont.

GenAI : le contenu n’est pas un attribut ordinaire

Les conventions GenAI standardisent des champs utiles pour corréler les opérations, les sources de données et les évaluations. Elles ne donnent pas pour autant une permission générale d’enregistrer les messages. Un champ normalisé peut rester sensible. La standardisation améliore la lecture et l’interopérabilité ; elle ne remplace ni la minimisation, ni la classification, ni le contrôle d’accès.

Pour un agent de développement, une politique raisonnable sépare au moins quatre niveaux : métadonnées de parcours, contenu nécessaire à une enquête ponctuelle, secrets ou identifiants à exclure, et données conservées seulement sous forme agrégée. Cette distinction permet d’investiguer une erreur de modèle ou d’outil sans transformer le backend d’observabilité en copie de conversations internes.

Checklist avant d’activer la collecte

1. Écrire la liste des attributs autorisés par type d’opération.
2. Identifier les champs qui peuvent contenir du code propriétaire, des secrets, des données personnelles ou des arguments d’outils.
3. Activer TLS et l’authentification sur les récepteurs et exportateurs concernés.
4. Faire tourner le Collector avec une identité dédiée et des privilèges minimaux.
5. Valider la configuration au démarrage et refuser les paramètres ambigus.
6. Tester la troncature, la rédaction et les chemins d’erreur avec des données synthétiques.
7. Limiter les accès au backend et définir une durée de conservation adaptée.
8. Conserver un journal de modification de la politique de télémétrie.

Quel niveau choisir selon le cas ?

Pour un prototype local sans données sensibles, l’instrumentation minimale et un export chiffré peuvent suffire. Pour une CI qui évalue un agent, le filtrage doit être appliqué avant l’envoi des traces, car les logs de test peuvent contenir des dépôts, des prompts et des sorties générées. Pour un service en production, il faut en plus séparer les identités, limiter les accès au backend et prévoir une procédure de retrait si un attribut sensible est découvert.

Le compromis le plus robuste n’est pas de supprimer la télémétrie GenAI. C’est de rendre explicite ce qui est capturé, où le filtrage intervient, qui peut consulter les données et quelle preuve justifie leur conservation. OpenTelemetry fournit les conventions et les composants nécessaires à cette architecture ; la responsabilité de la politique de sécurité reste dans l’équipe qui instrumente et opère le système.

Pour cadrer les données envoyées par un agent avant l’instrumentation, voir aussi le bac à sable pour agents IA de code. Pour traiter les secrets présents dans le contexte d’exécution, complétez avec les règles de protection des secrets face aux agents IA.