F5 Workforce AI Security place le contrôle des agents sur le trajet réseau

F5 Workforce AI Security sera disponible de manière générale en octobre 2026, étendant la plateforme de sécurité de F5 des applications d’IA aux activités des employés et des agents. Le produit cible un conflit croissant au sein des entreprises. Les employés veulent des outils d’IA capables d’agir, tandis que les équipes de sécurité ont besoin de contrôles avant que ces actions n’atteignent des systèmes sensibles.

F5 a annoncé l’offre le 9 septembre comme une couche sans agent destinée à découvrir l’usage de l’IA et à appliquer des politiques dans les interactions des employés. Selon l’annonce consacrée aux collaborateurs de l’entreprise, ces interactions incluent les navigateurs, les outils de développement, les agents de codage, les interfaces en ligne de commande et les clients Model Context Protocol.

Le changement important n’est pas l’ajout d’un tableau de bord pour compter les visites sur ChatGPT. F5 veut examiner ce qu’un agent d’IA a l’intention de faire, associer la requête à une identité et intervenir avant son exécution.

Cette approche oppose l’application de politiques fondée sur le réseau aux contrôles liés aux terminaux, aux navigateurs ou aux applications d’IA individuelles. Elle soulève aussi des questions difficiles concernant la couverture du trafic, les sessions chiffrées, la confidentialité des employés et la fiabilité de la classification automatisée des intentions.

Palo Alto Networks, Microsoft, Zscaler, Netskope et d’autres fournisseurs de sécurité proposent déjà des contrôles pour l’usage de l’IA par les employés. Le pari de F5 est plus ciblé et plus ambitieux. L’entreprise affirme que le trajet réseau peut devenir un point d’application cohérent à mesure que l’activité d’IA dépasse les prompts pour entrer dans un travail guidé par des outils.

F5 Workforce AI Security étend le contrôle au-delà des prompts

F5 considère l’appel d’un outil par un agent comme un événement de sécurité, et non comme une simple conversation avec une IA.

Les contrôles traditionnels de l’IA utilisée par les employés commencent généralement par la découverte des applications. Les équipes de sécurité identifient les services d’IA générative auxquels les employés accèdent, puis limitent les téléversements, les prompts ou les applications non approuvées.

Ces contrôles restent importants. Un employé peut exposer du code source, des dossiers clients, des identifiants ou des documents juridiques en les plaçant dans un modèle public. Les recommandations de Microsoft sur les contrôles des données sensibles préconisent d’analyser les prompts, les sorties, les opérations de mémoire, le contexte récupéré et les résultats des outils.

Les agents élargissent le problème, car ils peuvent agir après avoir reçu une réponse. Un agent de codage peut modifier un dépôt, invoquer un outil de déploiement ou exécuter des commandes. Un assistant peut récupérer des documents, mettre à jour un dossier client ou envoyer un message.

Ces actions héritent souvent des autorisations de l’utilisateur humain. F5 décrit cette situation comme une autorité empruntée. L’agent n’a pas besoin d’un compte entièrement indépendant pour créer un risque s’il fonctionne au moyen d’identifiants déjà accordés à un employé.

F5 Workforce AI Security est conçu pour identifier à la fois l’humain et l’agent impliqués dans une interaction. Il peut ensuite classifier l’intention de la requête, évaluer le risque d’accès et appliquer une politique avant l’exécution d’un appel d’outil pris en charge.

L’entreprise indique que les politiques peuvent autoriser, bloquer ou modifier les actions. Elles peuvent également prendre en compte l’exposition de données sensibles et l’identité associée à une requête.

Model Context Protocol, ou MCP, est un protocole ouvert qui relie les applications d’IA à des outils et à des sources de données. F5 affirme que son produit peut inspecter et classifier les appels d’outils sur les serveurs MCP et les outils d’agents pris en charge.

Cette distinction fait évoluer la sécurité des employés au-delà du contrôle du chatbot qu’un employé ouvre. Un agent autorisé peut néanmoins tenter une action qui dépasse la tâche immédiate de l’utilisateur ou la politique de l’entreprise.

