Zero-trust pour les agents IA : au-delà du périmètre réseau
L'architecture zero-trust appliquée aux systèmes multi-agents exige de repenser l'identité, l'autorisation et la vérification continue. Les modèles réseau classiques ne suffisent plus.
Steve P.
Research, Hikari Blue · 9 mars 2026
Le concept de zero-trust a été formalisé par Kindervag chez Forrester en 2010. Quinze ans plus tard, son application aux systèmes IA multi-agents reste largement impensée. La plupart des organisations qui déploient des agents IA en production leur accordent une confiance implicite que jamais elles n'accorderaient à un utilisateur humain.
Le problème de la confiance implicite
Dans une architecture classique, un agent IA déployé en interne bénéficie du même niveau de confiance que le service qui l'héberge. S'il tourne dans le VPC de production, il accède aux mêmes ressources que n'importe quel service de ce VPC.
C'est exactement le modèle que zero-trust est censé éliminer.
Le NIST Special Publication 800-207 ("Zero Trust Architecture", 2020) définit trois principes fondamentaux : ne jamais faire confiance, toujours vérifier, appliquer le moindre privilège. Avec les agents IA, chaque principe pose des problèmes spécifiques.
Ne jamais faire confiance
Un agent IA n'est pas un service déterministe. Pour une même entrée, il peut produire des sorties différentes. Son comportement évolue dans le temps (cf. le phénomène de drift). Il peut être manipulé par injection de prompt.
Concrètement, cela signifie que l'identité de l'agent ne suffit pas à garantir la légitimité de ses actions. Un agent authentifié et autorisé peut quand même prendre une décision aberrante.
Implication architecturale : chaque décision d'agent doit être évaluée indépendamment, pas seulement au moment de l'authentification mais à chaque interaction.
Toujours vérifier
La vérification continue dans un contexte multi-agents implique trois niveaux :
Niveau 1 — Identité. Chaque agent possède une identité cryptographique unique. Les communications inter-agents sont authentifiées mutuellement (mTLS ou équivalent). Google a documenté cette approche dans son BeyondProd paper (2019), mais l'application aux agents IA reste ad hoc dans la plupart des organisations.
Niveau 2 — Autorisation contextuelle. L'autorisation n'est pas binaire. Un agent peut être autorisé à accéder à un dataset pour une tâche spécifique, dans une fenêtre temporelle définie, avec un volume de requêtes plafonné. Le modèle ABAC (Attribute-Based Access Control), décrit dans le NIST SP 800-162, s'applique naturellement.
Niveau 3 — Vérification comportementale. C'est le niveau le plus spécifique aux agents IA. Il s'agit de vérifier non seulement que l'agent a le droit de faire quelque chose, mais que ce qu'il fait est cohérent avec son mandat. Un agent de support client qui commence à interroger la base de données RH a peut-être une faille, même s'il a techniquement les permissions.
Appliquer le moindre privilège
Le principe de moindre privilège est paradoxal avec les agents IA. Un agent efficace a besoin de contexte. Plus il a de contexte, meilleures sont ses décisions. Mais plus il a de contexte, plus la surface d'attaque est large.
Anthro (2024) a documenté ce dilemme dans leur research paper "Scaling Supervised Safety" : restreindre l'accès aux données dégrade les performances, mais l'accès large crée des risques de fuite de données.
La solution est une isolation par design :
Le modèle opérationnel
Une architecture zero-trust pour agents IA repose sur quatre composants :
1. Identity mesh. Chaque agent, chaque source de données, chaque canal de communication possède une identité vérifiable. Pas de credentials partagés. Pas de service accounts mutualisés.
2. Policy engine. Les politiques d'accès sont définies de manière déclarative et évaluées à chaque requête. Open Policy Agent (OPA) est un candidat naturel pour cette couche.
3. Continuous monitoring. Chaque interaction est loggée, analysée, et comparée au comportement attendu. Les anomalies déclenchent des alertes graduées.
4. Kill switch granulaire. La capacité de révoquer les accès d'un agent spécifique en temps réel, sans impacter les autres agents du système.