Des centaines de milliers d’entreprises développent des applications d’IA. Il y a plus de cinq millions de projets liés à l’IA rien que sur GitHub. La course à l’IA est lancée, et la plupart des entreprises évoluent plus vite que leur sécurité ne peut suivre.
Les informations d’identification qui authentifient les services d’IA, les invites du système qui définissent leur comportement et les données de formation qui façonnent leur sortie circulent tout au long du cycle de développement et sont transmises aux applications elles-mêmes, pratiquement sans aucune visibilité ni contrôle.
Cycle de vie du développement d’applications d’IA et risque lié aux données
Contrairement aux logiciels traditionnels, pour les applications d’IA, les données ne sont pas de simples entrées, ce sont elles qui déterminent le comportement des applications d’IA. Par conséquent, la surface d’attaque s’étend de la protection de la logique applicative à la sécurisation des données qui enseignent à l’IA ce qu’elle doit faire.
Les données de formation et les sources de récupération proviennent de la production
Les systèmes d’IA ont besoin de données pour fonctionner. Cela signifie que les chaînes de connexion et les jetons d’accès circulent à travers les dépôts, les wikis et les tickets, créant un rayon d’exposition beaucoup plus large que les applications typiques. Une seule identification divulguée expose potentiellement tout ce sur quoi un agent d’IA est formé ou peut interroger, plutôt qu’une seule base de données.
Les requêtes système révèlent votre périmètre de sécurité
Les configurations des modèles et les invites du système sont stockées dans des dépôts et des pages wiki. Elles décrivent les politiques internes, les schémas de données et ce que le modèle est ou n’est pas autorisé à faire. Il s’agit d'une feuille de route qui indique précisément aux attaquants ce qu’ils peuvent exploiter.
Les agents d’IA sont surprivilégiés par conception
Les agents appellent des API, interrogent des bases de données et effectuent des actions autonomes. Les périmètres d’accès excessifs définis pendant le développement persistent souvent en production.
L'incident dont nous devrions tirer des leçons
En 2024, la directrice de l’alignement de Meta a révélé que son agent d’IA autonome avait effacé toute sa boîte de réception, ignorant les instructions explicites qui lui demandaient de demander l’autorisation avant d'agir. L'agent disposait d’autorisations étendues et aucun garde-fou n’était appliqué lors de l’exécution. Il a contourné ses propres contraintes et a pris de lui-même des mesures destructrices et irréversibles.
Il ne s’agissait pas d'une attaque par injection d’invite par un adversaire extérieur. Il s’agissait des autorisations et des limites de confiance définies au cours du développement, qui se sont déroulées exactement comme prévu.
La leçon : la sécurité de l’IA commence par définir ce à quoi un système d’IA peut accéder et ce qu’il est autorisé à faire. Il est donc important de prendre ces décisions délibérément.
Lorsque le développement d’applications d’IA crée une dette de sécurité
Les équipes peuvent documenter les invites système dans Confluence, gérer des scripts de formation dans GitHub, empaqueter des modèles dans des images Docker et partager des configurations dans Slack. Au fil du temps, les identifiants, les données de formation et la logique de l’IA s'accumulent dans des dizaines d’outils qui ne sont pas conçus pour gérer de manière sécurisée ces informations sensibles.
Dépôts : l’endroit où les identifiants sont intégrés
Les systèmes d’IA nécessitent un accès aux sources de données, aux API et aux modèles. Cela signifie que les développeurs travaillent constamment avec des chaînes de connexion, des jetons d’API et des clés privées. Les mêmes schémas qui créent des risques dans le développement traditionnel sont amplifiés dans le développement de l’IA :
- Les clés d'accès AWS dans les fichiers .env sont validées en même temps que les scripts de formation des modèles
- Les chaînes de connexion à la base de données apparaissent dans les fichiers de configuration de récupération
- Les jetons API pour les fournisseurs de modèles se trouvent dans des fichiers de configuration aux côtés des invites système
- Les ensembles de données de test contiennent des données à caractère personnel (PII) réelles des clients utilisées pour valider les résultats des modèles
Une fois envoyés, les secrets persistent dans l’historique des validations Git même s’ils sont supprimés de la branche actuelle
Wikis et outils de suivi des problèmes : l’endroit où l’architecture de l’IA est documentée
Les décisions d’architecture, les diagrammes de flux de données, les portées d’autorisation des agents et la justification de la sélection du modèle sont documentées dans Confluence et Jira. C’est là que réside le plan de vos services d’IA, et où sont conservés les identifiants et les configurations sensibles. Par exemple :
- Runbooks de déploiement avec clés API codées en dur pour les fournisseurs de modèles
- Documents d'architecture décrivant les sources de données auxquelles les agents d'IA ont accès
- Contenu de l’invite système collé dans les tickets pour révision
- Jetons d’accès intégrés dans la documentation d’intégration pour l’outillage d’IA
Cette documentation est sensible pour toutes les applications, mais le risque est amplifié pour les services d’IA. Les documents d’architecture révèlent la logique et les autorisations que les attaquants peuvent exploiter pour causer un maximum de dégâts.
Registres d'artefacts : où les secrets sont intégrés dans les builds
Les images Docker et les paquets pour les applications d’IA contiennent souvent des identifiants intégrés, des configurations codées en dur et des données sensibles intégrées au moment de la création. Ceci est particulièrement dangereux, car les secrets intégrés dans une image conteneur persistent de manière permanente dans les couches de l’image. Même si vous supprimez un fichier secret plus tard, Docker conserve la couche précédente dans l’historique des images où ces identifiants restent entièrement récupérables.
Par exemple, une fois qu’une clé API de fournisseur de modèle et des identifiants de base de données sont codés en dur dans un conteneur pendant le processus de compilation, ces secrets persistent dans la couche d’image spécifique où ils ont été ajoutés. Docker met en cache la sortie de chaque commande dans sa propre couche. Ainsi, si l’étape 1 copie des fichiers contenant des secrets et que l’étape 2 supprime ces fichiers, la couche de l’étape 1 contiendra toujours le contenu des secrets.
Outils de collaboration : où le contexte est partagé (avec tout le reste)
Les développeurs partagent les configurations d’agents IA sur des plateformes de messagerie comme Slack et Teams. Par exemple, les prompts système ou les exemples de données sensibles peuvent être collés dans les messages pour déboguer le comportement du modèle ou illustrer des cas limites. Ces communications sont rarement surveillées.
Assistants d’IA : les données qui sortent de l’entreprise
Les développeurs collent du code dans ChatGPT, Copilot et d’autres assistants d’IA. Par exemple, ils peuvent vouloir déboguer la logique du modèle, optimiser les pipelines de récupération ou améliorer les invites de l’agent. Ce code contient souvent des identifiants de production et des données à caractère personnel, qui sont ensuite transmises à des fournisseurs d’IA externes sans visibilité organisationnelle.
Les anciennes solutions ne peuvent pas sécuriser une application d’IA
Les équipes de sécurité tentent généralement de sécuriser le développement d’applications d’IA avec des outils de sécurité des applications comme Entro, Snyk ou Checkmarx. Ces outils sont excellents pour trouver des secrets dans les référentiels de code et rechercher des vulnérabilités connues, mais ils n’ont pas été conçus pour les flux de données uniques du développement de l’IA. Par exemple, ils ne peuvent pas détecter lorsque les invites système dans les pages Confluence révèlent les limites de sécurité d’un agent, identifient des autorisations API excessives accordées pendant le développement, ou analysent les artefacts JFrog à la recherche d’ensembles de données de formation contenant des données à caractère personnel client.
Lorsque les développeurs collent des configurations de modèles propriétaires dans ChatGPT pour le débogage, les outils de sécurité des applications n’ont aucune visibilité sur cette exposition des données. La limitation fondamentale est que les outils traditionnels de sécurité des applications protègent le code, tandis que la sécurité du développement de l’IA nécessite la protection des données sensibles et des configurations dans les wikis, les systèmes de suivi des problèmes, les registres d’artefacts et les interactions avec les assistants d’IA tout au long du cycle de vie complet du développement.
À quoi ressemble la sécurité complète du développement de l'IA
Sécuriser le cycle de développement des applications d’IA nécessite de pouvoir découvrir des données sensibles, cartographier qui peut y accéder, détecter les menaces, et remédier aux risques sur tous les outils que les développeurs utilisent pour concevoir, construire, empaqueter et déployer des services d’IA.
Dans les dépôts :
- Analyse complète de l’historique des validations, pas seulement de la branche actuelle
- Classification intelligente qui distingue les identifiants de production des jetons de test.
- Remédiation automatisée des autorisations risquées, des erreurs de configuration, des utilisateurs fantômes et des liens de partage
- Alertes en temps réel relatives aux nouvelles validations contenant des données sensibles, afin que les secrets soient détectés et remplacés lorsqu’ils sont exposés, et non lors de la prochaine analyse périodique
Dans les wikis et les systèmes de suivi des problèmes :
- Analyse complète des pages Confluence et des tickets Jira, y compris les pièces jointes, les commentaires et les champs personnalisés pour les identifiants, les clés API et les modèles de données sensibles
- Élimination automatisée des autorisations à risque et des mauvaises configurations par l’application des politiques et la remédiation
- Des audits des autorisations qui signalent un accès par défaut trop large aux espaces contenant des invites système, des configurations de modèles et de la documentation sur l’architecture de l’IA, avec révocation automatique de l’accès en cas d’autorisations obsolètes
Dans les registres d’artefacts :
- Analyse des images Docker sur toutes les couches pour détecter les secrets intégrés
- Analyse des métadonnées des paquets pour les URL internes, les jetons et les identifiants qui se retrouvent dans les fichiers de configuration
- Blocage automatisé de l’accès public aux dépôts sensibles et suppression des utilisateurs et rôles obsolètes
- Audits de contrôle d’accès qui signalent un accès trop permissif aux artefacts de création d’IA de production dans les dépôts
Dans les outils de collaboration :
- Analyse des messages et des canaux sur Slack et Teams pour détecter les identifiants, les secrets et les données à caractère personnel groupées
- Politiques de remédiation automatisées qui s’exécutent une seule fois, selon un calendrier ou en continu en arrière-plan
- Audit des permissions des applications tierces avec suppression automatique des privilèges excessifs.
- Détection comportementale permettant de déceler les schémas d’accès anormaux, comme un seul utilisateur accédant à des milliers de canaux, avec restriction d’accès immédiate
Dans les assistants d’IA :
- Analyse d’invite qui détecte les secrets, les données à caractère personnel et les modèles de code sensibles avant qu’ils ne créent un risque
- Remédiation automatisée des autorisations risquées, des erreurs de configuration, des utilisateurs fantômes et des liens de partage
- Surveillance de l’utilisation permettant aux équipes de sécurité de voir quelles données les développeurs partagent avec des fournisseurs d'IA externes, avec des politiques automatisées bloquant le partage de données à haut risque
Développement d’applications IA sécurisées avec Varonis
Varonis sécurise le développement de l’IA, de la planification à la production :
- Analyse complète de l’historique des validations sur GitHub et Bitbucket, pas seulement sur les branches actuelles, avec une classification intelligente qui distingue les jetons de test des identifiants de production
- Sécurité complète du wiki et de l’outil de suivi des problèmes qui analyse les pages Confluence et les problèmes Jira, y compris les pièces jointes, les commentaires et les champs personnalisés, à la recherche d’identifiants, de clés API et de modèles de données sensibles
- Analyse des images Docker qui examine toutes les couches à la recherche de secrets intégrés, ainsi qu’analyse des métadonnées des paquets qui détecte les URL internes et les jetons dans les fichiers de configuration
- Surveillance des outils de collaboration sur les plate-formes de messagerie comme Slack et Teams à la recherche d’identifiants et de données à caractère personnel, avec audit des autorisations des applications tierces et détection des schémas d’accès anormaux
- Analyse des invites d’IA qui détecte les secrets et les données à caractère personnel avant qu’ils ne créent des risques, offrant aux équipes de sécurité une visibilité totale sur les données que les développeurs partagent avec les fournisseurs d’IA externes
Sécurisation des applications IA en développement, déploiement et production
Une fois vos applications d’IA créées et prêtes à être déployées, vous aurez besoin d’une solution de sécurité couvrant les tests, le déploiement et la production. C’est là que les vulnérabilités des environnements de production, les attaques par injection d’invites et les erreurs de configuration d’exécution deviennent de réelles menaces.
Atlas : sécurité d’IA complète pour les systèmes de production
Varonis Atlas est une plateforme de sécurité d’IA qui protège l’IA tout au long de son cycle de vie : de la gestion de la posture et des tests de sécurité à la protection en temps réel et à la gouvernance. Atlas teste de manière proactive vos systèmes d’IA pour détecter des vulnérabilités telles que l’injection d’invites et les débridages, grâce à des tests de pénétration réalisés par IA. Atlas met en place des garde-fous en temps réel grâce à une passerelle d’IA qui s’insère dans le chemin des requêtes en temps réel, en inspectant les invites, les réponses et les actions des agents avant qu’elles n’atteignent le modèle.
Couverture complète de la sécurité de l'IA
Avec Varonis developer data security and Atlas, vous bénéficiez d'une protection de bout en bout pour le développement d'applications d'IA, de la planification initiale au déploiement et aux opérations en cours, en passant par toutes les phases de développement. Cette approche globale garantit que vos systèmes d'IA restent sécurisés tout au long de leur cycle de vie, protégeant à la fois les données qui les construisent et les systèmes qui les exécutent.
Nos systèmes d’IA sont-ils sécurisés ?
Si la plupart des équipes de sécurité s'interrogent sur la sécurité de leurs systèmes d'IA, elles ne disposent pas des données nécessaires pour répondre à cette question.
- Quelles données sensibles se trouvent dans les dépôts où votre système d’IA a été créé ?
- Quels identifiants sont intégrés dans les images Docker qui exécutent vos agents d’IA ?
- Quelles données vos développeurs ont-ils partagées avec des assistants d’IA externes lors du développement du système ?
- Qui peut accéder aux pages Confluence qui décrivent les champs d’autorisation de votre agent ?
Si vous ne pouvez pas répondre à ces questions, vos systèmes d’IA ont très probablement des vulnérabilités intégrées.
Planifiez une évaluation gratuite des risques de Varonis pour voir exactement quelles données sensibles sont exposées dans votre écosystème de développeurs et obtenir une voie claire vers la remédiation avant que vos vulnérabilités ne deviennent des failles.
Veuillez noter que cet article a été traduit avec l'aide de l'IA et révisé par un traducteur humain.
.png)
.png)