F5 prévoit également des contrôles concernant le choix du service, le type de licence, les téléversements de fichiers et la politique de données. Une organisation pourrait autoriser un compte entreprise approuvé tout en limitant une version grand public du même service.

Le produit s’inscrit dans la plateforme plus large F5 AI Security Platform. F5 a présenté cette plateforme en juin 2026 pour la découverte, la gouvernance, les tests et la protection en exécution de l’IA.

En août, l’entreprise a ajouté des capacités AI Gateway, y compris une MCP Gateway. Workforce AI Security étend désormais la plateforme aux activités des employés et aux agents agissant avec les autorisations des employés.

Cette séquence est importante. Les tests de red team peuvent révéler des faiblesses avant le déploiement, tandis que les garde-fous à l’exécution protègent les applications d’IA en production. Les contrôles destinés aux employés répondent au risque distinct créé lorsque ceux-ci adoptent des outils externes ou délèguent des tâches à des agents.

F5 veut donc une structure de politiques unique pour le développement, le déploiement et l’usage de l’IA. La capacité des clients à bénéficier de cette cohérence dépendra de la qualité de l’intégration et de la couverture du trafic, et pas uniquement de la feuille de route produit.

Le produit doit être disponible de manière générale en octobre. Tant que les déploiements n’auront pas commencé, la précision de son application des politiques et sa charge opérationnelle resteront des affirmations de l’entreprise plutôt que des résultats validés de manière indépendante.

Pourquoi les actions des agents créent un problème de sécurité différent

Un agent d’IA peut transformer un prompt imprudent en une opération aux conséquences réelles sur des systèmes effectifs.

Lorsqu’un employé colle un texte confidentiel dans un chatbot, cela crée un problème de gouvernance des données. Lorsqu’un agent utilise des identifiants pour modifier un paramètre de production, cela crée aussi un problème d’autorisation.

Cette distinction explique pourquoi F5 met l’accent sur les actions plutôt que sur les seuls prompts. La frontière de sécurité se déplace dès lors qu’un système d’IA peut appeler des outils, modifier des données ou communiquer à l’extérieur.

Le rapport 2026 State of Application Strategy de F5 a révélé que 66 % des organisations interrogées autorisent l’IA à ajuster automatiquement des politiques ou des configurations. F5 a cité ce chiffre dans son annonce ; il doit donc être considéré comme une étude financée par l’entreprise.

Même avec cette réserve, le problème sous-jacent est clair. Les entreprises font évoluer l’IA d’interfaces de conseil vers des flux de travail disposant d’un accès en écriture.

L’agent peut recevoir une autorisation étendue parce que l’employé la possède déjà. Toutefois, l’autorité d’un utilisateur ne prouve pas que chaque action générée par un agent reflète l’intention éclairée de cet utilisateur.

Cela crée un écart entre authentification et autorisation. L’authentification établit qui a initié une session. L’autorisation doit déterminer si une action précise est appropriée dans son contexte actuel.

Les équipes de sécurité doivent également faire face à l’injection indirecte de prompts. Un attaquant peut placer des instructions malveillantes dans un contenu qu’un agent lira plus tard, comme un e-mail, un site web, un document ou un dépôt de code.

L’agent peut interpréter ce contenu hostile comme une instruction et entreprendre une action non voulue. Les recherches de NIST sur la sécurité des agents décrivent le vol de données et l’exécution de code malveillant comme des conséquences potentielles.

Une couche de politique réseau peut ajouter un point de contrôle supplémentaire avant que l’action résultante n’atteigne un outil. Elle n’élimine pas le raisonnement compromis au sein de l’agent, mais peut en restreindre le résultat.

F5 indique que ses contrôles utilisent des éléments de contexte tels que l’identité, l’intention, le risque et les données sensibles. Cette combinaison est nécessaire, car ni une simple liste de blocage d’applications ni une liste statique d’autorisations ne saisissent l’ensemble de la situation.

