Vous avez un budget pour la sécurité de l’IA. Et maintenant ?

À retenir

• Les budgets consacrés à la sécurité de l’IA doivent passer de dépenses fragmentées en outils à un investissement unifié dans la visibilité, la gouvernance et le contrôle, tout au long du cycle de vie de l’IA.

• Les organisations doivent prévoir un budget pour deux fronts complémentaires : sécuriser le développement agentique, où les agents d’IA génèrent du code, utilisent des outils et exécutent des flux de travail, et sécuriser les applications agentiques, où les agents interagissent avec les utilisateurs, les données, les API et les systèmes de production.

• Un budget solide pour la sécurité de l’IA doit inclure des fonds dédiés à l’identification des systèmes d’IA, à l’évaluation des risques liés aux agents et aux modèles, à l’application des politiques, aux tests adversariaux, à la protection à l’exécution et aux preuves de gouvernance.

• La gouvernance et la conformité doivent constituer un poste budgétaire à part entière, et non être noyées dans les dépenses d’outillage ou reléguées aux équipes GRC. Les équipes ont besoin d’une découverte continue, de politiques applicables, de rapports sur les risques et de pistes d’audit pour prouver que les systèmes d’IA sont gérés de manière responsable.

• L’achat d’outils ponctuels de sécurité de l’IA déconnectés peut accroître les coûts et la complexité sans fournir de contrôle unifié. Une approche par plateforme aide les équipes de sécurité à relier visibilité sur l’IA, renseignements sur les risques, application des politiques et éléments probants, en développement comme en production.

La plupart des organisations consacrent leur budget de sécurité de l’IA au mauvais niveau. Le premier réflexe consiste à acheter des outils de visibilité pour répertorier les modèles, cartographier les API et mettre en place un tableau de bord.

Mais la visibilité seule n’empêchera pas l’agent de programmation qui vient d’intégrer un serveur MCP compromis. Elle n’arrêtera pas non plus l’agent en production qui s’apprête à transmettre les données d’un client à une destination inappropriée. Elle ne pourra pas davantage empêcher un flux de travail autonome d’enchaîner cinq actions individuellement « autorisées » pour aboutir à un résultat dangereux.

Sans application des règles, la visibilité ne suffit pas à assurer la gouvernance. Les organisations qui adoptent des agents d’IA doivent désormais sécuriser deux fronts distincts, mais complémentaires :

1. Les agents qui développent des logiciels

2. Les agents qui opèrent au sein des applications en production

La question que les responsables de la sécurité doivent résoudre dès maintenant n’est pas de savoir s’ils peuvent détecter les risques liés à l’IA après coup, mais s’ils peuvent gouverner les agents tout au long de leur cycle de vie, de leur conception à leur comportement en production. Cela nécessite de sécuriser les deux fronts : déplacer la sécurité vers la gauche pour protéger le code généré par l’IA et la chaîne d’approvisionnement des agents pendant le développement, tout en assurant la visibilité et la gouvernance des agents et des applications en production.

Front 1 : sécuriser les agents qui développent des logiciels

Dans le développement agentique, les agents d’IA intègrent désormais des dépendances, font appel à des serveurs MCP, exécutent des scripts, enchaînent des actions dans différents environnements et génèrent du code prêt pour la production avec très peu de supervision humaine. Cela crée trois surfaces de risque que l’AppSec traditionnelle n’a pas été conçue pour contrôler : ce que les agents utilisent, ce qu’ils font et ce qu’ils génèrent.

1. Ce que les agents utilisent : serveurs MCP, compétences et outils externes

Les agents de programmation d’IA ne partent pas d’une page blanche. Pour accomplir leurs tâches, ils intègrent en continu des serveurs MCP, des API externes, des compétences réutilisables, des composants open source, des plug-ins et des outils tiers, qui peuvent tous être vulnérables, malveillants ou mal configurés.

