Analyse des modèles de sécurité de l’IA par F5 Labs : quand les agents IA exposent des données sans l’intervention d’un attaquant

Malcolm HeathChercheur principal en cybermenaces | F5

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

Les agents d’IA sont conçus pour accomplir des tâches de manière autonome et trouvent souvent des moyens d’atteindre un objectif que leurs opérateurs n’avaient pas envisagés. Des incidents récents montrent comment des agents s’efforçant de mener à bien leurs missions peuvent exposer de manière inattendue des données critiques ou déclencher des flux de travail indésirables.

Ces incidents n’impliquent pas nécessairement un comportement malveillant ou des modèles compromis. Des risques peuvent survenir lorsque des agents poursuivent des objectifs légitimes, mais fonctionnent sans contrôles adéquats encadrant ce à quoi ils peuvent accéder, ce qu’ils peuvent exécuter ou partager. Des données sensibles peuvent ainsi être exposées au public et potentiellement à des acteurs malveillants, sans qu’un attaquant ne soit jamais intervenu.

Deux exemples de ce type de risque sont analysés dans le rapport d’octobre de F5 Labs sur la sécurité de l’IA. Ce rapport mensuel examine la résilience des modèles à travers les classements de F5 Labs en matière de sécurité de l’IA, ainsi que les nouvelles menaces, les vulnérabilités et les incidents de sécurité touchant les systèmes d’IA. Il analyse également les nouvelles menaces et les nouveaux incidents liés à la sécurité de l’IA, notamment deux cas survenus ce mois-ci dans lesquels des agents exécutant des tâches légitimes ont exposé des informations sensibles sans l’intervention d’un attaquant externe. Ces incidents montrent que les risques de sécurité peuvent découler non seulement des vulnérabilités des modèles, mais aussi du comportement des agents et des mécanismes de contrôle encadrant leurs actions.

Tenez compte de la loi des conséquences imprévues

L’un de ces incidents, la récente fuite PixelLeak, met en lumière les risques liés au comportement des agents autonomes lorsque des contrôles de sécurité appropriés ne sont pas appliqués. Les agents de programmation IA sont couramment chargés de joindre aux pull requests des captures d’écran montrant le travail des développeurs avant et après leurs modifications. Mais personne ne s’attendait à ce qu’ils le fassent en publiant ces images propriétaires et potentiellement sensibles dans des dépôts GitHub publics.

Les agents utilisent une interface en ligne de commande (CLI) plutôt que l’interface web dont se servent les utilisateurs pour accéder au service d’hébergement d’images. Faute de moyen d’ajouter des images aux pull requests privées en ligne de commande, les agents ont estimé qu’ils devaient créer des dépôts publics pour éviter que les personnes chargées de la revue ne se retrouvent face à des liens brisés. Certains développeurs utilisaient également gitshot, un outil open source de publication de captures d’écran associé à la création de dépôts publics. Selon l’étude, environ un tiers des organisations concernées comptaient des développeurs utilisant cet outil.

Plus de 13 000 captures d’écran et enregistrements internes ont été exposés dans plus de 900 dépôts GitHub publics, touchant plus de 300 organisations. En une semaine, plus d’une douzaine d’agents chez un même éditeur de logiciels avaient intégré cette solution de contournement sous forme de compétence réutilisable. Le problème de sécurité plus général tient au fait que les agents ont pu publier des contenus potentiellement sensibles dans des dépôts publics, en dehors des mécanismes habituels de supervision de l’entreprise. Alors que 93 % des dépôts concernés se trouvaient sur des comptes personnels, ces résultats soulignent l’importance d’imposer des contrôles sur les emplacements où les agents peuvent publier des données, plutôt que de se fier uniquement aux processus prévus ou aux instructions des développeurs.

Un autre incident signalé en octobre a suscité des inquiétudes quant à l’exposition de données dans les environnements partagés d’agents d’IA. Selon le témoignage de la personne concernée, un agent d’assistance personnelle basé sur Grok a publié des informations sur les finances personnelles de son propriétaire dans un canal Slack professionnel dont ce dernier était membre. Le bot Grok était censé effectuer un audit en lecture seule des comptes bancaires de son propriétaire, analyser ses dépenses et lui communiquer les résultats chaque mois. Point essentiel : l’agent ne disposait d’aucune connexion à Slack ; il était censé transmettre l’audit à son propriétaire par d’autres moyens.