Prenons le cas d’un développeur utilisant un agent de codage approuvé. Lire un fichier de dépendances public peut être une opération courante. Téléverser du code propriétaire vers un modèle externe peut enfreindre la politique.

Ouvrir un ticket interne peut être acceptable. Modifier un déploiement en production peut nécessiter une approbation distincte ou une identité de service aux autorisations plus limitées.

La décision de sécurité dépend donc de l’identité de l’acteur, des données concernées, de l’outil ciblé et de l’opération demandée. Elle peut aussi dépendre de l’environnement et du moment.

C’est l’attrait pratique de l’application des politiques fondée sur l’intention. Elle promet davantage de contexte qu’une règle bloquant un service entier ou autorisant chaque interaction.

Cependant, l’« intention » est aussi une donnée difficile à évaluer. Un classificateur doit convertir des requêtes ambiguës en langage naturel et des appels d’outils techniques en catégories de politiques fiables.

Un blocage erroné peut interrompre un travail légitime. Une autorisation erronée peut exposer des données ou permettre une opération nuisible. Les environnements à haut risque auront besoin de contrôles déterministes autour des actions les plus conséquentes.

Les travaux de NIST sur l’identité des agents mettent l’accent sur l’identification, l’autorisation, l’audit et la non-répudiation. Ils interrogent également la manière dont les organisations peuvent atténuer l’injection de prompts.

Ces exigences vont au-delà de l’inspection du trafic. Les entreprises ont besoin d’identités d’agents claires, d’autorisations limitées, de journaux durables et d’une responsabilité attribuée à chaque flux de travail automatisé.

F5 Workforce AI Security peut devenir une couche d’application des politiques dans ce système. Il ne devrait pas devenir l’unique source de confiance.

Le principal enjeu oppose l’application réseau au contrôle spécifique aux outils

F5 parie que le réseau offre un point de contrôle plus durable que toute intégration à un modèle, un navigateur ou un terminal donné.

Les services d’IA évoluent rapidement. Les employés peuvent passer d’un chatbot familier à une extension de navigateur, un assistant de codage, un client en ligne de commande ou un modèle hébergé en privé.

Un contrôle de sécurité spécifique à une application doit reconnaître chaque service et comprendre son interface. Un produit pour terminaux nécessite un déploiement, une maintenance et des autorisations sur chaque appareil géré.

F5 propose d’appliquer des contrôles là où les prompts, les réponses et les actions d’agents traversent l’infrastructure de l’entreprise. L’entreprise affirme que cette approche est indépendante d’un modèle ou d’un fournisseur d’applications spécifique.

Son produit peut découvrir les services d’IA dans les navigateurs et les outils de développement. F5 indique également qu’il prend en charge les outils développés en interne qui accèdent à des API de modèles publics.

Selon F5, l’offre ne nécessite pas de client supplémentaire sur les terminaux. Cette formulation est importante. Elle signifie que les clients peuvent éviter d’ajouter un nouveau client, et non que le produit ne requiert aucun travail de déploiement.

Les clients doivent toujours mettre en place le positionnement réseau, l’intégration des identités, la configuration des politiques, la journalisation et les connexions à leur environnement de sécurité existant. La couverture dépend aussi du trafic que l’organisation peut observer.

La page produit de F5 décrit une découverte passive via du trafic réseau mis en miroir. Elle précise que l’analyse hors bande n’introduit aucune latence, car l’inspection s’effectue en dehors du trajet de production.

La même page décrit des contrôles adaptatifs qui bloquent, redirigent ou modifient l’activité. L’annonce indique également que les politiques opèrent dans le trajet d’interaction.

Ces fonctions représentent différents modes de fonctionnement. La découverte passive peut observer sans retarder le trafic. L’application active doit influencer la requête avant son exécution.

Les entreprises devraient demander quels composants fonctionnent passivement et lesquels sont placés en ligne. Elles devraient également confirmer ce qui se produit lorsque les services d’inspection échouent ou ne peuvent pas classifier une requête.

Les concurrents occupent déjà certaines parties de ce marché. Palo Alto Networks propose des contrôles d’accès à l’IA pour découvrir les applications d’IA générative et empêcher les fuites de données sensibles via les prompts et les téléversements.

