Injection de prompt par en-tête HTTP : auditer un agent de recrutement

Une injection de prompt par en-tête HTTP atteint un agent de recrutement lorsque son lecteur d’URL transmet au modèle des métadonnées contrôlées par le serveur. Pour auditer cette frontière, examinez les résultats exacts de l’outil pour les pages accessibles, les redirections et les échecs. Préservez la provenance des sources, écartez les métadonnées inutiles et faites appliquer les droits d’accès aux données des candidats et les droits d’écriture en dehors du modèle.

Imaginez que vous demandiez à un assistant de comparer le portfolio d’un candidat à votre grille d’évaluation pour un poste d’ingénieur backend. La page décrit des projets. Quelque part dans la réponse, son serveur indique aussi un score d’adéquation du candidat. Votre équipe doit savoir si cette affirmation entre dans le contexte de l’assistant, si elle apparaît dans le résumé et si quelque chose peut la transformer en évaluation enregistrée.

Ce sont des questions distinctes. Une capture d’écran du navigateur ne répond à aucune de ces questions. L’examen doit porter sur le contrat entre l’outil de récupération et le modèle : quels champs franchissent exactement cette frontière, avec quelle provenance et dans quelles conditions d’échec.

Qu’a réellement montré l’étude sur les en-têtes HTTP ?

L’enquête de Signals Corps, publiée par Sarah Andrews le 6 octobre, a examiné 217 097 223 réponses Common Crawl en échantillonnant un fichier de métadonnées WAT sur dix. Elle a classé 7 959 noms d’hôte comme envoyant des en-têtes destinés à l’IA, principalement des pointeurs vers des ressources ; 30 contenaient des tentatives d’injection. Deux affirmaient un score d’adéquation du candidat. Il s’agissait de chaînes de caractères observées, pas de compromissions démontrées d’un processus de recrutement.

La classification reposait sur un agent de recherche Claude. CCBot ne voit pas les contenus réservés à certains agents. Des expériences distinctes avec des marqueurs témoins ont constaté un rejet par défaut dans les configurations Claude testées ; les prompts donnant autorité aux instructions du serveur ont produit le mot-code demandé lors de sept des neuf essais. Chaque combinaison modèle/prompt n’a fait l’objet que d’un essai. Ce résultat n’est pas un taux de réussite généralisable. La discussion sur Hacker News a attiré l’attention sur ce travail ; les commentaires n’établissent aucun résultat supplémentaire.

L’annonce de publication de Common Crawl confirme indépendamment que la collecte sous-jacente comptait 2,17 milliards de pages provenant de 40,4 millions d’hôtes, recueillies du 4 au 17 septembre. Cela corrobore l’ampleur du jeu de données, pas la classification des en-têtes. Aucune de ces sources n’établit la fréquence des attaques réussies dans les systèmes de recrutement déployés.

Ne divisez pas le nombre de noms d’hôte distincts signalés par le nombre de réponses de pages pour en déduire un pourcentage de sites web. Les unités diffèrent. Un nom d’hôte n’identifie pas non plus un candidat, le titulaire d’un nom de domaine ou un client. Cette étude permet de repérer un périmètre à auditer, sans suggérer que des candidats ont compromis des décisions de recrutement à grande échelle.

Suivez la réponse jusqu’au modèle

Une réponse HTTP comprend un statut, des en-têtes décrivant la réponse et un corps contenant la page ou le document. Votre adaptateur choisit ce que reçoit le modèle. Examinez ce choix dans le code exécutable et dans les résultats réellement capturés à la sortie de l’outil.

Commencez par un processus utilisé en production. Notez le nom de l’outil, la version de l’adaptateur, le fournisseur d’extraction, le fournisseur de secours et les actions possibles en aval. Récupérez ensuite une page que vous contrôlez et examinez le résultat à son entrée dans le contexte du modèle. Examiner la réponse du fournisseur plus tôt dans la chaîne peut masquer un formatage, un résumé ou un traitement d’exception ultérieur.

Un contrat de sortie utile précise les champs autorisés, leur type, leur longueur maximale et leur sens. Il distingue aussi le texte extrait d’une source du statut généré par l’application. Par exemple, le titre d’une source reste une affirmation fournie par une page externe. Le placer dans un champ JSON distinct facilite sa traçabilité ; cela ne lui confère aucune autorité.

Repérez toutes les voies d’accès à une même URL

Votre lecteur habituel peut renvoyer du Markdown extrait. Un outil de débogage peut renvoyer des détails réseau. Une solution de secours peut fournir les extraits sélectionnés par un moteur de recherche. Si l’agent peut choisir un autre lecteur après un échec, cette autre voie doit aussi entrer dans l’audit.

Vérifiez ce qui se passe lorsque la source renvoie un PDF, un type de contenu inhabituel, une page d’accès bloqué ou une demande de connexion. Examinez séparément les réponses en cache et les réponses fraîchement récupérées si leur format diffère. Notez si une redirection modifie l’adresse affichée de la source. Une même URL demandée peut produire des éléments sensiblement différents selon la voie empruntée.

