Agentic Zero Trust : organiser la confiance autour des agents IA

Dans beaucoup d’entreprises, les règles qui déterminent qui peut accéder à quelles données sont dispersées dans plusieurs systèmes. Certaines se trouvent dans les solutions de gestion des identités et des accès. D’autres sont associées aux groupes utilisateurs définis dans l’annuaire de l’entreprise. Des règles d’accès existent également dans les applications métier, les bases de données au travers de vues SQL, les API

Seulement voilà, plus les systèmes se multiplient, plus le contrôle et la traçabilité donnent du fil à retordre. Cette fragmentation complique l’application du principe du « moindre privilège » à l’échelle. Ce dernier consiste à s’assurer que chaque utilisateur n’a accès qu’aux seules informations dont il a besoin, et à pouvoir le démontrer.

La gestion des politiques par le code (Policy-as-code) apporte une réponse à ce défi. Cette méthode consiste à transformer, dans un langage pivot, les règles de sécurité, de droits d’accès et de gouvernance en politiques explicites, versionnées, testables. Ses règles sont traduites dans le langage de la source et sont déployables automatiquement.

On passe de règles implicites et manuelles, à des règles formalisées sous forme de code. Ces règles sont d’abord évaluées par un composant qui décide si un accès est autorisé ou non (Policy Decision Point – PDP), puis appliquées concrètement par des points d’application dans les systèmes (Policy Enforcement Points – PEP), qui font respecter ces décisions.

Gérer les accès humains aux données de façon maîtrisée s’avère déjà un défi en soi. Dès que l’on croise qui accède à quoi, depuis quelle application, dans quel contexte et à quelles conditions, le nombre de combinaisons conduit à un produit cartésien considérable.

Cette complexité change d’échelle avec l’arrivée des agents IA. L’action dans le système d’information s’hybride de plus en plus. D’un côté, les acteurs humains, de l’autre, les agents IA. Ces derniers exploitent déjà des outils, sollicitent des API, interrogent des applications et associent des données issues de plusieurs sources.

Jusqu’ici, les questions portaient sur le « qui », le « quoi », les droits d’accès et le contexte, dans une logique de moindre privilège et de contrôle. Désormais, il faut composer avec les identités non humaines et autonomes (Non-Human Identities, NHI). Il faut donc s’attendre à ce que le produit cartésien augmente de façon exponentielle.

Dans cette situation, encore une fois, le Policy-as-Code, au sein du socle d’architecture agentique sécurisée, répond à cette complexification des contrôles d’accès. Et l’Agentic Zero Trust en constitue le cadre de confiance.

Son principe est aussi simple que radical. Aucun agent IA n’est considéré comme légitime par défaut, même s’il est interne et correctement authentifié. L’identité seule est une illusion de contrôle. Chaque action, chaque accès à une donnée doit être vérifié en temps réel, sans attendre la moindre validation humaine.

Car il faut savoir qui a le droit de faire quoi. Chaque action humaine ou applicative, automatisée ou agentique, doit aussi demeurer sous contrôle à chaque instant.

Vers un Agentic Zero Trust

Un agent IA chargé de préparer un rapport financier a accès, dans le cadre de sa mission, aux données de ventes.

En cherchant à enrichir son analyse, il tente d’interroger la base de données RH pour croiser performances commerciales et salaires individuels. Sa requête est techniquement valide, son identité correctement authentifiée.

Sans Agentic Zero Trust, il obtient les données. Mais avec, sa demande est bloquée. Cette action sort du périmètre autorisé pour cette finalité. L’authentification ne suffit pas.

C’est la légitimité de chaque action, dans son contexte, qui prime. C’est exactement le principe du Zero Trust, appliqué jusqu’ici aux humains et aux systèmes, ne jamais faire confiance, toujours vérifier. L’Agentic Zero Trust étend ces mêmes exigences aux agents IA.

Pour cela, la gestion des identités non humaines (Non-Human-Identity, NHI) constitue un prérequis. Chaque Agent doit être identifiée, rattachée à un propriétaire, gouvernée sur son cycle de vie et limitée selon les règles de minimisation qui s’impose.

Le risque de non-conformité réglementaire va aussi sensiblement augmenter. Un prérequis nécessaire mais non suffisant. Un agent peut être authentifié et pourtant tenter d’accéder à une donnée sensible, d’agir hors contexte autorisé ou appeler un outil (Tools) laxiste. Ce dernier est une interface mise à disposition d’un agent pour lui permettre d’interroger, d’utiliser une capacité métier ou d’exécuter une action.

Dans les transformations métiers par l’IA, les agents deviennent des acteurs opérationnels capables de préparer, décider, exécuter ou déclencher. Là aussi l’Agentic Zero Trust est nécessaire.

De la policy à l’exécution

