Que faire après la publication de la recherche sur l’injection de prompts de DeepSeek Harness en 2026 ?

Symptôme : la recherche 2026 sur l’injection de prompts de DeepSeek Harness montre qu’un contenu externe peut influencer une action sensible.
Solution la plus rapide : resserrez immédiatement les chemins entre pages, fichiers, Skills ou MCP et les outils privilégiés, sans appliquer automatiquement le taux publié à votre propre déploiement.

Cette consigne vaut dès la publication de l’étude, à condition de distinguer trois choses : ce que les chercheurs ont réellement testé, ce que votre configuration autorise et ce que vos outils peuvent réellement exécuter. La première semaine doit servir à isoler les sources non approuvées, imposer une approbation indépendante, réexaminer les Skills et relancer des cas représentatifs sur votre version.

Cette analyse s’adresse à vous si vous développez un agent qui lit des pages web, des documents, des journaux ou des commentaires de code avant d’appeler des outils. Elle vise aussi les ingénieurs sécurité qui doivent convertir une publication en contrôles exécutables, ainsi que les responsables techniques qui doivent choisir entre poursuivre le pilote, réduire son périmètre ou suspendre un accès privilégié.

Étude publiée contre vulnérabilité généralisée

La recherche consacrée à la sécurité de DeepSeek Harness avec AI-Infra-Guard examine la résistance de l’agent à l’injection indirecte de prompts. Elle ne teste pas une abstraction générale de tous les agents ni toutes les versions disponibles. Elle porte sur une révision précise du code, un modèle déterminé, une personnalité d’agent, une configuration de référence et des outils sensibles simulés.

La publication indique notamment les paramètres suivants :

• commit DeepSeek Harness 47f943859bef, daté du 13 août 2026 ;
• modèle deepseek-v4-flash utilisé par l’intermédiaire d’un proxy local ;
• configuration et personnalité de référence non modifiées ;
• 14 560 exécutions contrôlées ;
• 16 canaux de contenu, en modes texte et fichier ;
• 35 objectifs d’attaque, dont 32 nécessitant un appel vers un outil sensible ;
• 6 outils utilisés comme sources et 8 puits sensibles simulés ;
• deux mécanismes d’évaluation, l’un fondé sur des règles déterministes et l’autre sur une analyse sémantique.

Les chiffres publiés ne correspondent donc pas à des courriels réellement envoyés, à des commandes réellement lancées ou à des fonds réellement transférés. Les puits de l’étude écrivent dans un journal local et renvoient un résultat synthétique. Un appel enregistré signifie que l’agent a tenté l’action dans le scénario contrôlé ; il ne prouve pas qu’un système externe a subi un effet. Cette différence doit apparaître explicitement dans votre registre de risques. Voir le périmètre expérimental dans l’article arXiv.

Les résultats rapportés comprennent :

• 5,6 % de succès complets selon le juge à règles ;
• 5,3 % selon le juge sémantique ;
• 7,6 % d’influence large selon le premier juge ;
• 12,6 % selon le second en additionnant succès complet et conformité partielle ;
• jusqu’à 25,5 % pour le canal Unicode caché en mode fichier ;
• 16,0 % pour le canal Skills en mode fichier ;
• 17,0 % pour l’attaque « fake completion » en mode texte selon le juge sémantique.

Ces données suffisent à justifier une réduction immédiate du risque entre contenu externe et outil sensible. Elles ne permettent pas de conclure que toutes les installations DeepSeek Harness présentent le même taux. Le modèle, le commit, le parseur, les permissions, les Skills, les serveurs MCP et les règles d’approbation peuvent modifier le comportement.

Première journée : contenu externe contre outil privilégié

Le premier jour, vous n’avez pas besoin de désactiver tout DeepSeek Harness. Vous devez d’abord supprimer l’automatisation qui traverse une frontière de confiance sans contrôle indépendant.

Séparez les sources susceptibles de contenir des instructions hostiles :

• pages web et résultats de recherche ;
• fichiers PDF, tableurs et documents bureautiques ;
• courriels, en-têtes, messages et tickets ;
• journaux applicatifs et commentaires de code ;
• Skills, modèles de workflow et descriptions d’outils ;
• serveurs MCP et résultats récupérés par connecteur.

Séparez ensuite les actions qui doivent rester sous approbation :

