Qu’est-ce que le shadow AI ?

Présentation de l’IA fantôme

L’IA fantôme désigne toute utilisation de l’IA au sein d’une organisation qui échappe aux contrôles approuvés, qui n’est pas inventoriée et qui ne fait l’objet d’aucune surveillance de sécurité. Elle peut exister dans votre chaîne d’approvisionnement logicielle ou dans votre environnement cloud. Que désigne réellement l’IA fantôme ? Voici quelques exemples d’IA fantôme :

• Applications d’IA non approuvées, comme les chatbots, copilotes et outils de résumé
• Modèles/API non approuvés, comme les extensions de navigateur, les plug-ins et les endpoints de LLM publics
• Artefacts générés par l’IA, comme du code, des scripts et des packages

L’IA traditionnelle s’appuie souvent sur une plateforme centralisée intégrant la gouvernance, des pistes d’audit et la gestion des risques afin de minimiser les menaces de sécurité. L’IA fantôme est décentralisée, repose sur des contrôles minimaux et manque de pistes d’audit. Voici un aperçu de certaines différences clés entre l’IA fantôme et l’IA centralisée :

L’IA fantôme est souvent le résultat de l’utilisation, par les développeurs, analystes et autres équipes, d’outils d’IA non autorisés pour gagner en rapidité et en confort. Le copier-coller de données dans ces outils et services d’IA peut entraîner la fuite de code source, de secrets commerciaux et de données client sensibles. Les résultats produits par l’IA deviennent également des images et des packages, ce qui crée un effet d’entraînement et génère encore davantage d’artefacts d’IA fantôme.

Shadow IT vs Shadow AI

Le Shadow IT désigne l’utilisation de matériel, de logiciels ou de services cloud non autorisés sans l’approbation de l’équipe informatique d’une organisation. Par exemple, des membres d’une équipe peuvent utiliser au sein de l’organisation des solutions SaaS (logiciels en tant que service), des scripts ou des appareils non gérés non autorisés, ce qui peut entraîner des risques de sécurité.

En raison de sa visibilité et de son contrôle d’accès limités, le Shadow IT peut représenter une menace pour la sécurité des organisations. Toutefois, le Shadow AI (l’IA fantôme) ajoute des risques spécifiques au Shadow IT, en raison de la nature même des outils et services d’IA. Ces risques incluent :

• Données quittant l’organisation via des prompts d’IA
• Hallucinations de l’IA et code non sécurisé
• Fournisseurs de modèles et plug-ins tiers cachés
• Lacunes de provenance pour le code et les binaires générés par l’IA
• Actifs d’IA associés à des agents d’IA pouvant perturber les opérations

Le Shadow IT peut également entraîner le Shadow AI. Lorsque vous utilisez des solutions SaaS non approuvées avec des plug-ins ou des extensions activés, des fonctionnalités d’IA peuvent être activées par défaut.

Quels sont les risques de l’IA fantôme ?

Parmi les risques courants de l’IA fantôme figurent :

• Le code généré par l’IA n’est pas toujours sécurisé et peut introduire des failles courantes, comme l’injection, le contournement d’autorisation et la falsification de requêtes côté serveur (SSRF), créant ainsi des risques de sécurité inutiles.
• Les jetons collés dans des prompts et divulgués via des journaux ou historiques peuvent exposer des secrets.
• 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 Dockerfiles et images de base créés par l’IA à partir de sources inconnues peuvent représenter une menace pour la sécurité.
• Des problèmes peuvent également apparaître dans les pipelines de build, par exemple lorsque du code non examiné ou des scripts d’IA modifient des étapes CI/CD sans contrôle.
• Des solutions d’IA tierces peuvent avoir accès à des systèmes internes sensibles.

L’IA fantôme soulève également plusieurs préoccupations en matière de confidentialité des données. Des données sensibles comme le code source, les configurations, les données financières et les contrats 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, l’IA fantôme s’accompagne de risques de non-conformité et de responsabilités réglementaires. En tant qu’organisation, vous devez respecter certains processus de conformité et de gouvernance. Avec l’IA fantôme, vous ne savez pas qui a utilisé quel modèle, quelles données ont été saisies ni à quel moment. Il peut également exister des conflits avec les politiques liées aux cadres de conformité courants, notamment SOC 2, ISO 27001, le RGPD, HIPAA, PCI et les contrôles SDLC internes.

Il existe aussi 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, ainsi que de l’intégration possible de contenus soumis à restriction. De plus, des artefacts et dépendances non suivis peuvent entrer dans les builds et les releases, ce qui a un impact sur la chaîne d’approvisionnement logicielle.

Enfin, tout cela pourrait entraîner des dommages irréversibles à la réputation des organisations qui subissent l’une de ces conséquences négatives de l’IA fantôme.

Causes de l’IA fantôme

L’IA fantôme est toujours le résultat d’une utilisation non autorisée de l’IA, mais il existe quelques raisons pour lesquelles cela se produit :

• Innovation et recherche de praticité portées par les utilisateurs, entraînant une adoption prématurée des outils d’IA
• Manque de sensibilisation et de formation, pouvant conduire à une confiance excessive dans les résultats ou à une mauvaise compréhension des risques liés au partage de données via des prompts
• Absence de liste d’outils approuvés, de garde-fous ou de surveillance de l’IA, avec des contrôles SDLC manquants pour le code assisté par l’IA
• Lacunes organisationnelles, comme l’absence d’inventaire des packages, conteneurs, résultats de build, SBOM et métadonnées d’utilisation des modèles, pouvant amplifier l’IA fantôme

Exemples d’IA fantôme