Microsoft Purview peut découvrir l’activité d’IA, appliquer des politiques de prévention de la perte de données et faire apparaître les événements d’IA générative dans les journaux d’audit. Zscaler indique que AI Guard for Users inspecte les prompts et les réponses des employés pour les services d’IA publics.

Netskope combine la découverte d’applications, les contrôles de données et une infrastructure security service edge. Ces fournisseurs vendent déjà aux équipes chargées de la sécurité réseau et des données en entreprise.

F5 doit donc prouver que le contrôle des actions des agents apporte un avantage opérationnel significatif. La simple détection de l’IA fantôme ne suffira pas à créer une différenciation suffisante.

Sa plateforme plus large pourrait y contribuer. Selon les fonctionnalités produit de l’entreprise, les données de découverte peuvent alimenter les tests F5 AI Red Team et les politiques d’exécution F5 AI Guardrails.

Cette boucle de rétroaction est attrayante en théorie. Les comportements observés au sein des équipes peuvent révéler des cas d’usage risqués, que les équipes de sécurité peuvent ensuite tester et encadrer de façon plus délibérée.

Pourtant, les clients standardisent rarement toutes leurs fonctions de sécurité sur une seule plateforme. Nombre d’entre eux exploiteront F5 aux côtés de fournisseurs d’identité, d’outils de terminaux, de courtiers d’accès au cloud, de produits de sécurité des données et de contrôles natifs des modèles.

L’interopérabilité comptera davantage qu’une console unique. Les équipes de sécurité doivent pouvoir faire circuler proprement les événements et les décisions de politique entre leurs systèmes existants.

L’approche réseau présente également des angles morts naturels. Les connexions directes depuis les appareils, les réseaux non gérés, le chiffrement de bout en bout, les modèles locaux et les outils non pris en charge peuvent limiter le contexte observable.

F5 n’a pas établi publiquement que chacun de ces chemins est couvert. Les acheteurs devraient cartographier les véritables flux de travail des employés avant d’accepter une promesse de visibilité complète.

La version la plus solide de l’argument de F5 n’est pas que le réseau voit tout. C’est qu’un point de contrôle réseau peut assurer une application cohérente des règles à travers de nombreux outils autrement fragmentés.

Cette proposition peut être testée. Les clients peuvent comparer l’activité détectée avec la télémétrie des terminaux, les journaux SaaS, les enregistrements d’identité et les déploiements d’agents connus.

Si les données concordent, l’application des règles au niveau du réseau devient une couche commune utile. Si des lacunes importantes subsistent, la plateforme nécessitera des contrôles complémentaires.

Une large visibilité implique des compromis en matière de confidentialité et de précision

L’inspection de l’activité IA peut réduire le risque de sécurité tout en créant un enregistrement sensible des idées, erreurs et habitudes de travail des employés.

F5 affirme que sa plateforme peut journaliser les interactions avec l’IA et classifier l’intention métier. Ses supports produit citent des exemples tels que la synthèse et la génération de code.

Ces informations peuvent aider les équipes de sécurité à identifier des schémas risqués. Elles peuvent aussi exposer des conversations confidentielles, des stratégies en cours d’élaboration, des questions de personnel, des sujets de recherche et des indicateurs de performance individuels.

Un prompt n’est rarement qu’un simple événement réseau. Il peut contenir le raisonnement de l’utilisateur, ses incertitudes ou le contexte détaillé de travaux internes.

Les réponses peuvent être tout aussi sensibles. Un système d’IA peut combiner les données saisies par l’utilisateur avec des données d’entreprise récupérées, une mémoire privée ou du contenu provenant d’outils connectés.

Les organisations ont donc besoin de contrôles pour le système de sécurité lui-même. L’accès aux journaux de prompts et de réponses devrait respecter des rôles stricts, des limites de conservation et des exigences d’audit.

