F5 Workforce AI Security place la gouvernance de l’IA sur le chemin réseau

F5 Workforce AI Security ajoutera des contrôles sans agent pour l’usage de l’IA par les employés et les actions des agents, alors que la plupart des dispositifs de gouvernance en entreprise restent axés sur les prompts de chat. Annoncé le 9 septembre 2026, le produit devrait être disponible de manière générale en octobre. Il constitue la tentative la plus nette de F5 pour gouverner à la fois ce que les collaborateurs envoient à l’IA et ce que l’IA fait avec leurs autorisations.

Le problème ne se limite plus aux employés qui collent du texte confidentiel dans un chatbot non approuvé. Les agents de programmation et assistants IA peuvent appeler des outils, accéder à des systèmes internes, modifier des enregistrements et agir via les identifiants des utilisateurs. F5 veut permettre aux équipes de sécurité d’inspecter ces interactions sur le chemin réseau avant qu’une requête ou une action dangereuse ne soit exécutée.

Cette approche place F5 face à des fournisseurs de sécurité établis tels que Check Point et Netskope, qui présentent eux aussi les contrôles réseau comme une réponse au shadow AI. L’épreuve la plus difficile concerne la visibilité et le contexte. Un produit réseau doit reconnaître les identités, les intentions et les appels d’outils sans devenir une nouvelle source de friction, de surveillance ou de fausses alertes.

F5 Workforce AI Security étend le contrôle aux actions des agents

Le changement majeur réside dans la décision de F5 de traiter les actions des agents comme une activité réseau soumise à gouvernance, et non comme un simple comportement applicatif.

Selon l’annonce du produit, F5 Workforce AI Security découvrira les services d’IA utilisés via les navigateurs et les outils de développement. Les administrateurs pourront appliquer des politiques selon le service, le type de licence, les fichiers téléversés et les règles de données.

Le produit est également conçu pour attribuer les interactions aux utilisateurs et aux agents. Il consignera des éléments de contexte tels que l’intention, le risque évalué et la décision de politique appliquée à chaque interaction. Ces enregistrements doivent servir à l’application des règles, aux enquêtes et aux audits de conformité.

La fonctionnalité la plus déterminante concerne les appels d’outils. F5 affirme que le produit inspectera les appels effectués via les serveurs Model Context Protocol et les outils d’agents pris en charge avant leur exécution. MCP est un protocole qui permet aux applications d’IA de se connecter à des outils, des systèmes et des données via une interface commune.

Une politique pourrait autoriser, bloquer ou modifier une action selon l’identité, le risque lié aux autorisations ou l’exposition de données sensibles. Cela va au-delà de la détection de la visite d’un site web d’IA par un employé. Cela instaure un point de contrôle entre la requête d’un agent et le système qui effectuerait l’action demandée.

F5 indique que les contrôles couvriront les navigateurs, les interfaces en ligne de commande, les agents de programmation, les clients MCP, les environnements d’exécution d’agents et les outils développés en interne qui utilisent des API publiques de modèles. L’entreprise prévoit d’intégrer l’application des règles aux environnements existants de secure access service edge, communément appelés SASE.

Le déploiement proposé ne nécessite pas l’installation d’un autre client sur les terminaux. F5 place plutôt l’application des règles là où les interactions réseau pertinentes traversent son infrastructure. La découverte passive peut analyser le trafic mis en miroir hors du chemin de production, tandis que les politiques actives fonctionnent en ligne lorsqu’une intervention est requise.

Cette distinction importe aux équipes de sécurité qui gèrent déjà des environnements de terminaux encombrés. L’installation d’une extension de navigateur ou d’un agent local supplémentaire peut engendrer des problèmes de compatibilité, des retards de déploiement et une couverture inégale. Une couche fondée sur le réseau promet un déploiement plus large via une infrastructure que l’organisation contrôle déjà.

Toutefois, le terme « sans agent » ne signifie pas « sans déploiement ». Les organisations ont toujours besoin de visibilité sur le trafic, d’intégration des identités, de conception des politiques, de protocoles pris en charge et de points d’application correctement positionnés. Les appareils distants, les sessions chiffrées, les connexions privées et les modèles exécutés localement peuvent compliquer cette couverture.

L’annonce distingue également les faits actuels des capacités futures. F5 présente le produit comme une offre à venir, et sa liste de fonctionnalités emploie un langage prospectif. Les acheteurs ne peuvent pas encore considérer la sortie d’octobre comme une preuve indépendante de la couverture, de la qualité de détection ou de la fiabilité en production.

