Qu’est-ce que le Shadow AI ?

Aperçu du Shadow AI

Le Shadow AI désigne toute utilisation de l’IA au sein d’une organisation qui échappe aux contrôles approuvés, n’est pas inventoriée et ne fait l’objet d’aucune surveillance en matière de sécurité. Il peut exister au sein de votre chaîne d’approvisionnement logicielle ou de votre environnement cloud. Qu’est-ce que le Shadow AI, au fond ? Voici quelques exemples de Shadow AI :

• Applications d’IA non approuvées, telles que les chatbots, les copilotes et les outils de synthèse
• Modèles et API non approuvés, telles que les extensions de navigateur, les plug-ins et les points d’accès publics à des LLM
• Artefacts générés par IA tels que le code, les scripts et les packages

L’IA traditionnelle repose souvent sur une plateforme centralisée, avec des mécanismes de gouvernance, des pistes d’audit et une gestion des risques visant à réduire les menaces de sécurité. Le Shadow AI est décentralisé, les contrôles en place sont minimes et il n’y a pas de pistes d’audit. Voici une analyse des principales différences entre le Shadow AI et l’IA centralisée :

Le Shadow AI résulte souvent de l’utilisation, par les développeurs, les analystes et d’autres équipes, d’outils d’IA non autorisés pour gagner en rapidité et en commodité. Le copier-coller de données dans ces outils et services d’IA peut entraîner des fuites de code source, de secrets commerciaux et de données clients sensibles. Les résultats générés par l’IA prennent aussi la forme d’images et de packages, ce qui crée un effet boule de neige et entraîne encore plus d’artefacts de Shadow AI.

Shadow IT vs Shadow AI

Le Shadow IT (ou Informatique fantôme) est l’utilisation de tout matériel, logiciel ou service cloud non autorisé sans l’approbation de l’équipe IT d’une organisation. Par exemple, des collaborateurs au sein de l’organisation peuvent utiliser des solutions SaaS non autorisées, des scripts ou des appareils non gérés, ce qui peut entraîner des risques de sécurité.

Le Shadow IT, faute de visibilité et de mécanismes de contrôle d’accès adéquats, constitue un risque pour la sécurité des entreprises. Cependant, le Shadow AI introduit des risques spécifiques qui s’ajoutent à ceux du Shadow IT, en raison de la nature même des outils et services d’IA. Ces risques incluent :

• Des données exfiltrées de l’organisation par le biais de prompts d’IA ;
• Des hallucinations de l’IA et code non sécurisé ;
• Des fournisseurs de modèles et plug-ins tiers cachés ;
• Des lacunes en termes de provenance du code et des binaires générés par l’IA ;
• Les actifs d’IA associés aux agents peuvent entraîner des perturbations opérationnelles.

Le Shadow IT peut également déboucher sur le Shadow AI. L’utilisation de services SaaS non autorisés, avec des extensions ou plug-ins actifs, peut activer automatiquement des fonctions d’IA.

Quels sont les risques du Shadow AI ?

Parmi les risques courants du Shadow AI, on peut citer :

• Le code généré par l’IA n’est pas toujours sûr, introduisant des failles courantes telles que l’injection, le contournement des autorisations et la falsification des requêtes côté serveur (SSRF) qui créent des risques de sécurité inutiles.
• Des jetons copiés dans des prompts et exposés via les journaux ou l’historique peuvent divulguer des informations sensibles.
• L’IA peut suggérer des dépendances non sécurisées.
• L’IA peut supprimer ou modifier des données qu’elle ne devrait pas.
• Les fichiers Docker construits par l’IA et les images de base provenant de sources inconnues peuvent constituer une menace pour la sécurité.
• Les problèmes liés au pipeline de build, tels que le code non validé et les scripts d’IA, modifient les étapes CI/CD sans contrôle.
• L’IA tierce peut avoir accès à des systèmes internes sensibles.

Le Shadow AI pose également plusieurs problèmes de confidentialité des données. Des données sensibles, telles que le code source, les configurations, les données financières et les contrats avec les clients peuvent être exposées. Vous ne savez pas non plus où vont les prompts ni combien de temps ils sont stockés, et des connecteurs tiers peuvent être en mesure d’exfiltrer des données.