Les équipes juridiques, de confidentialité, de sécurité et de relations avec les employés devraient définir une surveillance acceptable avant un déploiement à grande échelle. Les règles régionales relatives au travail et à la confidentialité peuvent également influer sur la manière dont cette surveillance est introduite.

F5 indique que les pistes d’audit peuvent retracer le parcours d’une requête IA, de sa réponse et de l’intention de l’utilisateur. Les entreprises devraient déterminer quels champs sont conservés et si le contenu sensible peut être minimisé.

Elles devraient également demander si la suppression des informations sensibles intervient avant la journalisation ou seulement avant que les données n’atteignent un modèle externe. L’ordre modifie l’exposition créée par la plateforme de sécurité.

La précision de la classification pose un autre compromis. Une requête étiquetée « synthèse » peut contenir des dossiers réglementés. Une action de codage peut en réalité modifier l’infrastructure via un script généré.

L’intention exprimée en langage naturel peut compléter les faits techniques explicites, mais ne devrait pas les remplacer. La destination, le type d’opération, l’identité, la sensibilité de la ressource et l’étendue des autorisations fournissent des signaux plus robustes.

Les actions à fort impact méritent des politiques de refus par défaut ou des exigences d’approbation directe. Les actions à faible risque peuvent tolérer des classifications plus souples et un accompagnement accru.

Le système doit également distinguer les utilisateurs des agents agissant sous leur autorité. Les jetons partagés ou les sessions de navigateur héritées peuvent compliquer l’attribution.

Le NIST a averti que les agents reçoivent fréquemment l’accès à de nouveaux outils et données via des identifiants humains. Ses orientations d’identité d’août 2026 soulignent également la fatigue liée au consentement, provoquée par des demandes d’approbation répétées.

Un trop grand nombre de demandes peut apprendre aux utilisateurs à approuver les actions de manière réflexe. Trop peu de demandes peuvent permettre à un agent de franchir des limites importantes sans examen réel.

Le moteur de politiques de F5 doit aider les clients à décider où placer la friction. La réponse variera selon l’action, la ressource et la fonction métier.

Un assistant commercial rédigeant un e-mail présente un risque différent de celui d’un agent de codage qui modifie l’infrastructure de production. Un résumé local n’a pas les mêmes implications qu’un téléversement externe.

Les équipes ont aussi besoin d’un processus permettant de contester les décisions de politique erronées. Sans motifs transparents, les développeurs peuvent contourner les contrôles ou revenir à des outils non gérés.

C’est là qu’une base de connaissances IA consultable peut soutenir la gouvernance. Les employés ont besoin de registres clairs des outils approuvés, des règles relatives aux données et des voies d’escalade.

La documentation seule ne peut pas appliquer les politiques. Toutefois, une application des règles dépourvue de consignes compréhensibles pousse souvent l’adoption vers des canaux moins visibles.

Le positionnement sans agent de F5 réduit une source de friction au déploiement. Il ne supprime pas le travail organisationnel nécessaire pour classifier les données, attribuer les responsabilités et définir les actions autorisées.

La sortie d’octobre devra montrer comment ces contrôles se comportent sous la pression ordinaire. Une évaluation utile devrait inclure les faux positifs, les actions manquées, la latence des politiques et la charge de travail des administrateurs.

Les équipes de sécurité devraient également tester des prompts adversariaux, et pas seulement des flux de travail normaux. Un produit de contrôle des agents doit gérer les tentatives visant à dissimuler l’intention ou à répartir un travail risqué sur plusieurs appels.

Aucune barrière fixe ne peut garantir une protection permanente contre des attaquants adaptatifs. L’application des règles au niveau du réseau devrait participer à des tests, une surveillance et des mises à jour de politiques continus.

Trois signaux montreront si le pari de F5 fonctionne

La valeur du produit dépendra d’une couverture mesurée, de contrôles d’agents applicables et d’intégrations capables de résister à la complexité réelle des entreprises.

Le premier signal sera la preuve de déploiement après octobre 2026. F5 devrait publier des détails précis sur les navigateurs pris en charge, les outils en ligne de commande, les frameworks d’agents, les clients MCP et les configurations réseau.