Cet écart définit la tension centrale de l’article. Le positionnement sur le réseau donne à F5 un point de contrôle attractif, mais sa valeur dépend de la précision avec laquelle l’entreprise interprète des interactions d’IA qui évoluent rapidement.

Pourquoi l’IA des employés est devenue un problème d’identité

La sécurité de l’IA utilisée par les employés concerne désormais l’autorité déléguée, car un agent peut agir via les accès d’une personne au lieu de simplement répondre à sa question.

Les contrôles traditionnels du shadow AI demandent quelles applications les employés utilisent et quelles informations ils téléversent. Ces questions restent importantes. Elles ne suffisent plus lorsqu’un assistant peut ouvrir des dépôts, interroger des bases de données, mettre à jour des tickets ou déclencher des workflows.

F5 décrit cette situation comme une IA opérant avec une autorité empruntée. Un agent peut utiliser des autorisations initialement accordées à un employé, même lorsque l’agent ne possède pas d’identité distincte et gouvernable. Les équipes de sécurité doivent alors déterminer si l’action reflète l’intention de l’employé et son rôle autorisé.

Cette préoccupation est déjà visible dans les travaux de normalisation. Un document de réflexion NIST de 2026 examine comment les entreprises peuvent identifier les agents logiciels et appliquer des pratiques d’autorisation établies. Le projet étudie aussi comment les organisations devraient rattacher les actions d’un agent à des personnes responsables.

Ce rattachement devient difficile lorsqu’un utilisateur lance plusieurs agents sur plusieurs systèmes. Chaque agent peut hériter d’identifiants différents, appeler des outils imbriqués ou déléguer du travail à un autre service. Un enregistrement de connexion classique peut identifier le compte sans expliquer la chaîne d’actions qui en résulte.

F5 veut enrichir cet enregistrement avec l’intention de l’interaction. Par exemple, la plateforme pourrait distinguer la génération de code de la synthèse de documents ou de modifications administratives. Ce contexte pourrait aider une équipe de sécurité à différencier une requête ordinaire d’une utilisation inattendue d’outils privilégiés.

La classification de l’intention reste une inférence, et non une garantie. La même requête peut produire des actions différentes selon le modèle, la description de l’outil, le contexte récupéré et l’état du système. Un prompt apparemment inoffensif peut aussi conduire un agent vers une opération sensible plusieurs étapes plus tard.

Les recommandations OWASP sur MCP décrivent notamment les risques d’empoisonnement d’outils, d’injection indirecte de prompts et d’autorisations excessives. L’empoisonnement d’outils dissimule des instructions malveillantes dans les descriptions, les définitions de paramètres ou le contenu renvoyé. Un agent peut suivre ces instructions même si l’utilisateur n’a jamais demandé le comportement nuisible.

Les autorisations excessives créent un autre problème. Un serveur MCP peut demander un accès étendu alors qu’une autorisation restreinte en lecture seule suffirait. Un agent compromis peut alors devenir un adjoint trompé, utilisant une autorité légitime à une fin non prévue.

Ces risques expliquent pourquoi les contrôles avant exécution sont importants. Bloquer un secret divulgué après qu’un outil a déjà modifié un enregistrement de production n’offre qu’une protection limitée. La décision doit intervenir avant que le système n’accepte l’action.

F5 cite son étude 2026 State of Application Strategy afin de montrer à quelle vitesse cette exigence émerge. L’enquête F5 indique que 66 % des organisations autorisent l’IA à ajuster automatiquement des politiques ou des configurations.

Ce chiffre provient des propres recherches de F5 et doit être lu dans ce contexte. Il ne montre pas combien d’organisations accordent une large autonomie ni le degré de maturité de leurs contrôles. Il indique toutefois que les modifications initiées par des machines ont dépassé le stade des expériences isolées.

Pour les acheteurs en entreprise, l’objectif de sécurité passe donc du blocage des applications à la gouvernance des actions déléguées. Les équipes de sécurité ont besoin d’enregistrements reliant l’utilisateur, l’agent, l’outil demandé, l’autorisation accordée, la décision de politique et l’action résultante.

C’est également pertinent pour les équipes qui créent une base de connaissances consultable. Les systèmes d’IA peuvent récupérer un contexte interne utile tout en exigeant des limites strictes autour des identifiants, des fichiers confidentiels et des outils opérationnels.

