L’autorisation classique ne suffit plus face aux LLM

Les LLM présentent des risques de sécurité uniques que les méthodes d’autorisation traditionnelles ne peuvent pas traiter efficacement.

Nous sommes entrés dans une nouvelle phase du fonctionnement des logiciels. Les grands modèles de langage, ou LLM, ne se comportent pas comme les outils que nous avons construits dans le passé. Ils ne suivent pas des étapes strictes. Ils n’attendent pas des séquences de commandes fixes. Ils fonctionnent sur la base de l’intention, en prédisant ce que vous voulez et en agissant. Cela semble futuriste, et ça l’est, mais cela crée aussi un grand changement dans la façon dont nous devons penser la sécurité.

Traditionnellement, les systèmes sont construits autour de la vérification et de l’autorisation des utilisateurs selon des modalités prédéfinies. Une personne se connecte et le système vérifie ce qu’elle peut faire. Elle peut peut-être modifier des fichiers, ou simplement les lire. C’est prévisible et statique. Mais avec les LLM, ce modèle s’effondre. L’IA peut appeler les API de nouvelles manières. Elle peut extraire des données de sources inattendues. Elle décide de ce qu’elle doit faire à la volée. Résultat ? Vous ne pouvez plus deviner à l’avance ce qu’elle va faire. Et si elle fait une erreur, il n’y a pas d’humain dans la boucle pour la rattraper en temps réel.

Les chercheurs ont intégré des instructions cachées dans un courriel d’apparence simple. Microsoft 365 Copilotqui résume le contenu des courriels à l’aide de LLM, a suivi ces instructions cachées sans le moindre clic. Des données internes de l’entreprise ont été divulguées, non pas parce que quelqu’un a fait quelque chose de mal, mais parce que l’IA a fait exactement ce qu’elle pensait qu’on lui demandait de faire. Pas de filtres. Pas de barrières. Juste la conformité à la vitesse de la machine.

Ce niveau d’accès, combiné à l’imprévisibilité, transforme une IA utile en une menace interne parfaite. Elle peut se déplacer rapidement, accéder à tout et n’a aucun discernement. Les systèmes de sécurité traditionnels ne couvrent pas cela. Ils n’ont pas été conçus pour des logiciels qui improvisent.

Et c’est bien là le problème : les modèles de sécurité doivent évoluer. Rapidement. Si nous continuons à appliquer d’anciennes hypothèses à des systèmes aussi puissants, nous ne sommes pas seulement à la traîne, nous sommes exposés.

Les techniques existantes de garde-fou en matière d’IA offrent une protection partielle, mais ne sont pas complètes.

Beaucoup d’équipes s’adaptent déjà, rapidement. Elles ajoutent des garde-fous autour des LLM pour les empêcher de faire quelque chose d’imprudent. C’est un bon réflexe. Les développeurs créent des filtres d’entrée et de sortie et limitent l’accès aux outils. Ces mesures sont utiles. Mais ce ne sont pas des solutions complètes. Elles ne vont pas assez loin.

Les filtres d’entrée tels que Rebuff ou PromptGuard sont conçus pour détecter les requêtes suspectes avant qu’elles n’atteignent le modèle. Ils recherchent des schémas d’attaque connus, comme les invites de jailbreak, et les arrêtent. Le problème, c’est que les attaquants ne restent pas inactifs. Ils ne cessent de créer de nouvelles variantes, et les filtres ne peuvent détecter que ce qu’on leur a dit de chercher.

Les filtres de sortie, comme Guardrails AI ou NeMo Guardrails de NVIDIA, vérifient ce que le LLM est sur le point de dire et bloquent tout ce qui est inapproprié ou dangereux. Là encore, c’est utile. Mais lorsque le LLM a déjà accédé à des données confidentielles, le blocage de la sortie est trop tardif. La violation n’est pas évitée. Elle est juste cachée.

Certains outils, comme LangChain, suivent une autre voie. Ils limitent l’accès du LLM dès le départ, en ne lui donnant qu’un ensemble limité d’API ou d’outils à l’intérieur d’un environnement en bac à sable. C’est une bonne idée en matière de sécurité. Mais dans la plupart des systèmes du monde réel, les données ne sont pas uniformes. Vous ne pouvez pas vous contenter de restreindre le système au niveau de l’outil et supposer que tout le reste se mettra en place. Si vous ne vérifiez pas l’accès au niveau des données, vous vous exposez à des fuites, même à l’intérieur de votre petit bac à sable sécurisé.

C’est là toute la nuance. Ces outils sont des éléments utiles, mais ils reposent tous sur l’hypothèse que l’IA se comportera bien. C’est une base fragile pour construire la sécurité. Si nous voulons une véritable protection, en particulier à grande échelle, nous devons contrôler ce que l’IA peut voir et faire, jusqu’au niveau de l’utilisateur et de l’enregistrement, à chaque fois qu’elle agit.

