Services de sécurité IA/ML
L’IA est intégrée aux produits, aux flux de travail et aux appareils sur lesquels votre entreprise s’appuie. Nous testons la manière dont un attaquant pourrait manipuler vos modèles, corrompre les données sous-jacentes et abuser des systèmes qui agissent sur leurs sorties. Nous testons comme un attaquant et rapportons comme un ingénieur.
Les attaquants n’ont pas besoin d’un accès shell pour causer des dégâts. Un prompt injection peut transformer un chatbot en canal d’exfiltration. Des données empoisonnées peuvent orienter les décisions d’un modèle sans déclencher d’alerte. La génération augmentée par récupération (RAG) et l’appel d’outils, que ce soit via l’appel de fonctions, des plugins ou des serveurs Model Context Protocol (MCP), transforment une requête en appels vers des fichiers, des API et des systèmes de production.
IOActive teste l’ensemble du système d’IA : le modèle, les données sous-jacentes, les applications et les périphériques qui l’appellent, ainsi que l’infrastructure qui héberge ses poids. Chaque mission se termine de la même manière : constats démontrés avec des preuves rejouables, correctifs attribués à un responsable nommé, et retest une fois les corrections effectuées.
Les engagements ci-dessous suivent le cycle de vie d’un système d’IA. Commencez où vous en êtes.
Parler à un consultant en sécurité IA
Avant de construire : les fondations
Les décisions prises ici déterminent les attaques qu’un système devra supporter.
Évaluation du programme de sécurité de l’IA et de la gouvernance
Votre organisation sait-elle quelles IA elle utilise, qui en est propriétaire et ce qui se produit en cas de dysfonctionnement ? Nous inventorient les IA en place et évaluons les politiques et contrôles associés, de l’utilisation acceptable et de la classification du risque lié aux modèles à l’évaluation des fournisseurs et à la réponse aux incidents. Les constats sont organisés selon le NIST AI Risk Management Framework et son Generative AI Profile, et tout élément relevant de la réglementation, y compris l’AI Act européen, est signalé pour une revue juridique accompagnée du contexte technique.
Modélisation des menaces pour les systèmes d’IA
Où ce système peut-il être attaqué, et quel serait le gain pour l’attaquant ? Nous retraçons les chemins qu’un attaquant emprunterait à travers vos modèles, prompts, agents, plugins et fournisseurs, et associons chacun d’eux à un impact commercial. Les expositions sont alignées sur MITRE ATLAS, afin que les garde-fous et les détections qui en découlent constituent des tâches d’ingénierie concrètes.
Revue du cycle de vie du développement de l’IA
Comment les modèles, les données, les prompts et les outils sont-ils développés, testés et mis en production, et où ce processus est-il vulnérable aux abus ? Nous l’examinons de bout en bout et vous fournissons des garde-fous concrets pour la collecte des données, l’étiquetage et le CI/CD, adaptés au fonctionnement de vos équipes.
Pendant votre développement : code et résultats
L’IA change autant la manière dont le code est écrit que ce qui est déployé. Dans Le fossé de sécurité dans le code généré par l’IA (avril 2026), IOActive a soumis 730 prompts de codage réels à 27 modèles d’IA et outils de codage. Près d’un tiers des échantillons générés (31,6 %) étaient entièrement exploitables, et aucun modèle n’a réussi à chaque fois.
Revue de code sécurisé par IA
Le code enveloppant le modèle est-il aussi sécurisé que le modèle ? Nous examinons la manière dont votre application communique avec le LLM : construction des prompts, traitement des sorties, authentification et autorisation, accès aux bases de données vectorielles RAG, intégrations d’outils, orchestration des agents, secrets et journaux. Si IOActive examine déjà votre code, cela prolonge l’engagement que vous menez actuellement.
Codage sécurisé avec l’IA : implémentation et formation
Comment maintenir la productivité du développement assisté par l’IA sans hériter de ses défauts ? Nous vous aidons à définir la place de l’humain dans la boucle pour le code écrit et revu par l’IA (dedans, dessus ou au-dessus), à mettre en place les politiques et les outils, et à former vos ingénieurs sur les patterns de défaillance observés lors de missions réelles et dans nos recherches sur la gouvernance des assistants de codage IA.
Triage et vérification des résultats générés par l’IA
Vos scanners et agents d’IA signalent des milliers de problèmes. Lesquels sont réels ? Nous les vérifions : exploitabilité démontrée, doublons et faux positifs éliminés, sévérité réévaluée. Vous recevez un backlog court sur lequel vos ingénieurs peuvent agir. Si vous utilisez une plateforme de sécurité IA automatisée, c’est également ainsi que nous vérifions ce qu’elle vous indique.
Avant la livraison : tests adverses
Cinq missions, chacune ciblant une partie du système. Choisissez celle qui correspond le plus à votre risque ; la plupart des programmes ajoutent les autres à mesure que le système gagne en autonomie.
Évaluation des modèles d’IA
Peut-on faire confiance à ce modèle pour qu’il se comporte de manière sûre dans les situations critiques pour notre entreprise ? Nous testons le comportement du modèle, et non son infrastructure : sorties dangereuses ou biaisées, hallucinations, fuite de données sensibles, respect des instructions et refus, ainsi que son comportement en dehors de l’usage prévu. Nous adoptons ensuite une posture hostile : instructions obfusquées ou encodées, langues inattendues, attaques sur contexte long et multi-tours, et documents ou images contenant leurs propres instructions. Les systèmes de vision, de parole et de prise de décision sont soumis au même traitement. Livrables : un rapport d’évaluation de la sécurité de l’IA, une grille d’évaluation des risques et une feuille de route de remédiation.
Évaluation de la sécurité des applications d’IA
Un attaquant peut-il utiliser la fonctionnalité IA pour accéder à des données ou exécuter des actions non autorisées ? Le chemin reliant un utilisateur à vos systèmes d’entreprise traverse l’application, le prompt, le modèle, RAG, une base de données vectorielle, ainsi que les outils et les API que le modèle peut appeler, quelle que soit l’intégration. Nous testons chaque étape, y compris la ségrégation des données entre les locataires, les permissions des outils et les intégrations IA tierces, et nous incluons les failles classiques Web, mobiles et API amplifiées par les fonctionnalités IA. Les cibles IA sur les appareils et les systèmes embarqués sont dans le périmètre.
Évaluation de la sécurité des agents IA
Un agent peut agir, et pas seulement répondre. Que se passe-t-il si nous le convainquons de faire quelque chose qu’il ne devrait pas ? Nous tentons : lire un fichier confidentiel, envoyer un e-mail, modifier un enregistrement ou une configuration, exécuter du code, effectuer un achat, créer un autre agent, escalader ses propres privilèges. Chaque action que l’agent peut entreprendre et chaque outil auquel il peut accéder constituent un cas de test, y compris la manipulation par un autre agent ou une réponse d’outil empoisonnée. Pour chaque succès, nous vous indiquons quel contrôle a échoué et recommandons le correctif approprié.
Évaluation des données et de la confidentialité de l’IA
Un attaquant peut-il modifier ce que le modèle apprend ou récupère, et peut-on le contraindre à divulguer des informations qu’il ne devrait jamais révéler ? À l’entrée, nous examinons chaque point d’ingestion de données : jeux de données d’entraînement et de fine-tuning, documents RAG, embeddings et bases de données vectorielles, jeux de données tiers et chaîne d’approvisionnement du modèle, à la recherche d’opportunités de poisoning et de lacunes dans la traçabilité. À la sortie, nous testons les fuites accidentelles et l’extraction adversariale de données personnelles, de dossiers clients, de code source, d’identifiants, de documents internes et de prompts confidentiels, y compris la possibilité pour un attaquant de déterminer si un enregistrement a été utilisé lors de l’entraînement.
IA red teaming
Au lieu d’attaquer un réseau, l’équipe cible l’IA et tout ce qu’elle peut atteindre. Une campagne orientée objectifs couvre prompt injection, le jailbreaking, l’extraction du system-prompt, l’agence excessive, l’abus d’outils, l’exfiltration de données et la manipulation agent-à-agent. Vos garde-fous font partie de la cible : nous documentons chaque contrôle (filtres, modération, workflows d’approbation, limites de débit, permissions) puis tentons de les contourner, et chaque contournement est accompagné des étapes de reproduction. Les tests d’intrusion ciblant l’IA et les simulations d’attaques agentiques sont menées selon les mêmes règles d’engagement que nos services red et purple team.
Après la livraison : exploitation et retest
Les modèles, prompts, outils et sources de récupération changent chaque semaine. Une vulnérabilité corrigée en mars peut réapparaître en avril à la suite d’une mise à jour de modèle non testée.
Évaluation de l’infrastructure IA et de la garde des modèles
Comment vos poids de modèle sont-ils stockés, signés, déplacés et déployés, et qui peut y accéder ? Nous testons l'intégrité du déploiement, les limites d'accès aux poids, les limites de ressources et les contrôles de déni de service, l'observabilité des utilisations anormales et l'isolation entre les projets et les locataires, et nous signalons les lacunes qui permettent le vol de modèle, la manipulation ou le mouvement latéral.
Banc de test de retest et de régression
Chaque mission comprend des scripts de rejeu, des journaux structurés et des critères de réussite/échec explicites, afin que votre équipe puisse reproduire chaque constat et tester le correctif. Après correction, nous relançons le même banc de test pour mesurer l’évolution du taux de réussite des attaques.
Évaluation continue de l’IA
Pour les systèmes évoluant plus vite qu’un test annuel ne peut suivre, nous relançons le harnais selon une cadence convenue et après des modifications majeures (nouvelle version de modèle, nouvel outil, nouvelle source de données), à l’intérieur et à l’extérieur de votre périmètre, et nous signalons les évolutions. AIUC-1, la norme de certification pour les agents d’IA, exige des tests tiers experts de la robustesse aux attaques adverses et des appels d’outils au moins tous les trois mois ; une cadence trimestrielle fournit ici les preuves requises pour votre auditeur. Nous évaluons et transférons ; votre équipe opère les mesures de contrôle entre-temps.
Comment nous travaillons
Nous démontrons l’exploitabilité plutôt que d’énumérer les possibilités, nous vérifions les résultats sur plusieurs graines et paramètres de décodage pour distinguer les défaillances durables du bruit, et nous documentons chaque problème avec les entrées et les étapes de relecture permettant de le reproduire. Les constats sont mappés sur le OWASP Top 10 des applications LLM, le OWASP Machine Learning Security Top Ten, MITRE ATLAS, le NIST AI Risk Management Framework et, pour les agents IA, les exigences AIUC-1, et sont signalés pour une revue juridique lorsqu’ils touchent à la politique ou à la réglementation. Après les correctifs, nous répétons les tests, de sorte que le résultat est une variation mesurée du taux de réussite des attaques, et non une simple affirmation.
Adossé à la recherche
Les personnes qui réalisent ces évaluations publient leurs résultats. En 2026, IOActive a publié The Security Gap in AI-Generated Code, l’étude à l’origine des chiffres ci-dessus, a présenté Husn Canaries, ses recherches sur la gouvernance de l’utilisation du code source par les assistants de codage IA, au CSA AI Summit 2026, et a contribué à Cybersecurity AI: Hacking Consumer Robots in the AI Era, publié avec Alias Robotics en mars 2026. Lors de CanSecWest 2025, un consultant IOActive a montré comment des clones vocaux générés par IA ont été utilisés dans une mission red team réelle. Ces recherches sont à l’origine de nos cas de test.
Questions fréquemment posées
Quelle est la différence entre une évaluation de modèle, d’application et d’agent ?
Une évaluation de modèle teste le comportement du modèle. Une évaluation d’application teste tout ce qui l’entoure : prompts, retrieval, outils, API et permissions. Une évaluation d’agent teste ce que le système peut faire, chaque action et chaque permission sous-jacente. Choisissez selon la partie du système dont vous avez la responsabilité.
Avez-vous besoin de nos poids de modèle ou de notre code source ?
Cela dépend du périmètre. Les tests d’interface s’appliquent aux points de terminaison visibles par un attaquant. La revue de code nécessite un accès au code source. L’analyse de la mémorisation et de la garde nécessite un accès aux modèles ou aux poids. Nous convenons du niveau d’accès avant le début, et le rapport indique ce que chaque niveau nous a permis ou non de tester.
À quels référentiels associez-vous les constats ?
Le OWASP Top 10 des applications LLM, le OWASP Top Ten de la sécurité du machine learning, MITRE ATLAS, le NIST AI Risk Management Framework avec son profil Generative AI et, pour les agents IA, AIUC-1.
Cela nous rendra-t-il conformes à l’AI Act de l’UE, à l’ISO/IEC 42001 ou à l’AIUC-1 ?
Aucune évaluation ne peut, et nous ne délivrons pas de certificats. Nous fournissons les preuves techniques dont ces programmes ont besoin, des contrôles testés plutôt qu’attestés, et nous signalons les constats relevant de l’AI Act européen pour votre revue juridique. Les constats de gouvernance peuvent être organisés selon les clauses de la norme ISO/IEC 42001 sur lesquelles vous travaillez. Pour AIUC-1, la norme de certification des agents d’IA, nos évaluations de modèle, d’agent et red team produisent les preuves de tests tiers requises par leurs sections sécurité, sûreté et fiabilité, selon la fréquence trimestrielle qu’elles spécifient, pour examen par votre auditeur accrédité.
Que obtenons-nous à la fin ?
Un rapport dans lequel chaque constat est démontré et priorisé ; les scripts de rejeu et les journaux permettant de le reproduire ; les correctifs affectés à la couche modèle, pipeline ou application ; et un retest une fois les corrections appliquées. Les évaluations de modèles incluent une fiche de notation des risques et une feuille de route de remédiation.
Pouvez-vous tester un produit d’IA tiers ou SaaS que nous utilisons ?
Oui, dans les limites autorisées par votre fournisseur. Nous testons le produit tel qu’il est déployé pour vous : vos données, vos intégrations, vos permissions et les flux de travail accessibles. Lorsque les conditions du fournisseur limitent les tests, nous évaluons votre côté de la frontière et les contrôles dont vous avez la responsabilité.
Testez-vous en production ?
Uniquement dans le cadre des règles d’engagement convenues à l’avance. Les attaques susceptibles de déclencher des actions réelles sont exécutées contre des environnements similaires à la production ou avec les actions neutralisées, et nous vous informons avant chaque test de ce qui pourrait se produire en cas de réussite.
Est-ce en remplacement d’un test d’intrusion ou en complément ?
De plus, les fonctionnalités d’IA amplifient les failles classiques du Web, du mobile et des API, et une évaluation IA signale celles qu’elle détecte, mais une évaluation full-stack du système environnant reste la base. Si vous effectuez déjà des tests d’intrusion avec IOActive, les évaluations IA s’intègrent au même programme et à la même reporting.
Comment dimensionner une mission ?
L’évaluation ciblée d’un modèle, d’une application ou d’un agent constitue une mission délimitée ; les travaux relatifs au programme et à la gouvernance sont définis en fonction de votre inventaire IA. Lors de la réunion de cadrage, indiquez ce que fait le système, quelles actions il peut exécuter, à quelles données il peut accéder, comment il est déployé et quels accès vous pouvez nous accorder. Nous revenons ensuite vers vous avec un périmètre et un calendrier fixes.
Approfondir