Zero trust pour les systèmes d’IA : pourquoi les mêmes principes s’appliquent-ils — et où trouvent-ils leurs limites
Le zero trust est l’un des cadres les plus éprouvés en matière de sécurité d’entreprise. Ses principes — ne jamais faire confiance, toujours vérifier, supposer la compromission, appliquer le principe du moindre privilège — sont bien compris, largement mis en œuvre et profondément ancrés dans la façon dont les équipes de sécurité abordent le contrôle des accès.
Le problème, c’est que le zero trust a été conçu pour un modèle d’acteur bien précis : des utilisateurs humains dotés d’identités stables, de comportements prévisibles et de sessions clairement délimitées. Les systèmes d’IA ne répondent à aucun de ces critères. Ils agissent pour le compte des utilisateurs sans en être eux-mêmes. Leur comportement est sémantiquement complexe et opérationnellement opaque. Ils peuvent exécuter des milliers d’opérations sur les données en un temps record, là où un humain n’en réaliserait qu’une seule.
Cet article s’adresse aux RSSI et architectes sécurité qui doivent étendre l’architecture zero trust aux acteurs IA — et qui doivent comprendre où leurs cadres existants restent pertinents et où ils montrent leurs limites.
Résumé exécutif
Idée principale : Les principes du zero trust qui régissent l’accès humain aux données d’entreprise s’appliquent également aux systèmes d’IA — mais les mécanismes conçus pour les acteurs humains ne sont pas transposables tels quels. Les acteurs IA nécessitent des contrôles spécifiques, adaptés à leurs particularités en matière d’identité, de comportement et d’opérations.
Pourquoi c’est important : Les équipes de sécurité qui appliquent les cadres zero trust conçus pour les humains aux systèmes d’IA sans adaptation créent une faille de gouvernance invisible. Les contrôles semblent corrects sur le papier — authentification, politiques d’accès, journalisation configurée — mais ils ne sont pas appliqués comme l’exigent les caractéristiques opérationnelles de l’IA. Résultat : une posture zero trust présente en théorie, mais insuffisante en pratique.
5 points clés à retenir
- Les principes du zero trust s’appliquent aux systèmes d’IA sans modification — ne jamais faire confiance, toujours vérifier, supposer la compromission, appliquer le moindre privilège. Ce qui doit évoluer, c’est la mise en œuvre : les contrôles conçus pour les humains ne répondent pas au modèle d’identité, aux comportements ni à l’échelle opérationnelle de l’IA.
- L’identité de l’IA diffère fondamentalement de celle d’un humain. Un système d’IA ne possède pas d’ancrage identitaire stable — il agit pour le compte d’utilisateurs, reste vulnérable à l’injection de prompt qui peut modifier son intention apparente, et fonctionne généralement sous des comptes de service qui masquent l’identité réelle du donneur d’ordre.
- L’authentification au niveau de la session — approche par défaut pour la plupart des intégrations IA — va à l’encontre de l’exigence de vérification continue du zero trust. Seule l’autorisation à la requête, appliquée via RBAC et ABAC au niveau des données, répond réellement au principe du « never trust » pour les acteurs IA.
- Le rayon d’action d’un système d’IA compromis est bien plus vaste que celui d’un compte utilisateur compromis. Un système d’IA doté d’un accès large aux données et sans limitation de débit peut exfiltrer à une échelle et une vitesse qui rendent la réponse aux incidents purement réactive. L’architecture assume-breach pour l’IA impose des limitations de débit et de périmètre qui n’ont pas d’équivalent dans le zero trust appliqué aux humains.
- Les journaux d’audit des opérations IA doivent comporter une double attribution — l’identité du système d’IA et celle de l’utilisateur humain pour lequel il agit — afin de répondre aux exigences de conformité. Des logs qui n’enregistrent que les actions du système d’IA sont incomplets d’un point de vue forensic et réglementaire.
Pourquoi le zero trust est le bon cadre — et pourquoi il doit être étendu
Le zero trust est né suite à l’échec de la sécurité périmétrique : on a constaté qu’une fois l’acteur à l’intérieur du réseau, les contrôles traditionnels accordaient trop de confiance implicite. La réponse a été de considérer chaque demande d’accès comme potentiellement hostile, quel que soit l’emplacement réseau, et de vérifier l’identité, d’appliquer le moindre privilège et d’auditer chaque opération en continu. Ces principes sont valables pour les acteurs IA. Un système d’IA authentifié auprès d’un référentiel de données ne doit pas bénéficier d’une confiance implicite pour toute la durée de sa session. Ses requêtes doivent être évaluées selon la politique en vigueur. Ses opérations doivent être journalisées. Son accès doit être limité par les autorisations de l’humain qui le pilote.
L’extension requise ne concerne pas les principes, mais les postulats de mise en œuvre. Les cadres zero trust supposent que l’acteur dispose d’une identité stable et vérifiable — compte utilisateur, certificat, jeton matériel. Ils supposent que les frontières de session correspondent raisonnablement aux frontières d’autorisation. Ils supposent que le « comportement normal » est identifiable et que les écarts sont détectables. Les systèmes d’IA remettent en cause ces trois postulats, et les contrôles qui en découlent doivent être repensés pour un modèle d’acteur radicalement différent.
Le problème de l’identité : les systèmes d’IA n’ont pas d’identités stables
Le zero trust appliqué aux humains repose sur la vérification de l’identité : authentifier l’utilisateur, établir son identité et s’en servir comme ancrage pour les décisions d’autorisation. Cela fonctionne car l’identité humaine est stable — un compte utilisateur correspond à une personne précise, avec des rôles et des droits d’accès spécifiques, vérifiés via MFA et IAM. Les systèmes d’IA n’ont pas d’ancrage identitaire équivalent.
L’« identité » d’un système d’IA, dans la plupart des déploiements en entreprise, est un compte de service — un identifiant partagé qui représente la plateforme IA, et non l’utilisateur réel qui pilote ses actions. Cela pose deux problèmes de gouvernance. D’abord, le compte de service masque la responsabilité réelle de l’accès aux données : lorsqu’une IA récupère un document, le journal d’audit indique le compte de service, pas le collaborateur à l’origine de la demande. Ensuite, ce compte de service dispose généralement de droits supérieurs à ceux accordés à un utilisateur individuel — car il a été configuré pour permettre à l’IA de servir n’importe quel utilisateur, il doit pouvoir accéder à tout ce dont un utilisateur pourrait légitimement avoir besoin.
Le problème d’identité le plus profond est l’injection de prompt. Le comportement d’une IA dépend de ses entrées — et celles-ci peuvent être manipulées. Une attaque par injection de prompt consiste à insérer des instructions dans les données traitées par l’IA, détournant ainsi son comportement pour contourner les contrôles de gouvernance, extraire des identifiants ou accéder à des données hors du périmètre prévu. Contrairement à un humain dont l’identité reste stable quel que soit ce qu’il lit, l’« identité » effective d’un système d’IA — ce qu’il va faire ensuite — peut être modifiée par le contenu de sa fenêtre de contexte. La vérification d’identité traditionnelle ne permet pas de traiter ce risque. La protection zero trust des données pour l’IA impose de stocker les identifiants en dehors du contexte IA, dans le trousseau de clés du système d’exploitation, inaccessibles via une manipulation de prompt.
Le problème des frontières de session : quand la « continuité » impose l’autorisation à la requête
L’exigence de vérification continue du zero trust est généralement mise en œuvre via la gestion des sessions : réauthentification après inactivité, authentification renforcée selon le risque, détection d’anomalies dans le comportement utilisateur pendant la session. Pour les humains, cela fait sens — une session correspond à une période d’activité intentionnelle, et la réauthentification aux frontières de session apporte une vérification pertinente.
Les sessions IA ne fonctionnent pas ainsi. Un agent IA opérant pour un utilisateur peut maintenir une connexion persistante aux systèmes de données de l’entreprise pendant des heures, exécutant des milliers d’opérations individuelles au sein d’une même session. L’authentification au niveau de la session signifie que l’IA est vérifiée une fois, au début — mais toutes les opérations suivantes héritent de cette autorisation initiale sans vérification indépendante. Pour un humain qui navigue dans un système de fichiers, cela reste tolérable. Pour une IA capable d’exécuter mille opérations de récupération par minute, l’autorisation au niveau de la session n’est pas une vérification continue — c’est un simple point de contrôle suivi d’un accès non surveillé à la vitesse machine.
La vraie vérification continue pour l’IA impose une autorisation à la requête : chaque opération — chaque accès à un fichier, chaque requête de récupération, chaque navigation dans un dossier — doit être évaluée selon les règles RBAC et ABAC au moment où elle est demandée. Ce n’est pas seulement une bonne pratique — c’est la seule façon d’appliquer le « never trust, always verify » à la cadence opérationnelle réelle des systèmes IA. L’autorisation au niveau de la session, c’est une seule vérification suivie d’une confiance étendue. Ce n’est pas du zero trust ; c’est un modèle périmétrique avec un périmètre plus court.
Principes du zero trust : acteurs humains vs. acteurs IA
| Principe Zero Trust | Application pour les acteurs humains | Limites pour les acteurs IA |
|---|---|---|
| Vérifier l’identité | Identité utilisateur vérifiée via MFA, SSO, certificats à la connexion | L’identité système de l’IA est une construction à l’exécution — pas d’ancrage stable ; l’injection de prompt permet l’usurpation ; les comptes de service ne reflètent pas l’acteur réel |
| Appliquer le moindre privilège | RBAC/ABAC limite l’accès selon le rôle et les attributs de l’utilisateur authentifié | Les IA fonctionnent souvent sous des comptes de service surdimensionnés ; le moindre privilège impose une application à la requête et par utilisateur — pas seulement au niveau de la session |
| Supposer la compromission | Segmentation réseau ; limitation des mouvements latéraux ; surveillance des comportements anormaux | Une IA compromise peut exécuter des milliers de requêtes avant détection ; sans limitation de débit et contrôle à la requête, le rayon d’action est énorme |
| Inspecter tout le trafic | Inspection TLS ; analyse DLP ; filtrage du contenu en transit | Le trafic IA est sémantiquement opaque — les requêtes en langage naturel ne correspondent pas aux schémas DLP classiques ; l’inspection doit se faire au niveau de la récupération des données, pas du réseau |
| Vérification continue | Réauthentification de session ; accès basé sur le risque ; détection d’anomalies comportementales | Les sessions IA peuvent durer indéfiniment ; le « comportement normal » d’une IA est très variable ; la vérification continue impose une évaluation à chaque opération, pas une réauthentification périodique |
| Tout auditer | Journaux d’accès utilisateur avec identité, ressource, horodatage, action | Les logs IA doivent attribuer chaque opération à la fois au système d’IA ET à l’utilisateur humain pour lequel il agit — sans cette double attribution, les logs sont incomplets pour la conformité |
Le problème du rayon d’action : pourquoi « assume-breach » prend un autre sens avec l’IA
L’architecture assume-breach pour les humains vise à contenir les mouvements latéraux : segmentation réseau, moindre privilège, détection d’anomalies pour stopper un utilisateur compromis avant qu’il ne pivote vers d’autres systèmes. Le rayon d’action d’un compte humain compromis, bien que sérieux, reste limité par le rythme opérationnel humain — une personne ne peut accéder qu’à une quantité de données limitée en un temps donné.
Un système d’IA compromis opère à une toute autre échelle. Un agent IA avec un accès large aux référentiels et sans limitation de débit peut extraire des centaines de milliers de documents le temps qu’un analyste sécurité accuse réception d’une alerte SIEM. Les contrôles assume-breach efficaces pour les humains — détection d’anomalies, clôture de session, segmentation réseau — sont essentiellement réactifs à la cadence de l’IA. Quand l’anomalie est détectée et la session fermée, les données sont déjà parties.
L’approche assume-breach pour l’IA impose une limitation proactive du rayon d’action, inexistante dans les cadres zero trust humains. La limitation de débit sur les requêtes IA — appliquée au niveau des données, pas de l’application — plafonne le volume de données qu’une IA peut extraire, quelles que soient ses instructions. Les contrôles de chemin et de périmètre empêchent l’IA de sortir du domaine de données prévu. Ces contrôles ne détectent pas la compromission a posteriori ; ils limitent les dégâts avant même la détection. C’est une philosophie de contrôle radicalement différente de l’assume-breach humain, qui exige une architecture dédiée plutôt qu’une adaptation des contrôles de gestion des risques existants.
Le problème de l’audit : qui est responsable quand une IA accède à des données ?
Les exigences d’audit zero trust pour les humains sont bien établies : journaliser l’identité de l’utilisateur, la ressource accédée, l’horodatage et l’action réalisée. Cela produit une traçabilité conforme aux exigences HIPAA, RGPD, SOX et FedRAMP car le log répond à la question de responsabilité : une personne précise a accédé à une ressource précise et en assume la responsabilité.
Les logs d’accès IA, dans la plupart des implémentations en entreprise, n’enregistrent que l’identité du système d’IA — le compte de service — et rien d’autre. Lorsqu’une IA récupère un document sensible, le log indique que le compte de service de la plateforme IA a accédé au fichier. Il ne précise pas quel collaborateur a déclenché la requête, ce qui a été demandé ni l’usage du résultat. Ce n’est pas un simple manque d’attribution. Pour HIPAA, qui exige des logs identifiant la personne responsable de l’accès aux informations médicales protégées, une entrée de compte de service ne répond pas au critère minimal. Pour le RGPD, qui impose de prouver la base légale de chaque accès, un log incapable d’identifier le demandeur humain ne permet pas de l’établir.
Les logs IA doivent comporter une double attribution : l’identité du système d’IA et celle de l’utilisateur humain authentifié pour lequel l’IA agit, réunies dans une seule entrée pour chaque opération. Techniquement, ce n’est pas complexe — il suffit que l’IA transmette l’identité utilisateur au niveau des données lors de chaque requête, et que ce niveau journalise les deux identités ensemble. Mais cela exige une conception architecturale délibérée. La plupart des intégrations IA ne le font pas, et la plupart des cadres d’audit zero trust n’en font pas une exigence explicite.
Contrôles zero trust de Kiteworks pour l’IA : mise en œuvre et impact
| Contrôle Zero Trust | Mise en œuvre par Kiteworks pour l’IA | Ce que cela prévient |
|---|---|---|
| Isolation des identifiants | OAuth 2.0 avec PKCE ; jetons stockés dans le trousseau OS, jamais dans la fenêtre de contexte IA ni dans les fichiers de configuration | Élimine le vol d’identifiants par injection de prompt ; jetons inaccessibles au modèle IA en toutes circonstances |
| Autorisation à la requête | Politiques RBAC et ABAC évaluées pour chaque opération IA — accès fichier, navigation dossier, requête de récupération | L’IA ne peut accumuler d’accès au sein d’une session ; chaque requête est autorisée indépendamment selon la politique en vigueur |
| Journalisation d’audit à double attribution | Chaque opération IA est journalisée avec l’identité système IA ET l’identité utilisateur authentifié, donnée accédée, horodatage, action, résultat | Répond aux exigences d’attribution HIPAA, RGPD, SOX, FedRAMP ; permet l’investigation forensic des incidents impliquant l’IA |
| Limitation du débit | Limites de requêtes par utilisateur et session appliquées au niveau des données, indépendamment du comportement IA | Limite le rayon d’action en cas d’extraction massive ; un volume anormal de récupération déclenche les contrôles avant la sortie des données |
| Contrôles de chemin et de périmètre | Restrictions de chemin absolu ; prévention de la traversée de répertoires ; liste blanche d’opérations appliquée par défaut | L’IA ne peut sortir du périmètre de données prévu, quelle que soit la construction ou la manipulation des prompts |
| Intégration SIEM en temps réel | Toutes les opérations IA sont transmises au SIEM sans lot, limitation ni délai | Les équipes sécurité détectent les comportements IA anormaux en temps réel ; aucune latence entre l’activité IA et la visibilité sécurité |
Comment Kiteworks étend le zero trust à chaque requête IA
Les équipes de sécurité qui réussiront le mieux l’adoption de l’IA ne sont pas celles qui l’interdisent — ce sont celles qui étendent leur architecture de sécurité existante aux acteurs IA avec la même rigueur qu’aux acteurs humains. Cette extension nécessite des contrôles dédiés, car les postulats humains intégrés dans les cadres zero trust ne s’appliquent pas aux systèmes IA. Le modèle d’identité est différent. Le modèle de session est différent. Le rayon d’action est différent. Les exigences d’audit sont différentes.
Une équipe sécurité qui comprend ces différences et met en place des contrôles adaptés peut adopter l’IA en toute confiance. Celle qui applique les contrôles humains aux acteurs IA et s’arrête là n’a qu’une posture zero trust présente en théorie, mais insuffisante en pratique.
Kiteworks applique le zero trust aux acteurs IA à chaque niveau où le modèle humain montre ses limites. Isolation des identifiants : les jetons OAuth 2.0 sont stockés dans le trousseau OS, hors de la fenêtre de contexte du modèle IA, inaccessibles via une injection de prompt en toutes circonstances. Autorisation à la requête : le Data Policy Engine de Kiteworks évalue les politiques RBAC et ABAC pour chaque opération IA — non pas à l’établissement de la session, mais à chaque requête. L’IA hérite des droits de l’utilisateur demandeur et ne peut les dépasser pour aucune action, quel que soit l’état de la session.
La journalisation d’audit à double attribution enregistre à la fois l’identité système IA et l’utilisateur authentifié pour chaque opération, alimente le journal d’audit Kiteworks et s’intègre au SIEM en temps réel — sans lot, sans délai, sans latence de détection. La limitation de débit et les contrôles de chemin appliquent l’architecture assume-breach au niveau des données : un système d’IA compromis ou mal configuré ne peut exfiltrer à grande échelle car les contrôles sont intégrés à l’architecture du Réseau de données privé, sans dépendre du bon comportement du système IA.
Et comme ces contrôles étendent le même cadre d’échange de données zero trust qui régit la messagerie électronique, le partage et le transfert de fichiers dans l’organisation, il n’y a pas de programme de sécurité IA distinct à bâtir et maintenir. L’architecture zero trust déjà en place est simplement étendue à l’IA — sans être reconstruite pour elle.
Pour les RSSI et architectes sécurité qui souhaitent étendre le zero trust aux acteurs IA avec la même rigueur qu’aux humains, Kiteworks propose les contrôles dédiés qui rendent cela possible. Pour découvrir la mise en œuvre en détail, réservez votre démo sans attendre !
Foire aux questions
L’architecture zero trust existante a été conçue pour des acteurs humains dotés d’identités stables, de frontières de session prévisibles et d’un rythme opérationnel humain. Les systèmes IA remettent en cause ces trois postulats : ils agissent sous des comptes de service qui masquent l’identité humaine, opèrent sur des sessions étendues à la vitesse machine et peuvent être détournés par injection de prompt de manière imprévisible. Les principes restent valables ; les mécanismes doivent être conçus spécifiquement pour un modèle d’acteur radicalement différent d’un utilisateur humain.
L’injection de prompt est une attaque où des instructions malveillantes sont intégrées dans le contenu traité par l’IA — document, page web, fichier récupéré — détournant le comportement de l’IA à l’insu de l’utilisateur. Dans une intégration IA mal sécurisée, une IA ayant accès à ses propres identifiants d’authentification peut être amenée, via une injection de prompt, à divulguer ces identifiants, ouvrant un accès non autorisé aux systèmes de données. La protection zero trust des données pour l’IA impose de stocker les identifiants dans le trousseau du système d’exploitation — totalement hors du contexte IA — pour qu’ils restent inaccessibles, quel que soit le contenu traité par l’IA.
L’autorisation au niveau de la session vérifie l’IA une seule fois à la connexion et accorde un accès implicite pour toute la durée de la session. L’autorisation à la requête évalue les politiques RBAC et ABAC pour chaque opération IA — chaque accès fichier, chaque requête de récupération, chaque navigation dossier — au moment où elle est demandée. Pour les IA qui exécutent des milliers d’opérations par session, l’autorisation de session n’est qu’une vérification unique suivie d’un accès non surveillé. Seule l’autorisation à la requête répond à l’exigence « never trust, always verify » à la cadence réelle de l’IA.
Un compte humain compromis reste limité par le rythme opérationnel humain — une personne ne peut accéder qu’à une quantité de données limitée, ce qui laisse le temps à la détection d’anomalies d’intervenir. Un système IA compromis, avec un accès large et sans limitation de débit, peut extraire des centaines de milliers de documents avant même qu’une alerte SIEM ne soit prise en compte. L’architecture assume-breach pour l’IA impose une limitation proactive du rayon d’action — limitation de débit et contrôles de périmètre appliqués au niveau des données — et pas seulement une détection réactive. C’est une philosophie de contrôle radicalement différente de la réponse aux incidents humains, car la fenêtre de détection est trop courte pour que les contrôles réactifs suffisent.
La double attribution consiste à enregistrer à la fois l’identité du système IA et celle de l’utilisateur humain authentifié pour lequel l’IA agit — dans la même entrée de log, pour chaque opération. La plupart des logs IA n’enregistrent que l’identité du compte de service, ce qui ne permet pas d’identifier le demandeur humain. La conformité HIPAA exige des logs identifiant la personne responsable de l’accès aux informations médicales protégées. La conformité RGPD impose de pouvoir prouver la base légale de chaque accès, ce qui suppose d’identifier le demandeur humain. Un log qui indique seulement « le compte de service IA a accédé au fichier » ne suffit pas — la double attribution comble ce manque de traçabilité.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la vie privée avec l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
Le fossé de la gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.