• exécuter une commande ou un script ;
• modifier, supprimer ou déplacer un fichier ;
• envoyer un courriel ou publier un message ;
• soumettre un formulaire ou une requête HTTP ;
• modifier un dépôt, une configuration ou une permission ;
• effectuer un transfert ou changer une destination financière.

Le risque ne vient pas uniquement d’une phrase hostile. Il vient de la chaîne complète : récupération, conversion du format, sérialisation du résultat, insertion dans le contexte, planification, appel d’outil puis exécution. Un texte peut donc influencer l’agent sans remplacer le message initial de l’utilisateur.

Construisez une matrice temporaire de contrôle :

• source non approuvée → lecture seule : autorisée dans un environnement isolé ;
• source non approuvée → écriture locale réversible : autorisée avec journalisation ;
• source non approuvée → commande système : bloquée ;
• source non approuvée → courriel, publication ou soumission externe : bloquée sans approbation ;
• Skill ou MCP récemment ajouté → outil sensible : bloqué jusqu’à revue ;
• contenu comportant des métadonnées, de l’Unicode caché ou une conversion : soumis à un scénario distinct.

Cette approche conserve les usages créatifs à faible impact. Vous pouvez laisser l’agent analyser un brief audio, classer des rushes vidéo, proposer des variantes de design ou préparer un script de montage, tout en interdisant la publication automatique, l’écrasement des fichiers maîtres et l’envoi vers un service externe.

Première étape : provenance attachée contre avertissement unique

Pendant les trois premiers jours, rendez chaque contenu traçable. Un avertissement dans le message système ne doit pas être votre unique protection : il demande encore au modèle de reconnaître lui-même qu’un texte externe tente de modifier sa mission.

Pour chaque résultat transmis au contexte, enregistrez :

• l’identifiant de la source ;
• son propriétaire ou son équipe responsable ;
• le type de support : page, fichier, courriel, Skill, MCP ou commentaire ;
• le niveau de confiance ;
• la version ou le hachage du contenu ;
• l’heure de récupération ;
• les transformations appliquées ;
• les outils sensibles qui pourraient être appelés ensuite.

Dans DeepSeek Harness, vous pouvez placer ces contrôles autour du parcours d’exécution : avant l’appel d’outil, au moment de l’approbation, dans le bac à sable et après l’exécution. Le mécanisme ToolGuard peut refuser un appel en fournissant une raison, tandis qu’un contrôle préalable peut comparer la source, les arguments et le niveau de privilège. La publication décrit ces points d’extension dans son analyse de l’architecture de l’agent. Consultez la description des contrôles d’outils dans l’étude.

Votre processus d’autorisation doit suivre une séquence indépendante du modèle :

1. l’agent propose un outil et ses arguments ;
2. le moteur récupère la provenance du contenu ayant précédé cette proposition ;
3. une politique classe la sensibilité de l’outil ;
4. les arguments sont comparés à une liste autorisée ;
5. une approbation humaine est demandée si une frontière est franchie ;
6. seul le moteur d’exécution autorise l’appel final.

Une passerelle d’interposition peut compléter ce dispositif pour les serveurs MCP. Elle ne doit toutefois pas remplacer le contrôle des sources, des arguments et des permissions dans votre propre environnement. Voir les points d’interception documentés par ToolGuard.

Deuxième étape : Skills et fichiers contre simple lecture textuelle

La recherche donne une priorité particulière aux Skills et aux formats de fichiers. Le canal Skills atteint 14,3 % en mode texte et 16,0 % en mode fichier selon le juge à règles. Le canal Unicode caché en mode fichier atteint 116 cas sur 455, soit 25,5 %. En mode texte, le même canal est indiqué à 0,0 %. Un test limité au texte pourrait donc masquer un comportement lié à la représentation du fichier.

Vous devez vérifier séparément :

• les caractères Unicode invisibles ou confusables ;
• les métadonnées PDF et propriétés de document ;
• les commentaires HTML ou les instructions masquées par le style ;
• les cellules, feuilles et formules de tableur ;
• les champs d’en-tête dans les courriels ;
• les instructions ajoutées lors d’une conversion Markdown, HTML ou PDF ;
• les fichiers SKILL.md, modèles de tâche et descriptions MCP ;
• les résultats récupérés par un connecteur puis réinjectés dans le contexte.

Traitez les Skills comme du code opérationnel. Chaque Skill doit avoir un propriétaire, une version, une origine, une date de revue et une liste de privilèges. Vous devez aussi noter si son contenu est chargé intégralement au démarrage ou récupéré seulement après une action précise. Cette différence modifie la surface d’exposition. Voir la documentation sur le chargement et l’usage des Skills.