La pression s’exerce simultanément sur les équipes chargées de l’identité, de la sécurité et de l’infrastructure. Aucune ne peut résoudre le problème seule dès lors que les agents combinent autorisations humaines, raisonnement de modèle, accès réseau et outils externes.

Le chemin réseau est le principal avantage de F5 et son plus grand pari

F5 parie que le réseau reste le point d’application le plus cohérent, même si l’activité liée à l’IA se répartit entre applications, modèles, agents et outils.

Cette thèse découle de la position existante de F5 dans la fourniture d’applications, la sécurité des API et la gestion du trafic. Plutôt que de sécuriser un chatbot ou un fournisseur de modèles particulier, l’entreprise veut appliquer des politiques là où les prompts, les réponses et les requêtes d’outils circulent entre les systèmes.

La stratégie a commencé à prendre une forme plus claire en 2025. F5 a finalisé l’acquisition de CalypsoAI et introduit AI Guardrails pour la protection à l’exécution ainsi que AI Red Team pour les tests de sécurité. Ces produits ciblent les menaces orientées vers les modèles, notamment les injections de prompts et les tentatives de jailbreak.

En juin 2026, F5 a lancé sa plateforme plus large AI Security Platform et acquis SurePath AI. SurePath a apporté la découverte fondée sur le réseau, la classification de l’intention, la détection du shadow AI et la visibilité sur les appels d’outils des agents. F5 a présenté ces capacités comme la couche de découverte d’un cycle de sécurité continu.

Le lancement de la plateforme a décrit quatre fonctions connectées : la gouvernance, la découverte, les tests de sécurité et la protection à l’exécution. La découverte identifie les services et comportements d’IA actifs. Les tests détectent les faiblesses, tandis que les garde-fous appliquent des politiques contre ces risques.

En août, F5 a ajouté une AI Gateway qui combine le routage des modèles, les contrôles MCP et les garde-fous à l’exécution. La passerelle gouverne les systèmes que les organisations placent délibérément derrière elle. Workforce AI Security étend cette stratégie à l’activité des employés, qui peut commencer en dehors des parcours de développement approuvés.

Ensemble, ces composants créent une répartition logique des rôles. La découverte Workforce identifie les usages autorisés et non autorisés. La passerelle gouverne le trafic de modèles et d’outils approuvés. Les tests de red team sondent les systèmes, tandis que les garde-fous appliquent des protections à l’exécution.

Le principal argument de F5 est la cohérence architecturale. Les contrôles fonctionnent indépendamment d’un fournisseur de modèles ou d’une application employée en particulier. Une organisation pourrait changer de modèles sans devoir reconstruire chaque politique dans la console d’administration d’un autre fournisseur.

Cette indépendance peut compter dans des environnements multi-modèles. Différents services peuvent utiliser des assistants commerciaux, des modèles privés, des services de programmation et des agents spécialisés. Chaque service expose des journaux et des contrôles administratifs différents, tandis que certains offrent une intégration limitée avec l’entreprise.

Une couche réseau peut normaliser au moins une partie de cette activité fragmentée. Elle peut associer le trafic aux identités de l’entreprise, conserver des enregistrements centralisés et appliquer un processus de décision commun. Les équipes d’opérations de sécurité peuvent ensuite exporter les événements vers les systèmes existants de surveillance et de réponse aux incidents.

Cependant, la normalisation peut supprimer un contexte applicatif utile. Le contrôle natif d’un fournisseur peut comprendre un espace de travail, un document ou une transaction avec plus de précision qu’un intermédiaire qui observe le trafic. F5 doit démontrer que ses classifications conservent suffisamment de détails pour permettre des décisions pertinentes.

Le trafic chiffré présente une autre tension de conception. Les applications modernes protègent les sessions précisément afin d’empêcher les intermédiaires de lire le contenu. L’inspection peut nécessiter des certificats gérés, une redirection du trafic, des intégrations prises en charge ou d’autres formes de déchiffrement contrôlé.

L’activité locale crée un angle mort supplémentaire. Un agent exécuté sur l’appareil d’un développeur peut appeler un modèle ou un outil local sans emprunter un chemin d’entreprise observable. Les connexions directes, les points d’accès personnels et les appareils non gérés peuvent également contourner l’infrastructure attendue.

L’approche de F5 est la plus solide lorsque les organisations acheminent déjà les activités pertinentes via des réseaux contrôlés ou des services SASE. Elle paraît moins manifestement exhaustive lorsque le travail s’étend aux environnements d’exécution locaux, aux connexions non gérées et aux protocoles propriétaires chiffrés.

