Isolation des clients IA : protéger les données de recrutement

L’isolation des clients IA empêche qu’un client accède aux données d’entrée, au contexte récupéré et aux réponses d’un autre client. Dans un flux de recrutement, examinez à la fois l’application qui autorise l’accès aux dossiers et le fournisseur qui traite le prompt. L’engagement de ne pas entraîner un modèle avec vos données répond à une autre question.

Cette distinction compte même si le recruteur est autorisé à lire tous les champs transmis. L’autorisation peut être correcte au départ de la requête, tandis qu’une autre partie de la chaîne de traitement exige ses propres protections. Suivez le contexte du candidat tout au long de cette chaîne, jusqu’à la réponse reçue.

Posez une question précise : sur quelles preuves repose la décision d’envoyer ces champs par ce circuit pour cette tâche ? Commencez par là avant d’approuver une nouvelle fonction IA pour l’ensemble du recrutement.

Qu’établit la divulgation de Cloudflare ?

La divulgation du 26 octobre concerne GLM-5.3 sur Workers AI. Cloudflare fait état de contenus exposés entre clients dans 155 réponses, du 27 août au 9 septembre 2026, pour des prompts dépassant 681 280 jetons. L’entreprise ne signale aucun autre modèle Workers AI touché et indique n’avoir trouvé aucune preuve d’exploitation délibérée.

Selon Cloudflare, le moteur d’inférence n’a pas transmis un rejet de préremplissage à l’étape de décodage. Celle-ci a alors lu des pages de cache que la requête n’avait pas écrites. Cloudflare a reçu le signalement du chercheur le 8 septembre, restreint l’accès au modèle le lendemain, puis rétabli le service après correction de la configuration et du comportement du moteur. La publication a suivi une divulgation coordonnée.

Il s’agit d’une défaillance d’isolation à l’inférence, et non d’une preuve que les prompts des clients ont servi à l’entraînement. La discussion sur Hacker News a fait de cette divulgation un sujet d’actualité. Aucune des deux sources n’établit que des dossiers de candidature ou du trafic de Kit aient été concernés.

À quelles questions les engagements de confidentialité répondent-ils ?

Examinez séparément l’entraînement, la conservation, les autorisations et l’isolation. Une réponse rassurante sur l’un de ces sujets ne permet pas de conclure sur les autres.

La documentation officielle distingue souvent ces sujets. La page actuelle sur l’utilisation des données de Workers AI traite de l’entraînement et de la conservation à l’inférence, mais aussi des fonctions avec état, du stockage choisi et des traces ou du cache gérés par des passerelles. Lisez les conditions du service que vous utilisez réellement. N’étendez pas les engagements d’un service à un autre auquel une passerelle transmet les requêtes.

La documentation de confidentialité de Microsoft Foundry distingue elle aussi l’isolation des clients, l’utilisation pour l’entraînement, les fonctions avec stockage et la surveillance des abus. Les conditions dépendent du déploiement et des fonctions utilisées. Ces pages illustrent les questions à poser ; elles ne permettent pas de classer les fournisseurs.

Pour chaque réponse, précisez le périmètre. « Pas d’entraînement » sans service nommé ni conditions applicables laisse votre équipe dans le doute. Il en va de même pour « pas de conservation » sans liste des fonctions activées. Conservez un lien daté ou une référence contractuelle approuvée à côté de la configuration décrite. La personne qui reprendra le dossier pourra ainsi comprendre ce que couvrait la décision initiale.

De quel contexte candidat cette tâche a-t-elle réellement besoin ?

Choisissez les champs strictement nécessaires avant de construire le prompt. Le droit d’ouvrir une fiche candidat ne justifie pas de transmettre tous ses champs dans une requête IA.

Prenons une demande fictive : « Résumez l’expérience de ce candidat en exploitation de bases de données en production au regard des exigences de ce poste backend. » La tâche nécessite l’expérience pertinente et les critères du poste. Elle n’a généralement pas besoin d’un numéro de téléphone, d’une adresse personnelle, d’une signature d’e-mail ou d’échanges privés sans rapport avec cet objectif.

Définissez les données attendues avant de connecter l’intégration :

Il s’agit d’une sélection proposée, pas d’une description des réglages par défaut d’un produit. Une autre tâche peut nécessiter d’autres informations. Rédiger un message peut exiger un nom ; l’envoyer nécessite une adresse dans le système d’envoi. Cela n’impose pas forcément d’insérer cette adresse dans le prompt du modèle.

Les recommandations de l’OWASP sur la divulgation d’informations sensibles abordent le moindre privilège, la restriction des sources de données, ainsi que le masquage ou la tokenisation. Appliquez ces principes à la tâche réelle. Une consigne générale demandant de « garder les données privées » ne constitue pas une protection suffisante.

Une référence interne mérite aussi votre attention. Si l’application peut la rattacher à une personne, ne qualifiez pas le résultat d’anonyme. Un parcours professionnel détaillé peut identifier quelqu’un sans mentionner son nom. La minimisation réduit les informations exposées ; elle ne répare pas un moteur d’inférence et n’empêche pas toutes les déductions possibles.

