La vulnérabilité de l’agent virtuel de ServiceNow montre pourquoi la sécurité de l’IA doit s’appuyer sur les fondamentaux de l’AppSec

La récente révélation de ce que les chercheurs en sécurité qualifient de « vulnérabilité liée à l’IA la plus grave jamais découverte » sur la plateforme ServiceNow nous rappelle brutalement une chose : sécuriser l’IA agentique ne consiste pas seulement à mettre en place de nouveaux contrôles propres à l’IA ; il faut d’abord maîtriser les fondamentaux.

Anatomie de la vulnérabilité de l’agent virtuel

En octobre 2025, l’équipe de recherche en sécurité d’AppOmni a découvert une chaîne de vulnérabilités critiques dans l’agent virtuel de ServiceNow. Celle-ci permettait aux attaquants de prendre le contrôle de la plateforme avec pour seule information l’adresse e-mail de leur cible.

L’exploitation combinait trois défaillances en cascade :

1. Défaillance de l’authentification des API : ServiceNow fournissait le même identifiant codé en dur — la chaîne servicenowexternalagent — à chaque service tiers s’authentifiant auprès de l’API de l’agent virtuel. Ce jeton statique était identique dans tous les environnements clients.

2. Défaillance de la vérification d’identité : une fois connecté, le système acceptait une adresse e-mail comme preuve d’identité suffisante. Pas de mot de passe. Pas de MFA. Pas de validation SSO.

3. Privilèges excessifs de l’agent : le Record Management AI Agent pouvait créer des données n’importe où dans ServiceNow, notamment des comptes utilisateur dotés de privilèges d’administrateur.

Voici ce qui rend cette attaque particulièrement préoccupante : ServiceNow est une plateforme de gestion des services informatiques utilisée par 85 % des entreprises du Fortune 500. Elle s’étend aux RH, au service client, aux opérations de sécurité et à de nombreux autres systèmes. Un attaquant disposant d’un accès administrateur à ServiceNow ne prend pas seulement le contrôle de cette plateforme : il dispose d’un tremplin vers Salesforce, Microsoft 365 et tous les autres systèmes connectés.

Le problème ne venait pas du modèle d’IA

Cet incident illustre une tendance plus générale qui se dessine dans le secteur : les agents d’IA deviennent rapidement les principaux consommateurs d’API, et les défaillances du contrôle d’accès apparaissent comme le principal vecteur de risque.

Les causes profondes n’étaient pas des vulnérabilités inédites propres à l’IA. Il s’agissait de problèmes classiques de sécurité des applications :

• Défaillance de l’authentification – identifiants codés en dur — une catégorie de problèmes prise en charge depuis longtemps par l’analyse statique

• Défaillance de l’autorisation au niveau des fonctions

• Défaillance de l’authentification – association d’identités – une catégorie de problèmes détectables par la modélisation des menaces

L’agent d’IA a amplifié ces défaillances. Des bogues classiques qui auraient pu permettre un accès limité aux données ont entraîné la compromission complète de la plateforme, car l’agent pouvait enchaîner des actions de manière autonome : créer des comptes, attribuer des privilèges et assurer sa persistance.

Comme l’a souligné Gartner, les agents d’IA deviennent des « acteurs autonomes » qui héritent des autorisations des utilisateurs qu’ils assistent et les dépassent souvent. Lorsque ces agents interagissent avec des API présentant des lacunes fondamentales en matière de sécurité, de petites failles deviennent des défaillances systémiques.

Le point de vue de Snyk : une stratégie de défense globale

Cet incident montre pourquoi les plateformes de sécurité de l’IA doivent intégrer des capacités fondamentales de sécurité des applications. Sécuriser l’IA, c’est sécuriser les logiciels et les API qu’elle contrôle — dès la conception, à l’exécution et en fonction de l’impact. Traiter ces sujets séparément, c’est précisément ce qui ouvre la voie à des incidents comme cette vulnérabilité de l’agent virtuel.

