Imaginons un scénario hypothétique : un agent au sein d’une usine d’IA récupère un document. Celui-ci contient une instruction cachée que l’utilisateur n’a jamais voulu faire exécuter par l’agent. L’agent s’y conforme : il ouvre une connexion, appelle un outil via le protocole Model Context Protocol (MCP), récupère un enregistrement que personne n’a demandé et l’envoie vers une destination que personne n’a approuvée. Le garde-fou qui aurait dû détecter cette opération était un side-car situé dans le même conteneur ; l’agent l’a donc d’abord désactivé. Le journal étant sous le contrôle de l’agent, l’événement n’a jamais été consigné. Temps écoulé : moins d’une seconde. Personne ne l’a vu, car aucun élément sur le parcours n’était en mesure de le détecter.
Il ne s’agit pas d’une défaillance exceptionnelle. C’est le scénario par défaut dès lors que les mécanismes de contrôle se trouvent à proximité de l’agent, dans le même domaine de confiance, où un agent compromis ou induit en erreur peut les désactiver, les contourner ou modifier les éléments de preuve. En termes simples : l’agent ne peut pas assurer lui-même son propre contrôle.
La F5 Application Delivery and Security Platform assure la mise à disposition et la sécurité de chaque application et API. Les agents d’IA constituent la prochaine étape, et leur fonctionnement est différent : un agent appelle des modèles, utilise des outils via MCP, communique avec d’autres agents et accède à des API au sein de l’usine et au-delà. Pour apporter de la valeur, les agents ont besoin d’un accès contrôlé aux modèles, aux outils, aux API et aux données situés hors de leur environnement isolé, et ces interactions doivent rester soumises à des politiques applicables. La NVIDIA OpenShell Reference Architecture, que NVIDIA présente à la NVIDIA GTC Berlin, est précisément conçue dans cette optique. Elle répartit les autorisations d’exécution de l’agent, l’application des règles au niveau matériel et l’inférence sur trois niveaux de matériel NVIDIA, tout en laissant une place aux partenaires sur le parcours qui les relie. Le moyen le plus clair de montrer le rôle de chacun consiste à suivre une requête à sa sortie de l’environnement isolé.
Ce que fait l’architecture de référence NVIDIA OpenShell
L’architecture de référence part du principe que l’agent n’est pas digne de confiance et sépare le matériel en conséquence.
Dans l’architecture de référence NVIDIA OpenShell pour des agents d’IA sécurisés, NVIDIA OpenShell s’exécute sur des processeurs NVIDIA Vera et régit les autorisations de l’agent lors de son exécution. Son superviseur évalue les requêtes sortantes, applique des contrôles granulaires au trafic HTTP, GraphQL et MCP configuré, protège les identifiants et consigne chaque décision prise en matière de politique. L’agent s’exécute dans un environnement isolé. Ce n’est pas le cas du superviseur qui le régit.
NVIDIA Sentry ajoute une couche indépendante de surveillance et d’application des règles au niveau matériel sur les DPU NVIDIA BlueField-4, dans un domaine de sécurité isolé auquel l’agent ne peut ni accéder ni apporter de modifications : détection des menaces, inspection des requêtes et des réponses, gouvernance des agents et confinement en quelques millisecondes. NVIDIA Sentry est une couche facultative qui, dans les systèmes NVIDIA Vera Rubin, se trouve sur le chemin d’accès aux modèles.
L’infrastructure NVIDIA Vera Rubin NVL72 exécute les modèles auxquels les agents font appel. L’architecture détermine donc déjà si un agent est autorisé à agir et surveille déjà ses actions depuis une infrastructure à laquelle l’agent ne peut pas accéder. F5 complète ces contrôles par une inspection du contenu conçue pour le trafic d’IA, des tests d’intrusion et la mise à disposition des applications, en s’appuyant sur notre collaboration avec NVIDIA en matière de cybersécurité des agents.
Ce que décident OpenShell et NVIDIA Sentry
OpenShell sait quel agent a effectué une requête, dans le cadre de quelle politique, et si la destination et la méthode sont autorisées. Pour une protection renforcée, NVIDIA Sentry s’exécute sur NVIDIA BlueField-4 et utilise NVIDIA DOCA afin de surveiller les agents de manière indépendante, d’appliquer la politique au niveau du silicium et de placer les agents en quarantaine en quelques millisecondes. Ensemble, ils permettent de déterminer si l’agent est autorisé à agir, sans que celui-ci puisse influer sur la décision. C’est là tout l’intérêt de cette conception.
Les autorisations d’exécution, la surveillance des comportements et l’inspection des contenus propres à l’IA offrent des couches de protection complémentaires. F5 ajoute l’inspection des invites prises en charge, des réponses des modèles et des appels d’outils afin de détecter les injections d’invites, les contournements de restrictions et l’exposition de données sensibles, en complément de la gouvernance à l’exécution d’OpenShell, ainsi que de la surveillance comportementale continue et de l’application des politiques avec isolation matérielle assurées par NVIDIA Sentry.
F5 inspecte ce que l’agent envoie et reçoit
F5 AI Guardrails inspecte le trafic pris en charge qui lui est acheminé depuis le chemin d’application des règles, notamment les invites, les réponses des modèles et les appels d’outils transmis via les protocoles contrôlés par OpenShell. Il effectue trois opérations sur les éléments détectés. Il bloque les injections d’invites, les contournements de restrictions et les appels d’outils non conformes à la politique. Il masque les données sensibles avant leur sortie. Il consigne chaque décision dans l’enregistrement de session. Ses verdicts et ses données de télémétrie sont accessibles à OpenShell et à NVIDIA Sentry, de sorte qu’une requête bloquée peut donner lieu à une décision au niveau de l’agent, pouvant aller jusqu’au confinement, conformément à la politique de l’opérateur. Comme l’interception s’effectue sur le chemin d’application des règles et non dans le conteneur de l’agent, celui-ci ne peut ni désactiver Guardrails ni le contourner. Aucun side-car ne peut être désactivé.
F5 AI Red Team veille à l’efficacité des garde-fous. Il attaque les agents et les modèles en empruntant le même chemin qu’un utilisateur, qu’ils soient privés ou publics, et ses découvertes sont intégrées à la politique des garde-fous, afin que les défenses évoluent au même rythme que les agents qu’elles encadrent.
Gouverner un agent, c’est aussi être en mesure de prouver ce qu’il a fait. Le plan de contrôle F5 conserve l’historique de la session : utilisateur, contexte du prompt, appels d’outils, paramètres approuvés. OpenShell conserve ses décisions en matière de politiques. NVIDIA Sentry conserve le journal système : accès aux fichiers, appels au noyau, métriques des paquets du DPU. Une fois corrélés, ces enregistrements fournissent une chronologie unique de ce que le modèle avait l’intention de faire, de ce que l’agent a tenté de faire et de ce qu’il a effectivement fait, à partir de sources auxquelles l’agent ne pouvait pas accéder.
Le plan de contrôle de la F5 AI Security Platform et AI Red Team s’exécutent au sein de l’usine, côté serveur. Les modèles d’inférence en production auxquels les agents font appel s’exécutent sur NVIDIA Vera Rubin NVL72, et AI Red Team utilise également des ressources GPU pour les tests de sécurité. AI Guardrails ne nécessite qu’un processeur Arm et peut donc s’exécuter sur NVIDIA Vera et BlueField-4. Les deux architectures de référence ci-dessous montrent où se situe chaque composant.
Deux architectures de référence F5 sur NVIDIA OpenShell
Le tout se superpose aux trois niveaux de NVIDIA : AI Guardrails sur Vera, appliqué au framework d’agents dans OpenShell ; AI Guardrails également sur NVIDIA BlueField-4, hors du rayon d’impact de l’agent, avec le plan de données lorsque la fabrique en a besoin ; le plan de contrôle et AI Red Team sur Vera Rubin NVL72, aux côtés des modèles. On obtient ainsi deux architectures de référence. Toutes deux reposent sur l’architecture de référence NVIDIA OpenShell, utilisent la même politique et le même plan de contrôle ; la différence réside dans ce qui se trouve sur le chemin de l’agent.
Architecture de référence 1 : F5 AI Guardrails avec NVIDIA OpenShell et NVIDIA Sentry
Pour l’opérateur qui utilise la pile NVIDIA telle qu’elle a été conçue. F5 AI Guardrails s’exécute à deux endroits sous une même politique : sur NVIDIA Vera, où il s’applique à l’environnement d’exécution de l’agent dans OpenShell, et sur le DPU BlueField-4 intégré à NVIDIA Sentry, auquel l’agent ne peut pas accéder. Le premier intercepte ce que l’agent envoie au moment même de l’envoi. Le second ne peut pas être désactivé par l’agent. Guardrails bloque, expurge et audite le trafic pris en charge qui lui est acheminé et, sur BlueField, ses décisions sont mises à la disposition de NVIDIA Sentry afin de confiner immédiatement l’agent. Aucun matériel supplémentaire n’est requis. Un partenaire NVIDIA Cloud qui standardise son infrastructure sur la pile NVIDIA bénéficie ainsi d’une inspection du contenu sans avoir à modifier quoi que ce soit d’autre.
Pour une mise à l’échelle supérieure et un déploiement de niveau entreprise. F5 BIG-IP Next for Kubernetes s’exécute sur le DPU NVIDIA BlueField-4 aux côtés de NVIDIA Sentry, ou sur le processeur hôte, en tant que plan de données de la fabrique, tandis que F5 AI Guardrails s’exécute en son sein selon la même politique. NVIDIA Sentry assure l’application des règles de base ; BIG-IP Next for Kubernetes prend en charge le trafic. BIG-IP Next for Kubernetes achemine et répartit le trafic des agents et des applications entre les instances de modèles sur Vera Rubin NVL72, en s’intégrant à NVIDIA Dynamo. Il isole les locataires, met à l’échelle et sécurise les connexions Model Context Protocol (MCP), régit l’utilisation des jetons par locataire et offre à l’opérateur une vue unifiée de l’ensemble des locataires et des modèles. BIG-IP Next for Kubernetes applique également les politiques de trafic sortant externe de l’opérateur au trafic qui transite par son intermédiaire, en complément des contrôles d’accès à l’exécution d’OpenShell et de l’application des politiques d’infrastructure de NVIDIA Sentry.
Le choix revient à l’opérateur. Intégrez AI Guardrails à OpenShell et NVIDIA Sentry, ou ajoutez BIG-IP Next for Kubernetes avec AI Guardrails intégré. La stratégie et le plan de contrôle sont identiques dans les deux cas. La seconde option ajoute l’isolation des locataires, le contrôle des flux sortants et la gestion du trafic pour l’ensemble de l’usine.
Un chiffre, présenté séparément de l’architecture de sécurité, car il a été mesuré de manière indépendante. Lors des tests menés par The Tolly Group sur BIG-IP Next for Kubernetes avec des DPU NVIDIA BlueField-3 (rapport n° 226104, publié en mars 2026), BIG-IP Next for Kubernetes a fourni un débit de jetons supérieur de 40 % à celui de la configuration de référence testée, le chemin de données étant déchargé des processeurs hôtes. Cette mesure porte uniquement sur le plan de données de BIG-IP Next for Kubernetes. Elle n’inclut pas les fonctions d’inspection décrites ici. Dans le domaine de l’IA, les performances sont une question de rentabilité.
Une sécurité qui reste dans l’usine
Dans un déploiement entièrement auto-hébergé, les traitements de sécurité et les journaux d’audit de F5 restent dans l’environnement de l’opérateur : le plan de contrôle et la Red Team côté serveur avec les modèles, et l’inspection sur Vera et BlueField-4. L’accès aux modèles et services externes reste régi par la politique de l’entreprise ; ce n’est pas un hasard si les destinations publiques figurent dans le schéma. Pour conserver chaque requête et chaque réponse au sein de l’usine d’IA, il faut également des destinations hébergées localement et des restrictions sur les flux sortants externes. Cette architecture le permet. La politique de l’opérateur détermine si cela est appliqué, et BIG-IP Next for Kubernetes assure l’application de cette politique de flux sortants.
L’ère agentique n’a pas tant créé une nouvelle exigence de sécurité qu’elle n’a déplacé le point de contrôle le plus important vers le trafic sortant de l’agent, sur une infrastructure à laquelle celui-ci ne peut pas toucher. F5 travaille précisément sur ce type de chemin depuis trois décennies. Dans l’architecture de référence NVIDIA OpenShell, il s’agit d’un chemin que l’agent ne peut pas contourner par la persuasion.
Pour en savoir plus, je vous invite à consulter les pages consacrées à F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team et F5 BIG-IP Next for Kubernetes.
À propos de l’auteur
Kunal Anand dirige l’organisation produit de F5 en tant que directeur des produits. Responsable de la vision, de la stratégie et de l’exécution des produits, il veille au développement de solutions révolutionnaires qui répondent à des enjeux critiques et offrent aux clients des expériences exceptionnelles. Dans ses précédentes fonctions de directeur de la technologie et de l’IA, Kunal a défini la stratégie et la vision de l’entreprise en matière de technologie et d’intelligence artificielle. Avant de rejoindre F5, Kunal a occupé le double poste de directeur de la technologie et de directeur de la sécurité des systèmes d’information chez Imperva. Son parcours chez Imperva a débuté en 2018 avec l’acquisition de Prevoty, une start-up spécialisée dans la sécurité des applications qu’il avait cofondée en 2013. Avant de rejoindre Prevoty, il était directeur de la technologie chez BBC Worldwide. Fort d’une longue expérience en matière d’innovation et d’une solide expertise technique, Kunal a dirigé des équipes chargées de la sécurité, des données, de la technologie et de l’ingénierie chez Gravity, MySpace et au Jet Propulsion Laboratory de la NASA. Kunal possède plus de 15 ans d’expérience dans les domaines de l’IA et de l’apprentissage automatique, notamment dans l’entraînement de modèles, l’utilisation d’algorithmes fondés sur l’IA pour améliorer les produits, ainsi que la conception et la mise en œuvre d’architectures d’IA. Kunal est titulaire d’une licence en informatique du Babson College.
Autres articles de Kunal AnandArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.