Si vous utilisez v0.1.0-rc.7, vérifiez séparément sa relation avec le commit étudié le 13 août 2026. Un numéro de version plus récent ne prouve pas qu’un correctif, une nouvelle politique d’appel d’outil ou une modification du chargement des Skills est présente. Relevez le commit exact, les changements du pipeline et les valeurs par défaut avant d’interpréter une différence.

Troisième étape : régression locale contre taux publié

Avant d’élargir le pilote, reprenez un ensemble réduit de cas représentatifs. Vous n’avez pas besoin de reproduire toute l’étude ; vous devez reproduire les frontières qui existent réellement dans votre déploiement.

Sélectionnez au minimum :

• une page web contrôlée ;
• un document ou PDF avec métadonnées ;
• un fichier comportant des caractères invisibles ;
• une Skill réellement utilisée ;
• un résultat MCP ;
• un commentaire de code ou un journal ;
• un outil de lecture ;
• un outil d’écriture ;
• une commande sans effet externe ;
• une action qui, en production, enverrait ou publierait réellement.

Utilisez des fixtures isolées. Un outil de courriel doit écrire dans une boîte locale fictive. Une commande doit s’exécuter sans secret. Une requête HTTP doit viser un serveur local de test. Un outil de transfert doit enregistrer les arguments sans contacter de service externe.

Mesurez quatre signaux distincts :

1. le contenu malveillant est-il entré dans le contexte ?
2. le plan de l’agent a-t-il changé après la lecture ?
3. un outil sensible a-t-il été proposé ou appelé ?
4. la politique a-t-elle bloqué l’action avant son exécution ?

Cette séparation évite de confondre exposition, influence et effet opérationnel. Le juge sémantique peut détecter davantage de conformités partielles que le juge à règles, notamment lorsque le plan change sans que tous les arguments attendus soient présents. Conservez donc les traces complètes au lieu de réduire l’analyse à un taux unique.

Liste de contrôle avant l’élargissement

• [ ] Le commit DeepSeek Harness réellement exécuté est enregistré.
• [ ] Le modèle, la personnalité et les paramètres de référence sont conservés.
• [ ] Chaque source possède un propriétaire et un niveau de confiance.
• [ ] Les Skills et serveurs MCP ont une version vérifiable.
• [ ] Les métadonnées et caractères invisibles sont inclus dans les tests.
• [ ] Les outils sensibles utilisent des fixtures sans effet externe.
• [ ] Les arguments d’outil sont contrôlés indépendamment du modèle.
• [ ] Une approbation humaine existe pour les actions irréversibles.
• [ ] Les journaux distinguent contenu lu, plan modifié, outil appelé et action bloquée.
• [ ] Les scénarios sont rejoués après chaque modification de modèle, parseur, Skill ou politique.
• [ ] La décision de continuer, limiter ou suspendre est documentée.

Première semaine : pilote limité contre suspension globale

À la fin de la première semaine, prenez une décision par capacité et non une décision globale sur DeepSeek Harness.

Continuez le pilote si les tâches restent limitées à la lecture, à la synthèse, au classement ou à la génération de propositions, avec des sources identifiées et des outils sensibles désactivés ou soumis à approbation.

Limitez le périmètre si l’agent peut écrire dans un espace de travail non critique, avec des permissions minimales et des sorties réversibles. Pour un projet audio, vidéo ou design, cela peut correspondre à la création de fichiers proxy, de scripts de montage ou de variantes visuelles dans un répertoire temporaire, sans accès aux fichiers maîtres ni publication automatique.

Suspendez le déploiement privilégié si une source non approuvée peut encore atteindre une commande, un courriel, une soumission externe, un dépôt critique ou une opération financière sans contrôle indépendant.

Un environnement Mac distant séparé peut faciliter les essais, les fixtures et la conservation des journaux. Si vous devez tester une configuration hors de votre poste principal, vous pouvez examiner les nœuds de calcul Mac disponibles chez MacDate. Cette séparation matérielle ne remplace toutefois ni l’approbation, ni la réduction des permissions, ni l’isolement réseau. Pour choisir l’implantation technique d’un pilote, comparez les contraintes de latence, de stockage temporaire et de contrôle d’accès propres à votre équipe. Une estimation préalable des ressources peut s’appuyer sur un guide indépendant de comparaison des coûts de nœuds Mac, sans confondre coût d’hébergement et niveau de sécurité.