L’implémentation de référence de l’outil fetch MCP à la révision examinée dans la recherche fournit un exemple concret pour étudier l’extraction et le traitement des erreurs. Examinez la version exacte que vous déployez avant d’affirmer quoi que ce soit sur sa sortie. Le nom d’un outil ne suffit pas à établir son comportement.

Distinguez extraction et confiance

Supprimer les en-têtes bruts réduit un point d’entrée. Le corps de la page peut toujours contenir des instructions, des affirmations fausses ou des éléments sans rapport. Notre précédent article sur l’injection de prompt dans les CV traite du contenu des documents ; cet audit suit les mécanismes de récupération qui l’entourent.

Identifiez le texte externe comme un élément de preuve non fiable et précisez son usage autorisé dans les instructions de l’agent. Testez ensuite cette frontière. Les délimiteurs, la sérialisation JSON et les rappels aident à organiser le contexte, mais aucun ne garantit qu’un modèle rejettera toujours les instructions intégrées au contenu.

Testez les réussites, les redirections et les erreurs

Utilisez des candidats fictifs et une infrastructure que vous contrôlez pour tester séparément la visibilité du texte et le comportement du système. Examinez les entrées du modèle capturées pour vérifier quels marqueurs ont franchi la frontière de l’outil. Jugez le respect d’une instruction d’après le comportement demandé : citer un marqueur tout en rejetant l’instruction ne revient pas à la suivre.

Créez un portfolio fictif avec une description de projet courte et stable. Placez un marqueur unique dans son corps et un autre dans un en-tête de réponse personnalisé. Exécutez ce test de référence sans instructions, puis deux variantes distinctes : l’une avec une instruction inoffensive dans l’en-tête personnalisé, l’autre avec cette même instruction dans le corps. Demandez que la réponse de l’assistant soit un troisième marqueur. Gardez les faits concernant le candidat identiques dans toutes les variantes pour repérer les changements dus au canal de réponse.

Le tableau ci-dessous propose un plan d’audit. Il ne présente pas des tests réalisés sur Kit ou sur un fournisseur.

Pour chaque cas, conservez le résultat attendu et le résultat observé. Un test concluant de visibilité des en-têtes doit préciser quel champ a été omis. Un test concluant d’autorisation d’action doit identifier le mécanisme de l’application qui a refusé l’opération proposée. « La réponse semblait correcte » laisse trop de questions ouvertes.

Définissez aussi un contrat pour les sorties d’erreur

Les erreurs sont souvent conçues pour les développeurs, puis transmises aux modèles sans examen. Une exception peut contenir une réponse du fournisseur, un message en amont ou une URL de destination. Un résultat soigneusement restreint en cas de réussite renseigne peu sur ces champs.

Renvoyez une catégorie d’échec limitée et assez de contexte pour permettre une nouvelle tentative autorisée. Conservez les diagnostics détaillés dans un canal opérationnel dont l’accès est correctement restreint. Si le modèle a besoin d’un extrait d’erreur fourni par la source, identifiez-le comme tel et appliquez les mêmes limites qu’au texte extrait ordinaire.

Testez à la fois le premier échec et la solution de secours. Par exemple, le lecteur principal peut omettre les en-têtes tandis que le lecteur secondaire inclut un diagnostic complet. Rejouez cette matrice lorsque vous changez d’adaptateur, de fournisseur d’extraction ou de formateur d’exception. Enregistrez les versions concernées avec les résultats pour que les personnes qui les examineront sachent ce que couvrent les preuves.

Testez un routage réaliste sans données de vrais candidats

Utilisez la configuration de requête habituelle de l’agent pour les cas de test contrôlés. Si l’outil de récupération en production utilise un agent utilisateur distinct ou demande du Markdown, reproduisez cette configuration dans le test. Un navigateur ordinaire peut recevoir une réponse différente.

Ne placez ni vrais CV, ni identifiants, ni liens signés vers des dossiers candidats dans un test témoin. N’installez aucun paquet et ne connectez aucun outil suggéré par le cas de test. Vous cherchez à savoir si le système franchit une frontière ; un contenu fictif et inoffensif suffit à révéler cet échec.

Ne laissez pas le texte récupéré décider du recrutement

Un portfolio peut apporter des éléments sur un travail réalisé. Il ne peut ni définir votre grille, ni établir un score d’adéquation vérifié, ni autoriser l’accès au dossier d’un autre candidat. Maintenez cette distinction dans le résumé comme dans l’application qui le conserve.

Dans l’exemple hypothétique de l’évaluation backend, l’assistant pourrait trouver un dépôt public décrivant un traitement de tâches en arrière-plan. Une note acceptable identifie la source et précise ce qu’elle étaye : le portfolio décrit un travail sur le traitement de files d’attente, tandis que la responsabilité de son exploitation reste à vérifier. Le recruteur peut alors poser une question ciblée en entretien.

Un score non étayé ne doit jamais devenir silencieusement l’évaluation du recruteur. Exigez, pour chaque appréciation substantielle, une justification liée à un critère et des éléments de preuve traçables. Distinguez les affirmations du candidat des jugements des évaluateurs. Cette distinction doit rester compréhensible pour la personne qui consulte le dossier dans le parcours de gestion des profils candidats.

