Chapitre 10 — Concevoir des architectures LLM sécurisées

Dixième billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui traite l'architecture comme la discipline de sécurité primaire — parce que la configuration la plus sûre d'un composant probabiliste est celle dont le rayon d'explosion est borné par la structure, non par la retenue du composant lui-même.

Pourquoi ce chapitre existe

Les chapitres des parties I à III ont nommé les menaces et les défenses côté modèle. Le chapitre 10 parcourt l'architecture autour du modèle — les frontières d'isolation, les niveaux de validation, les moteurs de politique, les contrats d'API et les principes zero-trust qui donnent au système ses propriétés structurelles. La prémisse est inchangée par rapport à l'ingénierie de sécurité antérieure : supposer la compromission, contenir les dégâts, rendre la compromission lisible. Ce qui est nouveau, c'est que le composant à contenir est un orchestrateur piloté par langage naturel dont les instructions peuvent arriver par n'importe quel canal d'entrée. Les schémas architecturaux se transposent des ères antérieures ; les spécificités de leur application aux LLM sont là où ce chapitre fait son travail.

10.1 L'isolation borne le rayon d'explosion

Une frontière d'isolation est une couture délibérée à travers laquelle un composant d'un côté ne peut affecter directement un composant de l'autre sans passer par une interface contrôlée. La raison sécurité de l'isolation est que le dommage de compromission est borné par ce que le composant compromis pouvait atteindre par ses interfaces légitimes. Pour les systèmes LLM, la question d'isolation la plus importante est entre le modèle et tout ce à quoi le système a par ailleurs accès. Un modèle tournant dans un processus avec accès filesystem sans restriction, accès réseau sans restriction, et un outil d'exécution shell sans liste blanche a un grand rayon d'explosion. Un modèle dont le processus tourne dans un sandbox avec un jeu de syscalls défini, dont l'accès réseau passe par un proxy de sortie avec liste blanche au niveau domaine, dont les outils sont invoqués par des jetons de capacité que le code environnant émet par requête, en a un beaucoup plus petit. Le schéma s'étend à l'exécution de code — les outils sandbox comme ceux qu'OpenAI et Anthropic utilisent pour leurs environnements code-interpreter exécutent le code généré dans des VM éphémères gVisor ou Firecracker — et à la navigation, où les navigateurs headless tournent dans des espaces de noms réseau isolés sans accès aux points de terminaison internes. L'isolation est une décision de conception prise avant toute attaque spécifique, et c'est l'investissement sécurité le moins cher par unité de réduction du rayon d'explosion que le domaine offre.

10.2 La validation est stratifiée, et la politique est déclarative

Un point de validation unique est un point d'échec unique. Les points de terminaison LLM en production composent typiquement cinq couches entre la requête client et la réponse. L'authentification vérifie les identifiants du principal. La validation de requête vérifie la requête contre le schéma de l'API — types, plages, longueurs, jeux de caractères. L'évaluation de politique demande si le principal authentifié, la requête validée et l'état système courant permettent cette action. L'appel au modèle tourne avec le prompt système, l'entrée utilisateur validée, la liste d'outils cadrée à ce que la politique autorise, et les contraintes de sortie. Le filtrage de sortie vérifie la réponse contre du contenu qui ne devrait pas être renvoyé — secrets divulgués, contenu interdit, appels d'outil dangereux — avant qu'elle ne soit envoyée. La logique politique grandit dans le temps et, si éparpillée à travers le code applicatif, devient l'union de nombreux conditionnels difficile à inspecter, tester ou faire évoluer. Le domaine a convergé sur la séparation politique et code. Open Policy Agent (OPA), projet CNCF, évalue des politiques écrites en Rego. AWS Cedar, sorti en 2023, est un langage d'autorisation plus focalisé aux propriétés de vérification formelle. Les deux sont prêts pour la production ; le choix est d'habitude un alignement organisationnel. Les politiques deviennent des artefacts versionnés et revoyables, et la politique de sécurité effective du système est toujours lisible en un endroit.

10.3 Zero-trust appliqué aux appels de modèle

L'API est le contrat entre le système LLM et ses appelants. La conception d'API sécurisée est la discipline de façonner le contrat pour que ses invariants survivent au contact d'appelants adverses. Les schémas d'entrée explicites — types stricts, plages, énumérations en liste blanche — coûtent peu et bornent la confiance implicite que l'API accorde à l'appelant. Les réponses d'erreur structurées qui ne divulguent pas l'état interne évitent la collecte de renseignements que des erreurs formulées vaguement permettent. Les clés d'idempotence, identifiants de requête et versionnement donnent au système une observabilité sur le comportement de l'appelant sans exiger d'état supplémentaire. Le modèle zero-trust, articulé dans l'article BeyondCorp de Google en 2014 et formalisé dans NIST SP 800-207 en 2020, étend le principe : aucun appelant n'est de confiance en vertu de sa localisation réseau. Chaque requête s'authentifie, est autorisée contre une politique explicite, est évaluée contre l'appareil et le contexte, et est journalisée. Appliqué aux systèmes LLM, l'appel au modèle devient lui-même un principal — une requête du modèle vers un outil en aval s'authentifie comme le modèle, porte l'identité de l'humain au nom duquel le modèle opère, et est autorisée contre une politique qui connaît les deux identités. Les jetons de capacité à portée étroite et TTL court sont ce qui rend cela compositionnel. Le résultat est qu'un prompt compromis ne peut escalader vers la compromission système complète parce que les capacités propres du modèle sont bornées par des jetons que le code environnant a émis pour une requête spécifique.

Ce que prépare le Chapitre 10

Structure sans visibilité échoue invisiblement. Le chapitre 11 examine la couche d'observabilité qui transforme les défenses architecturales en un système exploitable — quoi journaliser quand un LLM est dans la boucle, comment structurer la télémétrie pour servir l'alerting en temps réel, l'investigation après coup, la planification de capacité, la conformité et l'évaluation continue à partir des mêmes enregistrements. Les conventions sémantiques OpenTelemetry GenAI, qui ont commencé à standardiser les spans et attributs spécifiques aux LLM en 2024, fournissent la fondation neutre vis-à-vis des fournisseurs. Les implémentations spécifiques — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — se posent dessus avec des compromis différents. Le chapitre 12 gère ensuite la dimension identité et accès — OAuth, mTLS, RBAC contre ABAC, isolation multi-locataire, limites de débit, et les contrôles de gouvernance d'entreprise qui rendent le système utilisable dans les environnements réglementés.

Prochaine étape — Chapitre 11 : Observabilité, journalisation et réponse aux incidents. Ce qu'il faut journaliser avec les conventions OpenTelemetry GenAI, comment détecter les schémas d'abus, et comment mener une réponse aux incidents inspirée de NIST pour un système dont les défaillances sont probabilistes.