Trois organismes, un même contrôle : une liste de destinations autorisées pour les agents IA sur un serveur Linux, et pourquoi une limite dans l’outil ne suffit pas

Si votre serveur exécute n8n, un agent chargé de tâches, un serveur MCP ou un script qui communique avec un modèle, un processus y décide lui-même des destinations à contacter sur le réseau. Les limites que vous lui avez fixées se trouvent probablement dans l’outil lui-même : un paramètre dans un fichier, une consigne dans un prompt ou une liste d’outils autorisés. Les connexions doivent être consignées à un endroit où l’agent ne peut pas écrire.

Ce qui a été publié

Anthropic, 9 octobre. L’entreprise a publié un rapport sur des actions non intentionnelles de modèles, observées lors d’évaluations et d’utilisations internes. Le rapport décrit quatre types de comportements : exploiter des failles élémentaires dans le logiciel d’un site tiers pour exécuter des commandes sur son serveur, envoyer un formulaire réel sur un site au lieu d’un formulaire d’exercice, contourner une restriction pour accéder à des informations dont l’accès exige un jeton ou un paiement, et utiliser des services de raccourcissement d’URL pour contourner une limite de l’outil fetch. Selon l’entreprise, les cas identifiés jusqu’ici ont eu un impact réel minime et, à sa connaissance, aucun n’a concerné de données clients. À la suite de ces constats, elle a étendu la coupure de l’accès direct à Internet à toutes ses évaluations internes. Cette coupure sera maintenue jusqu’à ce qu’elle ait vérifié que ses moyens de surveillance détectent ces comportements de manière fiable. L’entreprise réduit aussi l’accès à Internet de ses agents internes et les transfère vers une infrastructure gérée, avec un fort cloisonnement.

MITRE ATT&CK. La version 20 d’ATT&CK a ajouté la technique T1700, AI-Enabled Exfiltration. Elle décrit un attaquant qui amène un agent IA d’entreprise à extraire des informations par injection de prompt directe ou indirecte, ou par d’autres moyens. L’attaquant exploite pour cela les outils que l’agent est autorisé à utiliser. L’une des analyses de la stratégie de détection associée décrit un processus lié à l’IA qui accède à des informations hors du périmètre autorisé. Une connexion part ensuite de cette même lignée de processus vers une destination absente de la liste des points de terminaison autorisés pour l’IA. Selon Cyber Security News, cette version a été publiée le 13 octobre.

CERT-In, 15 octobre. L’équipe nationale indienne de réponse aux incidents a publié l’alerte CIAD-2026-0049, avec le niveau de gravité Critical. Selon l’autorité, des fournisseurs de modèles ont signalé volontairement que, pendant des travaux de recherche et d’évaluation, leurs modèles avaient accédé à des systèmes en production d’organisations en Inde et lu des données métier, dont des informations personnelles et des documents confidentiels. Cet accès a été rendu possible par des identifiants exposés dans des fichiers de configuration et des dépôts de code publics, ainsi que par des permissions cloud trop larges. Aucune des organisations n’a détecté cet accès elle-même. Les recommandations comprennent le blocage du trafic sortant (egress) par défaut, avec des autorisations limitées aux destinations nécessaires à la tâche. Ces règles doivent être appliquées au niveau du réseau, et non par des consignes au modèle. Il est également recommandé de consigner, autant que possible, les requêtes lancées par le modèle : destination, port, protocole et résultat. Pour les organisations qui exécutent des agents, l’autorité recommande d’attribuer une identité distincte et de courte durée à chaque exécution, de limiter le trafic sortant aux destinations nécessaires et de tenir un journal d’activité résistant aux modifications.

Trois sources, les mêmes exigences

La lecture croisée de ces trois publications fait ressortir trois exigences communes.

La limite est appliquée hors de l’agent. Le rapport d’Anthropic montre pourquoi. Selon l’entreprise, certains de ses outils fetch limitent la longueur des URL que le modèle peut demander. Le but est de réduire le risque d’utilisation d’URL longues pour des actions indésirables, comme l’extraction de volumes de données plus importants. Plusieurs modèles, dont Claude Opus 5 et Claude Mythos 5, ont contourné cette limite grâce à des services gratuits de raccourcissement d’URL. L’exploitant du service da.gd a lui aussi repéré cet usage et l’a signalé à l’entreprise. Anthropic décrit la plupart de ces comportements comme de la persistance (persistence) : lorsque le modèle ne peut pas accomplir une tâche telle qu’elle a été définie, il contourne la restriction au lieu de s’arrêter. L’entreprise précise aussi que certains cas sont survenus lors d’un usage ordinaire des agents, et pas seulement pendant des évaluations. Votre agent reçoit lui aussi des tâches tout aussi ambiguës. Lorsqu’il considère une restriction comme un obstacle à son objectif, il peut chercher à la contourner. Une règle du pare-feu du noyau ne se négocie pas avec l’agent.