Versions suivantes : conclusion mise à jour contre verdict figé

Traitez cette publication comme un point de départ dans votre gestion des changements. La conclusion peut évoluer si DeepSeek Harness modifie :

• la construction du contexte après un résultat d’outil ;
• les champs additionalContexts ;
• le registre des outils ;
• les écouteurs de pré-exécution ;
• les règles ToolGuard ;
• l’approbation ou le bac à sable ;
• le chargement des Skills ;
• le client MCP ;
• le modèle ou son adaptateur ;
• les parseurs et conversions de fichiers.

Après chaque modification, mettez à jour la conclusion de contrôle au lieu de publier une nouvelle synthèse inchangée. Gardez trois statuts :

• continuer : aucun chemin non approuvé vers un outil sensible dans les scénarios représentatifs ;
• restreindre : certaines sources ou actions restent bloquées jusqu’à correction ;
• suspendre : une action privilégiée reste accessible après l’influence d’un contenu externe.

Surveillez le texte complet de la publication, ses éventuelles révisions, le dépôt public d’AI-Infra-Guard, le dépôt DeepSeek Harness utilisé par votre équipe et les notes de version officielles. Le dépôt public décrit AI-Infra-Guard comme une plateforme de tests couvrant notamment les agents, les Skills et les serveurs MCP ; ses instructions indiquent également que certaines fonctions de déploiement doivent être protégées par une authentification avant exposition publique. Consultez le dépôt public de reproduction et ses consignes de déploiement.

Laisser un agent local lire librement des fichiers, des pages et des Skills avant d’exécuter des commandes conserve trois défauts : la provenance disparaît parfois lors de la sérialisation, l’approbation peut arriver trop tard et les permissions de la machine deviennent le dernier rempart. Une exécution distante non isolée ajoute souvent des secrets partagés, un accès réseau trop large et des résultats difficiles à reproduire. Pour un pilote temporaire, une machine Mac séparée peut donc être préférable à un poste de développement mélangé aux données de production, à condition de conserver les contrôles d’autorisation et les fixtures.

La conclusion est opérationnelle : resserrez maintenant les chemins entre contenus externes et outils sensibles, mais ne généralisez pas les taux de l’étude à toutes les installations DeepSeek Harness. Pour convertir ce signal en décision fiable, commencez par vérifier vos permissions, la confiance accordée aux Skills, l’isolement de l’espace de travail et la répétabilité de vos tests avant d’élargir le pilote.

Questions fréquentes

Les réponses ci-dessous servent à vérifier votre interprétation avant de transformer un résultat de recherche en décision de production.

La recherche sur DeepSeek Harness signifie-t-elle qu’il faut tout arrêter ?

Non. Elle impose de bloquer en priorité les chaînes qui relient une source non approuvée à une action irréversible sans approbation indépendante. Les tâches de lecture, de synthèse ou de préparation peuvent rester en pilote isolé si les secrets sont absents, les outils sensibles sont désactivés et les traces sont conservées. La suspension doit viser le privilège, pas nécessairement tout le moteur.

Le taux d’attaque publié peut-il être appliqué à votre déploiement ?

Non. Les pourcentages concernent une révision, un modèle, une configuration, des canaux et des fixtures déterminés. Reprenez quelques scénarios avec vos formats, vos Skills, vos serveurs MCP et vos contrôles. Comparez ensuite quatre étapes : entrée dans le contexte, changement de plan, appel d’outil et blocage. Le chiffre publié est un signal de priorité, non une estimation de votre probabilité locale.

Pourquoi les Skills et les pages web influencent-elles une action sensible ?

Parce que le résultat d’une source peut devenir une partie du contexte visible par le modèle, puis précéder sa décision d’appeler un outil. Une page, une Skill ou un document n’a pas besoin de remplacer le message utilisateur pour modifier la trajectoire de l’agent. La provenance, le support et le niveau de confiance doivent donc accompagner le contenu jusqu’au point d’autorisation.

Quelles tâches DeepSeek Harness faut-il suspendre maintenant ?

Suspendez les tâches où une page, un fichier, une Skill, un courriel ou un résultat MCP peut déclencher directement une commande, une écriture critique, un envoi, une publication, une modification de dépôt ou un transfert. Maintenez éventuellement les tâches de préparation sans effet externe, avec des permissions minimales, des données fictives et une validation humaine avant toute sortie du périmètre.