En outre, le Shadow AI s’accompagne d’obligations en matière de conformité et de réglementation. En tant qu’organisation, vous êtes dans l’obligation de suivre certains processus de conformité et de gouvernance. Avec le Shadow AI, vous ne savez pas qui a utilisé quel modèle, quelles données ont été saisies, ni quand. Il peut également y avoir des conflits de politique avec les cadres de conformité courants, y compris SOC 2, ISO 27001, RGPD, HIPAA, PCI, et les contrôles internes du SDLC.

Il existe également des risques potentiels en matière de propriété intellectuelle et de licences en raison de règles d’attribution et de réutilisation peu claires et de l’incorporation potentielle de matériel à diffusion restreinte. De plus, les artefacts et les dépendances non suivis peuvent s’introduire dans les builds et les versions, ce qui a un impact sur la chaîne d’approvisionnement logicielle.

Enfin, tous ces éléments ont le potentiel d’entraîner des dommages irréversibles pour la réputation des organisations qui subissent l’une ou l’autre de ces conséquences négatives du Shadow AI.

Causes du Shadow AI

Le Shadow AI résulte toujours d’un usage non autorisé de l’IA, mais plusieurs facteurs peuvent l’expliquer :

• L’innovation et la commodité axées sur l’utilisateur entraînent l’adoption prématurée des outils d’IA ;
• Manque de sensibilisation et de formation conduisant à une confiance excessive dans les résultats ou à une méconnaissance des risques liés au partage de données par le biais de prompts ;
• Pas de liste d’outils approuvés, de garde-fous ou de contrôle par l’IA avec des contrôles SDLC manquants pour le code assisté par l’IA ;
• Des lacunes organisationnelles, telles que l’absence d’inventaire des packages, des conteneurs, des artefacts de build, des SBOM et des métadonnées d’usage des modèles, peuvent amplifier le Shadow AI.

Exemples de Shadow AI

L’examen de quelques exemples de Shadow AI peut vous aider à mieux comprendre l’impact que l’IA fantôme peut avoir sur votre organisation. Voici quelques scénarios courants dans les environnements professionnels où le Shadow AI est utilisé :

• Des développeurs utilisent des LLM publics pour générer, remanier ou écrire des manifestes Terraform/Kubernetes et identifier les erreurs dans les journaux ;
• Des analystes utilisent des outils d’IA gratuits pour résumer des documents internes ;
• Des ingénieurs installent des extensions de navigateur pour capturer les données saisies dans des formulaires ;
• Les équipes utilisent des robots de « révision de code par l’IA » non approuvés afin de vérifier leur code ;
• Des fichiers Docker contenant des modèles d’IA de tiers non approuvés / des appels d’API d’IA.

Le Shadow AI peut se manifester à de nombreux endroits :

• Avec une clé OpenAI ou Gemini, le Shadow AI peut être incorporé dans pratiquement n’importe quel logiciel construit par un développeur et accéder à toutes les informations dont dispose le développeur ;
• Assistants de chat publics, outils de codage « copilote » et résumés de réunions par l’IA ;
• Extensions et plug-ins dans les IDE, les navigateurs et les outils de ticketing ;
• Générateurs de code alimentés par l’IA pour l’IaC, les pipelines et les fichiers de build de conteneurs.

En janvier 2023, Amazon a remarqué que les réponses de ChatGPT « correspondaient étroitement » à du matériel existant au sein de l’entreprise. En conséquence, Amazon a rappelé à ses employés de ne pas partager d’informations confidentielles dans les prompts de ChatGPT.

Comment gérer efficacement le Shadow AI

1. Détecter et mesurer l’utilisation du Shadow AI

La première étape de la gestion du Shadow AI consiste à détecter et à mesurer l’utilisation du Shadow AI. Il existe plusieurs façons de détecter l’utilisation du Shadow AI :

• Sorties réseau vers des points de terminaison d’IA courants ;
• Inventaires des extensions de navigateur ;
• Journaux IAM et autorisations OAuth pour les plug-ins d’IA.
• Analyse complète de la chaîne d’approvisionnement logicielle ;
• Les modèles Repo/CI tels que les signatures de commit générées par l’IA et les changements soudains de dépendances.

Vous pouvez également dresser un inventaire des outils/modèles approuvés, des équipes qui les utilisent et des types de données qui peuvent être utilisés avec ces outils.

2. Élaborer et appliquer des politiques d’utilisation de l’IA

