GenAI et “Vibe Coding” : Comment sécuriser le nouveau “Shadow IT”
Le GenAI, avec les coding agents et les options offertes de vibe coding, va faciliter l’apparition des applications de type DEMU (Développement en Milieu Utilisateur). Le shadow IT risque encore de se renforcer et, avec lui, le shadow GenAI. Cette prolifération crée une nouvelle surface d’attaque applicative que les équipes de sécurité peinent encore à maîtriser.
Pour aider à structurer la réflexion autour de ces nouveaux dangers, la communauté OWASP a publié le Top 10 des risques pour les applications basées sur les LLM. Ce référentiel devient essentiel pour cartographier les menaces. Dans ce contexte, comment s’assurer que ces modèles, agents et pipelines RAG — souvent développés hors des filières TI traditionnelles — soient protégés efficacement ? La question est complexe et doit s’adresser via une approche multicouche.
L’approche collaborative
Tout comme pour les DEMU traditionnels, interdire et menacer n’apporte que rarement des résultats positifs. En effet, vous aurez toujours un stagiaire ne sachant pas ce qu’il fait, une ligne métier avec un besoin vital de son application Access, ou une autre exception qui exposera un risque important. Au contraire, une autre approche est possible : favoriser ce type de développement, mais dans un cadre contrôlé. Cela signifie concrètement, offrir un support à ces lignes métier en termes de détection de vulnérabilités, de Threat Modeling (en s’appuyant sur le référentiel OWASP LLM) ou encore d’infrastructure matérielle. Ainsi, on facilite la découverte de ces applications et on améliore notre capacité d’agir.
La simple consommation en interne d’un LLM ne représente que peu d’intérêt selon moi pour une ligne métier. Par contre, ce qui va apporter beaucoup de valeur et donc susciter beaucoup de développements est la connexion de ce LLM avec des documents d’entreprise et des outils internes comme le CRM ou encore l’ITSM. C’est ce qu’offrent les agents IA : une capacité à se connecter à des outils pour entreprendre des actions.
Le contrôle par l’identité
Se connecter à des outils en interne ne peut s’effectuer sans identité, et c’est là un moyen idéal de rattraper les projets n’ayant pas embarqué dans l’approche collaborative. En effet, l’identité des outils internes est en général contrôlée via des processus formels et la définition d’un compte non humain pour consommer ces outils devrait systématiquement donner lieu à une analyse du contexte AI.
Avec la publication du protocole MCP (Machine-Consumable Policy) par Anthropic, le marché a vu apparaître des solutions pour consommer les outils de manière rigoureuse, sécuritaire et contrôlée. C’est ainsi que nous avons désormais des proxies, des gateways ou encore des catalogues dédiés aux serveurs MCP consommés dans l’entreprise. Une priorité pour les entreprises désirant investir sérieusement dans le développement d’agents à l’interne est donc de mettre en place une infrastructure spécifique aux serveurs MCP facile d’accès. Cette approche centralisée est une réponse directe aux risques OWASP LLM06 (Insecure Plugin Design) et LLM07 (Excessive Agency), en garantissant que les connexions sont authentifiées et que les permissions des agents sont rigoureusement contrôlées.
La protection périmétrique et le DLP
Bien évidemment, vous n’empêcherez jamais un stagiaire de vouloir consommer un jour un service AI sans le mentionner à personne. Le plus efficace est certainement de mettre en place une protection au périmètre avec des outils spécifiques de type CASB/SASE. Ces outils vont plus loin que les firewalls en analysant les applications consommées via les communications Internet. On peut citer dans ce marché des acteurs comme Netskope, Zscaler ou bien sûr Microsoft Defender for Cloud Apps. Afin d’être le plus efficace possible, je recommande des outils permettant le déchiffrement SSL du trafic. Ces contrôles périmétriques sont fondamentaux pour adresser le risque LLM05 (Sensitive Information Disclosure), en empêchant l’exfiltration de données confidentielles vers des modèles non approuvés.
À noter que plusieurs acteurs du monde du firewall sont actuellement en train de renforcer leur catalogue avec des produits de sécurisation des applications AI, tels que Palo Alto Networks (avec sa solution AI-Runtime Security, ou AIRS). Le marché est très dynamique en ce moment.
La deuxième couche de prévention serait logiquement au niveau des endpoints. Toutefois, je ne conseille pas aujourd’hui de trop se focaliser sur ce domaine. En effet, avec un EDR et un outil DLP de type Microsoft Purview, vous devriez être déjà en partie protégé. Mon sentiment, par contre, est que ces outils vont avoir beaucoup de difficultés par conception à maintenir un haut niveau de protection dans ce domaine, donc je les considérerais plus comme des alliés (contribuant également à la maîtrise du risque LLM05) que des acteurs de premier plan.
Conclusion
Ces solutions vont vous permettre de sécuriser l’environnement dans lequel vos initiatives AI vont prendre place. Elles ne sécurisent pas, par contre, vos agents en soi contre des risques de type OWASP LLM01 (Prompt Injection), ni contre les risques de chaîne d’approvisionnement (supply chain) comme le téléchargement de LLM malicieux depuis le Web, par exemple. Ce type de menaces sera abordé dans un autre article focalisé sur ce qu’on appelle la protection au runtime des Applications AI.