Le réseau constitue donc à la fois l’avantage de F5 et son pari. L’entreprise sait opérer sur le chemin du trafic, mais la sécurité de l’IA exige une compréhension sémantique qui va au-delà des contrôles ordinaires des paquets et des applications.

Check Point et Netskope se disputent le même point de contrôle

F5 entre dans une compétition active entre fournisseurs de sécurité réseau pour devenir la couche de politiques située entre les utilisateurs d’entreprise, les services d’IA et les agents autonomes.

Check Point commercialise déjà des contrôles d’IA pour les équipes, capables d’identifier les applications, d’inspecter les prompts, d’appliquer des protections des données et de distinguer les services approuvés. Son plus récent AI Network Firewall étend ce même concept à l’usage de l’IA par les employés, aux agents et aux applications d’IA.

Check Point promeut également un déploiement sans agent via son infrastructure de pare-feu existante. Son AI Network Firewall affirme pouvoir observer et gouverner le trafic d’IA sans extension de navigateur, client d’endpoint ni installation distincte. Cela recoupe directement le positionnement de F5 centré sur le réseau.

Netskope aborde cette opportunité par le biais du security service edge et des contrôles d’accès au cloud. Sa plateforme couvre le shadow AI, l’IA d’entreprise gérée, l’IA privée et l’activité des agents. Elle met l’accent sur la protection des données, la connaissance des applications et l’inspection en ligne du trafic cloud.

Un rapport de Netskope présente l’évolution du marché comme un passage de la découverte d’applications non autorisées à la gouvernance de transactions autonomes. Il identifie également l’injection de prompts, l’exécution de code malveillant et les violations de politiques en aval comme des préoccupations croissantes.

Ces concurrents mettent F5 sous pression sur deux fronts. Premièrement, les entreprises peuvent préférer étendre une plateforme existante de security service edge ou de pare-feu. Deuxièmement, les fournisseurs historiques peuvent intégrer les contrôles d’IA à des accords de sécurité et à des flux opérationnels plus larges.

La réponse de F5 est une connexion plus explicite entre la découverte, les tests, les garde-fous d’exécution, les politiques de passerelle et l’activité des équipes. L’entreprise veut qu’une seule plateforme couvre à la fois les systèmes d’IA utilisés par les employés et les applications d’IA développées par les entreprises.

Cette étendue est potentiellement utile, mais elle soulève aussi des questions d’intégration. Une plateforme large doit partager les identités, politiques, constats et journaux d’audit entre ses composants. Le fait que des noms de produits figurent dans une même console ne crée pas automatiquement un système d’application cohérent.

Les acquisitions de SurePath et CalypsoAI apportent des technologies spécialisées pour la découverte et la sécurité des modèles. F5 doit encore démontrer à quel point ces technologies fonctionnent harmonieusement avec ses produits de passerelle et de livraison d’applications. La qualité de l’intégration comptera davantage que la taille du portefeuille.

Une autre distinction concurrentielle concerne la gouvernance au niveau des actions. Détecter qu’un employé utilise un service d’IA est désormais une capacité de base. La question à plus forte valeur est de savoir si un produit peut identifier et contrôler l’opération précise qu’un agent souhaite faire exécuter par un outil.

MCP rend cette opportunité plus concrète, car il normalise certains éléments de la connexion entre les agents et les outils. Une passerelle peut inspecter les outils nommés, les paramètres, les identités et les règles de politique. Pourtant, MCP n’est qu’une des voies d’accès aux systèmes d’entreprise.

Les agents appellent également des API conventionnelles, exécutent des commandes, accèdent à des navigateurs ou interagissent avec des connecteurs propriétaires. Un produit qui gouverne MCP de manière exhaustive peut tout de même manquer des activités importantes ailleurs. Les acheteurs devraient examiner la couverture des flux de travail réels, et pas uniquement les listes de protocoles.

La concurrence portera donc sur la profondeur plutôt que sur de simples affirmations de visibilité. Les équipes de sécurité compareront les clients pris en charge, la fidélité des identités, la classification des données, la couverture des outils, la latence des politiques, l’effort de déploiement et les options d’exportation.

Elles évalueront aussi la manière dont chaque produit traite les exceptions. Les développeurs ont souvent besoin de capacités que des politiques d’entreprise générales interdiraient. Un système viable doit permettre des autorisations limitées et des circuits d’approbation documentés sans encourager les utilisateurs à contourner les contrôles.

