Le 24 octobre 2026, Reuters rapporte que Moonshot a réduit certaines capacités offensives de Kimi K3.1 Pro. Cette semaine, demandez à votre intégrateur de démontrer ce que la version proposée peut faire, avec vos outils et vos droits d’accès.
Selon Moonshot, des données et exercices liés à la cybersécurité ont été retirés de l’entraînement de Kimi K3.1 Pro pour limiter les usages malveillants, tout en préservant ses compétences générales de programmation. Reuters a relayé cette annonce le 24 octobre.
Pour votre entreprise, une question doit entrer dans le dossier d’achat : comment vérifier les capacités de la version effectivement installée ? Une promesse de réduction du risque ne décrit pas le comportement de votre futur agent lorsqu’il disposera d’un terminal, de documents et d’un accès réseau.
Ce qui est publié, et ce qui reste inconnu
Moonshot publie un résultat de 81 % sur son test cyber interne, contre 90,5 % pour une version sans ces mesures. Le modèle reste, selon l’entreprise, plus performant que son prédécesseur sur ces tâches. Reuters précise que ces résultats n’ont pas été vérifiés indépendamment.
Ces pourcentages mesurent la réussite d’exercices techniques. Ils ne représentent pas une probabilité d’incident dans votre entreprise.
Moonshot prévoit de publier les fichiers permettant d’exécuter le modèle sur une infrastructure tierce d’ici au 4 novembre. Cette échéance doit être distinguée de la disponibilité annoncée dans ses services hébergés.
L’annonce ne démontre ni la fiabilité de votre intégration, ni sa capacité à respecter votre périmètre d’autorisation. Ces deux points restent à vérifier sur votre installation.
À Toulouse, un audit de code doit rester dans son périmètre
Prenons une situation fictive : un éditeur de logiciels de 45 salariés, à Toulouse, souhaite utiliser Kimi pour examiner un ancien portail client. Son prestataire propose un agent capable de lire le code, de lancer des tests et de rédiger des corrections.
Le devis mentionne un modèle aux capacités cyber réduites. Mais l’environnement proposé contient aussi des identifiants donnant accès au portail en production.
Le dirigeant doit faire préciser le périmètre avant le pilote. L’agent doit-il seulement analyser une copie du code ? Peut-il exécuter des tests ? Sur quelles machines ? Qui autorise une intervention sur le service utilisé par les clients ?
Ces questions déterminent les accès à fournir et les résultats à accepter. Elles doivent figurer dans le cahier des charges.
Les 6 vérifications à exiger cette semaine
Les mesures suivantes constituent une grille de réception proposée pour votre déploiement.
- Identifiez précisément la version livrée. Faites inscrire dans le contrat le modèle, son mode d’hébergement et les éventuelles modifications du prestataire. Demandez une validation préalable avant tout remplacement. Une référence commerciale générale ne permet pas de reproduire vos essais.
- Testez les tâches que vous achetez. Préparez des exemples représentatifs : repérer une erreur, expliquer son impact, proposer une correction et vérifier celle-ci. Faites examiner les résultats par votre équipe technique. Consignez aussi les refus et les tâches inachevées, afin de connaître le travail humain restant.
- Délimitez les droits d’exécution. Listez les répertoires, machines et destinations réseau autorisés. Utilisez des comptes dédiés et un environnement d’essai séparé. Vérifiez que les restrictions fonctionnent réellement, y compris lorsque l’agent tente d’utiliser un outil supplémentaire.
- Réservez les interventions sensibles à une validation humaine. Désignez la personne qui autorise un test actif, une modification de code ou un passage en production. Faites approuver l’action et sa cible avant l’exécution. Une autorisation générale d’« améliorer la sécurité » laisse trop de place à l’interprétation.
- Exigez un journal permettant de reconstituer les actions. Conservez la version du modèle, les commandes exécutées, les ressources visées et les validations reçues. Fixez un délai de remise de ces éléments en cas d’incident. Demandez au prestataire de démontrer comment suspendre l’agent et retirer ses accès.
- Chiffrez les échecs et fixez une décision. Faites préciser la facturation des tentatives répétées, des corrections et des interventions humaines. Définissez un plafond pour le pilote. Avant vendredi 30 octobre, demandez un compte rendu permettant de décider entre prolongation des essais, déploiement limité ou abandon.
Ce que ça veut dire, vraiment
Une capacité volontairement réduite peut modifier à la fois le risque et l’utilité du service que vous achetez. Votre décision doit donc reposer sur un essai de la version livrée, dans un périmètre écrit et avec une facture mesurable. Cette semaine, demandez une démonstration sur vos tâches autorisées, puis faites approuver les accès nécessaires à chacune.