Créez une liste de contrôle des politiques d’utilisation de l’IA que vous pouvez appliquer. Éléments à inclure :

• Une liste des outils/modèles approuvés et des voies d’approvisionnement ;
• Règles de traitement des données spécifiant ce qui peut ou ne peut pas être collé (code source, secrets, données clients) et exigences de rédaction ;
• Exigences en matière de journalisation et d’audit ;
• Attentes en matière d’examen humain du code et des configurations générés par l’IA ;
• Gouvernance des plug-ins tiers (connecteurs, autorisations, rétention).

La définition de politiques constitue un point de départ nécessaire, et la formation des équipes est cruciale. Toutefois, une protection efficace passe par une mise en œuvre rigoureuse, afin d’assurer l’utilisation exclusive d’actifs d’IA validés. Il est essentiel que l’application de ces politiques soit intégrée d’une manière qui soit facile, sans friction et simple à suivre pour vos équipes, afin qu’elles ne soient pas tentées de chercher des solutions de contournement risquées.

3. Intégrer le Shadow AI dans vos cadres de sécurité et de gouvernance

Les résultats produits par l’IA doivent être considérés comme des intrants de la chaîne d’approvisionnement logicielle. Les exigences relatives à chaque résultat de l’IA doivent inclure :

• La provenance des artefacts (de quel outil/modèle ils proviennent, qui les a générés) ;
• Le scan des dépendances et des vulnérabilités ;
• Des étapes de validation des politiques avant promotion ;
• La création et maintien d’une nomenclature logicielle (SBOM).

Vous devez également mettre en œuvre le DevSecOps dans les pipelines CI/CD et les registres :

• Bloquer de manière proactive les packages et les images à risque ;
• Mettre en quarantaine les artefacts inconnus ;
• Promouvoir uniquement les builds conformes.

4. Proposer des alternatives sécurisées pour éviter que les équipes ne contournent l’IT

Proposer un parcours d’« IA sécurisée » est un excellent moyen de renforcer la gestion de la posture de sécurité de l’IA (AI SPM). Proposez un parcours qui inclut les comptes d’entreprise, l’authentification unique (SSO), la journalisation et les contrôles de rétention.

Mettez en place des processus de développement « secure-by-default », avec des templates validés à l’avance pour Dockerfiles et l’IaC, et appuyez-vous sur des garde-fous et des vérifications automatisées pour fluidifier les workflows.

5. Réponse aux incidents et amélioration continue

Lorsque vous découvrez que le Shadow AI est utilisée dans votre organisation, il y a trois étapes importantes à suivre :

1. Endiguer : révoquer les tokens, renouveler les secrets et retirer les extensions ;
2. Évaluer : déterminer quelles données ont été exposées et où elles ont été stockées ;
3. Corriger : rescanner les artefacts, reconstruire sur une base saine et actualiser les politiques et la formation.

En prenant ces mesures, les organisations transforment l’IA non gérée en actifs gouvernés, en appliquant les mêmes vérifications rigoureuses de sécurité et de contrôle que celles utilisées dans le reste de leur chaîne d’approvisionnement logicielle. Parmi les indicateurs importants à examiner figurent le pourcentage d’utilisation de l’IA sur des outils approuvés, le nombre d’artefacts bloqués/quarantinés et le temps nécessaire pour remédier aux risques.

En savoir plus : Comment détecter et éliminer le Shadow AI en 5 étapes

Gérer le Shadow AI avec JFrog

Mettre un terme à l’utilisation du Shadow AI et identifier les menaces de sécurité est un processus en plusieurs étapes qui nécessite du temps, des efforts et les bons outils. En utilisant la détection du Shadow AI au sein du JFrog AI Catalog, vous bénéficiez d’une vue d’ensemble de tous les modèles gérés et non gérés sur votre plateforme.

JFrog AI Catalog utilise Xray pour analyser vos artefacts et dépôts et identifier automatiquement les modèles non validés utilisés par votre équipe. Il étiquette les modèles comme étant gérés, non gérés ou partiellement gérés, ce qui vous permet de voir facilement quels assets requièrent votre attention. À partir de là, vous pouvez approuver des modèles sûrs ou bloquer ceux qui présentent des risques.

Pour plus d’informations, veuillez consulter notre site web, organisez une visite virtuelle ou organisez une démonstration individuelle à votre convenance.