DeepSeek V4 Pro : la sécurité dépend du « harness », pas seulement du modèle

Les organisations qui déploient des agents fondés sur DeepSeek V4 Pro ne devraient pas évaluer le modèle seul. L’unité pertinente est une configuration complète modèle–harness–tâche–environnement — le harness désignant la couche d’orchestration qui gère les instructions, les outils, l’état de session et l’exécution.

La disponibilité du modèle via plusieurs interfaces — web, application mobile, API, Responses API ou intégration Codex — peut confirmer une compatibilité technique. Elle ne prouve pas que les prompts, outils, permissions, mécanismes de reprise, mémoires ou effets de bord se comportent de la même manière partout.

La règle opérationnelle est donc simple : n’approuver qu’une configuration précisément épinglée, après que cette configuration a passé sa propre évaluation de sécurité.

Le harness transforme le modèle en agent

Un agent ne se résume pas à son modèle de langage. La couche d’orchestration détermine notamment la façon dont le modèle reçoit ses consignes, choisit ses outils, accède aux données, gère les erreurs et agit sur des systèmes externes.

Les différences importantes peuvent concerner :

• le prompt système et les adaptateurs de compatibilité ;
• la définition et l’implémentation des outils ;
• les niveaux d’autorisation et les étapes d’approbation ;
• les racines du système de fichiers et l’accès réseau ;
• les sources d’identifiants et l’identité utilisée ;
• l’exécution de sous-processus et de code généré ;
• les règles de nouvelle tentative, de délai d’attente et de concurrence ;
• l’état de session, les résumés, les caches et la mémoire persistante.

Le même backend DeepSeek V4 Pro peut donc présenter un profil de risque différent selon le harness et l’environnement d’exécution utilisés. Un schéma d’API compatible est une propriété d’intégration, pas une certification de sécurité.

Ce que montre AgentS4D — et ce que ses chiffres ne disent pas

Le benchmark AgentS4D évalue des configurations d’exécution complètes plutôt que des réponses isolées du modèle. Il a utilisé 328 cas comportant une injection de risque, testés avec quatre harnesses et cinq backends de modèles, pour un total de 6 560 exécutions en environnement sandboxé. L’étude rapporte 4 461 exécutions dangereuses, soit 68,0 %, et 4 344 exécutions, soit 66,22 %, à la fois dangereuses et jugées terminées. 13

Le résultat le plus important est le suivant : une tâche peut être menée à bien alors que son exécution reste dangereuse. Un agent peut produire le fichier demandé tout en effectuant une modification interdite, en exposant une donnée sensible, en contournant un contrôle prévu ou en créant un autre effet de bord indésirable.

Ces chiffres ne doivent pas être présentés comme le taux d’incidents en production de DeepSeek V4 Pro. L’évaluation repose sur des cas volontairement conçus pour injecter des risques, dans un bac à sable contrôlé, et agrège plusieurs combinaisons modèle–harness. Les tâches réelles, les contrôles disponibles, l’exposition à des contenus adverses, les actifs concernés et la définition d’un dommage peuvent différer en production. Le benchmark montre que la sécurité doit être mesurée directement ; il ne prédit pas ce qui arrivera dans chaque déploiement. 135

Réduire les conséquences maximales d’une erreur

Les contrôles doivent limiter les dégâts même lorsque le modèle ou un outil se comporte de façon inattendue.

Utiliser des identités dédiées et des privilèges minimaux

Créez des identités distinctes pour les agents, les environnements et les locataires. Évitez les identifiants employés réutilisés, les droits d’administration en production et les secrets largement partagés. Chaque identité doit être limitée aux ressources et opérations nécessaires à une tâche donnée.

Cloisonner le système de fichiers et le réseau

• Ne montez qu’une racine de travail dédiée.
• Rendez les chemins sans rapport réellement inaccessibles, au lieu de simplement les masquer.
• Autorisez explicitement les destinations réseau, méthodes, ports et, si nécessaire, le volume des sorties.
• Séparez les capacités de lecture, de rédaction, d’écriture en préproduction et d’écriture en production.
• Conservez les secrets dans un coffre ou utilisez des jetons à courte durée de vie.
• Ne placez jamais d’identifiants persistants dans les prompts, fichiers de travail, variables d’environnement ou sorties d’outils.

Les actions à fort impact — suppression, publication, paiement, modification des accès, déploiement ou communication externe — devraient passer par une vérification de politique au niveau de l’exécution ou nécessiter une approbation explicite.

Examiner toute la chaîne d’exécution

Les outils fournis directement par l’organisation ne constituent qu’une partie de la surface d’attaque. Les processus enfants, commandes shell, codes générés, installations de paquets, serveurs d’outils distants, extensions et compétences peuvent également produire des effets de bord.

La même politique doit s’appliquer à tous ces chemins. Il faut notamment empêcher le shell ou le code généré de contourner les contrôles portant sur le système de fichiers, le réseau, l’autorisation, la journalisation ou l’approbation.

Rendre les outils contraignants en dehors du modèle

Un appel d’outil généré par un modèle doit être considéré comme une demande non fiable. C’est le serveur d’outils — et non le modèle — qui doit appliquer les règles d’autorisation et de sécurité.

Privilégiez des schémas étroits intégrant notamment :