Les droits, outils autorisés, finalités et limites d’un agent se définissent en amont (« design-time policies ») en s’appuyant sur les sources d’informations (Policy Information Point, PIP).

Chaque action est évaluée par un PDP, encadrée à l’exécution par les PEP et tracée sans rupture pour assurer l’auditabilité. Le Policy-as-Code permet de formaliser, versionner, tester, auditer et propager ces règles vers les points d’exécution.

De la gouvernance à l’application des règles : le pari du Policy-as-Code dans une mutuelle d’assurance

Lors d’un projet de gouvernance des accès aux données mené au sein d’une grande société d’assurance mutualiste, nos équipes ont été confrontées à la complexité réelle de la gestion des accès.

Un même collaborateur pouvait appartenir à plusieurs groupes, exercer différentes responsabilités et accéder à des données réparties sur de multiples plateformes.

À cette diversité d’usages s’ajoutaient les niveaux de sensibilité des données, les restrictions d’accès à certaines informations ou à certains périmètres de données, ainsi que les exigences réglementaires propres à certains métiers.

Sécuriser la chaîne de confiance avec la passerelle IA et les bases de données

Dans cette architecture, il importe de sécuriser chaîne de confiance qui lie l’identité de l’agent, ses actions et les données qu’il manipule. La sécurité repose sur la passerelle IA (AI Gateway et sources d’informations du SI).

L’AI Gateway comme point de contrôle

Dans une architecture agentique, il est nécessaire de disposer d’un point de contrôle central chargé de superviser les échanges entre les agents IA et les serveurs MCP. C’est le rôle de l’AI Gateway (passerelle IA).

Cette passerelle IA surveille, entre autres, quelles méthodes il emploie et s’il ne dépasse pas ses quotas autorisées aux serveurs MCP et aux appels aux API exposant des sources d’informations. Elle assure une traçabilité complète et alimente l’observabilité.

Minimisation dès la source par les plateformes de données

Pendant que l’AI Gateway surveille les mouvements de l’agent, les plateformes de données assurent une protection physique au plus près de la source.

Elles appliquent alors le principe de minimisation, qui consiste à ne donner à l’IA que le strict nécessaire pour sa mission : masquage, filtrage, agrégation ou exclusion d’informations sensibles.

Industrialiser par une approche Policy-as-Code

Sans structuration, la combinaison entre profils de droits, sources, outils et finalités devient ingérable.

L’industrialisation passe par le Policy-as-Code: politiques définies, versionnées, et propagées automatiquement, avec traçabilité complète. Ce modèle exige un socle de gouvernance solide : données classifiées, niveaux de sensibilité définis, finalités clarifiées, responsabilités établies entre Data Owners, DPO, sécurité et Applications Owners.

Construire une architecture de confiance

Construire des architectures Agentic Zero Trust, c’est garantir que chaque action d’un agent est explicitement autorisée, contextualisée, limitée, contrôlée au niveau des appels (via l’AI Gateway), sécurisée au plus près de la donnée et auditée de bout en bout.

Le LLM peut raisonner, mais il ne doit jamais décider seul de ce qu’il est autorisé à faire.

En somme, déployer une architecture Agentic Zero Trust suppose de construire une véritable chaîne de confiance, depuis la définition des droits jusqu’à la capacité à démontrer qu’ils ont été respectés.

Synthèse de la chaîne de confiance

• Qui : les droits se définissent en amont
• Quoi : la data gouvernance qualifie
• Qui × Quoi : le PDP décide au runtime
• Comment : le Policy-as-Code industrialise
• Interactions : l’AI Gateway contrôle les échanges agentiques
• Application des règles : les PEP appliquent les règles
• Vérification : l’observabilité contrôle le respect des règles
• Preuve : l’audit démontre.

Le succès de l’IA agentique reposera avant tout sur la capacité des entreprises à construire une architecture de confiance ; celle qui gouverne l’identité, la donnée, les outils, les décisions et les actions. [SB1] [FM2]

Notre conviction est que l’Agentic Zero Trust constitue l’extension d’une architecture de confiance plus large. Et le Policy-as-Code en est l’élément central.

Il formalise des règles communes applicables aux actions humaines comme agentiques, et les déploie vers les bons points de contrôle pour garantir qu’à chaque instant, une action d’agent reste autorisée, limitée, observée et prouvable (PDP + PEP).

Pour conserver une gouvernance cohérente malgré cette complexité, les équipes ont distingué deux informations essentielles : qui accède aux données et à quelles données il souhaite accéder.

Le premier volet, le « qui », décrit l’utilisateur : son métier, son rôle, son équipe et les droits qui lui sont attribués. Ces informations sont gérées dans les systèmes de gestion des identités et des accès.

Le second volet, le « quoi », décrit les données elles-mêmes : leur domaine métier, leur niveau de sensibilité et les usages qui en sont autorisés. Ces informations sont centralisées dans le catalogue de données.

