Architecture zero-trust pour l'IA

Pourquoi le modèle périmétrique ne protège plus rien

Un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire en production n'est jamais un objet unique. C'est une chaîne : une interface qui reçoit une requête, un orchestrateur qui construit un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, un modèle qui génère du texte, des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire que ce modèle peut appeler, une base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire qu'il interroge, parfois un accès réseau sortant vers des API tierces. Le réflexe hérité de vingt ans d'architecture réseau consiste à protéger le périmètre de cet ensemble — pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire, VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire, zone démilitarisée — et à faire confiance à tout ce qui se trouve à l'intérieur.

Ce modèle échoue face à l'IA pour une raison précise : l'attaquant n'a plus besoin de franchir le périmètre. Il lui suffit d'écrire un texte. Une injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire dissimulée dans un document ingéré par un pipeline RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire, un commentaire malveillant dans un ticket qu'un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire doit résumer, une page web piégée que l'agent visite pour « faire une recherche » — dans tous ces cas, la charge utile arrive par le canal légitime, sous forme de langage naturel, sans jamais toucher le pare-feu. Une fois que le modèle a interprété cette instruction comme faisant partie de sa tâche, il agit avec les mêmes droits que l'utilisateur légitime qui l'a invoqué.

Dans une architecture zero-trust, aucun composant n'est présumé sûr du seul fait qu'il se trouve « dans le système ». Le modèle, l'agent, l'outil, la base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sont chacun considérés comme potentiellement compromis, et chaque interaction entre eux est vérifiée, autorisée et journalisée indépendamment des autres. La question n'est plus « est-ce interne ? » mais « est-ce que cette action précise, pour cette identité précise, dans ce contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire précis, est autorisée ? ».

Les principes du zero-trust transposés à l'IA

Le zero-trust n'est pas né avec l'IA générative — le concept vient de l'architecture réseau d'entreprise, popularisé par le modèle publié par le NIST (SP 800-207). Trois principes s'y transposent directement aux systèmes d'IA, avec des adaptations propres au fait que l'« utilisateur » qui déclenche une action peut être un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire plutôt qu'un humain :

• Vérification explicite : chaque appel — utilisateur vers agent, agent vers outil, agent vers base de données — s'authentifie et s'autorise indépendamment. Le fait qu'un appel précédent ait été validé ne dispense pas le suivant de sa propre vérification.
• Moindre privilège (least privilege) : chaque composant reçoit exactement les droits nécessaires à sa fonction, jamais plus, et pour une durée aussi courte que possible.
• Présomption de compromission (assume breach) : l'architecture est conçue en partant du principe qu'un composant sera un jour détourné — par injection de prompt, par une dépendance vulnérable, par un jeton volé — et que les dégâts doivent rester contenus à ce composant.

Le point de bascule pour l'IA tient dans un détail souvent sous-estimé : un modèle de langage ne « sait » pas distinguer une instruction légitime d'une instruction injectée dans les données qu'il traite. Le texte d'un document PDF ingéré et le texte tapé par l'administrateur système partagent le même canal — le contexte du prompt. Le zero-trust ne cherche pas à résoudre ce problème d'interprétation à la source ; il en limite les conséquences en s'assurant que même un agent totalement détourné ne peut agir en dehors d'un périmètre de droits étroit et vérifié à chaque pas.

Segmentation : découper la surface d'attaque

Segmenter un système d'IA, c'est refuser qu'un seul composant compromis donne accès à l'ensemble de la chaîne. En pratique, cela se traduit par au moins cinq segments distincts, chacun avec ses propres règles d'accès réseau et applicatif :

Chaque segment communique avec ses voisins via une interface étroite et contrôlée, jamais par un accès partagé de type réseau plat. Concrètement, cela signifie que le modèle d'inférence tourne dans un environnement — conteneur, machine virtuelle, fonction serverless — qui n'a par défaut aucune route réseau vers la base de données de production ni vers Internet. Tout accès dont il a besoin passe par l'orchestrateur, qui matérialise chaque appel d'outil sous forme d'une requête vérifiable, journalisée, et rejouable pour l'audit.

