L’IA fait désormais partie des opérations réelles. Il écrit du code, lit des documents, appelle des outils, résume les tickets, recherche les connaissances internes et touche aux données clients. Cela donne de la vitesse aux équipes. Cela donne également aux attaquants davantage de moyens de tester.
Mais le problème dépasse le cadre de l’IA.
Une entreprise moderne expose un contour de sécurité complet : applications Web, APIs, panneaux d'administration, clients mobiles, logiciels de bureau, rôles cloud, applications OAuth, pipelines CI, secrets, journaux, flux de paiement, magasins de données, fournisseurs, outils de support, index RAG et agents. L’IA ajoute de la pression à ce contour. Cela ne le remplace pas.
Cette distinction est importante. Un certificat qui couvre uniquement la couche IA est trop restreint pour un acheteur sérieux. L’acheteur veut savoir si le système peut gérer l’ensemble du chemin : identité, données, argent, code, infrastructure, opérations et les nouveaux flux de travail d’IA qui se trouvent au-dessus.
Les investisseurs demandent des preuves. Les banques demandent des preuves. Les partenaires Fintech demandent des preuves. Les achats d'entreprise demandent des preuves. Une réponse claire de l’équipe est utile. Un certificat vérifié a plus de poids.
Ce qui a changé en 2026
Le 11 mai 2026, Google Threat Intelligence Group a signalé que les adversaires abandonnaient les premières expériences d'IA pour se tourner vers l'utilisation industrielle de modèles génératifs dans les flux de travail d'attaque. Google a décrit la découverte de vulnérabilités, la génération d'exploits, l'obscurcissement des logiciels malveillants, les opérations autonomes de logiciels malveillants, la reconnaissance, les opérations d'information et les attaques de la chaîne d'approvisionnement de l'IA prises en charge par l'IA. Le rapport indique également que GTIG a identifié un acteur de la cybercriminalité à l'aide d'un exploit Zero Day qui, selon Google, a été développé avec l'IA.
Le 7 mai 2026, Microsoft Security a publié une recherche sur les chemins d'exécution de code à distance dans les frameworks d'agents IA. Dans une étude de cas du noyau sémantique, l’injection rapide a atteint l’exécution de l’outil car l’agent a accepté les paramètres fournis par le modèle. Une fois qu'un modèle peut appeler des outils, une invite peut passer de la manipulation de texte à l'écriture de fichiers, à l'exposition de données et à l'exécution de code à distance.
Le 30 avril 2026, la NSA, la CISA, le NCSC du Royaume-Uni, le Centre canadien pour la cybersécurité, l'ACSC d'ASD et d'autres agences ont publié des lignes directrices conjointes sur les services d'IA agentique. Leur avertissement est pratique : les systèmes agentiques ajoutent un risque de privilège, un risque de conception, un risque de comportement, un risque structurel et un risque de responsabilité. Les actions peuvent traverser les composants connectés plus rapidement que l’examen normal ne peut suivre.
L'OWASP répertorie l'injection rapide comme LLM01 dans le Top 10 2025 pour les applications LLM. La taxonomie d'apprentissage automatique contradictoire du NIST couvre les attaques par incitation directe, l'injection d'invite indirecte, l'empoisonnement des données, l'extraction de modèles, la compromission de la confidentialité et la sécurité des agents. Ce ne sont plus des cas extrêmes. Ce sont des risques opérationnels pour les produits qui intègrent l’IA dans les flux d’utilisateurs.
La leçon est simple. L'IA agrandit la carte. L'ensemble de la carte doit encore être vérifié.
La douleur commerciale
Le monde extérieur ne voit pas votre schéma d’architecture. Il ne voit pas le ticket dans lequel l'équipe indique que le problème est résolu. Il voit le risque.
Il voit un produit connecté aux flux de travail de finance, d'identité, de CRM, d'analyse, de cloud, de facturation, d'hébergement de code et de support. Il voit les autorisations OAuth. Il voit des vendeurs. Il voit les surfaces d'administration. Il voit les agents IA qui peuvent appeler des outils. Les données clients passent entre de nombreuses mains.
Pour une entreprise de technologie financière, cela peut ralentir l’intégration des partenaires. Pour une entreprise travaillant avec de l’argent, cela peut bloquer les paiements, les opérations bancaires ou l’examen des achats. Pour une startup qui lève des capitaux, cela peut créer un manque de diligence raisonnable. Pour une entreprise vendant à des acheteurs professionnels, cela peut rendre le questionnaire de sécurité plus long, plus lent et plus coûteux.
La sécurité doit devenir visible, concrète et facile à expliquer.
Ce que couvre le certificat SToFU
SToFU La certification de sécurité couvre l'intégralité du contour de la sécurité, y compris l'IA lorsque le produit l'utilise.
L'IA est incluse lorsque le produit l'utilise. Le reste du système est inclus car les attaquants ne respectent pas les catégories de produits. Ils empruntent le chemin utile le plus faible.
Nous commençons par la portée. Nous cartographions ce qui est exposé, ce qui est sensible et ce qui peut modifier l'argent, les données, l'accès ou les opérations. Une portée normale de certification peut inclure :
- Applications Web publiques et backend APIs.
- Panneaux d'administration, outils d'assistance et flux de travail internes.
- Authentification, autorisation, gestion de session et modèles de rôle.
- Applications OAuth, intégrations tierces et accès des fournisseurs.
- Identité cloud, stockage, règles réseau et chemins de déploiement.
- Pipelines CI/CD, créez des artefacts, des dépendances et des secrets.
- Applications mobiles, clients de bureau, canaux de mise à jour et stockage local.
- Flux de paiement, chemins de piratage de compte, flux de travail financiers et exposition à la fraude.
- Journalisation, alertes, préparation aux incidents et qualité des preuves.
- Agents IA, sources RAG, invites, autorisations des outils, mémoire et chemins de sortie.
Ensuite, nous testons le contour par rapport à des modes de défaillance pratiques. Nous recherchons les lacunes d'autorisation, les contrôles d'accès au niveau des objets brisés, les autorisations d'agent non sécurisées, les injections rapides, les fuites de données, l'exposition de secrets, les faiblesses de dépendance, les risques liés à la chaîne d'approvisionnement, le stockage non sécurisé, les chemins de récupération faibles et les erreurs de configuration qui peuvent transformer un petit bug en un événement commercial.
Le certificat enregistre ce qui a été examiné, quand il a été examiné, ce qui a été trouvé, ce qui a été corrigé et combien de temps le résultat reste valide.
Ce que le client reçoit
L'acheteur a besoin d'un document qui puisse évoluer tout au long d'un processus commercial sans traduction par un ingénieur à chaque réunion.
Le package de certification SToFU donne cette structure :
- Un certificat de sécurité avec la portée et la période de validité révisées.
- Un résumé de la portée qui nomme les systèmes, les flux et les limites examinés.
- Un résumé de l’état de correction pour les résultats fermés.
- Références de preuves pour les résultats des nouveaux tests et les contrôles importants.
- Notes pratiques pour les changements qui devraient déclencher une nouvelle révision.
Cela aide les dirigeants à répondre à des questions directes :
- Le contour exposé a-t-il été vérifié ?
- Les constatations critiques et à haut risque ont-elles été corrigées ?
- L’examen inclut-il uniquement l’IA ou l’ensemble du système ?
- Cela peut-il être montré aux investisseurs, aux partenaires, aux auditeurs et aux acheteurs d’entreprises ?
- Quels changements rendraient le certificat obsolète ?
Cette dernière question est importante. Un certificat est utile car ses limites sont claires.
Quand le certificat est délivré
Un certificat est délivré lorsque l'examen montre qu'aucune vulnérabilité exploitable critique ou à haut risque ne reste dans le périmètre convenu.
Si des vulnérabilités sont détectées, le chemin est direct : corriger, retester, conserver les preuves, puis certifier. Une faiblesse fermée fait preuve de discipline lorsque l'équipe la corrige et vérifie le résultat.
Pour la plupart des systèmes de production, le certificat est valable jusqu'à 12 mois. Il s'agit d'un rythme pratique pour les ventes, l'examen par les investisseurs, les achats et la planification annuelle de la sécurité. Les logiciels évoluent rapidement, la durée de validité doit donc respecter la réalité.
Les changements importants devraient déclencher un nouvel examen plus tôt. Les exemples incluent un nouvel agent IA, un nouveau flux de paiement, une nouvelle intégration OAuth, une migration majeure vers le cloud, un nouveau panneau d'administration, un changement de dépendance critique, un nouveau fournisseur avec un accès sensible ou un changement important dans la gestion des données.
Pourquoi c'est important maintenant
L’IA aide les attaquants à rechercher plus rapidement, à automatiser davantage, à générer des charges utiles plus propres et à tester la logique qui manque aux anciens scanners. Il aide également les défenseurs lorsqu’il est utilisé avec l’isolement, la surveillance, les autorisations restreintes et les preuves.
Mais le mouvement principal est plus ancien et plus fort que le battage médiatique.
Cartographiez le contour. Testez les chemins exposés. Réparez ce qui compte. Retester. Conservez la preuve. Donnez au marché un certificat attestant que le système a été révisé avec clarté et force.
C'est l'objectif de la certification de sécurité SToFU : rendre la sécurité suffisamment claire pour que les investisseurs, les partenaires fintech, les équipes d'approvisionnement et les acheteurs d'entreprise puissent y donner suite.