Constituez une courte fiche de vérification pour chaque flux de travail. Indiquez la tâche, le rôle à l’origine de la demande, les dossiers sources, les champs sélectionnés, la destination et les lieux de stockage des entrées et des réponses. Incluez les nouvelles tentatives et les circuits de repli. Attribuez explicitement chaque question sans réponse à un responsable, pour qu’une incertitude ne devienne pas tacitement une hypothèse approuvée. Notre guide de sécurité des données candidats élargit cette réflexion aux dossiers qui entourent la requête.

Que demander au fournisseur d’inférence ?

Demandez des preuves propres au service, au modèle et au déploiement concernés. Une page générale sur la sécurité apporte du contexte ; la décision doit tenir compte du circuit qui recevra les données de candidature.

Commencez par décrire concrètement le flux de travail. Précisez les types de dossiers transmis, l’éventuelle passerelle ou le routeur, les fonctions de stockage activées et les nouvelles tentatives prévues après un échec. Donnez au fournisseur assez de détails pour obtenir une réponse adaptée à votre configuration.

Posez ensuite des questions qui vous aideront à décider :

• Séparation des traitements : comment la séparation des clients s’applique-t-elle à l’inférence et à l’état réutilisable du traitement ? Quels éléments sont partagés, et quelles protections assurent cette séparation ?
• Comportement en cas d’échec : que se passe-t-il lorsqu’une requête est rejetée, annulée, interrompue ou relancée ? Les mécanismes d’isolation documentés couvrent-ils ces cas ?
• Persistance : quelles fonctions activées conservent les prompts, les réponses ou les données associées ? Quels réglages de traces et de cache relèvent de la passerelle plutôt que du service de modèle ?
• Preuves en cas d’incident : quels identifiants permettent au fournisseur de retrouver une requête et de délimiter un problème signalé ? Comment saurez-vous si le service ou le modèle utilisé est touché ?
• Responsabilité des changements : qui prévient votre équipe lorsqu’une modification du circuit, du modèle, d’une fonction ou des conditions de traitement justifie un nouvel examen ?

Ce sont des questions proposées aux acheteurs. Elles ne constituent pas un dispositif de certification, et le fournisseur peut légitimement garder confidentiels certains détails techniques sensibles. Votre responsable sécurité a néanmoins besoin de preuves suffisamment précises pour décider si le flux de travail est acceptable.

Les recommandations du NIST sur le développement sécurisé de l’IA générative s’adressent aux producteurs et aux acquéreurs tout au long du cycle de vie. Gardez cette vue d’ensemble pour répartir les responsabilités : l’acquisition, la configuration, l’exploitation et la gestion des incidents doivent chacune avoir un responsable. Les questions ci-dessus sont notre application de cette approche aux flux de recrutement, pas une liste prescrite par le NIST.

Consignez une décision explicite. Vous pouvez approuver une tâche limitée, réduire les champs transmis, désactiver une fonction de stockage ou refuser l’approbation tant qu’une question importante reste ouverte. Conservez les motifs à côté de l’inventaire des circuits. Une personne qui rejoint l’équipe doit comprendre ce qui imposerait de réexaminer la décision.

Que prouvent vos propres tests d’isolation ?

Vos tests vérifient un comportement observé dans l’application et les environnements que vous maîtrisez. Ils ne peuvent pas certifier le fonctionnement interne de l’ensemble de l’infrastructure d’inférence d’un fournisseur de service géré.

Utilisez des candidats fictifs dans des comptes détenus par votre organisation. Donnez à chaque dossier des faits inventés et des références distinctes. Ne prenez pas de vraies données de candidature comme marqueurs de test et ne cherchez pas à récupérer le contenu d’un autre client.

Un plan de test utile suit les accès jusqu’à la réponse :

1. Vérifiez la séparation des comptes. Un membre du compte de test A demande le candidat fictif qui appartient uniquement au compte B. Vérifiez que l’application refuse l’accès avant de construire une requête sortante contenant le contexte de B.
2. Vérifiez les restrictions au sein d’un compte. Un membre sans accès à un poste restreint demande le contexte fictif associé. Vérifiez les droits applicables au poste, sans vous limiter à l’appartenance au compte.
3. Vérifiez les erreurs et les nouvelles tentatives. Interrompez une requête dans l’environnement de test maîtrisé. Vérifiez qu’une nouvelle tentative conserve le compte et le contexte de tâche autorisés, et qu’une erreur n’élargit pas les données récupérées.
4. Vérifiez la destination. Menez à terme une requête autorisée et vérifiez où sa réponse est sauvegardée et affichée. Examinez aussi bien le traitement en arrière-plan que la réponse immédiate.
5. Vérifiez les accès après un changement. Modifiez les droits du membre de test pendant qu’un traitement est en attente. Vérifiez le comportement promis par votre produit lorsque la réponse devient disponible.

Pour chaque test, consignez le résultat attendu avant de l’exécuter. Recueillez assez de preuves pour distinguer une requête refusée d’une requête qui a récupéré des données interdites avant de simplement masquer la réponse. Ces deux comportements ont des conséquences différentes.