Le Policy-as-Code fait ensuite le lien entre ces deux univers. Il combine les caractéristiques de l’utilisateur et celles des données pour déterminer les règles d’accès à appliquer. Il les traduit ensuite automatiquement pour les différentes plateformes concernées.

Cette approche apporte une gouvernance homogène à l’échelle de l’entreprise, tout en simplifiant les opérations. Elle offre également un cadre unique de traçabilité, d’audit et de contrôle, indispensable lorsque les règles d’accès doivent être démontrées, expliquées et vérifiées.

Comme nous l’avons évoqué, cette logique vaut autant les protagonistes humains que les agents IA. Ces acteurs numériques doivent être soumis aux mêmes principes de contrôle, de traçabilité et de conformité que les collaborateurs humains. Une analogie simple illustre le rôle des différents mécanismes impliqués. Inspirons-nous de celle du code de la route.

Un code de la route pour les agents IA

Le Policy-as-Code et le PDP jouent le rôle du législateur. Ils définissent les règles, à savoir qui peut passer, à quelle vitesse, avec quelles restrictions.

Les PEP sont les feux, barrières et panneaux qui appliquent la règle au moment de l’action.

Mais comme sur la route, édicter des lois ne suffit pas, encore faut-il en vérifier le respect. C’est là qu’intervient l’observabilité IA, à la fois policier, radar et boîte noire. Elle détecte les comportements anormaux, trace les appels d’outils, surveille les accès aux données et documente les incidents.

Elle est aussi en mesure de lever des alertes en temps réel ou de bloquer tout trafic qui contreviendrait aux réglementations en vigueur (RGPD, AI-Act, etc.).

Analogie avec un principe fondamental de la physique quantique

Quelle analogie avec les agents IA ?  Sans cadrage préalable, le comportement réel d’un agent est connu qu’après observation de ses activités.

Le principe d’incertitude de Heisenberg établit qu’en physique quantique certaines propriétés d’une particule ne peuvent être connues simultanément avec une précision parfaite.

Sans cadrage préalable, le comportement d’un agent IA est connue qu’après observation. La Data & IA Observability couvre le suivi des prompts, sources de données impliquées, coûts, erreurs ou hallucinations. Observer un agent réduit l’incertitude sur ce qu’il a fait, mais ne garantit pas ce qu’il était autorisé à le faire. C’est l’objectif de l’Agentic Zero Trust que de fixer en amont les droits, limites et conditions d’usage et légitimé des agents IA.

Agentic Zero Trust encadre un agent avant qu’il ne se promène dans le SI. L’observabilité IA et Data offre la traçabilité sur ce qui a été exécuté et avec quels écarts éventuels vis-à-vis des règles de conformités (par exemple : RGPD, AI Act).

Sortir de l’illusion de sécurité des LLM

Un prompt n’est pas un pare-feu. La sécurité repose en effet une chaîne de confiance technique où chaque demande de l’agent est filtrée par un juge impartial avant d’être exécutée.

Confier au LLM la responsabilité de ne pas exploiter une donnée sensible dans un contexte inapproprié est une faille de conception. Un prompt système peut rappeler une règle, il ne la rend pas exécutable. Le prompt ne bloque pas un outil, ne masque pas une colonne, ne filtre pas une ligne, ne stoppe pas une action dangereuse, ne constitue pas une preuve d’audit. Autant coller un Post-it sur un dossier confidentiel avec la mention « Ne pas lire ». Rien ne garantit que l’IA tienne compte de la consigne.

La réponse doit être systémique.

Pour le dire autrement, la sécurité doit être extérieure à l’IA. Pour que le système puisse protéger les données, il doit d’abord savoir ce qu’elles contiennent. C’est le rôle du Data Office, garant du « quoi ». Il fournit le socle de métadonnées nécessaires à une automatisation et une gouvernance de bout en bout du socle Agentic Zero Trust.

Ce socle repose sur un catalogue fiable des données et des applications exposées, des classifications de sensibilité claires, des règles de minimisation formalisées ainsi que des finalités d’usage explicitement définies.

Les modèles de droits doivent évoluer pour intégrer les nouvelles identités non humaines (NHI), les périmètres de délégation, les outils autorisés, les finalités permises et les contraintes de minimisation à imposer.

Chaque accès doit être rattaché à un but précis. Cette qualification conditionne la capacité du moteur de décision (PDP) à statuer en temps réel sur la légitimité d’une requête d’agent. Celle-ci peut-être « cet agent est-il autorisé à utiliser cet outil, pour cette finalité, sur ces données et sous quelles conditions ? »

Le PEP s’appuie sur le PDP pour interdire l’accès si nécessaire. (Un prompt qui par exemple demande les salaires de tous les employés).