Claude Mythos d’Anthropic, dont l’accès est actuellement réservé à un petit nombre d’organisations de confiance dans le cadre du projet Glasswing en raison de ses capacités avancées en matière de cybersécurité, représente quelque chose de fondamentalement différent des générations précédentes d’IA.
Le risque lié à l’IA de pointe tient peu aux intentions malveillantes ; il découle de la capacité du modèle à raisonner, planifier, s’adapter et optimiser ses actions en temps réel. Qu’il fonctionne de manière autonome ou par l’intermédiaire d’une intégration compromise, un modèle de classe Mythos peut générer des campagnes d’ingénierie sociale extrêmement convaincantes, sonder des API à la vitesse d’une machine, tester en continu les contrôles de sécurité et changer immédiatement de tactique lorsqu’il rencontre une résistance.
Cela change la donne économique en matière de cyberdéfense.
La plupart des architectures de sécurité d’entreprise ont été conçues pour arrêter les attaquants qui suivent des schémas reconnaissables. La détection fondée sur les signatures, les politiques prédéfinies et les investigations humaines ont jusqu’ici bien protégé les organisations, car les attaquants humains laissent inévitablement un certain délai entre la reconnaissance, l’exploitation et l’adaptation.
Un modèle de raisonnement supprime cet avantage. Lorsqu’un agent d’IA peut observer, apprendre et modifier son comportement en quelques secondes, les équipes de sécurité ne peuvent plus se permettre d’attendre la détection pour réagir. Désormais, l’endroit où vous interceptez l’attaque compte davantage que le fait de la détecter.
La réponse réside dans le chemin emprunté par le trafic. Chaque prompt, chaque appel d’API, chaque requête Model Context Protocol (MCP) et chaque invocation d’outil doit passer par la couche de mise à disposition des applications avant d’atteindre une ressource de valeur. Quelle que soit l’intelligence d’un modèle d’IA, il ne peut pas contourner le réseau. C’est le seul point de contrôle auquel l’adversaire ne peut échapper.
“Lorsqu’un agent d’IA peut observer, apprendre et modifier son comportement en quelques secondes, les équipes de sécurité ne peuvent plus se permettre d’attendre la détection d’une menace pour réagir.”
Comprendre trois modèles de contrôle très différents
L’une des principales sources de confusion sur le marché actuel de la sécurité de l’IA réside dans l’emploi indifférencié de termes tels que « temps réel », « à l’exécution » et « en ligne ». Ces notions ne sont pas équivalentes, et cette distinction est importante. Quelles sont donc les différences ?
Contrôles en temps réel (visibilité et alertes après action): les contrôles en temps réel détectent les activités suspectes au moment où elles se produisent et génèrent des alertes en quelques secondes ou minutes. Ils offrent une visibilité, mais nécessitent généralement l’intervention d’un autre système — ou d’un analyste humain — pour agir.
Imaginez un agent d’IA qui interroge de manière intensive l’API d’une base de données clients à 2 h 47 du matin. Votre SIEM détecte correctement ce comportement anormal et crée immédiatement un incident.
L’alerte est exacte. Elle est déclenchée au moment opportun. Malheureusement, lorsque l’analyste examine le ticket, l’IA a déjà terminé sa reconnaissance et est passée à autre chose. Une détection sans mesure coercitive ne fait que consigner une attaque au lieu de l’arrêter.
Contrôles à l’exécution (garde-fous au niveau de l’exécution) : Les contrôles à l’exécution appliquent activement les politiques pendant l’exécution d’une application, d’un terminal ou d’un agent.
Cela représente une amélioration significative par rapport à la simple détection, car des mesures sont prises automatiquement. Toutefois, la protection à l’exécution reste limitée par des politiques prédéfinies et par ce que cet environnement d’exécution spécifique est en mesure d’observer.
Supposons qu’un agent de sécurité installé sur un terminal bloque un appel système suspect provenant d’un assistant d’IA local. Le modèle analyse l’échec, identifie un autre chemin d’exécution qui n’avait pas été anticipé par la politique de sécurité et atteint le même objectif en recourant à une autre technique.
La protection à l’exécution est extrêmement efficace contre les comportements prévisibles. Les modèles de raisonnement sont précisément conçus pour produire des comportements inattendus.
Contrôles réseau et applicatifs en ligne (interception du trafic) : les contrôles en ligne interviennent à un tout autre niveau. Au lieu d’attendre qu’une application ou un terminal prenne une décision, le dispositif de contrôle en ligne se place directement sur le chemin du trafic et inspecte chaque requête avant qu’elle n’atteigne le moteur d’inférence, l’API, l’application ou le service en aval.
Prenons l’exemple d’un modèle de classe Mythos tentant une injection de prompt sophistiquée en plusieurs étapes, conçue pour extraire des données d’entraînement par le biais d’un raisonnement indirect.
Il se peut qu’il n’existe aucune signature connue, aucun exemple antérieur ni aucun indicateur de compromission (IOC) historique auquel comparer la requête. Celle-ci peut néanmoins être inspectée, évaluée et bloquée avant même d’atteindre le modèle — ou avant qu’une sortie non sécurisée ne parvienne à l’utilisateur.
Cette distinction est essentielle : la sécurité en ligne empêche la requête d’aboutir dès le départ, au lieu d’intervenir une fois la compromission déjà survenue.
Pourquoi l’IA de pointe remet en cause les principes traditionnels de la sécurité
Historiquement, les défenseurs bénéficiaient d’un avantage majeur : le temps. Même les attaquants les plus expérimentés avaient besoin de plusieurs heures, voire de plusieurs jours, pour mener à bien les phases de reconnaissance, d’exploitation et d’élévation de privilèges. Les équipes de sécurité pouvaient ainsi détecter les activités suspectes, enquêter, mettre à jour les signatures et renforcer les contrôles avant que des dommages importants ne surviennent.
L’IA de pointe réduit considérablement ce délai. Au cours d’une seule session, un agent d’IA malveillant peut :
- Découvrir les API exposées, fantômes et non gérées.
- Générez des milliers de variantes de prompts afin d’identifier les garde-fous insuffisants.
- Déterminez quelles réponses témoignent d’une véritable application des règles, par opposition à un simple filtrage.
- Modifiez instantanément les techniques, les encodages et les structures des charges utiles.
- Exfiltrer des informations sensibles par le biais de canaux de sortie apparemment légitimes.
Ce qui nécessitait auparavant plusieurs jours à une équipe rouge expérimentée peut désormais être réalisé en quelques minutes. C’est pourquoi les architectures qui reposent sur une intervention humaine deviennent de moins en moins efficaces. Si la protection dépend d’un analyste chargé d’examiner les alertes, de mettre à jour les signatures ou de modifier manuellement les politiques, l’attaquant a déjà effectué plusieurs itérations avant même le début de la première intervention.
Face à une IA capable de raisonnement, l’application des mesures de sécurité doit s’effectuer à la vitesse du réseau.
L’architecture requise
Faire face à une IA capable de raisonnement directement au niveau du réseau exige une approche architecturale différente de celle pour laquelle la plupart des piles de sécurité ont été conçues.
Le contrôle doit s’exercer sur l’ensemble du parcours de livraison des applications au sein d’une surface unifiée, plutôt que d’être réparti entre des solutions ponctuelles isolées. L’inspection doit avoir lieu au niveau même de la couche d’inférence, afin que les requêtes et les réponses soient analysées en temps réel avant de parvenir à une personne ou à un modèle. La découverte des API doit s’effectuer en continu, car les inventaires gérés recensent rarement les API non gérées et fantômes que les agents autonomes recherchent en priorité.
Les tests fondés sur les techniques des attaquants doivent être menés en continu plutôt que périodiquement, et leurs résultats doivent être directement intégrés aux mécanismes d’application des règles. Sans cela, les protections sont mises à jour selon un cycle de gestion des politiques qui se compte en semaines, tandis que l’adversaire adapte ses méthodes en quelques minutes. Les agents d’IA doivent également être reconnus comme une catégorie d’identité à part entière, distincte des utilisateurs humains et des bots conventionnels, afin que les communications entre agents et outils, y compris les échanges MCP, soient soumises aux mêmes règles de gouvernance que l’authentification des utilisateurs.
Rien de tout cela ne peut fonctionner comme un ensemble d’outils déconnectés. Il faut une architecture de mise en application unifiée couvrant les API, le trafic d’inférence, l’identité des agents et la sécurité des applications, le tout régi par un cadre de politiques commun aux environnements hybrides et multicloud.
Pourquoi est-ce important à mesure que l’IA continue d’évoluer ?
Aujourd’hui, les discussions portent souvent sur l’injection de prompts. Demain, le défi résidera dans les systèmes autonomes orchestrant des milliers d’appels d’API, faisant appel à des outils et collaborant avec d’autres agents, en grande partie sans intervention humaine. Les organisations constateront alors une augmentation correspondante du trafic généré par les machines.
Chacune de ces interactions implique une nouvelle décision d’application des règles. Protéger des couches isolées — un filtre de prompts ici, une passerelle API là, un détecteur de bots ailleurs — crée des failles architecturales, et c’est précisément là que les IA capables de raisonnement chercheront en premier. Plus l’adversaire gagne en capacités, plus la cohérence architecturale devient essentielle.
L’impératif stratégique pour les RSSI
L’IA de pointe transforme la nature de la cyberdéfense. À mesure que les modèles autonomes s’intègrent profondément aux applications d’entreprise, aux API et aux processus métier, le chemin du trafic devient la principale surface d’application des politiques sous votre contrôle : chaque prompt, chaque appel d’API, chaque échange MCP et chaque invocation autonome d’un outil y transitent.
Les contrôles en temps réel vous indiquent ce qui s’est déjà produit. Les contrôles à l’exécution bloquent ce que la politique avait anticipé. Les contrôles en ligne bloquent ce qui est en train de se produire, avant que la requête n’atteigne sa destination.
Pour les RSSI, c’est la question d’architecture la plus importante.
Pour les responsables de la sécurité, l’impératif stratégique est clair : bâtir la défense de l’entreprise autour de l’unique couche structurelle qu’un adversaire ne peut contourner.
Pour en savoir plus, consultez notre page web consacrée à la F5 Application Delivery and Security Platform.
À propos de l’auteur
Articles de blog associés
IA et cybersécurité
Découvrez comment l’IA et la cybersécurité fonctionnent de concert. Découvrez comment l’IA et le machine learning (ML) permettent à votre entreprise de rester sécurisée, efficace et prête à innover avec F5.
Suivre le rythme de l’innovation de pointe ne suffit pas à faire avancer l’entreprise : se préparer à la réglementation de l’IA
À mesure que la réglementation de l’IA évolue, réfléchissez aux mesures de protection que vous pouvez mettre en place dès maintenant.
Les contrôleurs de mise à disposition d’applications reviennent au cœur des priorités stratégiques
L’IA rebat les cartes de la livraison d’applications. Nirav Shah de F5 revient sur la nouvelle étude de Gartner® consacrée aux ADC et explique ce qu’elle implique pour les décisions des entreprises en matière d’infrastructure.
Ce que nos clients nous disent sur l’IA, le multicloud hybride et la sécurité des applications
Le nouveau vice-président senior du marketing produit de F5 explique les pressions liées à l’IA auxquelles sont confrontés les dirigeants d’entreprise et ce dont ils ont besoin pour renforcer leur organisation.
Cinq niveaux de cyberrésilience antifragile transforment les pratiques en résultats
Découvrez comment cinq niveaux de résilience antifragile transforment les perturbations en comportements adaptatifs qui limitent les défaillances et renforcent l’architecture multicloud hybride.
Optimiser les pipelines d’IA en éliminant les goulets d’étranglement dans les charges de travail modernes
À mesure que les charges de travail d’IA montent en puissance, les entreprises constatent des ralentissements provenant du pipeline de données en amont qui alimente le modèle d’IA. Voici comment F5 BIG-IP peut les aider.