L’empreinte de F5 dans la livraison d’applications peut lui ouvrir des portes auprès de ses clients existants. Check Point et Netskope disposent de leurs propres avantages d’infrastructure. Aucun fournisseur n’a établi, sur la base de preuves publiques, qu’une architecture réseau unique capture chaque interaction significative entre les employés et l’IA.

L’approvisionnement devient donc une question d’adéquation. Le meilleur produit sera celui qui gouverne les véritables chemins de trafic et flux de travail des agents d’une organisation, et non celui dont le langage de catégorie est le plus vaste.

La gouvernance sans agent soulève encore des questions sans réponse

F5 a annoncé une couche de contrôle ambitieuse, mais n’a pas encore publié les preuves de production nécessaires pour valider ses affirmations centrales.

La première incertitude concerne la couverture. F5 cite les navigateurs, les outils en ligne de commande, les agents de codage, les clients MCP et les logiciels personnalisés utilisant des API publiques de modèles. L’entreprise n’a pas fourni publiquement de matrice de compatibilité détaillée montrant quels produits, versions, protocoles et modèles de déploiement bénéficient d’une inspection complète.

La deuxième incertitude concerne la qualité de classification. Une politique fondée sur l’intention dépend d’une interprétation exacte d’une interaction avant l’application de la règle. Les faux négatifs permettent des comportements risqués, tandis que les faux positifs interrompent le travail légitime et réduisent la confiance dans le système.

La classification devient plus difficile sur de longs flux de travail d’agents. Une demande peut commencer par une recherche ordinaire, puis appeler ultérieurement un outil privilégié. Le système doit conserver suffisamment de contexte pour évaluer chaque étape sans traiter le prompt initial comme l’intention complète.

La troisième incertitude concerne la modification. F5 affirme que les politiques peuvent autoriser, bloquer ou modifier les actions des agents. Modifier une demande peut être plus sûr que rejeter l’ensemble d’un flux de travail, mais cela peut aussi en changer le sens ou produire des comportements inattendus en aval.

Par exemple, supprimer un champ sensible d’un appel d’outil peut protéger les données tout en laissant la transaction incomplète. Rediriger une demande vers un modèle approuvé peut modifier le contexte disponible ou la qualité des résultats. Les administrateurs ont besoin de journaux clairs pour chaque intervention.

Le quatrième enjeu est la latence. La découverte passive peut s’exécuter hors du chemin de production, mais l’application de règles avant exécution doit prendre une décision rapidement. Les assistants de codage et les agents interactifs deviennent frustrants lorsque chaque appel d’outil introduit un délai perceptible.

F5 n’a pas publié de mesures indépendantes relatives à la latence des décisions de politique, au débit ou aux performances sous des charges de travail complexes d’agents. Les acheteurs devraient attendre des tests en production plutôt que de supposer que le positionnement réseau n’entraîne aucun coût opérationnel.

La confidentialité est une autre préoccupation. Une auditabilité détaillée peut exiger l’enregistrement des prompts, des réponses, des informations sur les fichiers, des identités des utilisateurs, des paramètres des outils et des résultats des politiques. Ces enregistrements peuvent contenir des données confidentielles ou réglementées, même lorsque l’action d’origine est bloquée.

Les équipes de sécurité doivent définir les périodes de conservation, les restrictions d’accès, les règles de masquage, le stockage régional et les procédures d’incident pour les données de surveillance elles-mêmes. Un système de visibilité peut créer un dépôt secondaire sensible si ces contrôles restent imprécis.

Le déploiement sans agent transfère également les responsabilités au lieu de les éliminer. Les équipes réseau doivent acheminer correctement le trafic. Les équipes chargées des identités doivent maintenir des correspondances fiables. Les équipes de sécurité doivent créer les politiques, tandis que les propriétaires d’applications vérifient que ces politiques préservent le comportement attendu.

Les organisations devraient remettre en question toute suggestion de visibilité instantanée et complète. La couverture dépendra de l’architecture, de l’accès géré, du chiffrement et de l’intégration. La question pertinente est de savoir ce que le produit ne voit pas dans la conception réelle du client.

Les statistiques et descriptions de fonctionnalités fournies par F5 nécessitent également un traitement prudent. Le taux d’adoption signalé de 66 % confirme l’urgence de contrôles automatisés, mais ne valide pas le produit de F5. La disponibilité de fonctionnalités ne démontre ni l’exactitude de la détection ni la réduction des taux d’incidents.

La disponibilité générale marquera le début d’une évaluation significative, et non sa fin. Les déploiements de référence, les tests tiers, les limites documentées et les preuves clients détermineront si la plateforme tient ses promesses.

