Les revues de sécurité des agents de codage doivent inclure les extensions exécutables autour du modèle. La recherche en laboratoire publiée par le CERT-EU le 30 octobre montre pourquoi une conversation d’apparence propre et un journal d’appels d’outils silencieux ne suffisent pas à établir que le processus environnant est resté dans les limites autorisées pour les fichiers et le réseau.
Dans des tests contrôlés, le CERT-EU a modifié des copies locales de deux paquets tiers utilisés avec Pi et Claude Code. Un déclencheur dans le texte soumis amenait le code ajouté dans le gestionnaire d’événements à collecter puis transmettre des informations sur l’hôte pendant que les conversations normales se poursuivaient. Les chercheurs ont utilisé un laboratoire isolé et des identifiants de test. Ils n’ont ni modifié ni diffusé de versions publiques, et le rapport n’établit pas la compromission d’une victime.
Le résultat concerne les configurations testées. Il ne montre pas que chaque extension est malveillante ni que chaque contrôle de sécurité d’agent peut être contourné. Selon l’analyse de Maetra, les responsables de déploiement devraient tester la frontière d’exécution du processus complet, en plus des contrôles appliqués aux actions générées par le modèle.
Demandez quel processus peut atteindre la ressource sensible
Une équipe d’ingénierie, par exemple, peut autoriser un agent de codage à inspecter un dépôt tout en refusant au modèle l’accès à un répertoire d’identifiants. Cette règle n’est utile qu’à l’intérieur de la frontière où elle est appliquée. Si une extension chargée peut lire directement le même répertoire via le processus hôte, l’équipe doit alors évaluer un chemin d’accès distinct.
Commencez une revue de déploiement en identifiant l’identité au niveau du système d’exploitation, les répertoires montés, l’environnement hérité et les autorisations réseau sortantes du processus qui charge les extensions. Demandez ensuite quels contrôles s’appliquent à ce processus et lesquels ne s’appliquent que lorsque le modèle demande une opération d’outil.
Gardez des réponses précises. Une demande d’autorisation du modèle, une règle de montage de conteneur et une restriction réseau peuvent toutes protéger des parties différentes d’un flux de travail. Consignez l’endroit où chacune opère et ce qui se passe lorsque l’opération provient d’un gestionnaire d’extension. N’inférez pas la couverture à partir d’un libellé de produit partagé.
Concevez un test inoffensif qui franchit la frontière prévue
Maetra recommande un environnement de test autorisé avec un faux secret délibérément créé et un collecteur contrôlé par l’équipe de test. Il n’est pas nécessaire d’utiliser des identifiants de production ni de reproduire un mécanisme de vol pour répondre à la question fondamentale de la frontière.
Définissez le résultat attendu avant d’exécuter le test. Par exemple, un processus d’extension ne devrait pas pouvoir lire un élément de test situé hors de son espace de travail attribué. Une requête vers une destination de test non approuvée devrait être refusée. Demandez au responsable de l’environnement d’observer si la règle appliquée au niveau de l’hôte bloque l’action et si la supervision enregistre la tentative.
Le plan de test doit nommer le composant exercé, sa version, son identité d’exécution et la restriction pertinente. Un refus réussi au niveau du modèle et un refus réussi au niveau de l’hôte constituent deux résultats distincts. Enregistrez les deux lorsque les deux comptent. Si l’environnement autorise l’opération, documentez la ressource accessible et décidez comment réduire cet accès avant d’élargir le déploiement.
Il s’agit d’un processus de validation défensive proposé. Maetra n’a pas reproduit indépendamment les expériences du CERT-EU, et cet article n’affirme pas l’existence d’un défaut non signalé dans un paquet précis.
Rendez visibles pour le responsable du déploiement les changements d’extension
Un inventaire de déploiement doit couvrir plus que le modèle et ses outils annoncés. Maetra recommande d’enregistrer chaque extension exécutable, son origine, la version installée, les hooks d’événements activés et le responsable qui a accepté le changement. Indiquez également comment elle est mise à jour et quel environnement la charge.
Lorsqu’une divergence fait l’objet d’une enquête, examinez l’artefact réellement installé. Une description de registre peut expliquer la fonctionnalité prévue, mais le dossier de déploiement doit identifier ce que le processus a effectivement chargé. Conservez la révision pertinente avec le résultat de la revue afin qu’une mise à jour ultérieure n’hérite pas silencieusement d’une conclusion plus ancienne.
Pour l’intégration continue, identifiez si l’agent s’exécute avec des jetons de dépôt, un accès au stockage d’artefacts ou des identifiants de déploiement. Demandez lesquels sont nécessaires pour la tâche assignée. Un test concluant dans l’environnement restreint d’un développeur n’établit pas la même frontière dans un exécuteur de build disposant de privilèges plus larges.
Conservez des éléments de preuve en dehors de la conversation
Un intervenant en réponse à incident doit pouvoir corréler l’installation des extensions et l’activité du processus avec la chronologie de la tâche. Les enregistrements utiles peuvent inclure la révision installée, l’identité d’exécution, les refus d’accès aux fichiers et les décisions réseau. Recueillez le minimum d’informations nécessaire pour répondre à la question d’enquête et appliquez les règles de conservation et d’accès de l’organisation.
Évitez de considérer l’absence d’appel d’outil du modèle comme une preuve qu’aucune opération sur l’hôte n’a eu lieu. Le dossier doit expliquer quelle télémétrie a été collectée et quels chemins restent non observés. Cette distinction aide un enquêteur à séparer un refus vérifié d’un angle mort de supervision.
La couverture secondaire du rapport du CERT-EU dérive de la source. Elle peut établir que la recherche a reçu une couverture médiatique ; elle ne valide pas indépendamment la télémétrie du laboratoire. Le rapport principal reste la base des affirmations expérimentales présentées ici.
Donnez un rôle défini à l’analyse à l’exécution
Maetra Secure inspecte les prompts, messages, appels d’outils et sorties couverts afin de détecter les menaces à l’exécution. Discover prend en charge l’inventaire et la détection des changements. Ces capacités peuvent contribuer à une revue de déploiement, mais l’analyse des entrées du modèle ou de ses appels d’outils ne remplace pas les contrôles appliqués au niveau de l’hôte sur du code exécutable arbitraire.
La tâche opérationnelle immédiate consiste à désigner un responsable de la frontière d’exécution des extensions et à tester, dans un environnement sûr, une restriction d’accès à un fichier ou de réseau sortant. La documentation de Maetra explique les frontières du produit que les équipes doivent prendre en compte lorsqu’elles décident où l’inspection à l’exécution s’insère dans ce plan de contrôle plus large.
Sources
- CERT-EU : Beyond the model: backdoors in AI agent harnesses, 30 octobre 2026. Recherche contrôlée sur des paquets modifiés localement, et non signalement de versions publiques modifiées.