Une liste d'autorisation de sortie (egress) est-elle réaliste pour un agent qui navigue sur le web ?

Oui, si vous limitez la forme plutôt que l'ensemble. Autorisez un large trafic GET via un proxy qui interdit les corps de requête et limite les tailles : l'agent peut ainsi lire à grande échelle sans disposer de canal suffisant pour exporter ce qu'il a lu.

Le DNS doit-il figurer sur la liste ?

Tout à fait. Un résolveur que l'agent peut interroger librement constitue un canal d'exfiltration — les données encodées dans des requêtes de sous-domaines s'échappent sans la moindre requête HTTP. Soumettez le DNS à la même politique.

Nous disposons déjà d'outils de moindre privilège. Est-ce redondant ?

Non, ils couvrent deux aspects complémentaires. Le moindre privilège limite ce que l'agent peut faire, tandis que le contrôle des flux sortants (egress) limite la destination de ce qu'il a déjà lu. Un agent en lecture seule avec un accès sortant ouvert peut tout de même divulguer l'intégralité de ce qu'il est capable de lire.

Sécurité et supervisionMis à jour 2026-08-25 · Version 1.1

Liste d'autorisation de sortie

Restreignez les destinations autorisées pour le trafic d'un agent. Le vol de données et la livraison de charges utiles d'injection se terminent tous deux par une requête sortante, de sorte qu'une liste de destinations autorisées avec refus par défaut est le contrôle qui fonctionne encore lorsque tous les autres ont échoué.

Preuve: Observation du secteurConfiance: ÉlevéSource: Observation du secteurSource: Expérience personnelleSource: Publication scientifique

Lisible par machine: JSON

Définition

Une liste d'autorisation de sortie est une politique au niveau du réseau ou du bac à sable (sandbox) qui n'autorise les requêtes sortantes d'un agent que vers un ensemble de destinations explicitement nommées et refuse tout le reste par défaut, de sorte que les données ne peuvent pas être envoyées vers un point de terminaison choisi par un attaquant, même si l'agent a été entièrement compromis.

Problème

Chaque chemin d'exfiltration se termine par une requête sortante. Un agent capable d'atteindre des hôtes arbitraires peut recevoir l'instruction d'envoyer tout ce qu'il a lu à n'importe quelle adresse, et aucune instruction au niveau du prompt ne peut l'empêcher.

Quand l'utiliser

Utilisez-le partout où un agent traite du contenu non approuvé et peut effectuer des requêtes réseau — récupération de pages, appels d'outils, rendu d'images, exécution de code généré. Ce pattern est le plus précieux là où l'injection est la plus probable.

Solution

Refus par défaut. La liste d'autorisation est la seule issue ; tout ce qui n'y figure pas est refusé, et le refus est journalisé comme un signal plutôt que d'être étouffé sous forme d'erreur.

Énumérez les destinations à partir de la tâche : les API que l'agent doit appeler, les domaines qu'il doit récupérer, les registres à partir desquels il doit installer — chacun avec un propriétaire et un motif écrit.

Appliquez les règles en aval de l'agent. Placez la politique dans le sandbox, le proxy ou le réseau, jamais dans le code de l'outil dont le modèle pourrait s'affranchir par la discussion. Une règle qu'un agent peut contourner par la persuasion est une simple documentation, pas un contrôle.

Fermez les canaux discrets. Les URL d'images générées, les aperçus de liens, les requêtes DNS, les webhooks, les rapports d'erreurs et les installations de paquets constituent tous des flux sortants (egress), et ils sont tous exploités.

Autorisez les hôtes dont vous pouvez analyser le comportement. Un caractère générique (wildcard) sur un hôte qui héberge du contenu fourni par l'utilisateur — un CDN de fichiers bruts, un site de partage de texte (paste site), un stockage d'objets public — est un canal ouvert déguisé en liste d'autorisation.

Déduisez la liste à partir de mesures réelles et recalculez-la lorsque la tâche change. Partez de ce que l'agent appelle réellement, et non de ce que l'on suppose qu'il appelle.

Composants

Une passerelle de sortie (egress gateway) ou une politique réseau de sandbox que tout le trafic doit obligatoirement traverser.Une règle de refus par défaut avec un inventaire explicite et géré des destinations autorisées.Des politiques par rôle, afin qu'un agent de recherche et un agent de déploiement ne partagent pas la même liste.La journalisation des refus connectée à un système d'alerte, car un refus est un événement à fort signal.Des contraintes sur les méthodes et les charges utiles (payloads) lorsque la destination seule ne suffit pas (GET uniquement, limites de taille du corps de la requête).Un cycle de révision régulier pour supprimer les destinations qui n'ont pas été utilisées.

Avantages

Limite l'exfiltration de données même après un compromis total du raisonnement de l'agent.
Rend les tentatives visibles : une destination refusée est l'un des rares signaux d'attaque non ambigus générés par une pile d'agents.
Indépendant du modèle — il continue de fonctionner lors des changements de modèle, des modifications de prompt et des migrations de framework.
Peu coûteux à étendre une fois la passerelle en place ; chaque nouvel agent hérite du point de contrôle.

Risques

