Les pare-feu cloud ont un angle mort, et il s’appelle le prompt. Les architectures SASE, taillées pour faire transiter puis inspecter le trafic avant de l’autoriser, calent dès qu’il s’agit d’encadrer l’IA générative et les agents autonomes. Le vrai sujet n’est plus ce qui circule sur le réseau, mais ce qui se joue dans l’application au moment où un utilisateur colle une donnée dans une invite, déclenche un outil ou récupère une réponse.
La ligne de fracture n’est pas neuve. Plusieurs acteurs du secteur la décrivent en 2026 : l’inspection des paquets garde son utilité, mais elle ne gouverne plus des flux chiffrés de plus en plus opaques, ni des interactions pilotées par des modèles qui opèrent à l’intérieur des applications SaaS, des navigateurs ou des assistants locaux.
Points clés
- SASE inspecte le trafic réseau mais rate le contenu des prompts et les actions des agents IA
- Le chiffrement (TLS 1.3, QUIC, pinning) rend l’inspection classique de moins en moins efficace
- La CISA recommande l’analyse comportementale du trafic chiffré plutôt que le déchiffrement systématique
- Les équipes sécurité déplacent l’enforcement vers la couche applicative, au plus près de l’interaction
Le modèle SASE pris à revers par l’IA
SASE, pour Secure Access Service Edge, empaquette des briques de sécurité et de réseau dans un service cloud. L’idée de départ : rapprocher les politiques de sécurité de l’utilisateur, filtrer le trafic, puis appliquer des contrôles sur les échanges avec les applications distantes.
Cette logique déraille quand l’activité sensible ne se résume plus à une destination réseau. Dans un scénario d’IA, ce qui compte, c’est le contenu du prompt, l’identité du compte utilisé, le document source consulté par l’agent ou la destination finale d’une réponse générée. Un proxy voit bien qu’un fichier part quelque part. Il ne voit pas ce qui a été copié dans l’invite, ni ce que l’agent en a fait ensuite dans son workflow.
L’éditeur de navigateur d’entreprise Island le formule sans détour : l’inspection réseau voit bien le trafic entre les agents et les LLM, mais pas « ce qui a été collé dans le prompt, quel document interne il a référencé, ce que contenait la sortie, ni où cette sortie est allée ensuite ». Même refrain ailleurs : le risque loge dans l’interaction, pas dans l’itinéraire des paquets.
Le chiffrement referme la boîte noire
Et l’IA n’est pas seule en cause. TLS 1.3, l’essor de QUIC et le pinning rognent les métadonnées disponibles pour les outils d’inspection classiques. Les équipes sécurité se retrouvent face à un arbitrage devenu banal : bloquer ce qu’on ne peut pas déchiffrer, ou assumer un angle mort.
Un article de The Cybersignal sur les recommandations publiées par la CISA résume le virage : l’inspection systématique du trafic TLS n’est plus une approche universellement conseillée. L’agence fédérale américaine pousse plutôt l’analyse comportementale du trafic chiffré, à base de modèles et de signaux, sans tout déchiffrer. Conséquence directe pour SASE : le bon vieux « break and inspect » ne couvre plus tous les usages modernes.
En parallèle, l’IA a déplacé la surface d’attaque vers le navigateur, les applications SaaS et les agents logiciels. Un assistant de code qui cause en Protobuf, un outil d’IA embarqué dans une application métier ou un compte personnel utilisé sur le même service qu’un compte pro génèrent des flux que les contrôles fondés sur la destination détectent mal.
Où les équipes sécurité déplacent le curseur
La réponse esquissée est commune : ramener une partie de l’enforcement là où l’action se produit, au lieu de tout miser sur le point de sortie réseau. Cela suppose une visibilité sur les prompts, les réponses, les appels d’outils, les droits du compte et le contexte d’usage réel.
- Suivre les flux IA au niveau de l’interaction, pas seulement de la destination.
- Distinguer comptes personnels et comptes d’entreprise sur une même application.
- Mesurer ce que les agents lisent, copient, envoient et restituent.
- Réduire la dépendance à l’inspection TLS quand elle casse des usages ou n’y voit plus grand-chose.
Le débat SASE n’oppose donc pas un réseau « ancien » à un réseau « nouveau ». Il oppose deux lieux de contrôle : le trafic en transit d’un côté, l’application elle-même de l’autre, là où les prompts et les actions d’agents fabriquent des risques qu’un pare-feu cloud ne verra jamais passer.
