L’authorization dans les applications LLM

• Les grands modèles de langage (LLM) sont des systèmes imprévisibles qui traitent des entrées humaines incertaines, ce qui rend indispensable l’application du principe du moindre privilège (least privilege)
• Comme les LLM sont en pratique utilisés pour diverses tâches comme la recherche interne et l’automatisation, ils doivent fonctionner uniquement avec des « permissions effectives » minimales afin d’éviter les incidents de sécurité et les usages abusifs
• Dans une architecture RAG (Retrieval-Augmented Generation), les embeddings de données et les vérifications d’autorisation sont séparés des sources de données, ce qui exige un contrôle d’accès granulaire au niveau des ressources
• À mesure que les usages complexes se multiplient — données/RAG externes (3rd party), agents, MCP, etc. —, l’endroit et la manière dont les permissions sont effectivement appliquées deviennent un enjeu central de sécurité
• L’authentification par jetons comme OAuth a des limites pour le contrôle fin des permissions au niveau des ressources ; la logique d’autorisation réelle doit donc être implémentée directement dans la couche applicative

---

Terminologie et concepts de base

• Prompt : requête de l’utilisateur transmise au LLM (instruction, question, etc.)
• RAG (Retrieval-Augmented Generation) : workflow qui ajoute des données au prompt pour améliorer la précision de la réponse du LLM (ex. : joindre automatiquement la liste des congés de l’entreprise)
• Context : données auxiliaires jointes au prompt (documents pertinents retrouvés, etc.)
• Embedding : représentation vectorielle numérisée d’un texte, utilisée pour la recherche et le matching de données
• Agent : moteur d’exécution basé sur un LLM qui effectue des actions selon le prompt (appel automatique d’outils, etc.)
• Tool : fonction externe qu’un LLM peut appeler directement, comme une API ou une application
• Model Context Protocol (MCP) : protocole standard proposé par Anthropic pour l’accès des LLM aux outils

Principes clés du modèle d’autorisation des LLM

• Golden Rule :
  > Un LLM ne doit fonctionner qu’avec les privilèges minimaux strictement nécessaires pour traiter la demande de l’utilisateur
• Chez les utilisateurs humains, un certain « excès de privilèges par habitude » peut être toléré, mais un LLM est imprévisible, rapide et peut causer des dégâts à grande échelle en cas d’erreur.
  → Les « permissions effectives » du LLM doivent donc être limitées à l’intersection des permissions de l’utilisateur, du LLM et de la tâche

Calcul des permissions effectives

• Permissions effectives d’une application LLM =
  1. permissions du LLM
  2. permissions de l’utilisateur
  3. permissions nécessaires à la tâche demandée
     intersection de ces trois éléments
• L’utilisateur « délègue » son rôle au LLM (chatbot, etc.) par impersonation,
  mais le LLM ne doit jamais dépasser le périmètre des permissions de l’utilisateur comme du LLM lui-même
• Explication intuitive via un diagramme de Venn des permissions
  • exécution autorisée uniquement lorsque les permissions requises par la tâche sont entièrement incluses dans l’intersection

RAG (Retrieval-Augmented Generation) et traitement des autorisations

1. RAG sur données 1st Party (internes)

• Exemple : un chatbot interne qui retrouve dans le code source de l’entreprise les « fichiers contenant des clés secrètes »
• Embedding : tous les fichiers sont transformés en vecteurs et stockés en base de données ; le prompt est lui aussi vectorisé pour un matching par similarité
• Lieu d’application des permissions :
  • vérifier immédiatement l’organisation propriétaire réelle du « fichier » retourné comme résultat de recherche, son type, son dépôt et les permissions de l’utilisateur
  • vérifier si l’utilisateur peut accéder à ce fichier (permissions au niveau ressource)
  • effectuer le contrôle d’autorisation dans la couche applicative lors de la liaison entre embedding et données sources
• Intégrer la logique de permissions directement dans le LLM lui-même est peu fiable (impossible à garantir en raison de sa nature probabiliste)
• En résumé :
  • le cœur du RAG consiste à appliquer fermement des permissions par utilisateur et par ressource après la liaison entre embeddings et données d’origine

2. RAG sur données 3rd Party (externes)

• Utilisation de données provenant d’API ou de systèmes externes (ex. : wiki, système de tickets, etc.) après embedding
• Problème : les embeddings et les données sources résident dans des systèmes différents → le lieu d’application des permissions devient flou
• Trois méthodes de traitement des permissions
  1. Déléguer les permissions au système externe (vérification réelle des permissions à chaque appel API unitaire, avec réponse lente et problèmes de rate limit)
  2. Synchroniser les ACL (listes de contrôle d’accès) dans l’application (bonne précision et fiabilité, mais coût accru de gestion/synchronisation des ACL)
  3. Réimplémenter en interne la logique d’autorisation externe elle-même (charge de gestion/synchronisation et complexité logique accrues)
• Conclusion : selon le contexte réel, le choix du lieu d’application des permissions et de la méthode implique des trade-offs importants
  (performance vs simplicité, coût de gestion vs précision, etc.)

LLM orientés agents (AI Agent) et autorisations

• Exemple : un chatbot qui automatise des tâches de maintenance comme la suppression de branches de dépôt ou la fermeture d’issues
• Avec MCP (Model Context Protocol), les tools (fonctions/API) sont exposés au LLM de manière standardisée
• Le modèle de permissions effectives doit être appliqué à chaque requête MCP
  (intersection des permissions de l’utilisateur, de l’agent et de la tâche)
• Limites de l’authentification par jetons comme OAuth
  • les informations de permissions sont incluses dans le jeton, mais ne couvrent pas les permissions temps réel au niveau des actifs/ressources
  • en pratique, seules certaines informations sont placées dans le jeton, et le reste exige une logique d’autorisation séparée dans la couche applicative

Conclusion et résumé pratique

• Dans les environnements LLM/RAG/Agent, le cœur de la gestion des autorisations est le choix du lieu et de la manière d’appliquer les permissions

• Avec le modèle de permissions effectives, il faut limiter le LLM à un fonctionnement strictement contenu dans l’intersection « utilisateur + LLM + tâche »

• Les jetons d’authentification comme OAuth ne doivent servir qu’à identifier « qui a fait la requête »,
  la vérification réelle des permissions par ressource devant impérativement être effectuée dans l’application

• Lors de l’intégration à des systèmes externes,
  il faut concevoir en prenant en compte divers trade-offs : 1) délégation des permissions (baisse de performance), 2) synchronisation des ACL (complexité opérationnelle), 3) réimplémentation de la logique d’autorisation (maintenance élevée)

• Résumé final :
  > Un LLM ne doit fonctionner que dans le cadre des privilèges minimaux strictement nécessaires au traitement de la demande utilisateur,
  > et les permissions effectives doivent être définies comme l’intersection des permissions du LLM, de l’utilisateur et de la tâche
  > La vérification réelle des autorisations doit impérativement être réalisée au niveau des ressources, dans la couche applicative