AWS a montré comment limiter l’accès des agents AI d’AgentCore aux seuls domaines approuvés

AWS a publié un guide pratique sur la façon de restreindre l'accès à Internet pour les agents IA au niveau du domaine. Il ne s'agit pas d'un nouveau modèle, mais d'une mesure de sécurité de base : les ressources AgentCore peuvent être configurées pour n'accéder qu'aux sites préapprouvés.

Pourquoi c'est nécessaire

Lorsqu'un agent obtient un accès réseau, le risque change radicalement. Même si le modèle suit bien les instructions, il peut encore recevoir une URL indésirable, une redirection ou un service externe qui ne devrait pas participer au processus. Pour les scénarios d'entreprise, c'est un problème non seulement de sécurité, mais aussi de contrôle des coûts, de conformité avec les politiques internes et de prévisibilité des résultats.

AWS suggère de résoudre ce problème au niveau du réseau plutôt que de compter uniquement sur les prompts et la logique de l'application. Dans la ventilation publiée, l'entreprise montre comment définir une liste blanche de domaines pour les ressources AgentCore via AWS Network Firewall. L'idée est simple : un agent ne doit pas choisir l'intégralité d'Internet lui-même si le processus métier exige de travailler avec un ensemble limité de sources.

Pour les équipes qui construisent des pipelines avec des agents IA au-dessus de l'infrastructure cloud, c'est aussi une question de maniabilité. Plus le périmètre externe est étroit, plus il est facile de traiter les incidents, de vérifier la conformité avec la politique de sécurité et de comprendre pourquoi l'agent a pu accéder à une ressource particulière. Cette approche est particulièrement importante lorsque l'agent IA est associé à des données internes, des documents clients ou des actions automatisées.

Comment fonctionne le filtre

Au cœur du schéma se trouve l'SNI, Server Name Indication. Ce paramètre est envoyé au début d'une connexion TLS et indique le domaine auquel le client souhaite se connecter. Le Network Firewall peut analyser ce champ et le comparer à une liste de domaines autorisés. Si le domaine est dans la liste blanche, la connexion passe ; sinon, la demande est bloquée avant même que l'agent commence à interagir avec la ressource externe.

Cette approche est utile lorsqu'un agent a besoin d'accès à plusieurs points clairs du réseau externe : documentation, APIs internes via un point d'entrée public, services partenaires ou plates-formes SaaS spécifiques. Dans ce scénario, la sécurité est construite non pas autour de la « confiance abstraite du modèle », mais autour de règles réseau strictement définies.

• L'agent ne voit qu'une liste approuvée de domaines externes
• Les nouveaux sites ne peuvent pas être accédés sans mises à jour explicites des règles
• Le blocage se produit avant l'exécution de la logique métier sur la ressource externe
• La politique d'accès est centralisée dans l'infrastructure plutôt que dispersée dans le code
• Le contrôle devient plus clair pour l'audit et les équipes de sécurité internes

Pourquoi ce n'est pas suffisant

AWS souligne séparément que le filtrage basé sur le domaine n'est que la première couche de défense. Il réduit la surface d'attaque, mais ne résout pas tous les risques associés aux agents. Si un domaine approuvé sert lui-même du contenu nuisible ou indésirable, la liste blanche n'aidera pas. De même, cette approche ne vérifie pas ce que l'agent fait après la connexion à une ressource acceptable.

"Le filtrage au niveau du domaine par vérification SNI est la première

couche d'une défense multicouche."

Il y a aussi une limitation plus pratique : le contrôle de domaine voit l'adresse de destination mais pas l'intention complète de la demande. Il ne distingue pas les chemins d'URL spécifiques, les paramètres, les types d'opérations et le contexte métier au sein du même domaine autorisé. Par conséquent, la liste blanche est bonne comme filtre grossier mais très utile—surtout au point d'entrée d'Internet—cependant, elle ne peut pas être considérée comme une politique complète pour le comportement de l'agent.

La conclusion pratique de ceci est : une liste blanche réseau doit être combinée avec d'autres mesures. Cela inclut généralement l'isolation de l'environnement, les droits IAM minimaux, la vérification des actions de sortie de l'agent, la journalisation, les limites des outils et les politiques supplémentaires au niveau de l'application. En d'autres termes, Network Firewall répond à la question « où l'agent peut aller » mais ne remplace pas le contrôle sur « ce que l'agent fait » et « ce qu'il ramène ».

Ce que cela signifie

AWS formalise essentiellement un principe simple mais important pour les systèmes d'agents : l'accès à Internet ne doit pas être ouvert par défaut mais plutôt le minimum nécessaire. Pour les entreprises testant des agents IA en production, c'est une bonne directive : d'abord restreindre le réseau externe à une liste de domaines approuvés, puis construire des couches de protection plus profondes.