Tel est le véritable défi de l’IA en matière de sécurité. Et pour le résoudre, il faut plus que des filtres ou des restrictions. Il faut traiter l’IA comme n’importe quel utilisateur, avec des contrôles d’autorisation exécutoires et en temps réel, intégrés à chaque étape.

L’autorisation en temps réel et à granularité fine, intégrée à la couche d’accès aux données, constitue une solution viable.

Résoudre sécurité de l’IA ne se résume pas à des correctifs marginaux. Il faut cibler le cœur du flux de travail, là où les données sont demandées et les actions déclenchées. C’est là que l’autorisation fine et en temps réel est importante. Il s’agit de passer de mesures réactives à un contrôle réel.

Oso est un système qui fonctionne bien à l’heure actuelle. Il ne traite pas les MLD différemment des humains en termes d’accès. Si vos droits sont limités en tant qu’utilisateur, l’IA qui travaille en votre nom voit ces mêmes limites. Que le modèle effectue une recherche vectorielle dans une base de données ou qu’il appelle une API pour obtenir des enregistrements internes, chaque requête passe par le même cadre de permissions. Les règles sont définies avec intention et cohérence, jusqu’à l’utilisateur, la ressource ou l’action spécifique.

Techniquement, l’infrastructure de politique est écrite en Polar et s’intègre directement dans des outils de backend familiers comme SQLAlchemy de Python. Cela signifie que vous écrivez la règle d’accès, quelque chose comme « seuls les responsables voient les dossiers du département » ou « les utilisateurs ne voient que leurs propres tickets » – et à partir de là, Oso insère ces restrictions dans chaque recherche ou requête. Cela change la donne. Désormais, le LLM ne voit jamais les mauvaises données. Il n’y a rien à fuir, car les informations non autorisées n’ont jamais été exposées en premier lieu.

Cette approche a déjà été mise en œuvre par des entreprises telles que Duolingo, Intercom et PagerDuty. Ce n’est pas de la théorie. Elle est déjà en production dans des produits à grande échelle pilotés par l’IA.

Traiter les agents d’IA comme n’importe quel autre utilisateur nous permet d’appliquer aux machines des décennies de leçons de sécurité durement acquises dans le cadre du contrôle d’accès humain. Il en résulte une application fiable et évolutive qui ne repose pas sur l’espoir que l’IA prenne la bonne décision. Elle réduit les risques tout en permettant au système de fonctionner à pleine capacité, sans être limité par des barrières inutiles, juste lié par les règles qui assurent la sécurité des données. C’est la voie à suivre.

L’intégration de la sécurité au cœur des systèmes d’IA est essentielle pour prévenir les violations et soutenir l’innovation.

L’IA évolue rapidement, plus rapidement que ce que la plupart des systèmes de sécurité ont été conçus pour gérer. Mais cette rapidité ne justifie pas que l’on prenne des raccourcis. La sécurité doit faire partie de la structure fondamentale dès le premier jour. Si elle est ajoutée plus tard, vous ne sécurisez pas le système, vous corrigez les défaillances une fois que les dégâts sont déjà faits.

Lorsque la sécurité est directement intégrée au cœur du système d’IA, quelque chose s’ouvre : la confiance. L’organisation peut aller de l’avant en toute confiance, sans hésitation. Les équipes peuvent créer et déployer des produits d’IA innovants tout en sachant que les contrôles d’autorisation, la segmentation des données et le blocage des actions fonctionnent automatiquement. Ce type de configuration est particulièrement critique dans les environnements d’entreprise où les informations sont très sensibles entre les équipes, les zones géographiques et les frontières des clients.

Dans des cas d’utilisation tels que génération augmentée par la recherche (RAG)où les LLM font référence à des documents internes pour créer des réponses éclairées, vous ne pouvez pas vous permettre de laisser le modèle produire des résultats qu’un utilisateur ne devrait pas voir. En appliquant des règles au point de récupération du vecteur ou de la requête SQL, les plateformes comme Oso s’assurent que les LLM n’ont accès qu’au contenu autorisé avant même de commencer à générer des réponses.

Il ne s’agit pas de restreindre l’innovation. Bien au contraire. C’est ce qui la rend possible. Le coût d’une erreur dans le contrôle d’accès piloté par l’IA est bien trop élevé pour être laissé au hasard. Une seule fuite peut nuire à la réputation, entraîner des retombées juridiques ou des revers opérationnels massifs. Mais lorsque la sécurité fait partie intégrante de l’infrastructure, les équipes progressent plus rapidement et courent moins de risques.