Au lieu de cela, les informations financières du propriétaire se sont retrouvées pendant deux heures sur le canal Slack de son entreprise, comme s’il les avait publiées lui-même, jusqu’à ce qu’un collègue le signale. Bien que cet incident n’ait pas été confirmé, il met en évidence un risque de sécurité plausible : les autorisations définies au niveau de chaque agent peuvent ne pas garantir un cloisonnement suffisant lorsque plusieurs agents partagent des identifiants, des sessions ou des intégrations au sein d’un même environnement.

Le bot financier n’avait pas accès à Slack, mais un autre bot du même compte y avait accès, et tous les bots d’un utilisateur partagent des ressources. La documentation de SpaceXAI met d’ailleurs explicitement en garde contre le fait de considérer des bots distincts comme une barrière de sécurité. L’incident signalé soulève des questions quant à la capacité des autorisations propres à chaque agent à offrir une protection suffisante dans les environnements partagés. Lorsque les agents peuvent accéder à des identifiants, à des sessions ou à des ressources en commun, les organisations doivent vérifier que des mécanismes efficaces d’isolation et de contrôle des autorisations sont bien appliqués.

Anticipez les risques, même en l’absence d’adversaires

Ces incidents illustrent une distinction importante : la résistance d’un modèle aux attaques adverses ne garantit pas la sécurité de chaque application ou agent conçu à partir de celui-ci. La résilience du modèle est un facteur important à prendre en compte, mais la sécurité dépend aussi des autorisations, des intégrations et des mécanismes de contrôle qui encadrent le système d’IA déployé.

L’indice global de sécurité de l’IA (CASI) de F5 Labs mesure la résistance des modèles aux attaques adversariales, notamment aux injections de prompt et aux tentatives de contournement des garde-fous. Le score de résistance agentique (ARS) évalue la résilience face aux attaques agentiques complexes en plusieurs étapes. Ces deux indicateurs fournissent des éléments précieux sur la résilience face aux attaques adversariales, mais aucun n’a vocation à évaluer l’ensemble des autorisations, des intégrations ou des contrôles d’exécution qui encadrent un agent déployé.

Cette distinction est importante, car les agents évoluent au sein d’un système plus vaste de connecteurs, d’identifiants, de ressources partagées et d’autorisations. Les travaux de recherche d’octobre montrent comment des faiblesses dans ces mécanismes de contrôle périphériques peuvent entraîner des divulgations involontaires, sans intervention d’un attaquant. Ils recensent également d’autres cas, notamment GitSpawn et la vulnérabilité de GitLab AI Gateway, dans lesquels des attaquants pouvaient exploiter des limites de confiance ou d’exécution qui n’étaient pas appliquées au moment nécessaire. La leçon commune est que les limites de sécurité doivent être efficaces, qu’une action risquée provienne d’un agent accomplissant une tâche légitime ou d’un attaquant exploitant une faiblesse.

Pour les RSSI, cela implique d’évaluer bien plus que le modèle. La modélisation des menaces doit couvrir l’ensemble de l’architecture des agents, notamment l’identité, les autorisations, l’accès aux outils, les environnements partagés et les conséquences des actions autonomes. Les approches de détection axées principalement sur les intrusions malveillantes peuvent également laisser passer des actions préjudiciables effectuées par des agents pourtant dûment autorisés. Une forte résilience du modèle face aux attaques est précieuse, mais elle ne saurait remplacer l’application et la surveillance des règles encadrant ce à quoi les agents déployés peuvent accéder, ce qu’ils peuvent exécuter ou ce qu’ils peuvent divulguer.

Protégez votre organisation contre les risques non adversariaux

Ces résultats montrent pourquoi les organisations ne peuvent pas se fier uniquement au comportement prévu d’un agent ou au score de sécurité d’un modèle. Les RSSI ne peuvent pas anticiper toutes les actions qu’un agent autonome pourrait entreprendre, mais ils peuvent réduire l’impact des comportements inattendus en définissant et en validant des limites dont le respect peut être imposé. Cinq domaines méritent une attention particulière :

