Chapitre 12 — Contrôle d'accès et identité

Douzième billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui répond à la question compositionnelle — qui a le droit d'invoquer quelle capacité d'une application intégrant un LLM, et comment l'application est structurée à travers les composants du système.

Pourquoi ce chapitre existe

Les disciplines traditionnelles de contrôle d'accès s'appliquent toutes aux systèmes LLM : authentifier le principal, autoriser ses requêtes contre la politique, isoler les locataires, borner la consommation par principal, exposer des surcouches de gouvernance d'entreprise. Les mécanismes sont ceux que le domaine utilise depuis des décennies — OAuth 2.0, mTLS, RBAC, ABAC, seaux de jetons, SAML, SCIM. Ce qui est nouveau, c'est que l'appel au modèle lui-même peut devenir un principal — un agent agissant au nom d'un utilisateur porte sa propre identité et ses propres permissions — et que la configuration par locataire du comportement du modèle est une fonctionnalité produit de premier ordre pour les plateformes LLM multi-locataires.

12.1 Authentification et autorisation se transposent, avec ajouts

L'authentification vérifie les identifiants. Les clés API sont le mécanisme le plus simple — une chaîne à haute entropie remise au principal au provisioning, hachée en base d'identifiants, présentée dans un en-tête à chaque requête. Elles sont faciles à implémenter et à utiliser, et faciles à fuiter par les journaux, la sortie CI et les dépôts commit. Les jetons porteurs OAuth 2.0 améliorent la situation avec des jetons courts et une restriction de portée ; le brouillon OAuth 2.1 consolide les meilleures pratiques de sécurité de la dernière décennie. mTLS ajoute l'authentification mutuelle pour les appels machine-à-machine, particulièrement utile pour les services LLM internes. L'autorisation demande ce que le principal authentifié a le droit de faire. RBAC — rôles, permissions, attributions — fonctionne quand la population se divise en groupes stables. ABAC — contrôle d'accès à base d'attributs — évalue des prédicats sur les attributs du principal, de la ressource et du contexte et gère les cas que RBAC ne gère pas : permissions qui dépendent du propriétaire de la ressource, de l'heure ou de la localisation de la requête, ou de relations dans le système. Les deux ne sont pas mutuellement exclusifs ; les systèmes de production les superposent souvent, avec RBAC pour l'accès à gros grain et ABAC pour les conditions spécifiques. Les moteurs de politique du chapitre 10 — OPA, Cedar — sont la manière dont ABAC devient maintenable à l'échelle.

12.2 L'isolation multi-locataire est une question de défense en profondeur

Un système multi-locataire sert plusieurs clients depuis un unique déploiement. L'exigence d'isolation est qu'aucun locataire ne puisse voir les données, requêtes ou interactions modèle d'un autre locataire sous quelque mode de défaillance que ce soit. Trois approches architecturales s'inscrivent sur un spectre. L'isolation au niveau base — base de données séparée par locataire — est la plus forte mais la plus coûteuse à opérer. L'isolation au niveau schéma — schéma PostgreSQL ou base MySQL séparé par locataire sur infrastructure partagée — est un juste milieu. L'isolation au niveau ligne — schéma partagé, ID de locataire sur chaque ligne, row-level security imposée par la base — est la moins chère mais exige un code applicatif discipliné. Pour les systèmes LLM, l'isolation s'étend au corpus de récupération (namespaces vector-database par locataire), à la logique de construction du prompt (pas de concaténation inter-locataire), au magasin de journaux (pas de lectures inter-locataire), et au modèle lui-même quand affiné sur des données spécifiques au locataire. Les limites de débit et quotas ajoutent l'axe consommation de ressources. Le token bucket permet des rafales courtes jusqu'à une capacité définie ; la fenêtre glissante impose un débit plus uniforme à coût de calcul plus élevé ; le leaky bucket lisse le débit aval. Pour les systèmes LLM, la dimension limite de débit s'élargit : requêtes par seconde, tokens par minute, coût par jour, invocations d'outil par heure, embeddings par seconde. Chaque dimension a sa propre justification économique et sécurité, et les niveaux entreprise discriminent typiquement sur plusieurs.

12.3 La gouvernance d'entreprise est la surcouche qui rend le système utilisable

Les clients entreprise ont des exigences de gouvernance au-delà de l'authentification et des limites de débit. Ils doivent savoir quels employés utilisent le système, sur quelles données, à quelles fins. Ils ont besoin de journaux d'audit suffisants pour la conformité interne et l'audit externe. Ils ont besoin de contrôles sur les modèles autorisés, les outils disponibles, les catégories de contenu permises. Ils ont besoin d'engagements de traitement des données — usage entraînement, chiffrement, résidence, rétention, suppression. Les fonctionnalités devenues standard reflètent ces exigences. L'authentification unique via SAML ou OpenID Connect fait du fournisseur d'identité de l'entreprise la source de vérité sur qui peut utiliser le système. Le provisioning SCIM propage les changements d'utilisateur automatiquement. L'export de journaux d'audit envoie la télémétrie du système LLM dans le SIEM d'entreprise. Les engagements de résidence des données garantissent que les données d'un locataire ne quittent pas une juridiction spécifiée. Les clés de chiffrement gérées par le client permettent à l'entreprise de faire tourner ou révoquer indépendamment du fournisseur. Les options de déploiement privé déplacent le service LLM dans le compte cloud propre de l'entreprise. Chacune de ces fonctionnalités est une surface de gouvernance qui doit être opérée, non seulement implémentée ; la surcouche de gouvernance d'entreprise est ce qui transforme une plateforme LLM multi-locataire en quelque chose qu'une industrie réglementée peut adopter.

Ce que prépare le Chapitre 12

La partie IV a développé les dimensions au niveau système de la sécurité LLM : frontières architecturales (chapitre 10), observabilité et réponse aux incidents (chapitre 11), et contrôles d'identité et d'accès (chapitre 12). Le traitement a été orienté mécanisme, et il donne une posture technique défendable. Le chapitre 13 ouvre la partie V en se déplaçant vers l'extérieur, du cœur technique au périmètre réglementaire. L'AI Act européen, pleinement effectif dès août 2026 pour la plupart des catégories à haut risque, est l'instrument unique le plus conséquent, mais la posture fédérale américaine (évoluant après la transition EO 14110 vers EO 14179), les lois au niveau des États (Colorado, Californie, New York City et autres), le RGPD tel qu'il s'applique à l'IA, et les cadres émergents à Singapour, au Japon, en Corée, en Inde et ailleurs rendent collectivement la surface de conformité plurielle plutôt qu'unifiée. Le chapitre examine ce que ces réglementations exigent en termes pratiques et comment les contrôles des chapitres 3, 10, 11 et 12 cartographient sur ces exigences.

Prochaine étape — Chapitre 13 : Paysage réglementaire. L'applicabilité échelonnée de l'AI Act européen, le RGPD contre les systèmes IA, l'auditabilité, les fiches de modèle, et les cadres de classification des risques qui structurent l'architecture réglementaire.