Pour les dirigeants, la priorité est claire : croissance et rapidité sans compromis. C’est tout à fait possible, mais uniquement lorsque la sécurité est conçue pour fonctionner à la même échelle et au même rythme que les systèmes d’IA qu’elle protège. Nous savons aujourd’hui comment y parvenir. Ce n’est plus une option.

Un écosystème de sécurité collaboratif est essentiel pour atténuer efficacement les menaces liées à l’IA.

Il n’existe pas d’outil unique pour résoudre le problème de la sécurité de l’IA. Le paysage est trop dynamique et les risques sont trop vastes. C’est pourquoi il est contre-productif de penser en termes de solutions isolées. Ce qui fonctionne, c’est une approche composite, la construction d’une architecture de sécurité où les systèmes se renforcent les uns les autres, chacun traitant différentes parties du problème.

Vous disposez d’outils tels qu’Oso, qui fournissent en temps réel une autorisation fine liée à des utilisateurs et à des données spécifiques. Vous avez LangChain qui limite l’accès aux outils d’IA, en veillant à ce que les LLM ne puissent interagir qu’avec des API et des actions approuvées. Il existe également des bibliothèques de garde-fous qui surveillent les entrées et les sorties, fournissant une couche supplémentaire de filtrage contre les abus ou les manipulations. Chacune joue un rôle essentiel, mais aucune n’est complète si elle est isolée.

Ce qui importe pour les dirigeants, c’est de comprendre comment ces éléments s’imbriquent les uns dans les autres. Un écosystème bien conçu ne se contente pas de bloquer les défaillances de sécurité évidentes, il anticipe la nature imprévisible des agents d’intelligence artificielle et répartit les responsabilités entre plusieurs couches. Si un filtre d’entrée manque un vecteur d’attaque, l’application des autorisations sur la couche de données peut neutraliser l’impact. Si la surveillance des sorties signale quelque chose d’inhabituel, les systèmes de journalisation peuvent enregistrer le comportement pour l’examiner. Ces systèmes ne se chevauchent pas, ils se coordonnent.

Les dirigeants doivent s’attendre à ce que leurs équipes chargées de l’infrastructure de l’IA mettent en place ce type d’architecture en couches. Il s’agit d’une attente minimale pour toute entreprise déployant des LLM en production. Toutes les menaces ne sont pas prévisibles, mais lorsque votre stratégie de défense est modulaire et redondante, vous réduisez le rayon d’action de tout ce qui passe au travers d’un segment. Il s’agit là d’une résilience pratique et réalisable.

La sécurité ne consiste pas seulement à empêcher les menaces d’entrer. Il s’agit de garder le contrôle sur ce que les systèmes peuvent voir, faire et produire, quelle que soit la complexité ou l’autonomie des agents qui les exploitent. Et le seul moyen réaliste d’y parvenir avec les LLM est de tirer parti d’un écosystème connecté d’outils spécialisés, chacun appliquant une couche spécifique de gouvernance en temps réel. C’est la stratégie qui s’adapte.

Principaux enseignements pour les dirigeants

• Les LLM nécessitent un nouveau modèle de sécurité : Les agents d’IA agissent de manière autonome et interprètent l’intention, rompant ainsi avec les cadres d’autorisation traditionnels. Les dirigeants devraient donner la priorité aux systèmes qui valident les actions de manière dynamique, et pas seulement à ceux qui authentifient les utilisateurs de manière statique.
• Les garde-fous ne sont pas suffisants : les filtres d’entrée, les moniteurs de sortie et les contraintes d’outils offrent une couverture partielle mais dépendent toujours du comportement attendu des LLM. Les entreprises doivent éviter de s’appuyer sur ces éléments comme défenses autonomes.
• Il est essentiel de disposer d’autorisations fines en temps réel : L’application de permissions spécifiques aux utilisateurs et aux données au niveau de la requête ou de l’action garantit que les LLM ne peuvent pas accéder à des contenus non autorisés ou les exposer. Les décideurs doivent intégrer des solutions qui appliquent des politiques automatiquement au moment de l’exécution.
• La sécurité doit être intégrée dans la conception de l’IA : La mise en place d’un contrôle d’accès après le déploiement est très risquée. Pour permettre l’innovation sans compromis, les dirigeants doivent exiger que la logique d’autorisation soit intégrée dès le départ dans les flux de travail de l’IA.
• La défense nécessite un écosystème à plusieurs niveaux : Aucun outil ne peut à lui seul sécuriser les systèmes d’IA de manière fiable. Les dirigeants doivent mettre en œuvre une stratégie coordonnée impliquant des moteurs d’autorisation, des limiteurs d’outils et des garde-fous comportementaux pour réduire les risques à chaque niveau.