1. Élargissez votre définition de la sécurité de l’IA. Évaluez la résilience du modèle ainsi que la sécurité du système d’IA dans son ensemble, notamment l’identité des agents, les autorisations, l’isolation, l’accès aux ressources et les environnements d’exécution. Il s’agit d’évaluations de sécurité distinctes, mais complémentaires.
2. Prenez en compte l’ensemble de l’infrastructure d’IA. Intégrez les passerelles d’IA, les moteurs de modèles et les services d’orchestration d’agents aux inventaires des actifs, à la gestion des vulnérabilités, aux processus d’application des correctifs et aux revues des accès privilégiés. La faille découverte en octobre dans GitLab AI Gateway montre pourquoi ces composants doivent être considérés comme des éléments d’infrastructure critiques pour la sécurité.
3. Faites respecter les limites techniques. Les instructions des prompts et les paramètres propres aux agents ne remplacent pas des mécanismes efficaces d’isolation et d’autorisation, en particulier lorsque les agents partagent des ressources. Limitez les emplacements où les agents peuvent publier des artefacts, examinez les compétences réutilisables créées par les agents et surveillez les résultats réels de leurs actions.
4. Vérifiez les contrôles avant l’exécution. Assurez-vous que les contrôles de confiance et d’approbation interviennent avant que des actions potentiellement dangereuses puissent avoir lieu. Dans le cas de GitSpawn signalé en octobre, la configuration du dépôt pouvait déclencher l’exécution de code au démarrage de l’agent, avant les vérifications de confiance pertinentes, sans appel d’outil par le modèle. Examinez en conséquence le comportement au démarrage, les autorisations des points de terminaison destinés aux développeurs et les voies de la chaîne d’approvisionnement logicielle.
5. Réévaluez les modèles et les environnements des agents à mesure qu’ils évoluent. Les résultats CASI d’octobre montrent des variations même au sein d’une seule famille : GPT-6 Luna a obtenu un score de 93,52, Astra de 89,62 et Sol de 88,22. Chaque variante de modèle mérite donc une évaluation de sécurité distincte. Réévaluez également les autorisations des agents, les intégrations et l’infrastructure après tout changement important. Les tests adversariaux, notamment ceux réalisés avec F5 AI Red Team, peuvent aider à identifier les faiblesses, mais doivent être complétés par des vérifications des contrôles opérationnels qui encadrent les actions des agents.

Les résultats d’octobre confirment un enseignement concret pour les RSSI : la résilience des modèles, le comportement des agents et les mesures de contrôle encadrant un déploiement d’IA doivent être évalués conjointement. Un score élevé de résilience aux attaques adverses n’élimine pas les risques liés aux autorisations, aux intégrations ou à l’infrastructure.

Consultez le rapport d’octobre de F5 Labs sur la sécurité de l’IA pour découvrir les derniers résultats CASI et ARS, les nouvelles techniques d’attaque et l’analyse des vulnérabilités des systèmes d’IA.

Découvrez comment la F5 AI Security Platform peut contribuer à protéger votre organisation. Pensez également à lire l’article de blog de F5 Labs du mois dernier consacré au renseignement sur les menaces, qui portait sur les différents indicateurs de sécurité que les RSSI doivent évaluer avant et après le déploiement des modèles.

À propos des auteurs

Malcolm HeathChercheur principal en cybermenaces | F5

Malcolm Heath est chercheur principal en menaces chez F5 Labs. Au cours de sa carrière, il a travaillé dans la réponse aux incidents, la gestion de programmes, les tests d’intrusion, l’audit de code, la recherche sur les vulnérabilités et le développement d’exploits, au sein d’entreprises de toutes tailles. Avant de rejoindre F5 Labs, il était ingénieur senior en sécurité au sein de la F5 SIRT.

Autres articles de Malcolm Heath

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

Louise Scully est Senior Manager en marketing produit pour la sécurité de l’IA et le renseignement sur les menaces chez F5. Au cours de sa carrière, elle a exercé dans les domaines du marketing produit, de la gestion de produits, de la stratégie de mise sur le marché, de la communication, du leadership d’opinion et du développement de catégories, dans les secteurs de la sécurité de l’IA et des technologies d’entreprise. Avant de rejoindre F5, Louise a dirigé le marketing chez CalypsoAI et Artomatix, contribuant à la commercialisation de technologies et de travaux de recherche en IA.

Autres articles de Louise Scully