Les menaces de l’IA sont partout. Un RSSI axé sur le risque décide des priorités

Lucas Morel

L’IA aide les attaquants et les défenseurs. Les RSSI doivent donc se concentrer sur les risques qui pourraient nuire le plus à leur entreprise.

La bonne nouvelle ? L’IA offre aux cyberdéfenseurs certains des meilleurs outils de découverte dont ils ont jamais eu besoin.

La mauvaise nouvelle ? Cela donne aux attaquants la même capacité.

Cette dualité a amené les RSSI à gérer l’IA sur deux fronts simultanés. En dehors de l’organisation, les attaquants utilisent l’IA pour rendre le phishing plus convaincant, automatiser la reconnaissance et réduire le délai entre la divulgation et l’exploitation des vulnérabilités. Les incidents OpenAI/Hugging Face et JADEPUFFER ont révélé le risque que des agents autonomes mènent des attaques de bout en bout sans direction humaine. Au sein de l’organisation, les employés adoptent les outils d’IA plus rapidement que les équipes de sécurité ne peuvent les gérer, et les données sensibles circulent vers des plateformes d’IA grand public où elles ne sont pas protégées.

En tant que RSSI moi-même, je constate qu’en matière d’IA, la tentation est d’essayer de tout sécuriser, partout, d’un seul coup. C’est impossible. Les RSSI qui prendront les devants adopteront une approche « axée sur le risque d’abord », traitant l’IA de la même manière qu’ils traitent tous les autres défis de sécurité : comme un risque commercial.

Le risque que vous possédez déjà

Vous avez probablement vu les gros titres sur l’IA aidant les acteurs malveillants à renforcer leurs attaques. Et c’est certainement vrai : l’IA aide les attaquants à faire évoluer l’ingénierie sociale, à accélérer la recherche et à développer rapidement des exploits et des outils malveillants. Ces capacités continueront de s’améliorer. Mais votre exposition peut être plus grande grâce à l’adoption par votre propre entreprise.

Nous savons que les employés utilisent déjà l’IA générative au travail, mais cela pose problème lorsqu’ils le font via des comptes personnels qui fonctionnent en dehors des contrôles de l’entreprise. Selon le dernier DBIR de Verizon, la part des employés qui utilisent régulièrement l’IA sur les appareils d’entreprise a triplé pour atteindre 45 % l’année dernière, contre 15 %. En outre, environ les deux tiers des utilisateurs d’IA sur des appareils d’entreprise utilisaient des comptes personnels en dehors des contrôles de l’entreprise. Cela augmente le risque que des informations sensibles soient téléchargées vers des LLM non sécurisés, à l’insu des équipes de sécurité.

De plus, les agents IA des employés commencent à exécuter des tâches avec un minimum de surveillance humaine. En avril 2026, chez la société SaaS PocketOS, un agent de codage d’IA bien connu a rencontré une incompatibilité d’informations d’identification lors d’une tâche de routine et a décidé de la résoudre en supprimant un volume de stockage cloud. Il a recherché un jeton API, en a trouvé un dans un fichier sans rapport dont les autorisations n’étaient pas limitées à cette action, et a supprimé la base de données de production et toutes les sauvegardes au niveau du volume en un seul appel API.

Une autre préoccupation concerne les systèmes agents partagés, que de nombreuses entreprises ont déployés pour accroître leur productivité. De par leur nature, les assistants internes et les copilotes ont besoin d’une large portée sur les systèmes et les données pour être utiles, ce qui signifie que la plate-forme englobant le modèle devient une cible de grande valeur.

Même si un RSSI a confiance dans ses contrôles de confidentialité des données et dans les actions de ses agents, il existe un risque simple mais souvent négligé : la facturation basée sur l’utilisation. À mesure que la tarification basée sur des jetons pour les outils d’IA devient standard, les clés API et les informations d’identification liées aux comptes de facturation deviennent vulnérables. Le Resilience Risk Operations Center (ROC) a déjà observé que des jetons API volés étaient utilisés de manière abusive pour faire grimper les factures d’IA, entraînant des pertes extrêmement importantes. Cela met l’accent sur les mesures de base de contrôle des coûts pour contrer la menace émergente.

Risque externe provenant des acteurs de la menace