Cela vaut aussi lorsque l’instruction de la source ne déclenche aucun appel d’outil. Un assistant en lecture seule peut tout de même exagérer une expérience, omettre des réserves ou présenter une autodéclaration comme une vérification indépendante. Auditez la fidélité des réponses en même temps que les écritures. Comparez les résumés obtenus avec les différents cas de test et demandez aux évaluateurs de repérer les affirmations réellement étayées par les sources.

Les recommandations de l’OWASP sur l’injection de prompt préconisent plusieurs niveaux de protection : privilèges limités au périmètre nécessaire, séparation des contenus non fiables, approbation humaine pour les actions lourdes de conséquences et tests adversariaux. Adaptez ces protections aux conséquences de l’opération. Un brouillon de résumé et le rejet d’une candidature justifient des autorisations différentes.

Préservez la provenance sans constituer une archive sensible

Consignez l’identité de l’outil, l’URL demandée, l’URL finale lorsqu’elle est disponible, la catégorie de réponse, le nom des champs exposés et l’action proposée ensuite. Ajoutez l’heure d’extraction et assez d’informations de version pour reproduire le comportement de l’adaptateur. Si vous ne pouvez pas établir la destination finale, mentionnez explicitement cette incertitude.

Préférez des fiches structurées de taille limitée et des exemples fictifs expurgés aux copies intégrales des réponses. Les journaux ordinaires ne doivent collecter ni cookies, ni valeurs d’autorisation, ni liens signés, ni données personnelles des candidats. La provenance aide les relecteurs à établir l’origine d’une affirmation ; une journalisation excessive crée un lieu supplémentaire où protéger des données sensibles.

La fiche de provenance doit subsister après les résumés ultérieurs. Si un second modèle condense les notes de recherche, conservez le lien entre chaque affirmation et ses preuves. Sinon, un premier résumé prudent peut devenir en aval une déclaration catégorique sans fondement.

Vérifiez l’action suivante et examinez l’exemple concret de Kit

L’application doit décider si une action proposée est autorisée à partir des droits de l’utilisateur authentifié, du périmètre du compte, de la destination et de la finalité. Un texte récupéré sur un site web ne peut étendre aucune de ces autorisations.

Un lien vers un serveur MCP peut constituer une documentation utile. Se connecter à ce serveur ajoute une capacité et exige une autorisation distincte. Une page demandant à l’agent d’envoyer ailleurs des données de candidats formule une demande, pas une permission. Vérifiez la destination proposée et le périmètre des données avant toute transmission, même si le résumé qui précède semble raisonnable.

L’accès aux outils doit correspondre à la tâche. Une étape de recherche peut nécessiter la lecture de sources et l’enregistrement d’un brouillon. Déplacer une candidature, contacter un candidat ou exporter des dossiers exige une décision d’autorisation distincte. La référence des outils MCP de Kit aide à choisir des intégrations, mais la disponibilité d’une opération via MCP ne suffit pas à établir qu’elle est autorisée dans un cas donné.

L’adaptateur Outreach de Kit fournit un exemple limité

L’examen statique réalisé pour cet article a repéré une implémentation pertinente dans l’adaptateur de récupération Outreach de Kit. Cet exemple concerne la recherche sur des prospects. Il ne prouve ni l’existence d’une fonctionnalité déployée de récupération de portfolios dans Hiring, ni la réalisation d’un test de sécurité de bout en bout.

L’adaptateur lit l’URL source enregistrée pour un prospect et vérifie qu’il s’agit d’une URL publique sûre. Il peut utiliser les champs de profil enregistrés ou tenter une extraction avec Cloudflare, puis Exa. Dans le parcours Cloudflare habituel, le résultat visible par le modèle contient une URL et du texte extrait plutôt qu’une réponse HTTP brute. En cas de réussite, Exa renvoie une URL, un titre, des extraits sélectionnés et du texte.

Cloudflare décrit son point d’accès Markdown comme un outil d’extraction du contenu des pages. Cette transformation n’établit pas que les injections de prompt sont éliminées. Le texte extrait reste un contenu tiers. L’examen statique a aussi constaté que le traitement des échecs d’Exa peut inclure un message d’exception, dont la sortie mérite un examen distinct.

Ces observations définissent un audit concret à mener : capturer les résultats réels lors des réussites des fournisseurs, du recours à une solution de secours, des redirections et des échecs, puis tester les actions suivantes autorisées. Elles ne prouvent ni que tous les en-têtes sont exclus dans l’ensemble du système, ni que Kit est immunisé contre l’injection.

Pour votre propre intégration, rendez le contrat de récupération vérifiable avant d’étendre les pouvoirs de l’agent. Conservez un petit ensemble de cas de test fictifs à côté de l’adaptateur, consignez ce qui atteint le modèle et vérifiez qui autorise l’action suivante. Votre équipe de recrutement disposera ainsi d’éléments qu’elle pourra examiner lorsqu’une source change, qu’un fournisseur échoue ou qu’un assistant propose une action lourde de conséquences.