Quand les garde-fous flanchent : les outils de codage IA et la question de la couche de données
Pas de conférence de presse. Pas de lettre de notification de violation. Une faille dans un assistant de codage IA largement utilisé — une faille que les chercheurs affirment pouvoir chaîner à une injection de prompt pour extraire des données d’environnements où elles n’auraient jamais dû se trouver — a été corrigée discrètement, et tout le monde est passé à autre chose. Le problème était une injection de null-byte dans le nom d’hôte SOCKS5 du bac à sable réseau de l’outil — une faiblesse qui permettait au trafic sortant d’échapper à la liste d’autorisation censée le contenir. La correction a été déployée sans CVE et sans mention dans les notes de version.
Le silence est justement ce qui mérite réflexion. Les outils IA qui lisent vos fichiers, exécutent vos commandes et accèdent à vos dépôts sont omniprésents, et la frontière entre l’assistant qui fait son travail et celui qui agit pour le compte d’un attaquant est plus mince que la plupart des organisations ne veulent l’admettre. La vraie question n’est pas de savoir si ce bug a été corrigé — c’est le cas. C’est de savoir à quoi ressembleront vos défenses la prochaine fois que ce ne sera pas le cas.
5 points clés à retenir
1. Un contournement de bac à sable corrigé discrètement annonce la suite, ce n’est pas une simple curiosité.
Un assistant de codage IA a permis, via une évasion du bac à sable chaînée à une injection de prompt, une exfiltration de données — corrigée discrètement, sans CVE, sans note de version. La correction a restauré la frontière qui avait cédé. La plupart des organisations n’ont pas de deuxième ligne de défense. La prochaine faille ne s’annoncera pas, et si la seule défense est celle qui vient de céder, c’est la première phrase du rapport d’incident.
2. Les garde-fous au niveau du modèle échouent en tant que catégorie.
Une étude portant sur près de 15 000 assistants IA personnalisés a révélé que plus de 95 % ne disposaient pas de protections de sécurité adéquates, et que 96,51 % étaient vulnérables à la manipulation par jeu de rôle. Les prompts système, filtres et bacs à sable régulent le comportement à un niveau où il reste négociable — et les chercheurs trouvent sans cesse les entrées qui font déroger les modèles à leurs règles. Un prompt plus malin reste un prompt. La gouvernance IA doit s’exercer là où la persuasion du modèle ne peut pas agir.
3. La conformité réglemente l’accès aux données, pas l’acteur.
HIPAA, CMMC, RGPD et PCI DSS déterminent qui peut accéder aux données et si vous pouvez le prouver a posteriori. Peu importe que ce soit un humain ou un agent IA qui effectue l’action. La gouvernance relève donc de la couche données. Que l’accès soit autorisé, chiffré et journalisé — ce sont des questions de couche données, pas de couche modèle.
4. Vos outils actuels ne voient pas les agents IA.
DLP, WAF et EDR ont été conçus pour inspecter l’activité initiée par des humains. Un agent autorisé qui effectue des appels API légitimes ne correspond pas à leurs modèles d’inspection. Un outil IA compromis qui exfiltre des données ressemble — pour tous ces outils — à un outil IA qui fait simplement son travail. La vérité n’est visible qu’au niveau des données. 60 % des organisations n’ont pas de détection d’anomalies spécifique à l’IA selon les Prévisions Kiteworks 2026.
5. Faites appliquer les règles au niveau des données : un modèle trompé ne peut pas accéder à ce qu’il n’a jamais été autorisé à toucher.
Les contrôles d’accès basés sur les attributs et la journalisation inviolable de chaque requête IA transforment un modèle manipulé en modèle contenu. C’est le moteur de règles — et non le bon comportement du modèle — qui tranche. Seules 43 % des organisations disposent d’une passerelle centralisée de données IA selon les Prévisions Kiteworks 2026 — les 57 % restantes n’ont aucun point de contrôle qui résiste à un modèle compromis.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Que s’est-il réellement passé : un contournement de bac à sable associé à une injection de prompt
Oublions les noms de produits : le principe est simple. Un outil de codage IA s’exécute dans un bac à sable — une frontière censée l’empêcher d’aller au-delà de sa mission. Les chercheurs ont trouvé comment franchir cette frontière. Ce qui rend ce cas préoccupant, c’est la deuxième partie : il pouvait être combiné à une injection de prompt.
L’injection de prompt consiste à dissimuler des instructions malveillantes dans un contenu que l’IA va lire — un commentaire de code, un fichier, une page web, un ticket support — pour que le modèle traite une entrée hostile comme une commande légitime. Enchaînez une injection de prompt à un contournement de bac à sable et vous obtenez un scénario complet : l’instruction malveillante entre, la frontière censée stopper l’action saute, et les données sortent par un canal qui ressemble à un trafic normal d’outil. Aucun élément n’est exotique. Les dégâts viennent de la fluidité de la chaîne.
Le fournisseur a corrigé — très bien. Mais regardez la nature de la correction : une réparation de la frontière qui avait cédé. La défense et la vulnérabilité coexistaient au même endroit. Quand ce point lâche, il n’y a pas de deuxième ligne. C’est ce schéma qu’il faut généraliser, car il ne concerne pas un seul outil ou fournisseur.
La couche où vivent les garde-fous est celle qui cède sans cesse
La plupart des protections IA actuelles sont construites au niveau du modèle : prompts système, règles comportementales, filtres de contenu, frontières de bac à sable. C’est utile. Mais, en tant que catégorie, elles sont contournables — et pas de façon exceptionnelle. Une étude sur près de 15 000 assistants IA personnalisés a montré que plus de 95 % manquaient de protections adéquates, 96,51 % étaient vulnérables à la manipulation par jeu de rôle et 92,20 % à la fuite de prompt système. Toutes les grandes plateformes qui ont déployé des défenses contre l’injection de prompt ont vu les chercheurs les contourner.
Il ne s’agit pas de pointer un fournisseur en particulier. C’est une propriété structurelle : contrôler le comportement à un niveau où il reste négociable. On peut convaincre un prompt de désobéir à ses instructions. Le rapport CrowdStrike 2026 Global Threat Report a documenté une augmentation de 89 % en un an de l’activité d’adversaires dopés à l’IA et a constaté que 82 % des détections étaient sans malware — les attaquants exploitent de plus en plus des accès légitimes plutôt que d’introduire des outils détectables. Un agent IA doté d’un accès large et non gouverné, c’est précisément l’accès légitime dont l’abus dépend.
La question devient évidente : quel contrôle ne se discute pas ? La réponse n’est pas un prompt plus malin. Elle doit résider là où la persuasion du modèle ne peut pas agir.
Gouvernez les données, pas le modèle
Déplacez l’application des règles du modèle vers la donnée elle-même. Le modèle peut être compromis, manipulé, remplacé. La règle sur qui peut accéder à une donnée réglementée n’a pas à résider dans le modèle. Elle peut vivre au point d’accès à la donnée — et s’appliquer quel que soit ce que le modèle a été trompé de demander.
Tous les cadres de conformité réglementent l’accès aux données. HIPAA, CMMC, RGPD, PCI DSS — ils imposent que l’accès soit autorisé, que la donnée soit chiffrée, que l’interaction soit journalisée, et que l’on puisse le prouver a posteriori. Un contrôle au niveau du modèle répond à la question : peut-on convaincre le modèle de mal se comporter ? Un contrôle au niveau des données répond à une question différente : peu importe ce que le modèle a tenté, cet accès précis est-il autorisé pour ce demandeur précis à cet instant ? La première question a reçu de multiples fois la réponse oui, par des chercheurs en quelques heures. La seconde ne dépend pas du jugement du modèle.
Seules 43 % des organisations disposent d’une passerelle centralisée de données IA, 60 % n’ont pas de détection d’anomalies spécifique à l’IA, 63 % ne peuvent pas limiter l’usage des agents à un objectif précis, et 60 % ne peuvent pas désactiver un agent malveillant selon les Prévisions Kiteworks 2026. L’appétit pour l’IA est universel. La capacité à la contenir ne l’est pas.
Pourquoi DLP, WAF et EDR ne détectent pas un agent compromis
La pile de sécurité de la plupart des organisations a été conçue pour surveiller les humains. Un agent IA ne se comporte pas comme un humain, et c’est précisément dans l’écart entre ces deux types de trafic qu’un agent compromis se cache. DLP a été paramétré pour détecter une personne qui envoie un tableur sur un compte personnel. Il ne réagit pas à un agent autorisé qui fait un appel API légitime. Les WAF inspectent le trafic entrant humain, pas les flux machine-à-machine d’un workflow agentique. L’EDR surveille les processus et binaires sur un appareil, pas le contenu sémantique d’une intégration autorisée.
En combinant ces angles morts : un outil IA compromis qui exfiltre des données ressemble, pour tous ces outils, à un outil IA qui fait simplement son travail. Il n’y a pas de malware, donc pas de déguisement. Le trafic est autorisé, authentifié, validé au niveau réseau. La seule vérité visible se trouve au niveau des données — l’enregistrement de ce qui a été effectivement demandé et restitué.
Un contrôle que le modèle ne peut pas discuter
Le serveur Kiteworks Secure MCP connecte les assistants IA au contenu d’entreprise via le Model Context Protocol, mais chaque requête est évaluée selon des contrôles d’accès basés sur les attributs avant tout retour de données. L’agent reçoit exactement le contexte nécessaire à sa mission, rien de plus. Si une injection de prompt pousse le modèle à demander quelque chose hors périmètre, c’est le moteur de règles — et non le bon comportement du modèle — qui refuse. La requête est authentifiée, liée à la personne qui a autorisé la tâche, évaluée selon la classification des données et l’identité de l’agent, et restituée uniquement sous chiffrement validé FIPS 140-3. Aucune de ces décisions ne demande au modèle de bien se comporter — elles s’appliquent, que le modèle soit fiable ou non.
Chaque requête, acceptée ou refusée, est inscrite dans un journal d’audit inviolable qui alimente directement la pile de surveillance de l’équipe sécurité. Plutôt que de demander à DLP ou au pare-feu de reconnaître des comportements d’agent qu’ils n’ont pas été conçus pour voir, l’enregistrement de chaque interaction agent-donnée existe déjà là où l’accès s’est produit — attribué, horodaté, envoyé au SIEM en temps réel. L’AI Data Gateway étend cela aux pipelines RAG. Le Réseau de données privé Kiteworks l’étend à la messagerie, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API — un moteur de règles, un journal d’audit consolidé.
Ce que les équipes qui déploient l’IA doivent faire dès maintenant
Première étape : recensez tous les accès IA. Cartographiez chaque assistant, copilote et agent pouvant lire ou déplacer du contenu d’entreprise — y compris ceux déployés sans en informer la sécurité. Impossible de gouverner un accès invisible.
Deuxième étape : déplacez l’application des règles au niveau des données. Considérez le modèle comme non fiable par défaut et placez la décision d’accès à un endroit inaccessible à un modèle manipulé. Seules 43 % des organisations disposent d’une passerelle centralisée de données IA selon les Prévisions Kiteworks 2026 — le point de contrôle où la décision d’accès survit à un modèle compromis.
Troisième étape : appliquez le principe du moindre privilège et limitez l’usage de chaque agent à un objectif précis. Aujourd’hui, 63 % des organisations ne peuvent pas limiter l’usage des agents — la plupart opèrent sans périmètre défini, libres de s’égarer dès qu’ils sont redirigés.
Quatrième étape : journalisez chaque interaction agent-donnée dans une trace inviolable. Attribuez la requête à la personne qui a autorisé l’agent et envoyez l’enregistrement au SIEM. Quand un auditeur demande ce qu’un agent a consulté, la réponse doit déjà exister.
Cinquième étape : bâtissez un contrôle de confinement déclenchable rapidement. 60 % des organisations ne peuvent pas désactiver un agent malveillant selon les Prévisions Kiteworks 2026. Pouvoir couper un agent en quelques secondes fait la différence entre un incident et une fuite. C’est une décision d’architecture, et c’est le seul élément de cette histoire qu’un attaquant ne peut pas contourner par la ruse.
Pour en savoir plus sur la protection du contenu sensible face aux workflows agentiques IA, réservez votre démo sans attendre !
Foire aux questions
L’injection de prompt consiste à dissimuler des instructions malveillantes dans un contenu lu par l’IA — fichier, commentaire de code ou page web — pour que le modèle traite une entrée hostile comme une commande légitime. Si elle est combinée à un contournement de bac à sable, l’IA peut accéder à des données ou les exfiltrer au-delà de son périmètre autorisé. Les études montrent que la grande majorité des assistants IA personnalisés sont vulnérables à ce type d’attaque.
Un bac à sable limite un outil IA à sa mission. Un contournement lui permet d’aller au-delà de cette frontière. Le risque s’accroît lorsqu’on l’associe à une injection de prompt : un attaquant peut à la fois pousser l’IA à mal se comporter et supprimer le contrôle qui aurait bloqué l’action — transformant une faille de confinement en voie d’exfiltration de données. C’est la chaîne rendue possible par la faille récemment corrigée.
Les garde-fous au niveau du modèle régulent le comportement là où il reste négociable — les attaquants trouvent donc sans cesse des entrées qui font déroger les modèles à leurs règles. 96,51 % des assistants IA personnalisés étaient vulnérables à la manipulation par jeu de rôle selon une étude sur 15 000 systèmes. 60 % des organisations n’ont pas de détection d’anomalies IA selon les Prévisions Kiteworks 2026. Quand ces garde-fous échouent, peu de choses prennent le relais — d’où l’importance des contrôles d’accès au niveau des données comme deuxième ligne essentielle.
La gouvernance au niveau des données impose les règles d’accès au moment où la donnée est récupérée — indépendamment du modèle ou du prompt. Chaque requête est authentifiée, évaluée selon une politique basée sur la classification des données et l’identité de l’agent, et journalisée. Seules 43 % des organisations disposent d’une passerelle centralisée de données IA selon les Prévisions Kiteworks 2026. Le Secure MCP Server et l’AI Data Gateway offrent ce point de contrôle.
En général, non. DLP, WAF et EDR inspectent le trafic et les mouvements de fichiers initiés par des humains — un agent IA autorisé qui effectue des appels API légitimes ne correspond pas à ces modèles. 60 % des organisations n’ont pas de détection d’anomalies IA selon les Prévisions Kiteworks 2026. La visibilité nécessite une journalisation inviolable au niveau des données, où chaque requête agent et son résultat sont capturés, quel que soit l’outil à l’origine de la demande.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée à l’ère de l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.