Une longue liste de compatibilité ne suffira pas. Les clients doivent savoir quels flux de travail ne prennent en charge que la découverte et lesquels permettent une application des règles avant exécution.

Ils devraient comparer l’inventaire de F5 avec la télémétrie des terminaux, les journaux d’identité, les enregistrements d’API et les enquêtes auprès des employés. Les écarts inexpliqués révéleront des angles morts.

Ces éléments renforceront la position de F5 si un déploiement réseau unique identifie l’activité sur de nombreux outils avec une faible surcharge opérationnelle. D’importantes lacunes de couverture l’affaibliront.

Le deuxième signal sera la preuve que les contrôles des actions des agents fonctionnent dans des conditions adversariales. Cela implique de tester davantage que les requêtes évidentes visant à supprimer des fichiers ou exporter des enregistrements.

Les évaluations devraient inclure l’injection indirecte de prompts, les requêtes ambiguës, les appels d’outils imbriqués, les identifiants réutilisés et les actions réparties sur plusieurs étapes.

Les clients devraient mesurer à la fois les actions nuisibles bloquées et les actions légitimes interrompues. Un produit qui bloque tout n’est sécurisé qu’au sens le plus étroit du terme.

F5 propose déjà des capacités de red teaming IA ; les acheteurs devraient donc demander si les politiques Workforce AI Security peuvent être testées face à des scénarios d’attaque reproductibles. Les résultats devraient orienter les modifications de politiques.

Une validation indépendante aurait plus de poids que des scripts de démonstration. La documentation technique devrait expliquer les limites de classification et les comportements de défaillance sans exposer de logique de détection sensible.

Le troisième signal sera la réaction de la concurrence. Palo Alto Networks, Microsoft, Zscaler, Netskope et les fournisseurs d’identité disposent de points de contrôle adjacents et de relations clients établies.

Si ces entreprises étendent l’application des règles sur les appels d’outils et les fonctionnalités d’identité des agents, la différenciation de F5 se réduira. Cela confirmerait également que la sécurité de l’IA en entreprise évolue au-delà de la gouvernance des chatbots.

Si les clients se regroupent plutôt autour d’autorisations natives des modèles ou de contrôles centrés sur l’identité, l’inspection réseau pourrait rester une couche de soutien. F5 serait alors en concurrence sur l’intégration et la commodité opérationnelle.

L’issue la plus probable est une sécurité en couches. Les fournisseurs de modèles limiteront l’utilisation des outils, les systèmes d’identité limiteront l’autorité et les produits pour terminaux observeront l’activité des appareils.

Les contrôles réseau peuvent évaluer les flux de données et les opérations à travers les fournisseurs. Les garde-fous d’exécution peuvent surveiller les applications que les entreprises développent elles-mêmes.

La question centrale n’est pas de savoir quelle couche l’emporte. Elle consiste à déterminer si la politique reste cohérente lorsqu’une action passe entre ces différentes couches.

Pour les acheteurs en entreprise, l’étape immédiate consiste à inventorier les véritables flux de travail IA avant de choisir un produit de contrôle. Incluez les services approuvés, les outils fantômes, les agents de codage, les modèles privés et les connexions MCP.

Identifiez ensuite les flux de travail capables de lire des données sensibles, de communiquer vers l’extérieur ou de modifier l’état d’un système. Ces capacités méritent les identités et les contrôles de politique les plus rigoureux.

F5 Workforce AI Security arrive à un moment opportun, car l’adoption des agents révèle les limites des listes de blocage d’applications. Sa stratégie réseau offre un point de contrôle commun plausible.

La stratégie reste non éprouvée à grande échelle. F5 doit montrer qu’il peut observer suffisamment de contexte, classifier les actions avec précision et appliquer les politiques sans rendre l’usage productif de l’IA intolérable.

Les responsables de la sécurité devraient considérer le lancement d’octobre comme le début d’une évaluation, et non sa conclusion. Quelles actions d’agents la plateforme peut-elle réellement voir, expliquer et arrêter dans votre environnement ?