Ces composants sont sélectionnés et utilisés à l’exécution, sans approbation préalable. Des outils externes non fiables peuvent donc être introduits dans votre flux de travail en un instant. Si un outil de sécurité analyse uniquement l’artefact final, il ne détecte pas le moment où le risque s’est introduit dans le flux de travail : lorsque l’agent a sélectionné et utilisé une entrée non fiable.

Les recherches de Snyk ont déjà mis au jour des capacités d’agents malveillantes dans des écosystèmes partagés, des serveurs MCP vulnérables et des failles critiques dans des infrastructures d’agents largement utilisées. CVE-2025-6514, par exemple, exposait mcp-remote à une exécution de code à distance complète.

2. Ce que font les agents : exécution d’outils, scripts et accès système

Les agents ne se contentent pas de faire des suggestions : ils exécutent des actions de manière autonome, à la vitesse d’une machine. Une fois qu’ils ont reçu un objectif, ils peuvent lancer des commandes, modifier des fichiers, interagir avec l’infrastructure, interroger des systèmes, appeler des API et enchaîner des flux de travail dans différents environnements, souvent avec des autorisations étendues, peu de supervision et sans validation humaine.

L’incident Replit a illustré concrètement ce type de défaillance : un agent d’IA a ignoré des instructions explicites de « gel », supprimé une base de données de production et fabriqué des milliers de faux enregistrements pour dissimuler ses actes.

Ce type d’incident ne se produit pas parce qu’un analyseur a manqué une fonction vulnérable. Il survient parce que le comportement dynamique de l’agent, composé de plusieurs étapes, n’a pas été gouverné au moment de l’action. Le développement agentique exige des contrôles au sein de la boucle d’exécution, suffisamment proches pour évaluer le contexte, les autorisations et les risques avant qu’une action dangereuse ne soit menée à bien.

3. Ce que les agents génèrent : code et dépendances

Les agents génèrent également du code et des dépendances plus vite que les humains ne peuvent les vérifier. Ces éléments peuvent contenir des vulnérabilités, des dépendances dangereuses, des secrets codés en dur ou des erreurs de configuration.

Dans le développement agentique, le problème est que l’IA produit du code en continu, à la vitesse d’une machine et souvent en dehors des processus de vérification sur lesquels les organisations s’appuient. Lorsque l’analyse après commit est lancée, le code vulnérable peut déjà se trouver dans le dépôt. Dans certains flux de travail, il peut même déjà être empaqueté, déployé ou réutilisé par un autre agent.

Sécuriser le code généré consiste à le valider dès sa création, avant qu’il n’entre dans le dépôt ou ne s’intègre à un flux de travail plus vaste piloté par des agents. Dans le développement agentique, si vous ne sécurisez pas ce que les agents génèrent au moment de la création, vous ne faites que courir après un risque déjà introduit.

Front 2 : sécuriser les agents qui opèrent au sein des applications en production

Le deuxième front concerne la production. La plupart des organisations ont déjà des agents qui opèrent au sein de leurs applications : agents d’assistance qui traitent les demandes des clients, agents de flux de travail qui accèdent aux systèmes internes, pipelines autonomes qui appellent des API et applications natives de l’IA qui récupèrent des données, prennent des décisions et agissent sans intervention humaine.

Savez-vous ce que font vos agents et pouvez-vous les arrêter lorsqu’ils agissent de manière inappropriée ? Une fois les agents en service, la gouvernance se dégrade sur trois plans : découverte, évaluation des risques et conformité.

1. Découverte : impossible de gouverner des agents que vous ne voyez pas

Les équipes de sécurité ont besoin d’une vision à jour des environnements où les agents d’IA sont utilisés, des modèles qu’ils utilisent, des outils auxquels ils font appel, des données auxquelles ils accèdent et des flux de travail qu’ils exécutent.