Un pilote judicieux devrait inclure des applications de chat approuvées, des comptes personnels, des outils de codage, des API internes et plusieurs serveurs MCP. Il devrait tester l’activité ordinaire ainsi que l’injection de prompts, les autorisations excessives, les chargements de données sensibles et les demandes d’outils ambiguës.

Les équipes devraient mesurer séparément la couverture et les mauvaises décisions. Un produit peut détecter de nombreux services tout en comprenant mal leurs interactions. Il peut également classifier correctement les prompts tout en manquant le trafic local ou direct.

Le résultat devrait être une limite cartographiée plutôt qu’un verdict binaire. Les acheteurs doivent savoir où F5 offre un contrôle fiable, où un autre outil apporte du contexte et où des garanties procédurales restent nécessaires.

Trois signaux montreront si la stratégie de F5 fonctionne

Le lancement d’octobre, les preuves au niveau des actions et la réponse concurrentielle révéleront si F5 a construit une véritable couche de gouvernance ou un récit de plateforme séduisant.

Le premier signal est la sortie en disponibilité générale d’octobre 2026. F5 doit fournir une documentation de déploiement concrète, des listes de services pris en charge, des exemples de politiques, des intégrations d’identité et des distinctions claires entre l’observation passive et l’application en ligne.

Une matrice de compatibilité détaillée renforcerait l’argument selon lequel le produit couvre davantage que des démonstrations contrôlées. Une documentation absente ou des flux de travail pris en charge de manière limitée affaibliraient l’affirmation d’une visibilité à l’échelle de l’entreprise.

Le deuxième signal est la preuve issue d’actions réelles d’agents. Les clients devraient rechercher des résultats mesurés sur les appels d’outils MCP, les agents de codage, les assistants de navigateur, les clients en ligne de commande et les API propriétaires. Les preuves utiles incluront les taux de détection, les mauvaises décisions, la latence et les conditions de contournement.

Les études de cas devraient expliquer ce que F5 a observé et quels contrôles ont arrêté une action. Les affirmations générales sur la visibilité auront moins de poids que des exemples reliant les identités, les autorisations d’outils, les données sensibles et les résultats finaux des politiques.

Des évaluations indépendantes seraient particulièrement précieuses. La conception de F5 semble techniquement plausible, mais les démonstrations de l’entreprise ne peuvent pas reproduire tous les protocoles chiffrés, environnements d’exécution locaux ou chaînes d’agents inhabituelles présents dans les grandes entreprises.

Le troisième signal est la manière dont Check Point, Netskope et les autres fournisseurs de sécurité réagissent. Les concurrents peuvent étendre les contrôles au niveau des actions, approfondir la prise en charge de MCP ou combiner la télémétrie du navigateur et du réseau. Une réponse rapide transformerait l’annonce de F5 en référence pour toute la catégorie.

Une réponse plus lente suggérerait que F5 a assemblé une combinaison différenciée grâce à SurePath, CalypsoAI et sa plateforme réseau existante. Les migrations de clients ou les déploiements consolidés apporteraient des preuves plus solides que les seules comparaisons de fonctionnalités.

Les entreprises devraient également surveiller si les fournisseurs convergent vers des normes d’identité pour les agents. Des identités d’agents cohérentes et des autorisations à portée limitée rendraient les politiques réseau plus fiables. Des approches fragmentées obligeraient les plateformes de sécurité à déduire davantage de contexte à partir du trafic.

F5 Workforce AI Security répond à une véritable évolution : le passage des conversations avec l’IA aux actions menées par l’IA. Son positionnement au niveau du réseau offre à l’entreprise une voie crédible vers une application centralisée des règles, en particulier pour les organisations utilisant déjà l’infrastructure F5.

La question non résolue est de savoir si cette approche capture suffisamment de contexte dans les flux de travail modernes impliquant des agents. Les équipes de sécurité devraient tester le produit face aux autorisations réelles, aux outils privés et aux cas de défaillance avant de considérer qu’« agentless » équivaut à une couverture complète.

À l’approche d’octobre, les acheteurs peuvent se préparer en recensant le trafic IA, en cartographiant les autorisations des agents et en identifiant les actions nécessitant une approbation avant exécution. Quels sont les trois flux de travail qui causeraient le plus de dommages si un agent utilisait incorrectement une autorité empruntée ? Commencez par là, puis évaluez si F5 Workforce AI Security peut voir, expliquer et arrêter chacun d’eux sans entraver le travail quotidien.