Le principe de Zero Trust pour les agents IA s’applique après la connexion

Le principe de Zero Trust a été conçu pour corriger une ancienne hypothèse : si vous étiez à l’intérieur du réseau, vous étiez considéré comme fiable. Puis le Cloud, le SaaS et le télétravail ont remis ce modèle en cause. La sécurité s’est alors déplacée vers l’identité, la vérification des appareils, l’authentification forte (MFA), le moindre privilège et la vérification continue.

Mais désormais, avec les agents, la partie complexe commence après l’accès. L’agent lit un prompt, récupère du contexte, choisit un outil, appelle une API et peut déclencher un workflow. La connexion vous indique que l’agent est « fiable ». Cela ne vous indique pas si l’action suivante est pertinente.

Les agents héritent du problème des identités machine

Les équipes de sécurité ont déjà été confrontées à une version plus discrète de ce problème avec les identités machine. Les comptes de service, clés API, tokens et certificats sont créés pour un projet, se voient accorder des accès, puis restent actifs longtemps après l’évolution ou la fin du projet.

Ce problème est familier : privilèges permanents, propriétaires devenus obsolètes et journaux consultés seulement après qu’un incident s’est produit.

Les agents compliquent ce problème ancien en y ajoutant une dimension de jugement. Un compte de service suit généralement du code. Un agent interprète un objectif, lit du contexte en temps réel, choisit un outil et décide de ce qu’il faut essayer ensuite.

L’équipe chargée de la sécurité doit désormais couvrir chaque système auquel l’agent peut accéder, ainsi que chaque action qu’il est sur le point d’effectuer.

Le niveau d’autonomie détermine le niveau de contrôle nécessaire.

La note de mai 2026 de Gartner est utile ici, car elle permet de distinguer deux éléments souvent confondus : le degré d’autonomie d’un agent et le niveau d’accès dont il dispose.

La combinaison est importante. Un agent qui résume des documents a besoin d’un accès en lecture limité au périmètre nécessaire et de logs clairs. Un agent qui met à jour des enregistrements, écrit du code ou modifie des workflows doit disposer d’étapes d’approbation, de garde-fous renforcés, d’une surveillance, d’un responsable et d’un mécanisme de restauration.

L’échelle d’autonomie de Gartner constitue un bon point de départ : observer, conseiller, agir selon des approbations, agir de manière autonome. Chaque niveau doit s’accompagner d’un nombre accru de contrôles, car l’agent se rapproche progressivement d’une action métier.

C’est ici que réside la transformation vers le Zero Trust pour les agents. L’identité vous indique qui agit. Le contexte d’exécution vous indique si l’action est adaptée à la situation.

La décision de politique de sécurité doit s’appuyer sur les détails que l’équipe de sécurité perd généralement après la connexion : quelles données sont concernées, quel outil est appelé, quelle instruction a façonné la requête et quel système sera concerné ensuite.

Ce que les équipes de sécurité devraient faire maintenant

Commencer par un simple inventaire. Recenser les agents déjà utilisés, l’endroit où ils s’exécutent, les ressources auxquelles ils accèdent et les personnes qui en sont responsables.

Regrouper les agents selon leur environnement d’utilisation : agents de codage sur les endpoints, agents gérés au sein de plateformes SaaS, agents personnalisés développés par les équipes internes, et agents personnels ou tiers connectés via OAuth.

Classifier l’autonomie. L’agent se contente-t-il d’observer, de conseiller, d’agir selon des approbations ou d’agir de manière autonome ? Associer ce niveau d’autonomie à l’accès aux données, aux outils utilisés, aux actions autorisées, au responsable désigné et à un approbateur.

Utiliser le niveau d’autonomie comme première limite de contrôle, comme suggéré ci-dessous :

Délimiter les privilèges en fonction des actions. Donner à chaque action son propre traitement de sécurité. Lire un enregistrement et supprimer un enregistrement ont des conséquences très différentes pour l’entreprise.

Intégrer des garde-fous au chemin d’exécution et considérer les prompts ainsi que le contenu récupéré comme des entrées non fiables. Vérifier les réponses avant que des données sensibles ne soient exportées et valider les paramètres des appels d’outils avant leur exécution. Exiger une approbation humaine pour les actions à fort impact, telles que la suppression d’enregistrements, les mouvements financiers, les communications en masse ou les appels à des API externes.

Rendre la piste d’audit utile. Vous avez besoin des prompts, des réponses, des appels d’outils, des données consultées et des décisions de règle afin de comprendre ce qui s’est passé. Si l’agent se comporte de manière inattendue, l’équipe de sécurité doit disposer de suffisamment d’éléments pour bloquer l’action suivante et expliquer ce qui s’est produit.

L’architecture doit permettre de voir l’action.

L’équipe sécurité doit disposer d’un point d’inspection du prompt, de la réponse, de l’appel d’outil, des mouvements de données et de l’étape du workflow pendant que le traitement est en cours.

Cato AI Security for Agents s’intègre à ce point du flux. Cette solution détecte l’activité des agents, régit l’utilisation des outils et les flux de données, et maintient une visibilité exploitable pour les audits sur les outils, API, données et workflows.

La valeur réside dans le contexte entourant l’action. Lorsque le comportement de l’agent est analysé avec les données de contrôle des utilisateurs, des applications, du réseau, du SaaS et de la sécurité, l’investigation commence avec les preuves. Quel agent a été exécuté. Qui détient l’agent. Quelles données ont été transférées. Quel outil a été appelé.

Pour les dirigeants, cela se traduit par une gouvernance plus claire des utilisateurs, des applications et des agents. Pour les équipes de sécurité, cela signifie que le principe du Zero Trust peut suivre l’agent jusque dans l’exécution de son travail, au lieu de s’arrêter après la connexion.

Commencer par un seul workflow

Choisir un workflow d’agent déjà utilisé ou proche d’être utilisé en production. Cartographier l’identité, le niveau d’autonomie, l’accès aux données, les outils, les actions autorisées, les points d’approbation, les journaux et le chemin de restauration.

Cet exercice vous indiquera où sont les lacunes. Si vous ne pouvez pas voir l’action, l’approuver, l’arrêter ou l’expliquer par la suite, le contrôle est trop éloigné.

Le principe de Zero Trust pour les agents d’IA commence après la connexion, car c’est à ce moment-là que se prend la décision importante : cette action doit-elle avoir lieu, dans ces conditions, maintenant ?