• des valeurs d’énumération limitées et des longueurs maximales ;
• la normalisation des chemins et des identifiants de ressources explicites ;
• des listes d’autorisation pour les destinations ;
• des limites de pagination et de taille des résultats ;
• une validation des arguments en dehors du modèle ;
• une autorisation côté serveur tenant compte de l’appelant, du locataire, de la cible et de l’opération.

Séparez les outils de planification ou de prévisualisation des outils qui produisent effectivement un changement. Pour les opérations destructrices ou difficiles à inverser :

• exigez une prévisualisation et une confirmation, ou un jeton d’approbation ;
• privilégiez la corbeille, la mise en quarantaine ou les procédures réversibles ;
• utilisez des clés d’idempotence ;
• définissez le comportement lorsqu’une même requête est relancée ;
• renvoyez des reçus persistants afin qu’une nouvelle tentative ne reproduise pas l’effet.

Un appel JSON parfaitement valide peut malgré tout viser une ressource non autorisée, contenir un chemin dangereux, demander des privilèges excessifs ou déclencher une opération qui devrait être soumise à un contrôle humain.

Définir l’état et la mémoire avant le déploiement

L’état peut transporter un risque d’un tour de conversation à l’autre, d’une tâche à l’autre, ou d’un utilisateur à l’autre. Il faut documenter et appliquer les règles de cycle de vie des messages, fichiers importés, fichiers de travail, résumés, résultats d’outils, caches et mémoires persistantes.

Précisez au minimum :

• L’isolation : séparer l’état par utilisateur, locataire, tâche et environnement, sans partage implicite entre sessions.
• La conservation : définir la durée de vie, le chiffrement, les contrôles d’accès et les règles de suppression.
• La réinitialisation : prévoir une procédure documentée pour effacer le contexte, la mémoire, l’espace de travail, les identifiants et les caches entre deux exécutions.
• Les reprises et délais : limiter le nombre de tentatives et les budgets d’exécution ; les reprises doivent préserver l’idempotence et ne jamais élargir silencieusement les privilèges.
• La concurrence : définir le verrouillage et la gestion des conflits pour les fichiers partagés, les approbations et les opérations externes.

La réinitialisation de l’état fait partie de la frontière de sécurité. Si d’anciennes instructions, de vieux identifiants ou des résultats d’outils peuvent réapparaître dans une nouvelle tâche, une mise à jour du modèle ou une modification du prompt peut changer le niveau de risque sans que des tests limités aux réponses ne le détectent.

Considérer tout contenu porteur de risque comme non fiable

Une injection de prompt ne vient pas nécessairement du message direct de l’utilisateur. Des instructions dangereuses peuvent être intégrées dans :

• des documents importés et des fichiers de dépôt ;
• des pages web récupérées ;
• des compétences et extensions externes ;
• les réponses d’un service d’outils ;
• la mémoire persistante ;
• des résumés et du contexte mis en cache ;
• du texte fourni par l’utilisateur.

Ces contenus doivent être analysés, étiquetés et cités comme des données. Ils ne doivent pas pouvoir modifier l’autorité de l’agent, ses politiques, le choix de ses outils, l’utilisation de ses identifiants ou les exigences d’approbation. Cette séparation doit être imposée par l’environnement d’exécution, et pas seulement confiée à la capacité du modèle à reconnaître une instruction malveillante.

La checklist de mise en production

Avant d’autoriser un déploiement, figez et consignez la configuration exacte :

1. Modèle et routage : identifiant et version du modèle, route du fournisseur, paramètres d’inférence ou niveau d’effort, adaptateurs de compatibilité.
2. Comportement du harness : version, prompt système, logique de session, règles de reprise et de délai, politique des sous-processus et implémentation de la mémoire.
3. Outils et politiques : définitions et versions des outils, versions des politiques, seuils d’approbation, logique d’autorisation et frontières de confiance des serveurs d’outils.
4. Permissions : identités, périmètres, racines du système de fichiers, destinations réseau, sources d’identifiants et chemins d’écriture en production.
5. Sémantique de l’état : isolation, conservation, réinitialisation, comportement des caches, concurrence et frontières entre sessions.
6. Couverture adversariale : injections via chaque vecteur de risque, tentatives de confusion de rôle, exposition d’identifiants, traversée de chemins, SSRF ou abus des sorties réseau, réponses d’outils malveillantes, duplication par reprise, empoisonnement de mémoire et contournement des approbations.
7. Éléments de preuve : versions des prompts et politiques, appels et résultats d’outils, approbations, décisions de politique, différences dans l’espace de travail, requêtes sortantes, identité utilisée, artefacts finaux, résultat de complétion et résultat de sécurité associés à un identifiant d’exécution stable.

Évaluez séparément la réussite de la tâche et la sécurité. Un artefact final correct ne doit pas compenser un effet de bord dangereux : c’est l’enseignement central des résultats d’AgentS4D. 12

Relancer les tests après chaque changement important

La cible approuvée est la configuration épinglée, et non une étiquette permanente telle que « agent DeepSeek V4 Pro ». Relancez la suite propre à cette configuration après toute modification substantielle du modèle ou de sa route, des paramètres d’inférence, du prompt système, de l’adaptateur, de la logique de session, des outils, des politiques d’autorisation ou d’approbation, des identifiants, de la mémoire, des reprises, des délais, de la concurrence ou des limites réseau et fichiers.

Cette méthode transforme la sécurité d’exécution, souvent réduite à une hypothèse sur la qualité du modèle, en une décision de mise en production mesurable et liée à l’environnement précis capable de produire des effets dans le monde réel.