Architecture de sécurité pour les agents d'IA : les couches et les outils qui les couvrent

Un agent lit des fichiers, appelle des API et modifie des enregistrements : sa sécurité est donc une question d'architecture avant d'être une question de produit. Les fournisseurs vendent désormais des contrôles propres à l'IA, mais leurs noms se recoupent et leur portée varie. Cet article est une carte des couches, avec des exemples d'outils pour chacune; ce n'est pas un guide d'achat.

Partez des couches

• Périmètre réseau : inspecte le trafic vers et depuis les services d'IA et peut révéler des usages d'IA que personne n'a approuvés.
• Passerelle d'IA : se place entre vos applications, vos agents, vos modèles et vos outils, et vérifie les consignes et les appels d'outils.
• Identité et portée des outils : chaque agent a sa propre identité, des outils limités et des approbations pour les actions à risque.
• Détection et réponse : télémétrie des agents, des terminaux et des identités, surveillée par des personnes.
• Essais avant la mise en production : attaques et évaluations exécutées en intégration continue, avant qu'un changement soit livré.

Ce que chaque fournisseur dit que son outil fait

• Fortinet décrit FortiAIGate comme une passerelle d'IA auto-hébergée pour les modèles, les agents et les outils MCP. Elle se place entre vos applications, vos agents, vos LLM et vos outils MCP, bloque les attaques et les fuites de données, applique la politique d'utilisation et plafonne les dépenses. Fortinet indique que FortiGate envoie à FortiAIGate le trafic d'IA qu'il détecte.
• Palo Alto Networks documente un serveur MCP de Prisma AIRS qui fonctionne en interceptant les invocations d'outils, en effectuant une analyse de sécurité et en retournant un verdict sur la détection ou non d'une menace.
• CrowdStrike a annoncé en septembre 2025 un accord pour acquérir Pangea, afin d'offrir ce qu'elle appelle la détection et la réponse pour l'IA, en appliquant à l'IA le modèle de détection et de réponse sur les terminaux. Vérifiez le produit et sa disponibilité actuelle auprès du fournisseur.
• promptfoo se décrit comme un outil en ligne de commande et une bibliothèque à code source ouvert pour évaluer et soumettre à des tests d'attaque (red teaming) les applications à base de LLM. garak, de NVIDIA, est un analyseur de vulnérabilités de LLM à code source ouvert. Les deux peuvent être exécutés avant la mise en production.

Comment les couches s'articulent

Une requête entre par le périmètre, atteint l'agent, puis chaque consigne et chaque appel d'outil passent par la passerelle d'IA avant d'atteindre un modèle ou un système d'affaires. La télémétrie alimente la détection et la réponse. Les tests d'attaque et les évaluations s'exécutent en intégration continue : un changement qui rend l'agent plus facile à tromper est donc détecté avant que les utilisateurs le voient.

Des principes qui survivent à tout produit

• Présumez que le modèle peut être trompé, et faites en sorte qu'un modèle trompé puisse faire peu de dégâts : identités à portée limitée, identifiants à courte durée.
• Gardez le contrôle hors du modèle. Les politiques, les limites et les approbations appartiennent à du code que le modèle ne peut pas réécrire.
• Gardez une personne dans la boucle pour les actions à risque. La spécification de MCP indique qu'il devrait toujours y avoir une personne capable de refuser les invocations d'outils.
• Consignez chaque appel d'outil avec l'identité qui a agi, afin de pouvoir rejouer un incident.

Questions à poser à tout fournisseur

• Quelle couche couvre-t-il, et laquelle laisse-t-il à quelqu'un d'autre?
• Est-il auto-hébergé ou offert en nuage, et où vont les consignes et les journaux?
• Voit-il le trafic MCP et celui des agents, ou seulement les appels simples aux modèles?
• Comment ses protections sont-elles mises à l'essai, et comment se rapportent-elles aux listes de l'OWASP? Traitez les déclarations d'alignement du fournisseur lui-même comme de simples déclarations.