Commencez par modéliser les menaces

La modélisation des menaces adaptée aux agents aide les équipes à définir les limites de sécurité avant même d’écrire le code. Dans le cas de la vulnérabilité de ServiceNow, une modélisation adéquate aurait mis en évidence :

• Le risque lié au partage d’identifiants entre les instances des différents clients

• L’absence d’obligation d’utiliser la MFA ou le SSO pour valider les identités auprès des API

• Le rayon d’impact d’un agent autorisé à créer librement des données

L’approche de Snyk en matière de modélisation des menaces pour les applications natives de l’IA consiste à cartographier « ce que les agents peuvent faire, les ressources auxquelles ils peuvent accéder et la portée de leurs actions » avant le déploiement.

Déployez le DAST pour détecter les vulnérabilités classiques

Les deux premières causes profondes de cette vulnérabilité de l’agent virtuel — les défaillances de l’authentification et de l’autorisation — sont des problèmes classiques de sécurité web. Le SAST pourrait détecter le secret codé en dur. Le DAST pourrait détecter un problème cryptographique. La vulnérabilité principale est la BFLA, qui ne pouvait être déclenchée qu’en la combinant aux deux premières failles (le secret codé en dur et l’association d’identités).

Cela souligne la nécessité de tester la sécurité des API, en particulier dans le contexte des applications agent à agent (A2A).

Les outils DAST classiques peinent souvent à tester l’autorisation, car la logique d’authentification dépend du contexte. L’approche de Snyk s’appuie sur des LLM pour comprendre la sémantique des API et détecter des « failles d’autorisation complexes, auparavant difficiles à identifier » que les règles statiques ne repèrent pas.

Ajoutez le red teaming IA pour découvrir l’impact

C’est là qu’interviennent les contrôles de sécurité propres à l’IA. Le DAST détecte les vulnérabilités à l’origine du problème, tandis que le red teaming IA révèle les scénarios d’impact catastrophique qui peuvent survenir lorsque les contrôles classiques échouent et que des agents d’IA sont dans la boucle.

Le red teaming IA de Snyk assure des tests offensifs continus pour les applications natives de l’IA. Le DAST trouve la faille. Le red teaming IA montre ce qu’elle peut provoquer lorsqu’un agent autonome est en mesure de l’exploiter.

Pour une application comme l’agent virtuel de ServiceNow, le red teaming IA chercherait à déterminer jusqu’où un utilisateur usurpé pourrait aller, en testant si l’agent peut être amené à élever ses privilèges, à exfiltrer des données ou à se déplacer latéralement vers des systèmes connectés.

Le red teaming IA ne remplace pas les contrôles AppSec classiques. Il révèle comment les agents d’IA peuvent transformer des bogues ordinaires en compromissions complètes de plateformes.

Pourquoi l’IA agentique nécessite des contrôles de sécurité à plusieurs niveaux

La leçon à tirer de cette vulnérabilité de l’agent virtuel est claire : sécuriser l’IA agentique exige des contrôles à plusieurs niveaux, qui prennent en charge à la fois les vulnérabilités classiques et les risques propres à l’IA.

C’est le principe même de la sécurité agentique : intégrer directement la sécurité au cycle de développement de l’IA, plutôt que de la traiter comme une réflexion après coup.

Les mesures à prendre dès maintenant

Si vous déployez des agents d’IA — ou si des fournisseurs le font pour vous — voici quelques mesures à envisager sans attendre :

1. Auditez les autorisations des agents

Comme l’a souligné Aaron Costello, chercheur chez AppOmni : « Les organisations doivent veiller à ne pas autoriser les agents d’IA à effectuer des actions puissantes, comme créer des données n’importe où sur une plateforme. Le périmètre des actions possibles pour les agents d’IA doit être très restreint. »

Appliquez rigoureusement le principe du moindre privilège. Si un agent n’a pas besoin de capacités d’administration, ne les lui accordez pas.