L’incident OpenAI/Hugging Face a placé les attaques natives et agentiques de l’IA au sommet du cycle de l’actualité. L’attaque, menée par des modèles d’IA ayant échappé à un environnement de test isolé, a alerté le monde de la sécurité sur la réalité des attaques pilotées par des agents, même si le récit comportait quelques gonflements marketing. Les données de Resilience montrent que les attaques natives de l’IA n’entraînent pas encore de pertes financières, mais les équipes de sécurité devraient se préparer à un avenir d’attaques menées en grande partie par l’IA, en particulier à mesure que les modèles ouverts rattrapent leur retard.

Ce printemps, le Threat Intelligence Group (GTIG) de Google a signalé que le premier Zero Day aurait été développé avec l’IA : un contournement d’authentification à deux facteurs pour un outil d’administration open source largement utilisé, écrit en Python, qu’un groupe de cybercriminalité connu prévoyait d’utiliser dans le cadre d’une exploitation massive. L’incident a illustré l’accélération et l’intensification des menaces avec l’aide de l’IA.

Ce qui est encore plus préoccupant est l’utilisation intensive de l’IA agentique pour les cyberopérations au lieu de simplement contribuer à des tâches spécifiques. Les outils de tests d’intrusion agents prolifèrent du côté défensif ; AWS a même publié le sien cette année, une étape vers la marchandisation. Je pense qu’il s’agit d’un investissement nécessaire pour que les équipes de sécurité puissent identifier les failles de manière continue et proactive, car la même capacité est déjà dirigée vers des cibles réelles. Lors d’un récent engagement offensif, des chercheurs de CodeWall ont déployé un agent autonome contre l’écosystème d’IA propriétaire de McKinsey. En deux heures, l’agent a réussi à exploiter une vulnérabilité d’injection SQL via des API non sécurisées pour obtenir des privilèges complets de lecture et d’écriture sur l’environnement de production. Bien que le cabinet de conseil ait rapidement corrigé la faille et n’ait signalé aucun signe d’exfiltration de données, l’incident souligne la rapidité de l’exploitation pilotée par les agents.

La première étape pour gérer les risques liés à l’IA consiste à comprendre où elle est déjà utilisée dans l’entreprise et où elle est le plus susceptible d’affecter l’entreprise. Identifiez quelles équipes s’appuient sur quels outils, à quelles données ces outils accèdent et quels agents d’IA sont capables d’entreprendre des actions autonomes. D’un point de vue externe, il n’a jamais été aussi essentiel de comprendre les services accessibles sur Internet.

À partir de là, les RSSI doivent se concentrer sur les contrôles qui réduisent le plus grand risque commercial. Pour se prémunir contre les actions entreprises par les outils internes ou destinés aux clients, le contrôle d’accès basé sur les rôles et la gestion des identités doivent être prioritaires, afin qu’un compte ou un agent n’atteigne que ce que son travail exige. Les données sensibles doivent être classifiées afin que les organisations comprennent à quels systèmes d’IA sont autorisés ou non l’accès. Donnez la priorité aux tests continus et à l’identification des vulnérabilités de l’infrastructure informatique, de tout logiciel ou API proposé aux clients et de toute faiblesse dans les chaînes d’approvisionnement logicielles.

Pour les organisations qui créent des logiciels avec l’IA, la révision automatisée du code et la gestion des dépendances deviennent encore plus importantes à mesure que l’IA augmente la vitesse de développement. Une génération de code plus rapide peut également signifier une introduction plus rapide des vulnérabilités si les processus de révision n’évoluent pas parallèlement.

Enfin, préparez votre organisation à l’échec. Les exercices sur table devraient inclure des scénarios impliquant des agents d’IA compromis ou un outil ou un modèle clé perturbé. Ces exercices aident les responsables de la sécurité à comprendre où existent les lacunes opérationnelles avant qu’elles ne soient testées lors d’un incident réel. Au niveau du terrain, il est maintenant temps de revoir vos tests et votre formation en ingénierie sociale pour vous assurer qu’ils sont à la fois pertinents par rapport aux menaces d’IA et suffisamment difficiles pour imiter des attaquants armés de ces outils.

Les risques liés à l’IA continueront d’évoluer plus rapidement qu’aucun d’entre nous ne peut écrire à ce sujet. La réponse n’est pas de suivre chaque gros titre ou de mettre en place un contrôle pour chaque nouvelle technique d’acteur menaçant. La stratégie doit plutôt consister à classer les risques en fonction du préjudice qu’ils pourraient causer à une entreprise, en simulant pour confirmer et en réexaminant systématiquement le classement à mesure que le paysage évolue. C’est ce qui différenciera les RSSI axés sur le risque des autres.

Intelligence artificielleGestion des risquesSécurité