Dans de nombreuses organisations, les employés utilisent déjà l’intelligence artificielle pour automatiser, coordonner et optimiser des tâches complexes. Une partie de ces usages passe par des outils validés par l’IT. Mais une autre partie s’appuie sur des comptes personnels et des extensions de navigateur que personne en sécurité n’a évalués.
Longtemps, le réflexe a consisté à « repérer puis fermer la porte » : identifier les applications utilisées avec un CASB, compléter avec des règles DLP et suivre les usages. Cette approche a fait ses preuves pour limiter le « SaaS sprawl ». Pourtant, dès qu’on parle d’IA, le risque ne se présente plus de la même façon. C’est précisément là que la sécurité IA interaction change la donne.
Pourquoi le modèle CASB/DLP suffit moins pour l’IA
Avec le SaaS classique, le risque est souvent rattaché à un périmètre clair : une application, un fichier ou un champ de données structuré. On peut alors appliquer des contrôles qui inspectent ce qui circule et décider d’autoriser ou non l’accès.
Avec l’IA, la mécanique est différente. Le risque apparaît dans la conversation : dans le prompt, dans la réponse produite par le modèle, et parfois dans les actions menées par des agents autonomes à partir d’une consigne malveillante.
Or, ni CASB ni DLP n’ont été conçus pour évaluer finement la signification d’un échange IA. CASB examine surtout l’autorisation d’accéder à une application (y compris un outil d’IA) et, dans de nombreux cas, les actions possibles à l’intérieur. Mais l’IA ajoute une couche que ces contrôles ne sondent pas assez : le contexte sémantique et l’intention derrière l’échange.
Le vrai danger : le contenu n’est pas seulement ce qu’il ressemble
Un prompt peut sembler inoffensif au premier coup d’œil. Pourtant, si l’on creuse la formulation, le contexte et la finalité de la demande, le niveau de risque peut augmenter fortement. Avec l’IA, les fuites ne passent pas toujours par un collage évident de données sensibles (numéro de compte, clé API, etc.).
Parfois, les informations sont divulguées indirectement : elles sont décrites autrement, mais restent suffisamment claires pour que le modèle reconstitue ce qui compte. L’impact business est alors réel, même si rien ne correspond à un motif DLP connu.
Quelques exemples typiques :
- Partager des éléments autour d’un contrat fournisseur en cours de finalisation, alors même que la structure des données ne déclenche pas une règle DLP.
- Résumer un incident technique, ce qui peut révéler des informations confidentielles sur des délais, des causes ou des impacts, sans que cela ressemble à une « donnée sensible » cataloguée.
Dans ces situations, le système peut « laisser passer » l’application, car l’accès est autorisé, mais le risque naît plus tard : dans la manière dont l’utilisateur formule ses demandes et dans ce que l’IA produit ou fait ensuite.
Le dilemme des équipes sécurité : resserrer ou laisser filer
Les équipes sécurité se retrouvent coincées entre deux risques opérationnels.
- Si l’on serre trop (contrôles CASB renforcés), les utilisateurs peuvent se tourner vers des outils non gérés, hors visibilité. Résultat : davantage d’« IA fantôme » que personne ne peut surveiller.
- Si l’on assouplit trop (DLP trop permissif), des données sensibles peuvent fuiter. Les contrôles laissent alors les portes ouvertes à des exportations involontaires, des restitutions ou des envois vers des destinations non désirées.
Au lieu d’opposer CASB et DLP, le point clé est de comprendre que l’IA déplace le lieu du risque : le danger se matérialise pendant l’interaction entre la personne et le modèle.
Inspecter l’interaction : là où le risque se produit vraiment
Une stratégie robuste doit faire fonctionner les contrôles au bon endroit : dans l’échange. Concrètement, il faut examiner :
- ce qui est demandé (le prompt) ;
- ce que le modèle génère en réponse ;
- les outils qu’un agent invoque, le cas échéant ;
- les données récupérées ou transmises ;
- et surtout, si les actions qui en résultent sont autorisées.
Autrement dit, il ne s’agit plus uniquement de trancher la question « l’utilisateur peut-il ouvrir l’outil ? ». Pour une sécurité IA interaction, la décision doit aussi porter sur la sécurité du prompt, la sécurité de la réponse et la légitimité de l’action déclenchée.
Pourquoi des cas concrets valident cette approche
Plusieurs scénarios montrent que cette distinction est essentielle :
- Utiliser l’IA pour proposer une structure d’article classique est une utilisation courante. En revanche, l’utiliser pour écrire un argumentaire marketing incluant la référence à un produit non annoncé peut exposer des informations sensibles.
- Pour un développeur, répondre à une question générale présente généralement peu de risque. Mais dès que la demande contient une logique interne propriétaire, surtout si elle est reliée à un problème réel d’un client, la situation change. Qu’il s’agisse d’informations fournies ou générées, on n’est plus dans un usage « sûr ».
- Dans des workflows agentiques, le fait que l’agent récupère une base de connaissances approuvée peut être acceptable. Mais transférer à l’extérieur une documentation interne restreinte constitue un risque majeur.
- Résumer un document déjà public reste relativement faible. Pourtant, reconstituer une information confidentielle à partir d’un contexte partiel peut devenir dangereux.
- Traiter le contenu récupéré comme de simples données est attendu. Cependant, si des instructions sont dissimulées au sein de ce contenu et que l’agent les suit, on introduit un risque sérieux de prompt injection, que le modèle ne peut pas toujours distinguer de façon fiable entre « données » et « consignes ».
- Authentifier un agent ou une session est un bon point de départ, mais ce n’est pas suffisant : une demande initialement anodine peut se transformer en action à haut risque. Cela appelle une logique capable de détecter l’anomalie et d’ajuster l’autorisation.
Étendre la gouvernance au lieu de bloquer par défaut
Bloquer l’accès « par défaut » semble protecteur sur le papier. Mais dans la durée, le besoin de productivité prend le dessus : les employés contournent les restrictions en utilisant des comptes personnels ou des extensions non gérées. La visibilité se dégrade, et l’organisation perd la maîtrise.
Réduire le risque lié à l’IA n’est donc pas une guerre entre CASB, DLP et analyse d’interaction. Ces briques doivent couvrir des couches différentes d’un même problème.
Une approche cohérente combine plusieurs objectifs :
- Traiter dès maintenant les risques de prompt injection et de mésusage d’agents comme des sujets quotidiens, pas comme des cas marginaux à traiter plus tard.
- Utiliser CASB et DLP pour découvrir les applications SaaS et IA réellement utilisées, gouverner l’accès, détecter des motifs sensibles connus et soutenir la conformité.
- Ajouter une couche d’analyse d’interaction qui approfondit la sémantique du prompt, évalue la nature sensible de la réponse et vérifie si l’action de l’agent est autorisée.
- Permettre l’adoption : l’objectif n’est pas de verrouiller l’IA « jusqu’à ce qu’elle soit sûre », mais de donner aux équipes de quoi expérimenter tout en gardant les données sensibles, la propriété intellectuelle et le comportement des agents dans des limites claires.
Construire la bonne question de sécurité
La question « est-ce que cette personne peut ouvrir l’outil ? » n’est plus suffisante pour un contexte IA. La bonne approche consiste à se demander :
- ce que l’utilisateur demande réellement (et pourquoi) ;
- si la réponse peut exposer des informations sensibles ;
- et si l’action déclenchée par un agent est autorisée selon la politique de l’organisation.
En bâtissant votre stratégie autour de ces réponses, vous facilitez l’usage productif de l’IA par les employés tout en réduisant le risque de fuite de données et d’exécution non souhaitée.
Conclusion
Les contrôles CASB et DLP restent utiles pour encadrer l’accès aux applications, découvrir les usages et repérer des patterns connus. Mais l’IA introduit un déplacement du risque : il surgit dans la conversation, dans la réponse et dans les actions d’agents potentiellement affectées par une consigne malveillante.
Pour une sécurité IA interaction efficace, il faut donc compléter la gouvernance existante par une inspection centrée sur l’échange : analyse du prompt, évaluation de la réponse, vérification des actions et contrôle de l’autorisation. C’est la manière la plus réaliste d’allier adoption de l’IA et protection des données sensibles.