Des marqueurs fictifs uniques peuvent aider à retracer une erreur dans votre système. Un test réussi ne prouve pas l’isolation de chaque requête, modèle, équipement ou déploiement du fournisseur. Limitez la conclusion au résultat observé : le parcours applicatif testé s’est comporté comme prévu dans les conditions consignées.

Définissez ce qui déclenche la mise à jour du plan de test. Une modification de la récupération des données, des tâches en arrière-plan, du basculement vers un autre fournisseur ou du stockage des réponses peut changer la séparation des accès sans modifier visiblement la fonction de recrutement. Réexaminez les tests concernés lorsque ces circuits changent et distinguez les questions au fournisseur des assertions testées dans l’application.

Comment réagir à des données inattendues dans une réponse IA ?

Traitez l’apparition d’un dossier personnel inattendu comme un incident à contenir et à examiner. Une explication convaincante du modèle ne prouve pas l’origine des informations.

Commencez par restreindre l’accès à la réponse et suspendez le flux de travail ou le circuit du modèle concerné pendant que le responsable de l’incident évalue la situation. Délimitez précisément ce qui est suspendu. Évitez de copier le dossier inattendu dans une discussion partagée, une capture destinée à l’assistance ou un autre outil IA externe pour l’analyser.

Conservez les identifiants et la configuration nécessaires à l’enquête : références de requête et de réponse, horodatages, modèle, circuit, réglages pertinents et compte à l’origine de la demande. Suivez la procédure de gestion des incidents pour ne conserver que le contenu nécessaire. Limitez l’accès à ces preuves et désignez un responsable.

Contactez ensuite le fournisseur par son canal de sécurité ou de gestion des incidents. Demandez-lui de vous aider à établir l’origine et le périmètre de la réponse. Examinez aussi la récupération des données et l’acheminement des réponses dans votre application : une erreur applicative reste une explication possible tant que les preuves ne l’écartent pas. Si vous mettez ce canal de signalement en place, notre guide de divulgation des vulnérabilités décrit la procédure de réception des signalements.

Retracez ce qui s’est passé après réception de la réponse. A-t-elle été sauvegardée comme note, incluse dans un résumé de candidature, exportée ou affichée à un autre évaluateur ? Les mesures de confinement doivent couvrir ces copies autant que la requête initiale. Consignez les résultats sans élargir l’accès aux informations personnelles.

Confiez aux responsables désignés de la confidentialité et de la sécurité l’évaluation des éventuelles obligations de notification, à partir des faits confirmés et des règles applicables. L’apparition d’un texte inattendu ne suffit pas à établir une conclusion juridique. Avant de rétablir le flux de travail, documentez la défaillance, le changement qui justifie la reprise et les incertitudes restantes.

Explicitez les limites de chaque protection dans Kit

Intégrez à votre examen les protections de l’application et les réglages des fournisseurs de Kit, en précisant ce que chacun couvre. Examinez aussi les données transmises hors de l’application.

L’examen du code de l’outil MCP de résumé candidat de Kit montre une séparation applicative concrète : il exige l’appartenance au compte, recherche le candidat dans le compte courant et vérifie les offres d’emploi accessibles. Un candidat associé uniquement à des postes restreints n’est pas renvoyé par cet outil à un membre sans accès.

Le résumé autorisé peut néanmoins contenir le nom, l’e-mail, le numéro de téléphone et le contexte accessible du CV. Le chiffrement au repos de l’e-mail et du téléphone n’empêche pas ces champs d’apparaître en clair dans le résultat d’un outil autorisé. Examinez l’outil et la tâche réels avant de supposer que les coordonnées ont été exclues.

La documentation des fournisseurs IA de Kit décrit aussi plusieurs circuits de traitement. Le fournisseur préféré prend en charge la plupart des échanges et des tâches de génération dans l’application. L’indexation et la recherche sémantiques utilisent le service de plongements de Google avec la clé de plateforme de Kit, indépendamment de ce choix. Hiring Live Review utilise la clé Gemini propre au compte, et l’enrichissement en arrière-plan du module de recherche de rémunération suit un autre circuit Gemini fixe. Les plafonds de dépenses liés à la clé du compte ne bloquent pas tous ces circuits distincts.

Un assistant externe connecté par MCP ajoute son propre périmètre de traitement. Son autorisation à demander des informations à Kit et la manière dont il traite les informations reçues sont deux questions distinctes. Changer le fournisseur préféré de Kit ne configure pas cet assistant externe.

Commencez par une tâche de recrutement. Identifiez qui peut récupérer les dossiers, examinez les champs qui quittent l’application, puis vérifiez le circuit de traitement réel et la réponse sauvegardée. Testez ensuite les séparations applicatives que vous maîtrisez et clarifiez les points en suspens auprès du fournisseur avec le responsable concerné. Si vous évaluez Kit, appuyez-vous sur les circuits documentés et un candidat fictif pour rendre cet examen concret avant d’ajouter des données de recrutement sensibles.