Examiner quelques exemples d’IA fantôme peut vous aider à mieux comprendre son impact potentiel sur votre organisation. Voici quelques scénarios courants d’utilisation de l’IA fantôme dans les environnements professionnels :

• Développeurs utilisant des LLM publics pour générer, refactoriser ou rédiger des manifestes Terraform/Kubernetes, ou pour identifier des erreurs dans des journaux
• Analystes utilisant des outils d’IA gratuits pour résumer des documents internes
• Ingénieurs installant des extensions de navigateur pour capturer les données saisies dans des formulaires
• Équipes utilisant des bots non approuvés de « revue de code par IA » pour vérifier leur code
• Dockerfiles contenant des modèles d’IA tiers ou des appels à des API d’IA non approuvés

L’IA fantôme peut apparaître dans de nombreux environnements différents :

• Avec une clé OpenAI ou Gemini, l’IA fantôme peut être intégrée à pratiquement n’importe quel logiciel développé par un développeur, et accéder à toutes les informations auxquelles celui-ci a accès
• Assistants conversationnels publics, outils de codage de type « copilot » et outils de résumé de réunions basés sur l’IA
• Extensions et plug-ins dans les IDE, navigateurs et outils de ticketing
• Générateurs de code optimisés par l’IA pour l’IaC, les pipelines et les fichiers de build de conteneurs

En janvier 2023, Amazon a remarqué que certaines réponses de ChatGPT « correspondaient de très près » à des contenus internes existants de l’entreprise. En conséquence, Amazon a rappelé à ses employés de ne pas partager d’informations confidentielles dans les prompts ChatGPT.

Comment gérer efficacement l’IA fantôme

1. Détecter et mesurer l’utilisation de l’IA fantôme

La première étape pour gérer l’IA fantôme consiste à détecter et à mesurer son utilisation. Il existe plusieurs façons de détecter l’utilisation de l’IA fantôme :

• Trafic réseau sortant vers des endpoints 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
• Indicateurs dans les dépôts/CI, comme les signatures de commits générés par l’IA et les changements soudains de dépendances

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

2. Définir et appliquer des politiques d’utilisation de l’IA

Créez une checklist de politiques d’utilisation de l’IA que vous pouvez faire appliquer. Incluez notamment :

• Une liste des outils/modèles approuvés et des circuits d’approvisionnement associés
• Des règles de traitement des données précisant ce qui peut ou ne peut pas être collé dans les outils d’IA (code source, secrets, données client) ainsi que les exigences de masquage des données
• Vos exigences en matière de journalisation et d’audit
• Vos attentes en matière de revue humaine pour le code et les configurations générés par l’IA
• Des règles quant à la gouvernance des plug-ins tiers (connecteurs, autorisations et règles de conservation)

La rédaction d’une politique est une première étape nécessaire, et la formation des collaborateurs à cette politique est essentielle. Toutefois, une véritable protection exige une application stricte afin de garantir que seuls les actifs d’IA approuvés sont utilisés. Surtout, cette application doit être intégrée de manière simple, fluide et facile à suivre pour vos équipes, afin qu’elles ne soient pas tentées de chercher des contournements risqués.

3. Intégrer l’IA fantôme à vos cadres de sécurité et de gouvernance

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

• Provenance de l’artefact (de quel outil/modèle il provient, qui l’a généré)
• Analyse des dépendances et des vulnérabilités
• Point de contrôle de politique avant promotion
• Génération et conservation des SBOM

Vous devez également appliquer des politiques DevSecOps dans les environnements CI/CD et les registres :

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

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

Fournir un parcours d’« IA sécurisée » est un excellent moyen de renforcer l’AI SPM. Proposez un parcours incluant des comptes d’entreprise, l’authentification unique (SSO), la journalisation et des contrôles de conservation.

Activez des workflows développeur « sécurisés par défaut », comme des modèles préapprouvés pour les Dockerfiles et l’IaC, et utilisez des garde-fous ainsi que des contrôles automatisés afin de réduire les frictions et de préserver l’efficacité des workflows.

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

Lorsque vous découvrez que l’IA fantôme est utilisée dans votre organisation, voici trois étapes importantes à suivre :

1. Contenir : révoquer les jetons, renouveler les secrets et supprimer les extensions
2. Évaluer : identifier les données partagées et l’endroit où elles ont été stockées
3. Corriger : réanalyser les artefacts, reconstruire des versions propres, puis mettre à jour les politiques et la formation

En suivant ces étapes, les organisations transforment l’IA non gérée en actifs gouvernés, auxquels elles appliquent les mêmes contrôles rigoureux de sécurité et de gestion que dans le reste de leur chaîne d’approvisionnement logicielle. Parmi les métriques importantes à examiner figurent le pourcentage d’utilisation de l’IA sur des outils approuvés, le nombre d’artefacts bloqués ou mis en quarantaine, ainsi que le temps nécessaire pour corriger les expositions.

Gérer l’IA fantôme avec JFrog

Mettre fin à l’utilisation de l’IA fantôme 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 Shadow AI Detection dans JFrog AI Catalog, vous bénéficiez d’une vue complète de tous les modèles gérés et non gérés sur l’ensemble de votre plateforme.

JFrog AI Catalog utilise Xray pour analyser vos artefacts et vos dépôts, et identifie automatiquement les modèles non validés utilisés par votre équipe. La solution étiquette les modèles comme gérés, non gérés ou partiellement gérés, afin que vous puissiez facilement identifier les actifs qui nécessitent votre attention. À partir de là, vous pouvez approuver les modèles sûrs ou bloquer ceux qui présentent des risques.

Pour en savoir plus, rendez-vous sur notre site web, faites une visite virtuelle ou planifiez une démonstration individuelle au moment qui vous convient.