Un agent qui répond aux tickets clients est découpé en trois segments réseau distincts : le segment « lecture CRM » (accès en lecture seule à la fiche client, filtré par l'identifiant du ticket en cours), le segment « rédaction de brouillon » (aucun accès sortant, uniquement génération de texte), et le segment « envoi » (droit d'écriture limité au seul ticket concerné, avec validation humaine obligatoire au-delà d'un certain montant de remboursement proposé). Un attaquant qui parvient à faire dévier l'agent par injection de prompt reste bloqué au segment dans lequel l'appel a été initié — il ne peut pas, depuis une simple lecture de ticket, déclencher un virement.

Moindre privilège pour les identités machine et les agents

Le moindre privilège appliqué à l'IA suppose de traiter chaque agent, chaque outil et chaque intégration comme une identité machine à part entière, avec son propre jeton, sa propre portée (scope) et son propre cycle de vie. Trois règles concrètes en découlent :

1. Un jeton par action, pas par session. Un agent qui doit lire un document puis envoyer un e-mail ne doit pas recevoir un jeton unique couvrant les deux opérations. Deux jetons distincts, à portée étroite, limitent l'impact si l'un des deux fuite.
2. Des portées granulaires, jamais des rôles génériques. Un rôle « lecture base de données » qui couvre toutes les tables est une dette de sécurité qui se paiera au premier incident. La portée doit refléter la table, voire la ligne (row-level security), et la nature de l'opération.
3. Une durée de vie courte (TTLTTLRéseauxCompteur porté par chaque paquet IP, décrémenté à chaque routeur traversé. À zéro, le paquet est détruit — ce qui évite les boucles infinies et permet à traceroute de cartographier un chemin.Voir dans le glossaire). Un jeton d'agent qui reste valide 24 heures est un jeton qui reste exploitable 24 heures après une compromission. Des jetons de quelques minutes, renouvelés à chaque appel via le point de décision de politique, réduisent cette fenêtre de manière drastique.

La cause numéro un d'incidents liés à des agents IA n'est pas une faille sophistiquée dans le modèle : c'est une clé d'API à portée large, copiée depuis un compte de service existant par commodité au moment du prototypage, et jamais réduite avant la mise en production. Un agent de démonstration hérite souvent des droits du compte de service qui a servi à le développer — accès complet à un bucket de stockage, à une base entière, parfois à un compte cloud administrateur. Ce raccourci transforme n'importe quelle injection de prompt réussie en incident majeur.

La délégation d'autorité pose une difficulté propre à l'IA : quand un agent agit « pour le compte » d'un utilisateur, faut-il lui donner les droits de cet utilisateur, ou des droits propres, plus restreints ? La bonne pratique consiste à propager l'identité de l'utilisateur final jusqu'au système d'autorisation final (on parle de délégation contrainte, ou tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire exchange avec des standards comme OAuth 2.0 Token Exchange), plutôt que de faire agir l'agent sous une identité de service à privilèges élevés. Ainsi, même si l'agent est détourné, il reste borné par ce que l'utilisateur qui l'a invoqué avait le droit de faire.

Vérification continue : contexte, télémétrie, ré-authentification

Le zero-trust ne se limite pas à une vérification au moment de la connexion. Il exige une réévaluation continue, appel après appel, en tenant compte du contexte : l'identité, l'appareil ou le service d'origine, l'heure, le volume de requêtes récent, la sensibilité de la ressource demandée, et — spécifique à l'IA — des signaux issus du contenu lui-même, comme la détection d'un motif d'injection de prompt dans l'entrée traitée.

Cette vérification continue repose sur deux composants qui reviennent dans toutes les architectures zero-trust matures :

• Le point d'application de la politique (PEP, Policy Enforcement Point) : le composant technique qui intercepte chaque appel et applique la décision — laisser passer, bloquer, exiger une validation humaine.
• Le point de décision de politique (PDP, Policy Decision Point) : le service qui évalue la demande au regard des règles définies (identité, portée, risque) et rend une décision, généralement en quelques dizaines de millisecondes pour ne pas dégrader la latence perçue.

Pour un pipeline agentique, cela signifie que chaque appel d'outil déclenché par le modèle repasse par le PDP, même si l'appel précédent dans la même conversation a été autorisé. Un agent qui a eu le droit de lire un document il y a trois secondes ne conserve pas automatiquement ce droit pour l'appel suivant — la décision est reprise à zéro, sur la base du contexte courant.

Avant d'élargir les droits d'un agent en production, commencez par le déployer en mode « journalisation seule » (shadow mode) : toutes ses tentatives d'appel d'outilsappel d'outilsIAMécanisme par lequel un modèle produit un appel de fonction structuré que le code environnant décide d'exécuter. Le modèle n'a jamais d'accès direct : il propose, le code dispose.Voir dans le glossaire sont enregistrées et évaluées par le PDP, mais aucune action réelle n'est exécutée au-delà d'un périmètre minimal. Cela permet de calibrer les règles de moindre privilège sur un comportement réel avant de les rendre bloquantes, et de repérer les tentatives d'appels anormaux — signe possible d'une injection de prompt en cours d'exploitation — sans risque opérationnel.

Étude de cas : sécuriser un pipeline RAG en zero-trust

Prenons un pipeline de génération augmentée par récupération (RAG) utilisé pour interroger une base documentaire d'entreprise. Sans zero-trust, l'architecture courante est la suivante : l'utilisateur envoie une question, le serveur d'application interroge directement la base vectorielle avec des droits d'accès complets sur tout le corpus, injecte les passages récupérés dans le prompt, et le modèle répond. Le compte de service qui interroge la base vectorielle a généralement accès à l'intégralité de l'index — y compris les documents que l'utilisateur courant ne devrait pas pouvoir consulter (contrats confidentiels, données RH, notes internes sensibles).

En zero-trust, la même chaîne est reconstruite ainsi :

• L'identité de l'utilisateur final est propagée jusqu'à la requête sur la base vectorielle, qui applique un filtrage au niveau des métadonnées (row-level security) : seuls les documents auxquels cet utilisateur précis a droit sont éligibles à la récupération, avant même d'être injectés dans le prompt.
• Le modèle d'inférence tourne dans un segment sans accès réseau direct à la base — c'est l'orchestrateur, authentifié séparément, qui exécute la requête et transmet uniquement les passages autorisés.
• Toute tentative du modèle d'invoquer un outil en dehors de la liste blanche définie pour ce cas d'usage (par exemple, une tentative d'appel réseau sortant suite à une instruction cachée dans un document piégé) est bloquée au niveau du PEP, avant exécution, et journalisée comme anomalie.
• Les réponses générées sont elles-mêmes soumises à un contrôle de sortie (output filtering) qui vérifie qu'aucun fragment issu d'un document non autorisé pour cet utilisateur ne s'est glissé dans la réponse finale — un garde-fou nécessaire car un filtrage imparfait en amont n'empêche pas toujours une fuite en aval.

Ce redécoupage ne complique pas fondamentalement l'architecture existante : il ajoute une couche de vérification à chaque frontière déjà présente, plutôt que de repenser tout le pipeline.

Ajouter une vérification à chaque frontière introduit une latence supplémentaire, typiquement de quelques dizaines à quelques centaines de millisecondes par appel selon la complexité des règles évaluées. Pour la grande majorité des cas d'usage d'entreprise, ce coût est négligeable face au risque évité — une fuite de documents confidentiels ou une action non autorisée déclenchée par injection de prompt coûte largement plus cher qu'un budget de latence de 100 millisecondes.

Pièges fréquents en déploiement

Plusieurs erreurs reviennent systématiquement dans les architectures qui se présentent comme « zero-trust » sans en respecter les principes :

• La segmentationChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire de façade. Des composants séparés en apparence (conteneurs distincts, services nommés différemment) mais qui partagent en réalité le même compte de service ou le même réseau plat. La segmentation logique sans segmentation des droits ne protège rien.
• La confiance transitive implicite. Un agent A appelle un agent B, qui hérite automatiquement de tous les droits d'A sans réévaluation. C'est exactement le schéma de propagation que le zero-trust cherche à casser.
• L'absence de contrôle de sortie. Beaucoup d'efforts sont investis dans le filtrage des entrées (détection d'injection de prompt) et très peu dans la vérification de ce que le modèle produit réellement avant de l'exécuter ou de l'afficher — alors que c'est souvent le dernier point de blocage disponible.
• Les portées trop larges par commodité de développement. Un jeton à portée large simplifie le prototypage ; il devient une dette de sécurité s'il n'est jamais resserré avant la mise en production.
• L'absence de journalisation exploitable. Journaliser les appels ne sert à rien si personne ne surveille les anomalies — un volume inhabituel d'appels à un outil sensible, ou des tentatives répétées de sortir du périmètre autorisé, doivent générer une alerte, pas seulement une ligne de log.

Checklist de mise en œuvre

Avant de qualifier une architecture d'IA de « zero-trust », vérifiez chacun des points suivants :

• Chaque segment (interface, orchestrateur, modèle, outils, données) dispose de son propre périmètre réseau et ne peut pas atteindre les autres directement.
• Chaque appel inter-segment passe par un point d'application de la politique, y compris entre composants internes considérés comme « de confiance ».
• Les jetons utilisés par les agents et les outils ont une portée étroite, une durée de vie courte, et sont émis par action plutôt que par session.
• L'identité de l'utilisateur final est propagée jusqu'aux systèmes de données, pour un filtrage d'accès cohérent avec ses droits réels.
• Un contrôle de sortie vérifie le contenu généré avant exécution d'une action sensible ou affichage à l'utilisateur.
• Les appels d'outils et les accès aux données sont journalisés avec suffisamment de contexte pour permettre un audit a posteriori.
• Des alertes sont configurées sur les écarts de comportement (volume, séquence d'appels inhabituelle, tentative de sortie du périmètre autorisé).
• Les comptes de service hérités du prototypage ont été audités et resserrés avant la mise en production.

En résumé

Le zero-trust appliqué à l'IA ne consiste pas à ajouter un pare-feu de plus autour du modèle : c'est un changement de posture qui traite chaque composant de la chaîne — interface, orchestrateur, modèle, outil, base de données — comme une identité indépendante, jamais présumée fiable du seul fait de sa position dans le système. La segmentation limite ce qu'un composant compromis peut atteindre ; le moindre privilège limite ce qu'il peut faire ; la vérification continue s'assure qu'un droit accordé il y a une seconde n'est pas automatiquement reconduit à l'appel suivant. Ces trois principes se combinent pour transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire une injection de prompt réussie — un incident qu'aucune architecture ne peut garantir d'empêcher totalement — d'un accès complet au système en un incident contenu à un segment étroit, journalisé et détectable.