La plupart des organisations n’ont pas cette vue d’ensemble. L’IA fantôme aggrave le problème : des employés et des équipes créent des outils GenAI personnalisés, intègrent des agents à leurs flux de travail et connectent des systèmes d’IA à des données internes sans examen formel de sécurité. Les lacunes de l’inventaire ne se limitent donc pas à une documentation incomplète des systèmes connus : elles concernent aussi des agents inconnus qui opèrent en dehors des canaux établis.

Si vous ne savez pas quels agents existent, vous ne pouvez pas leur appliquer de politiques, évaluer leurs risques, prouver votre conformité ni attribuer la responsabilité en cas de problème. L’inventaire est le fondement de la gouvernance, mais il ne constitue pas une finalité.

2. Évaluation des risques : les règles doivent s’appliquer là où les agents agissent

De nombreuses organisations disposent déjà de politiques de gouvernance de l’IA. Le problème, c’est que la plupart d’entre elles restent dans des documents, des feuilles de calcul ou des processus de vérification auxquels les agents ne sont jamais confrontés. Cette « gouvernance sur papier » crée un dangereux faux sentiment de sécurité.

Par exemple, une politique stipulant que « les agents ne peuvent pas exposer les données des clients à des services externes » n’a de valeur que si elle est appliquée lorsque l’agent tente d’agir. Sinon, l’organisation a une gouvernance sur papier et des comportements incontrôlés en production.

Les applications agentiques ont besoin d’une application des politiques au niveau de l’exécution, où les règles évaluent ce que l’agent tente de faire, les données qu’il manipule, les outils auxquels il fait appel et si l’action dépasse une limite définie. Ainsi, si un agent manipulé tente d’envoyer des données client vers un point de terminaison externe, l’action peut être bloquée ou modifiée avant son exécution.

3. Conformité : vous devez pouvoir prouver ce qui s’est passé, pourquoi et avec quelle autorisation

Lorsqu’un agent cause un problème pour l’entreprise, les équipes de sécurité ont besoin de plus que de simples journaux. Elles ont besoin d’un dossier défendable retraçant les faits : ce qu’a fait l’agent, les données auxquelles il a accédé, l’outil utilisé, la politique applicable, si l’action a été autorisée ou bloquée et qui était responsable du flux de travail.

L’affaire Air Canada a montré que les organisations peuvent être tenues responsables de ce qu’un chatbot d’IA dit aux clients. L’incident d’injection de prompt chez Chevrolet a montré à quel point une IA destinée au public peut facilement être manipulée pour produire des résultats ayant des répercussions sur l’entreprise. Les enchaînements toxiques montrent comment les agents peuvent combiner des outils, des données et des API de façon qu’aucune action prise isolément ne permettrait de révéler.

La gouvernance et la conformité doivent constituer un poste budgétaire dédié à la sécurité de l’IA, et non être noyées dans les dépenses d’outillage ou considérées comme une tâche GRC en aval. À mesure que les agents d’IA se répandent dans les flux de développement et les applications en production, les organisations doivent pouvoir prouver quels systèmes d’IA existent, quelles politiques s’y appliquent et si ces politiques sont effectivement mises en œuvre. Sans ces bases, le coût de la gouvernance se manifestera plus tard sous forme d’audits échoués, de négociations commerciales bloquées, d’enquêtes après incident ou de missions de conseil urgentes pour reconstituer une piste d’audit qui aurait dû exister dès le départ.

Pourquoi l’achat de deux outils déconnectés ne fonctionne pas

Les risques liés à l’IA ne restent pas sagement confinés à un seul niveau. Un modèle, un framework d’agent ou un serveur MCP peut être intégré au code, déployé via un pipeline, appelé par une application, puis utilisé par un agent pour agir en production. Si chaque étape est régie par un outil différent, les équipes de sécurité doivent assembler des vues partielles d’un même système.

Les risques liés à l’IA ne restent pas sagement confinés à un seul niveau. Un modèle, un framework d’agent ou un serveur MCP peut être intégré au code, déployé via un pipeline, appelé par une application, puis utilisé par un agent pour agir en production. Si chaque étape est régie par un outil différent, les équipes de sécurité doivent assembler des vues partielles d’un même système.