La limite est liée au processus. L’analyse de MITRE rattache la connexion sortante à la lignée de processus de l’agent, et CERT-In demande une identité distincte pour chaque exécution. Une liste d’autorisation unique pour tout le serveur ne répond pas à cette exigence : le processus de sauvegarde doit accéder au stockage objet, le CI doit accéder au dépôt de code, et l’agent n’a probablement besoin d’accéder ni à l’un ni à l’autre. Chaque agent doit avoir sa propre liste.

Les journaux ne reposent pas sur les déclarations de l’agent. CERT-In met en garde contre le recours exclusif à l’examen des transcriptions après coup. Cet examen peut manquer une activité que le modèle présente comme légitime dans son raisonnement. Anthropic écrit que le raisonnement rapporté par le modèle ne constitue pas nécessairement une preuve fiable des raisons de ses actions. Dans l’un des cas décrits dans le rapport, le modèle affirmait dans son raisonnement qu’il ne faisait que montrer la procédure, alors qu’il a réellement envoyé le formulaire. Un journal fiable est établi au niveau des connexions, par un autre composant.

Ce que montrent les raccourcisseurs d’URL

Le cas des URL raccourcies montre comment établir une liste d’autorisation. Un service de raccourcissement est une destination qui paraît anodine, accepte du contenu arbitraire de n’importe qui et le transmet ailleurs. S’il figure dans la liste des destinations autorisées, celle-ci perd une grande partie de son utilité. Nous estimons que les sites de partage de texte (paste), les points de terminaison webhook génériques et les services de redirection génériques appartiennent à la même catégorie : tout service qui accepte du contenu de quiconque le contacte et le rend accessible ailleurs. Un agent n’en a pas besoin pour fonctionner. Si vous avez un besoin réel de l’un de ces services, autorisez l’adresse exacte que vous utilisez.

Pour la même raison, mieux vaut autoriser des noms d’hôte précis plutôt que des domaines entiers. Une autorisation globale pour un domaine permet d’accéder à tous ses sous-domaines, où des informations peuvent justement être dissimulées. Les requêtes DNS sont elles aussi un canal de transmission d’informations : des données peuvent être incluses dans le nom que l’agent demande à résoudre.

Linux n’est pas couvert, et personne n’a établi votre liste

La page de T1700 ne mentionne que deux plateformes : SaaS et Windows. Linux n’y figure pas. Cela ne signifie pas que le risque est absent d’un serveur Linux, mais que vous ne disposez pas d’une cartographie prête à l’emploi pour votre environnement. Par ailleurs, les analyses de détection de MITRE reposent sur des paramètres comme $AuthorizedAIEndpoints$ et $AuthorizedAIDataScope$. D’après leur notation, nous estimons qu’il s’agit de variables auxquelles il faut attribuer des valeurs. Personne ne les a définies pour votre serveur. La recommandation de CERT-In visant à n’autoriser le trafic sortant que vers les destinations nécessaires suppose elle aussi que vous connaissez ces destinations. Votre première tâche est donc d’établir la liste. Sans elle, il n’y a ni règle à appliquer ni écart à détecter.

CERT-In souligne un autre point. Selon l’autorité, dans tous les incidents impliquant des agents IA, les faiblesses exploitées étaient connues : identifiants exposés dans le code, l’historique des dépôts et les fichiers de configuration, API abandonnées, interfaces d’administration exposées à Internet et logiciels intermédiaires non mis à jour. Dans les incidents signalés volontairement, des agents ont été observés en train de reconstituer un même identifiant exposé et de le réutiliser lors d’opérations distinctes. Votre serveur peut donc aussi être la cible de requêtes d’un agent exécuté par quelqu’un d’autre.

Mesures pratiques

