Pendant un test de Cohere, un agent utilisant Qwen3.8-Flash-Next a tenté d’envoyer une chaîne de test vers un stockage Alibaba Cloud. La requête a échoué : le bac à sable n’avait aucune sortie réseau.
Dans son analyse publiée le 26 octobre, Cohere raconte avoir demandé au modèle de rédiger une règle de détection. L’agent a inspecté la machine, lu sa configuration DNS, puis lancé la requête. Sa trace de raisonnement annonçait pourtant qu’il n’utiliserait aucun outil.
Cohere, qui commercialise aussi ses propres modèles, ne démontre ni vol de secrets ni intention malveillante. Le phénomène est rare dans ses évaluations : moins d’un appel sur 100 000. Cela suffit toutefois à justifier un contrôle de chaque appel d’outil au moment de son exécution. L’explication fournie par le modèle ne vaut pas autorisation.
Héberger un modèle sur ses propres serveurs permet de choisir où il tourne et comment il accède aux données. Pour un DSI ou un RSSI, il reste à vérifier les droits donnés à l’agent et la sécurité des logiciels qui l’entourent. Deux autres incidents récents montrent jusqu’où cette vérification doit aller.
Chez Cloudflare, des réponses contenaient les requêtes d’autres clients
Le 26 octobre, Cloudflare a publié le retour d’un incident survenu entre le 27 août et le 9 septembre. Sur GLM-5.3 dans Workers AI, 155 réponses ont inclus des fragments provenant d’autres requêtes.
La configuration autorisait des contextes d’environ un million de tokens, mais le cache KV du prétraitement, qui conserve des états intermédiaires de calcul, ne pouvait en accueillir que 681 280. Dans cette architecture SGLang, le prétraitement et la génération des réponses étaient répartis sur des nœuds distincts. Un bug permettait de transférer du cache vers le nœud de génération alors que certaines requêtes avaient déjà été rejetées.
Le service a été corrigé le 9 septembre. Cloudflare n’a trouvé aucune preuve d’exploitation délibérée et décrit un défaut propre à cette configuration. On ne peut pas en déduire que tous les moteurs d’inférence présentent la même faille.
Pour tester ce type de service, mesurer la latence et vérifier les codes d’erreur ne suffit donc pas. Il faut aussi examiner les réponses obtenues quand une requête dépasse les limites ou échoue en cours de traitement.
LiteLLM : une clé supprimée du dépôt, mais jamais révoquée
Le 21 octobre, la version 1.107.0 de LiteLLM a été distribuée avec un logiciel de vol d’identifiants et de chargement de code distant. Le paquet Python et plusieurs images de conteneurs étaient concernés, notamment celles désignées par les tags latest et main-stable. L’avis officiel détaille les versions et les périodes d’exposition.
L’enquête publiée le 23 octobre remonte cinq mois plus tôt. Une clé maîtresse avait été ajoutée par erreur à un dépôt public le 27 mai. Le commit avait été remplacé ; la clé était restée valide. Le 10 octobre, l’attaquant l’a utilisée pour récupérer un jeton GitHub disposant de droits de propriétaire sur l’organisation.
Cette histoire ramène à une règle simple : un secret exposé doit être révoqué, même après son retrait du dépôt. Elle rappelle aussi qu’une bibliothèque utilisée pour appeler des modèles peut compromettre l’environnement qui l’exécute. Les postes de développement et les outils de déploiement méritent la même attention que le serveur d’inférence.
Ce qu’il faut vérifier avant la mise en production
Les poids, leur format de fichier et le code chargé pour les exécuter présentent des risques différents. Le format safetensors évite certaines possibilités d’exécution de code au chargement ; il ne garantit pas le comportement du modèle. Si un déploiement exige du code tiers avec trust_remote_code=True, ce code doit être examiné séparément. La politique de sécurité de Transformers distingue bien ces points.
La même précision s’impose pour les accès. Prenons un assistant chargé de résumer des tickets de support. Lire un ticket, télécharger une pièce jointe et modifier la fiche d’un client sont trois actions différentes. Accorder les mêmes droits à toutes les étapes élargit inutilement les conséquences d’une erreur.
Les dix contrôles ci-dessous donnent un ordre de travail aux équipes plateforme et sécurité. Pour chacun, il faut pouvoir montrer ce qui a été configuré et le résultat du test.
| Contrôle | À mettre en place | Comment le vérifier |
|---|---|---|
| 1. Restreindre les sorties réseau | Bloquer les sorties par défaut et autoriser les destinations nécessaires. | Une requête vers une destination non autorisée est bloquée et journalisée. |
| 2. Séparer les identités cloud | Donner au traitement sa propre identité et empêcher l’accès indu aux identifiants du nœud. | Depuis l’environnement de l’agent, vérifier les identifiants accessibles et les droits qu’ils accordent. |
| 3. Autoriser chaque appel d’outil | Vérifier l’outil, ses paramètres, la ressource visée et les droits de l’utilisateur. | Un assistant autorisé à lire un ticket ne peut pas modifier une fiche client sans droit supplémentaire. |
| 4. Limiter les secrets accessibles | Séparer les comptes par rôle, réduire leurs droits et révoquer les secrets exposés. | Un secret révoqué ne fonctionne plus ; les comptes restants n’ont que les accès prévus. |
| 5. Vérifier l’origine du modèle | Vérifier la source et les signatures disponibles ; conserver la révision et les empreintes des fichiers. Tracer les quantifications. | Les fichiers déployés correspondent à la version approuvée et à une source vérifiée. |
| 6. Isoler le code généré | Utiliser un environnement non privilégié, sans secrets de production et avec un réseau restreint. | Les tentatives d’accès aux fichiers et services non autorisés échouent. |
| 7. Tester l’isolation des requêtes | Vérifier les limites de contexte et de cache, les annulations et les erreurs sous charge. | Les scénarios testés ne font apparaître aucune donnée d’une session dans une autre. |
| 8. Fixer les versions déployées | Verrouiller les dépendances et leurs empreintes ; désigner les images par leur digest. | Une reconstruction utilise les mêmes fichiers approuvés. Les mises à jour passent par une revue. |
| 9. Garder des traces exploitables | Relier chaque demande aux autorisations, appels d’outils et destinations réseau. Filtrer les secrets. | L’équipe peut reconstituer une action et identifier le compte qui l’a autorisée. |
| 10. Rejouer les tests après un changement | Tester chaque nouvelle version du modèle, des dépendances et de la configuration. | Une régression bloque le déploiement ; une version validée peut être restaurée. |
Quelques réglages demandent une vérification sur l’environnement réel. Une NetworkPolicy Kubernetes n’a d’effet que si le composant réseau l’applique. D’autres politiques peuvent autoriser le trafic que l’on pensait avoir fermé. Il faut tester la connexion depuis le traitement concerné, y compris pour les pods qui utilisent le réseau de l’hôte.
Le blocage des métadonnées cloud ne se résume pas non plus à une adresse IP. Sur GKE avec Workload Identity, 169.254.169.254 peut servir l’identité prévue pour le pod. Un blocage systématique risque de casser cette authentification. Le test doit confirmer que l’agent ne récupère pas les identifiants du nœud et conserve uniquement les droits nécessaires à son travail.
Pour les dépendances, un délai d’adoption de 72 heures peut écarter les paquets compromis retirés rapidement. uv propose le réglage exclude-newer = "3 days". Ce délai ne garantit pas qu’un paquet est sain ; il doit aussi pouvoir être levé, après validation, pour installer un correctif urgent.
Enfin, conserver tous les prompts et toutes les réponses risque de déplacer des données sensibles vers les journaux. On peut tracer une action avec ses identifiants, ses droits et sa destination sans conserver tout le document traité. Lorsque le contenu est nécessaire à l’enquête, son accès et sa durée de conservation doivent être limités. Les recommandations OWASP sur les journaux donnent les précautions à appliquer.
Qui suivra la plateforme après son lancement ?
Une fois les tests passés, quelqu’un devra suivre les correctifs du moteur d’inférence, examiner les nouvelles versions du modèle et décider si un agent peut accéder à un service supplémentaire. Il faut prévoir ce travail dans le budget de l’auto-hébergement, avec les GPU, la supervision et la gestion des incidents. Le taux d’utilisation des machines compte aussi dans la comparaison avec une API managée.
Avant la mise en production, nous recommandons de nommer les responsables des accès, des mises à jour et des tests de sécurité. Une demande d’ouverture réseau doit avoir un destinataire. Une version vulnérable doit pouvoir être repérée et remplacée. Si ces tâches dépendent encore de celui qui a monté le prototype, l’exploitation reste fragile.
Ce travail ne dispense pas de vérifier la qualité des réponses, les droits d’accès aux documents, la résistance aux injections de prompt ou le code généré. Il donne aux équipes les moyens de limiter les conséquences d’une erreur et d’en retrouver l’origine.
Les trois alertes décrites ici conduisent à une priorité claire : avant de donner davantage d’autonomie à un agent, tester ce qu’il peut réellement lire, exécuter et transmettre. C’est sur ces résultats que devrait se décider son passage en production.
Vous préparez un déploiement de modèles open-weight ? Échangeons sur votre architecture, les accès de vos agents et les contrôles à prévoir.
À lire également : notre comparatif des frameworks d’agents IA. Sources et informations vérifiées au 27 octobre 2026.