Un outillage fragmenté entraîne un contrôle fragmenté. Cela se traduit par :

• Des politiques incohérentes entre le développement et l’exécution

• Des inventaires en double qui ne concordent pas

• Des angles morts entre la compilation et le déploiement

• Des pistes d’audit distinctes qui ne racontent qu’une partie de l’histoire

• Une responsabilité mal définie lorsqu’un incident impliquant un agent se produit

Cela entraîne également une fragmentation des coûts : chaque outil ponctuel implique sa propre licence, son travail d’intégration, son pipeline de données, son tableau de bord et sa relation avec le fournisseur. Les équipes font souvent double emploi dans les domaines de la découverte, de l’analyse des risques et de l’application des politiques, tout en laissant subsister des lacunes entre ces domaines. Une fois les différents outils connectés, le coût total et la complexité peuvent dépasser la valeur d’une plateforme unifiée, sans pour autant offrir un contrôle unifié.

En matière de sécurité de l’IA, la consolidation ne relève pas seulement d’une décision budgétaire. C’est une exigence de gouvernance. Les équipes de sécurité ont besoin d’une vue unifiée des environnements où l’IA est présente, des risques qu’elle introduit, de son comportement et des politiques appliquées tout au long de son cycle de vie. Sans ce lien, les organisations risquent de dépenser davantage tout en restant privées de la visibilité, de la responsabilité et du contrôle nécessaires pour déployer l’IA à grande échelle en toute sécurité.

Snyk sécurise les deux volets de la sécurité agentique depuis une seule plateforme

La plateforme de sécurité de l’IA de Snyk sécurise les deux volets du cycle de vie des agents depuis une seule plateforme. Pour le développement agentique, Snyk aide à gouverner ce que les agents utilisent, ce qu’ils font et ce qu’ils génèrent, des serveurs MCP et des compétences à l’exécution et au code généré par l’IA. Pour les applications agentiques en production, Snyk offre un système de référence pour les risques liés à l’IA concernant les agents, les modèles, les outils, les données et les flux de travail grâce à Evo AI-SPM, qui transforme les objectifs de gouvernance en politiques applicables.

Résultat : une seule couche de contrôle pour la sécurité des agents, avec une découverte et des politiques communes, une application des règles en temps réel et une traçabilité vérifiable, en développement comme en production.

Ensemble, ces éléments créent un modèle unifié de sécurité des agents :

• Un système de référence unique pour les risques liés à l’IA et aux agents

• Un modèle de politiques commun au développement et à la production

• Une couche d’application des règles contre les comportements dangereux des agents

• Une piste d’audit unique pour la gouvernance et la responsabilisation

La question à laquelle répondre avant de finaliser le budget

Si vous disposez d’un budget consacré à la sécurité de l’IA et que votre équipe dirigeante attend des résultats, la question essentielle est simple : Pouvez-vous appliquer une politique de sécurité à un agent — en développement comme en production — avant qu’une action dangereuse ne soit menée à bien ?

Si la réponse est non, vous ne disposez pas d’une sécurité des agents et n’êtes pas suffisamment préparé à ce que le prochain agent supprime une base de données de production, hallucine une politique qui engage la responsabilité de votre entreprise, divulgue des données sensibles ou combine des outils approuvés pour créer un processus dangereux. Les organisations qui réussiront avec l’IA ne seront pas celles qui ralentissent son adoption. Ce seront celles qui intègrent un contrôle continu à la manière dont les agents développent des logiciels et fonctionnent en production.

Le budget est approuvé et la menace est bien réelle. La prochaine étape consiste à vous assurer que votre programme de sécurité de l’IA peut intervenir avant qu’une action dangereuse ne se transforme en incident métier. Vous souhaitez un guide pratique pour mettre en place une gouvernance continue et applicable ? Téléchargez dès aujourd’hui le guide de direction sur la mise en œuvre et l’application de la gouvernance de l’IA.