Alors que les copilotes et assistants IA sont intégrés au travail quotidien, les équipes de sécurité se concentrent toujours sur la protection des modèles eux-mêmes. Mais des incidents récents suggèrent que le plus grand risque réside ailleurs : dans les flux de travail entourant ces modèles.
Deux extensions Chrome se faisant passer pour des assistants d'IA ont récemment été découvertes en train de voler les données de chat ChatGPT et DeepSeek de plus de 900 000 utilisateurs. Par ailleurs, les chercheurs ont démontré comment des injections rapides cachées dans les référentiels de code pouvaient inciter l'assistant de codage IA d'IBM à exécuter des logiciels malveillants sur la machine d'un développeur.
Aucune des attaques n'a brisé les algorithmes de l'IA eux-mêmes.
Ils ont exploité le contexte dans lequel l’IA opère. C’est le modèle auquel il convient de prêter attention. Lorsque les systèmes d’IA sont intégrés dans des processus métier réels, résumant des documents, rédigeant des e-mails et extrayant des données à partir d’outils internes, la sécurisation du modèle à elle seule ne suffit pas. Le flux de travail lui-même devient l'objectif.
Les modèles d'IA deviennent des moteurs de workflow
Pour comprendre pourquoi cela est important, réfléchissez à la manière dont l’IA est réellement utilisée aujourd’hui :
Les entreprises s'en servent désormais pour connecter des applications et automatiser des tâches qui étaient auparavant effectuées manuellement. Un assistant de rédaction IA pourrait extraire un document confidentiel de SharePoint et le résumer dans un brouillon d'e-mail. Un chatbot commercial pourrait croiser les enregistrements CRM internes pour répondre à la question d'un client. Chacun de ces scénarios brouille les frontières entre les applications, créant ainsi de nouvelles voies d'intégration à la volée.
Ce qui rend cela risqué, c’est la façon dont fonctionnent les agents d’IA. Ils s'appuient sur une prise de décision probabiliste plutôt que sur des règles codées en dur, générant des résultats basés sur des modèles et un contexte. Une entrée soigneusement écrite peut pousser une IA à faire quelque chose que ses concepteurs n'ont jamais prévu, et l'IA s'y conformera car elle n'a pas de concept natif de limites de confiance.
Cela signifie que la surface d’attaque inclut chaque entrée, sortie et point d’intégration touché par le modèle.
Le piratage du code du modèle devient inutile lorsqu'un adversaire peut simplement manipuler le contexte vu par le modèle ou les canaux qu'il utilise. Les incidents décrits ci-dessus illustrent cela : des injections rapides cachées dans les référentiels détournent le comportement de l'IA lors de tâches de routine, tandis que des extensions malveillantes extraient les données des conversations d'IA sans même toucher au modèle.
Pourquoi les contrôles de sécurité traditionnels ne suffisent pas
Ces menaces liées aux flux de travail révèlent un angle mort de la sécurité traditionnelle. La plupart des défenses existantes ont été conçues pour des logiciels déterministes, des rôles d'utilisateur stables et des périmètres clairs. Les flux de travail basés sur l’IA brisent ces trois hypothèses.
- La plupart des applications générales font la distinction entre le code fiable et les entrées non fiables. Les modèles d’IA ne le font pas. Pour eux, tout n’est que texte, donc une instruction malveillante cachée dans un PDF n’est pas différente d’une commande légitime. La validation traditionnelle des entrées n'aide pas car la charge utile n'est pas un code malveillant. C'est juste du langage naturel.
- La surveillance traditionnelle détecte les anomalies évidentes telles que les téléchargements massifs ou les connexions suspectes. Mais une IA lisant un millier d’enregistrements dans le cadre d’une requête de routine ressemble à un trafic normal de service à service. Si ces données sont résumées et envoyées à un attaquant, techniquement, aucune règle n’est enfreinte.
- La plupart des politiques de sécurité générales précisent ce qui est autorisé ou bloqué : ne pas autoriser cet utilisateur à accéder à ce fichier, bloquer le trafic vers ce serveur. Mais le comportement de l’IA dépend du contexte. Comment rédiger une règle qui dit « ne jamais révéler les données client dans la sortie » ?
- Les programmes de sécurité sont basés sur des examens périodiques et des configurations fixes, telles que des audits trimestriels ou des règles de pare-feu. Les flux de travail de l’IA ne restent pas statiques. Une intégration peut acquérir de nouvelles fonctionnalités après une mise à jour ou se connecter à une nouvelle source de données. Au moment où un examen trimestriel est effectué, un jeton a peut-être déjà été divulgué.
Protégez les flux de travail basés sur l'IA
Une meilleure approche de tout cela serait donc de traiter l’ensemble du flux de travail comme ce qui est protégé, et pas seulement le modèle.
- Commencez par comprendre où l’IA est réellement utilisée, depuis les outils officiels comme Microsoft 365 Copilot jusqu’aux extensions de navigateur que les employés peuvent avoir installés eux-mêmes. Sachez à quelles données chaque système peut accéder et quelles actions il peut entreprendre. De nombreuses organisations sont surprises de trouver des dizaines de Services Shadow AI exécutés dans toute l’entreprise.
- Si un assistant IA est destiné uniquement aux résumés internes, empêchez-le d'envoyer des e-mails externes. Analysez les sorties à la recherche de données sensibles avant qu'elles ne quittent votre environnement. Ces garde-corps doivent se trouver en dehors du modèle lui-même, dans un middleware qui vérifie les actions avant leur sortie.
- Traitez les agents IA comme n’importe quel autre utilisateur ou service. Si une IA n’a besoin que d’un accès en lecture à un système, ne lui donnez pas un accès général à tout. Limitez les jetons OAuth aux autorisations minimales requises et surveillez les anomalies, telles qu'une IA accédant soudainement à des données qu'elle n'a jamais touchées auparavant.
- Enfin, il est également utile pour informer les utilisateurs sur les risques liés aux extensions de navigateur non vérifiées ou à la copie de messages provenant de sources inconnues. Examinez les plugins tiers avant de les déployer et traitez tous les outils qui touchent les entrées ou les sorties de l'IA comme faisant partie du périmètre de sécurité.
Comment des plateformes comme Reco peuvent vous aider
En pratique, faire tout cela manuellement n’est pas évolutif. C'est pourquoi une nouvelle catégorie d'outils émerge : les plateformes de sécurité SaaS dynamiques. Ces plates-formes agissent comme une couche de protection en temps réel sur les flux de travail basés sur l'IA, apprenant à quoi ressemble un comportement normal et signalant les anomalies lorsqu'elles se produisent.
Reco en est un exemple frappant.
 |
| Figure 1 : Découverte d'applications d'IA générative Reco |
Comme indiqué ci-dessus, la plateforme donne aux équipes de sécurité une visibilité sur l'utilisation de l'IA dans l'ensemble de l'organisation, en montrant quelles applications d'IA générative sont utilisées et comment elles sont connectées. À partir de là, vous pouvez appliquer des garde-fous au niveau du flux de travail, détecter les comportements à risque en temps réel et garder le contrôle sans ralentir l’activité.
Demander une démo – Commencez avec Reco.