2. Imposez une identité forte aux frontières des API

Une adresse e-mail ne suffit pas pour s’authentifier. Toute API qui accepte des requêtes d’agents d’IA doit imposer :

• Une authentification forte (OAuth 2.0, clés API avec rotation)

• La validation MFA ou SSO pour les opérations sensibles

• La limitation du débit et la détection des anomalies

3. Mettez en place des tests continus

Les évaluations statiques de sécurité peinent souvent à suivre le rythme de la croissance rapide des déploiements d’IA. Les organisations ont besoin :

• Du DAST automatisé dans les pipelines CI/CD

• D’un red teaming IA continu pour les systèmes en production

• De mises à jour régulières des modèles de menace, à mesure que les capacités des agents évoluent

4. Examinez les déploiements d’agents d’IA comme du code

Comme l’a expliqué Costello : « Avant d’être intégré à un produit, le code est examiné. La même logique devrait s’appliquer aux agents d’IA. »

Mettez en place des processus d’approbation pour :

• Les nouveaux déploiements d’agents d’IA

• Les changements apportés aux autorisations ou aux capacités des agents

• Les intégrations avec des systèmes sensibles

Perspectives

La vulnérabilité de l’agent virtuel préfigure le paysage de la sécurité de l’IA qui se dessine. À mesure que les organisations accélèrent le déploiement de l’IA agentique, la surface d’attaque s’étend de façons que les outils de sécurité classiques n’ont pas été conçus pour gérer.

Mais la solution n’est pas d’abandonner l’AppSec classique : il faut ajouter des contrôles propres à l’IA à des bases solides. La modélisation des menaces identifie les risques avant l’écriture du code. Le DAST détecte les vulnérabilités à l’exécution. Le red teaming IA révèle des scénarios d’impact qui n’apparaissent qu’en présence d’agents autonomes.

ServiceNow a réagi rapidement pour résoudre les problèmes immédiats, en renouvelant les identifiants et en désactivant l’agent concerné dans la semaine suivant la divulgation. Mais la leçon reste valable pour l’ensemble du secteur : sécuriser l’IA agentique commence par savoir ce que les agents peuvent faire, les ressources auxquelles ils peuvent accéder et la portée de leurs actions.

La question n’est pas de savoir si votre organisation déploiera des agents d’IA. C’est de savoir si vous les sécuriserez avant qu’une nouvelle vulnérabilité de ce type ne fasse la une.

Ressources Snyk connexes

• Le nouveau paysage des menaces : applications natives de l’IA et workflows agentiques — Découvrez comment les applications natives de l’IA et les workflows agentiques élargissent la surface d’attaque

• Snyk ouvre la voie à l’avenir du DAST : la sécurité pilotée par l’IA à l’ère de l’IA — Découvrez Snyk API & Web et sa détection BOLA optimisée par l’IA

• Comment le red teaming IA de Snyk apporte des tests offensifs continus aux systèmes d’IA — Découvrez en détail les tests adverses automatisés pour les applications natives de l’IA

• Présentation d’Evo by Snyk : le premier système d’orchestration de la sécurité agentique au monde — Découvrez comment Evo associe modélisation des menaces, red teaming et application des politiques

• La boucle OODA agentique : comment l’IA et les humains apprennent à se défendre ensemble — Créer des workflows de sécurité collaboratifs entre humains et IA

Ressources vidéo

Play Video: Manoj Nair, Snyk | The AI Security Summit 2025

Manoj Nair, Snyk | The AI Security Summit 2025 — Le PDG de Snyk explique la raison d’être d’Evo et comment sécuriser les applications pilotées par des LLM

Play Video: Liran Tal: How to Secure your Apps and AI Agents

Liran Tal : comment sécuriser vos applications et vos agents d’IA — Découvrez en détail l’évolution des pratiques de sécurité pour les applications natives de l’IA