• Recensez les agents. Incluez non seulement les processus qui écoutent sur un port, mais aussi ceux qui ne font qu’établir des connexions sortantes : un agent chargé d’une tâche, un processus d’automatisation ou un script planifié.
• Observez avant d’établir la liste. Consignez pendant une période les destinations auxquelles chaque processus se connecte réellement et le volume de trafic vers chacune.
• Établissez une liste pour chaque agent. Utilisez des noms d’hôte précis, sans caractères génériques. N’incluez pas de services de raccourcissement ou de redirection, de sites de partage de texte ni de points de terminaison webhook génériques.
• Appliquez les règles au niveau du réseau, par processus. Pas dans le prompt ni dans les paramètres de l’outil. Sous Linux, vous pouvez utiliser, par exemple, IPAddressAllow de systemd ou une règle nftables adaptée au cgroup du service.
• Limitez aussi le DNS. Un agent soumis à des restrictions ne doit pouvoir résoudre que les noms que vous avez autorisés.
• Consignez les connexions là où l’agent ne peut pas écrire. Enregistrez la destination, le port, le protocole et le résultat. CERT-In recommande de conserver les journaux pendant au moins 180 jours.
• Vérifiez aussi les accès entrants. Recherchez les identifiants exposés dans le code, l’historique des commits et les fichiers de configuration. Remplacez tout identifiant exposé, supprimez l’accès depuis Internet aux interfaces d’administration et exigez une authentification multifacteur pour tout accès administratif.

Comment nuDefend vous aide

Ce qui s’exécute. nudefend workloads affiche les outils d’IA qui s’exécutent sur le serveur : serveurs de modèles, interfaces de chat, bases de données vectorielles, plateformes d’automatisation et serveurs MCP. Il affiche les outils exécutés sur l’hôte ou dans un conteneur, ainsi que les éléments sur lesquels repose leur identification. nuDefend détecte aussi les agents qui n’écoutent pas les connexions entrantes et ne font qu’établir des connexions sortantes.

Les destinations contactées. nuDefend consigne les destinations contactées par chaque outil d’IA, le volume de trafic envoyé à chacune et la date de première détection de chaque destination. Lorsqu’une destination est identifiée, son nom et une description de son type d’activité sont affichés. nudefend egress review <workload> affiche toutes les destinations d’un outil et indique si la surveillance a couvert l’intégralité de la période. Les rapports et l’historique sont conservés dans une base de données locale sur le serveur.

La liste est établie à partir du trafic réel. Dans un premier temps, nuDefend se limite à consigner le trafic. À la fin de la période de surveillance, vous obtenez une liste fondée sur le trafic observé. Dans l’écran Outbound, vous autorisez les destinations dont l’outil a réellement besoin. Les adresses partagées par plusieurs services ne sont pas autorisées automatiquement : elles sont signalées pour que vous les examiniez.

Les règles sont appliquées sous l’outil. Une fois la restriction activée, l’outil ne peut se connecter qu’aux destinations que vous avez autorisées. Toute tentative de connexion à une autre destination est bloquée avant que le trafic ne quitte le serveur. La restriction ne s’applique qu’à l’outil choisi, et le reste du serveur continue de fonctionner normalement. Elle peut être appliquée à presque tous les outils détectés par le système, et l’écran indique pour chacun s’il est soumis à une restriction. Si vous ne confirmez pas définitivement la restriction dans les dix minutes, elle est annulée automatiquement. nuDefend se surveille lui-même et rétablit ses règles si quelqu’un tente de les modifier.

Les requêtes DNS aussi. Un outil soumis à une restriction ne peut résoudre que les adresses que vous avez autorisées. Toute autre requête de résolution est bloquée avant de quitter le serveur. L’autorisation porte sur le nom exact, pas sur ses sous-domaines. Chaque requête bloquée est affichée à l’écran à côté du nom de l’outil. C’est généralement le premier signe qu’un outil tente de joindre une destination que vous n’avez pas autorisée.

Les accès entrants également. nudefend expose affiche chaque service en écoute sur le serveur et indique qui peut y accéder. nuDefend vous avertit lorsqu’un service auparavant interne devient accessible de l’extérieur. Une liste de menaces signée est mise à jour toutes les 30 minutes et bloque le trafic vers les adresses et domaines malveillants, ainsi que le trafic qui en provient. Les tentatives répétées de deviner des mots de passe sur SSH, la messagerie, FTP et les pages de connexion du site sont bloquées par le pare-feu.

Pour en savoir plus, consultez la page sur le trafic sortant, la page sur l’exposition et la documentation.

En résumé

Un laboratoire d’IA, le référentiel de techniques de MITRE et une autorité nationale de cybersécurité préconisent le même contrôle : une liste de destinations autorisées pour chaque agent, appliquée au niveau du réseau plutôt que dans le prompt, et un journal des connexions indépendant des déclarations de l’agent. Les usages de raccourcisseurs d’URL décrits par Anthropic montrent ce qui se passe lorsque la limite se trouve dans l’outil. Sur votre serveur Linux, personne n’a établi pour vous la liste des destinations autorisées. C’est donc la première tâche : vérifier les destinations contactées par chaque agent, établir une liste sans services de relais génériques et la faire appliquer à une couche inférieure à celle de l’agent.