Le relais sur liste d'autorisation : un hôte autorisé qui réachemine lui-même les données réduit la liste d'autorisation à une simple formalité.
Risque de rupture lorsqu'une dépendance légitime change d'hôte, ce qui pousse à élargir la liste dans l'urgence.
L'érosion par caractères génériques (wildcards) : chaque entrée large ajoutée « temporairement » devient permanente tant qu'aucun audit n'est réalisé.
Application au mauvais niveau — un contrôle au sein du processus (in-process) que le code généré peut simplement contourner.

Quand ne pas l'utiliser

Agents entièrement hors ligne, pour lesquels il n'y a aucun flux sortant à restreindre et où le contrôle ne serait que de la figuration.
Lorsque la conception n'autorise déjà qu'une seule et unique destination, faisant de la liste d'autorisation une propriété intrinsèque de l'architecture plutôt qu'une politique à ajouter.
Lorsqu'un proxy d'entreprise applique déjà la même politique et qu'une seconde liste diviserait la responsabilité sans ajouter de contrainte réelle.

Technologies

Egress proxiesContainer network policiesService mesh policyDNS filteringDenial logging and alerting

Exemples

Un agent de codage dans un conteneur dont la politique de sortie (egress) ne mentionne que le registre de paquets et l'hôte Git interne. Une instruction injectée visant à envoyer un POST du dépôt vers un collecteur externe échoue au niveau de la couche réseau et apparaît comme un refus.
Un agent de recherche autorisé à effectuer des requêtes étendues mais contraint de passer par un proxy qui n'autorise que le GET et limite la taille des corps sortants — lui permettant ainsi de lire le web sans disposer de canal pour y écrire.
Le paquet stdio publié pour cette base de connaissances : sa seule destination sortante est le point de terminaison public pour lequel il sert de proxy, de sorte que la liste d'autorisation est une propriété de la conception plutôt qu'une politique superposée a posteriori.

KPI

Tentatives de sortie (egress) refusées: Le signal que ce pattern a pour but de produire. Une hausse prolongée indique soit une attaque, soit une tâche devenue trop large pour sa liste — deux informations cruciales à connaître.
Taille de la liste d'autorisation: Destinations autorisées par rôle d'agent. Une croissance sans suppression correspond à une dérive de la liste vers un mode « tout autoriser ».
Entrées avec caractères génériques (wildcards): Nombre d'entrées larges. Chacune d'elles représente un canal dont vous ne pouvez pas analyser le comportement ; l'objectif est d'en avoir zéro.
Délai entre le refus et le tri: Le temps d'attente d'un refus avant qu'un humain ne l'examine. Un refus non consulté est une alerte qui n'existe pas réellement.

Modes de défaillance observés

Le relais sur liste d'autorisation : un hôte approuvé qui réacheminera tout ce qu'il reçoit, de sorte que la vérification de la destination réussit et que les données s'échappent tout de même.
L'érosion par caractères génériques (wildcards) : des entrées larges temporaires qui survivent à la raison pour laquelle elles ont été ajoutées.
Application au sein du processus (in-process) : le contrôle réside là où le code généré s'exécute, permettant à ce dernier de l'ignorer.
Refus silencieux : des refus enregistrés comme de simples erreurs réseau ordinaires, de sorte que l'unique signal généré par le pattern ne parvient jamais à personne.

Leçons apprises

Le contrôle des flux sortants (egress) est le dernier rempart qui fonctionne encore une fois que le modèle a été manipulé. Mettez-le en place avant d'en avoir besoin.
Déduisez la liste à partir du trafic mesuré plutôt que de suppositions. C'est précisément ce que nous avons fait pour la règle d'origine entrante sur notre propre point de terminaison MCP, ce qui a produit une règle bien différente de celle que nous aurions écrite par défaut.
Traitez un refus comme une alerte, pas comme une erreur. C'est le signal d'attaque le plus économique de la pile.
Chaque caractère générique (wildcard) est une promesse que vous ne pouvez pas tenir. Nommez explicitement les hôtes, ou acceptez le fait que vous n'avez pas de liste d'autorisation.

FAQ

Une liste d'autorisation de sortie (egress) est-elle réaliste pour un agent qui navigue sur le web ?: Oui, si vous limitez la forme plutôt que l'ensemble. Autorisez un large trafic GET via un proxy qui interdit les corps de requête et limite les tailles : l'agent peut ainsi lire à grande échelle sans disposer de canal suffisant pour exporter ce qu'il a lu.
Le DNS doit-il figurer sur la liste ?: Tout à fait. Un résolveur que l'agent peut interroger librement constitue un canal d'exfiltration — les données encodées dans des requêtes de sous-domaines s'échappent sans la moindre requête HTTP. Soumettez le DNS à la même politique.
Nous disposons déjà d'outils de moindre privilège. Est-ce redondant ?: Non, ils couvrent deux aspects complémentaires. Le moindre privilège limite ce que l'agent peut faire, tandis que le contrôle des flux sortants (egress) limite la destination de ce qu'il a déjà lu. Un agent en lecture seule avec un accès sortant ouvert peut tout de même divulguer l'intégralité de ce qu'il est capable de lire.