L’IA agentique force le Zero Trust à affronter une crise d’identité

L’IA agentique a fait son entrée dans Google News avec une affirmation saisissante : les systèmes autonomes bouleverseraient la cybersécurité Zero Trust. Le titre de Breaking Defense met en évidence un véritable conflit, même si les détails sous-jacents restent difficiles à vérifier de manière indépendante. Les équipes de sécurité ont construit les contrôles d’accès autour des personnes, des appareils et d’applications prévisibles. Les agents d’IA brouillent désormais ces trois catégories tout en agissant avec une autorité déléguée.

Cela ne rend pas le Zero Trust obsolète. Cela modifie ce que les organisations doivent vérifier, la fréquence de ces vérifications et l’identité ayant exécuté chaque action. Un agent peut interpréter un objectif, sélectionner des outils, lire du contenu externe, appeler des API et modifier des données. Son comportement ne se résume pas pleinement aux autorisations attribuées à son propriétaire humain.

Il en résulte un renversement inconfortable. Le Zero Trust suppose que chaque requête doit être évaluée, tandis que les flux de travail agentiques génèrent de longues chaînes de requêtes à la vitesse des machines. Le véritable enjeu n’oppose donc pas l’IA agentique au Zero Trust. Il oppose le contrôle d’accès statique au contrôle continu des comportements autonomes.

L’affirmation de Google News révèle une véritable évolution de la sécurité

Le changement essentiel ne tient pas au fait que l’IA peut accéder aux systèmes d’entreprise, mais au fait qu’elle peut décider quoi faire après y avoir accédé.

Les logiciels traditionnels suivent des chemins définis à l’avance par les développeurs. Ils peuvent contenir des bugs, accepter des entrées malveillantes ou exposer des interfaces vulnérables. Les défenseurs peuvent toutefois généralement relier leurs fonctions prévues à des comptes, processus et connexions réseau établis.

L’IA agentique ajoute une couche de décision entre l’instruction d’un utilisateur et l’action qui en résulte. Un agent peut décomposer un objectif général en tâches plus petites, choisir parmi les outils disponibles et s’adapter lorsqu’une voie échoue. Le NIST décrit les agents modernes comme des modèles généralistes associés à des logiciels leur permettant de manipuler des outils au-delà de la génération de texte.

Ces outils peuvent inclure des navigateurs, des bases de données, des calendriers, des interpréteurs de code, des fichiers locaux et des interfaces administratives. La taxonomie de l’utilisation d’outils du NIST distingue l’accès en lecture seule de l’accès en écriture restreint ou non restreint. Elle distingue également les environnements de confiance des environnements non fiables.

Cette distinction compte, car un seul agent traverse souvent plusieurs catégories au cours d’une même mission. Il peut lire un e-mail, extraire un numéro de client, interroger une base de données interne et mettre à jour un dossier de support. Chaque étape peut sembler autorisée lorsqu’elle est examinée séparément.

Le flux de travail combiné peut néanmoins produire un résultat dangereux. Un attaquant pourrait placer des instructions cachées dans l’e-mail. L’agent pourrait interpréter ces instructions comme faisant partie de sa tâche, puis utiliser des autorisations légitimes pour divulguer des données.

Cette attaque est appelée injection indirecte de prompt : des instructions malveillantes parviennent à un agent par le contenu qu’il traite. L’attaquant n’a pas besoin du mot de passe de l’employé. Il cible l’interprétation, par l’agent, des informations fiables et non fiables.

Le titre de Google News illustre cette évolution avec l’expression « bouleverser ». Auparavant, les équipes de sécurité craignaient que des personnes fassent un mauvais usage des logiciels ou compromettent leurs identifiants. Elles doivent désormais aussi tenir compte de logiciels qui interprètent l’autorité d’une personne et agissent de manière indépendante dans ce cadre.

Il ne s’agit pas simplement d’un terminal supplémentaire entrant sur le réseau. Un terminal possède normalement une fonction, une posture et un modèle de propriété relativement stables. Un agent peut modifier son plan immédiat tout en conservant la même identité, les mêmes identifiants et la même connexion.

Cela crée un problème de visibilité. Un journal peut indiquer qu’un compte de service valide a accédé à une base de données. Il peut ne pas révéler quel utilisateur a initié la tâche, quel agent a élaboré le plan ou quelle entrée externe a influencé la décision.

Le titre doit néanmoins être considéré comme une thèse, et non comme la preuve d’une violation spécifique. Aucun détail d’incident vérifié n’accompagne l’élément Google News fourni. Le problème de sécurité plus large est toutefois étayé par des recherches publiques et des travaux de normalisation en cours.

Les équipes de sécurité ne protègent plus uniquement les accès d’un humain à une application et d’une application à une autre. Elles doivent sécuriser une chaîne reliant un humain, un agent, un modèle, plusieurs outils et de multiples sources de données. La confiance peut se perdre à chaque transfert.

Le Zero Trust a été conçu pour les requêtes, pas pour les objectifs ouverts

Le Zero Trust reste pertinent, mais son unité de contrôle conventionnelle est trop étroite pour le travail autonome.

Le NIST a publié son architecture Zero Trust fondatrice en 2020. Ce modèle rejette la confiance implicite fondée sur l’emplacement réseau ou la propriété d’un actif. L’authentification et l’autorisation interviennent avant qu’une session n’atteigne une ressource de l’entreprise.

L’architecture se concentre sur les ressources plutôt que sur les segments réseau traditionnels. Elle suppose qu’un réseau peut déjà être compromis. L’accès doit donc rester limité au plus petit ensemble d’autorisations requis pour une mission précise.

Cette approche répond à l’ancien modèle du périmètre. Dans le cadre de la sécurité périmétrique, les utilisateurs authentifiés bénéficiaient souvent d’un accès étendu après avoir pénétré dans un réseau de confiance. Les attaquants pouvaient ensuite se déplacer latéralement entre les systèmes après avoir compromis un compte ou un appareil.

L’IA agentique n’invalide pas ces principes. Au contraire, le principe du moindre privilège et l’évaluation continue deviennent plus importants lorsque les machines peuvent exécuter rapidement de nombreuses actions. La difficulté consiste à traduire un objectif général de l’utilisateur en autorisations applicables et de courte durée.

Prenons le cas d’un agent chargé de préparer un rapport trimestriel sur les risques clients. La tâche semble informative, mais son exécution peut nécessiter plusieurs capacités. L’agent doit localiser des dossiers, croiser des données, calculer des tendances et produire un document.

L’agent doit-il recevoir l’accès à chaque dossier client pendant toute la durée de la mission ? Doit-il conserver ces autorisations ensuite ? Peut-il envoyer le rapport par e-mail, ou sa diffusion doit-elle nécessiter une approbation distincte ?

Un système d’accès conventionnel peut répondre à ces questions en s’appuyant sur le rôle existant de l’utilisateur. Si l’employé peut lire la base de données et envoyer des e-mails, l’agent hérite de ces deux pouvoirs. Cet héritage est simple, mais il crée une autorité excessive.

L’agent peut combiner des actions que l’employé n’avait jamais envisagées. Il peut aussi les répéter à une échelle que les flux de travail manuels atteignent rarement. Une petite erreur d’interprétation peut se transformer en centaines de requêtes de base de données ou de messages.

Les objectifs ouverts compliquent la conception des politiques. « Trouver les éléments de preuve pertinents » ne précise pas quels référentiels doivent être recherchés. « Résoudre le problème » ne définit pas si l’agent peut émettre un remboursement, modifier un compte ou exécuter du code.

Le Zero Trust évalue traditionnellement les requêtes d’accès en fonction de l’identité, de l’état de santé de l’appareil, de la sensibilité de la ressource et du contexte environnemental. Les systèmes agentiques ajoutent une autre question : cette action reste-t-elle cohérente avec la tâche qui a justifié l’accès ?

Cette question exige des contrôles tenant compte de l’intention. Ces contrôles comparent une action à l’objectif assigné à l’agent, à son plan actuel et à la politique approuvée. Ils ne peuvent pas dépendre uniquement du fait qu’un compte détient techniquement une autorisation.

La frontière de sécurité se déplace également dans le travail multi-agents. Un agent peut déléguer la recherche à un autre agent. Ce second agent peut appeler un service tiers, qui renvoie du contenu contenant de nouvelles instructions.

Chaque transfert peut modifier le contexte tout en préservant une autorisation apparente. Une politique statique voit des identités approuvées transmettre des données. Une politique comportementale doit déterminer si l’ensemble de la chaîne sert toujours l’objectif initial.

C’est pourquoi la sécurité de l’IA agentique ne peut pas s’arrêter à la segmentation réseau. Le plan de contrôle doit comprendre les identités, les tâches, les outils, la traçabilité des données et l’historique des actions. Il doit également préserver ces relations pour les investigations ultérieures.

La promesse initiale du Zero Trust demeure : ne jamais accorder sa confiance simplement parce que quelque chose se trouve déjà à l’intérieur. Les flux de travail agentiques révèlent simplement que « à l’intérieur » peut décrire une fenêtre de contexte, une tâche déléguée ou une chaîne d’outils. Cela ne renvoie plus uniquement à un réseau.

Les agents d’IA ont besoin d’identités distinctes de celles de leurs propriétaires

Une organisation ne peut pas gouverner un agent autonome si chaque action apparaît sous un compte humain ou un compte de service partagé.

L’identité constitue le premier point de pression pour les équipes de sécurité d’entreprise. Les personnes ont des dossiers d’emploi, des responsables, des fonctions et des procédures de départ. Les applications ont des propriétaires, des processus de publication et des comptes de service.

Les agents combinent des caractéristiques de ces deux groupes. Ils peuvent recevoir des objectifs de personnes, mais ils s’exécutent par logiciel. Ils peuvent fonctionner brièvement pour une tâche ou continuer à tourner comme des travailleurs numériques persistants.

Traiter un agent comme une fonctionnalité cachée au sein d’une application masque la responsabilité. Le traiter comme un employé ordinaire crée également un faux sentiment de confiance. L’agent a besoin d’une identité machine de premier rang, liée à son propriétaire, à son objectif et à son déploiement.

Cette identité ne doit pas remplacer celle de l’utilisateur à l’origine de la demande. Les deux doivent être conservées tout au long du flux de travail. Les enquêteurs doivent savoir qui a demandé une action et quel agent l’a exécutée.

Un enregistrement d’audit utile doit également capturer le modèle, l’outil, la politique et la source de données concernés. Sans ce contexte, un journal de base de données ne montre que l’accès final. Il ne peut pas expliquer pourquoi l’agent a estimé que cet accès était approprié.

Les équipes de sécurité doivent éviter les identifiants partagés pour les déploiements d’agents. Les comptes partagés empêchent une attribution fiable et compliquent la révocation. Ils permettent également à des agents abandonnés de rester actifs après la fin de leurs projets d’origine.

L’identité d’un agent nécessite un cycle de vie. Sa création doit identifier un propriétaire responsable et un usage approuvé. Des revues périodiques doivent confirmer que l’agent reste nécessaire et que ses autorisations correspondent toujours à son objectif.

L’expiration est tout aussi importante. Les agents temporaires doivent perdre leur accès lorsqu’une tâche ou un projet prend fin. Les agents persistants doivent faire l’objet d’une recertification régulière, tout comme les comptes humains privilégiés.

Les autorisations doivent également être spécifiques à la tâche et de courte durée. Un agent préparant un rapport peut recevoir un accès temporaire en lecture à certains dossiers. L’envoi de ce rapport hors de l’organisation doit nécessiter une autorisation distincte ou une confirmation humaine.

Cette conception réduit la dérive des privilèges, qui survient lorsque les identités accumulent des accès ne correspondant plus à leurs responsabilités. La dérive des privilèges est déjà difficile à gérer chez les employés. Les agents autonomes peuvent multiplier le problème, car les équipes peuvent les créer rapidement.

La découverte des agents devient donc une exigence opérationnelle. Les équipes de sécurité ont besoin d’un inventaire couvrant les services SaaS, les plateformes de développement, les systèmes d’automatisation internes et les intégrations tierces. Les seuls registres d’achats n’identifieront pas les agents créés au sein de produits existants.

La découverte doit distinguer une fonctionnalité d’IA d’une identité agissante. Une fonctionnalité de synthèse qui ne lit qu’un document présente des risques différents de ceux d’un agent capable de rechercher dans des lecteurs et d’envoyer des messages. Les deux peuvent utiliser le même modèle.

Le propriétaire doit aussi être visible dans les politiques et les journaux. Lorsqu’un agent agit en dehors des attentes, les intervenants ont besoin d’une personne ou d’une équipe capable de le suspendre. L’automatisation anonyme crée des délais lors des incidents.

Les organisations utilisent déjà des identités non humaines pour les services, les charges de travail et les machines. Les identités d’agents prolongent cette discipline au lieu de la remplacer. La différence est que la politique doit tenir compte d’un comportement variable au sein d’un même rôle attribué.

Les grands fournisseurs de sécurité évoluent dans cette direction. Cisco a annoncé la découverte d’agents, des contrôles d’identité agentique et l’application de Model Context Protocol dans sa mise à jour sur la sécurité des agents. Model Context Protocol, ou MCP, relie les modèles à des outils et à des données externes.

Les annonces des fournisseurs ne constituent pas une preuve indépendante que ces contrôles fonctionnent dans tous les déploiements. Elles montrent néanmoins la direction que prend la concurrence. Les plateformes d’identité, les courtiers d’accès et les passerelles de sécurité cherchent tous à devenir le point de contrôle du trafic des agents.

Les acheteurs en entreprise devraient éviter de considérer une seule passerelle comme une solution complète. NIST souligne depuis longtemps qu’aucun fournisseur ne propose à lui seul une architecture Zero Trust complète. La sécurité agentique ajoute davantage de composants et davantage de risques d’application incohérente des contrôles.

La pression immédiate pèse sur les équipes de gestion des identités et des accès. Elles doivent prendre en charge des acteurs machine créés rapidement, sans reproduire le problème des comptes de service non gérés. Les attributions de rôles statiques ne suffiront pas.

Le détournement d’agents révèle les limites des vérifications statiques des autorisations

Un agent correctement authentifié peut tout de même effectuer la mauvaise action, car l’authentification ne valide pas son raisonnement.

L’argument le plus solide en faveur d’une refonte du Zero Trust provient des recherches sur le détournement d’agents. En mars 2026, NIST a publié les résultats d’une vaste compétition publique de red teaming couvrant 13 modèles de pointe. Plus de 400 participants ont mené plus de 250 000 tentatives d’attaque.

Au moins une attaque de détournement réussie a été identifiée contre chacun des modèles testés. Les modèles différaient dans leur résistance, mais leurs capacités ne prédisaient pas systématiquement leur sécurité. Certaines familles d’attaques se sont également transférées entre différents modèles et scénarios.

Ces résultats ne signifient pas que chaque agent déployé est facile à compromettre. Une compétition encourage des attaquants ciblés et peut ne pas reproduire tous les contrôles de production. Elle établit toutefois que la résistance au niveau du modèle ne peut, à elle seule, servir de frontière de sécurité.

NIST définit le détournement d’agents comme une attaque qui place des instructions malveillantes dans les données qu’un agent traite. L’objectif est de rediriger l’agent vers un comportement nuisible. Les conséquences potentielles incluent l’exfiltration de données ou l’exécution de code malveillant.

Le détail crucial est que l’agent utilise souvent des outils et des identifiants valides. Un pare-feu peut voir une connexion approuvée. Un système d’identité peut voir un compte authentifié. L’étape dangereuse se produit dans l’interprétation du contenu par l’agent.

Cela rend les listes d’autorisation statiques incomplètes. Autoriser un agent à lire des e-mails et à mettre à jour une base de données peut être nécessaire à son travail. La politique doit néanmoins empêcher qu’un e-mail redéfinisse ce que l’outil de base de données doit faire.

Les résultats du red team pertinents plaident en faveur d’une défense en profondeur. Les modèles doivent être évalués, mais les déploiements ont également besoin d’outils contraints, de frontières de données, de surveillance et de points d’approbation.

Les autorisations d’outils devraient refléter les conséquences, et non la commodité. Lire une page web publique présente des risques différents de l’exécution de code téléchargé. Interroger un dossier client diffère de sa suppression ou de son exportation.

Les outils à fort impact devraient exposer des opérations limitées. Un agent qui doit planifier une réunion ne devrait pas recevoir un contrôle illimité de la boîte mail. Un agent financier qui prépare un paiement ne devrait pas également l’approuver et le transmettre.

Ce principe s’appelle la séparation des tâches. Il empêche une identité de contrôler toutes les étapes d’un processus sensible. Les systèmes agentiques ont besoin de la même séparation, même lorsque l’automatisation rend la centralisation tentante.

L’approbation humaine reste utile aux frontières irréversibles. Les virements, suppressions, publications externes, déploiements en production et modifications d’identifiants méritent des vérifications explicites. L’approbation devrait afficher l’action prévue et le contexte pertinent.

Un bouton générique « autoriser » apporte peu de protection. Le réviseur doit savoir quel agent a demandé l’action, quelles données il a utilisées et quel effet l’approbation produira. Sinon, l’automatisation ne fait que déplacer l’ingénierie sociale vers l’écran d’approbation.

La surveillance devrait se concentrer sur les changements de comportement. Un agent qui accède soudainement à des dépôts inconnus peut indiquer un détournement ou une planification défaillante. Des appels d’outils échouant de façon répétée peuvent signaler qu’un agent teste les limites de son rôle.

Les limites de débit réduisent également les dommages causés par les erreurs. Une exécution à la vitesse des machines peut transformer une seule mauvaise décision en incident généralisé. Limiter le volume d’actions donne aux systèmes de surveillance et aux intervenants le temps d’agir.

Le sandboxing reste précieux, mais il ne doit pas créer une présomption de sécurité. Un agent peut causer des dommages sans s’échapper de son environnement d’exécution. Envoyer des données autorisées à la mauvaise destination peut ne nécessiter aucun exploit logiciel.

L’incertitude centrale est de savoir si les systèmes sensibles à l’intention peuvent prendre des décisions fiables sans bloquer le travail utile. Les plans des agents changent, les tâches métier comportent des ambiguïtés et les politiques ne peuvent anticiper toutes les exceptions légitimes.

Des contrôles excessivement stricts produiront des demandes d’approbation constantes. Les équipes pourraient alors accorder des autorisations plus larges pour rétablir la productivité. Cette réponse recrée exactement la confiance implicite que Zero Trust devait éliminer.

Des contrôles excessivement permissifs produisent l’échec inverse. Les agents fonctionnent sans heurt jusqu’à ce qu’une entrée malveillante ou une erreur de planification exploite leur autorité. Les équipes de sécurité doivent mesurer à la fois le travail bloqué et les actions non sûres.

Ce compromis empêche d’affirmer facilement qu’un produit « Zero Trust agentique » a résolu le problème. Les démonstrations de produits montrent généralement des flux de travail sélectionnés. Les déploiements réels contiennent des systèmes hérités, des identités partagées et des journaux incohérents.

L’approche la plus crédible à court terme est multicouche. Attribuez une identité à chaque agent, limitez chaque outil, conservez l’utilisateur à l’origine de la demande, validez les actions conséquentes et surveillez les comportements. Partez du principe que les garde-fous des modèles échoueront parfois.

La bataille concurrentielle se déplace vers le plan de contrôle

Les fournisseurs de sécurité rivalisent pour arbitrer le comportement des agents, tandis que les entreprises ne disposent toujours pas d’un modèle commun pour prouver que cet arbitrage fonctionne.

L’IA agentique crée des opportunités pour les fournisseurs d’identité, les fournisseurs de sécurité réseau, les plateformes cloud et les entreprises spécialisées dans la sécurité de l’IA. Chaque groupe contrôle une partie différente du flux de travail. Aucun ne voit automatiquement l’ensemble de la chaîne.

Les fournisseurs d’identité savent qui a reçu l’accès. Les plateformes réseau observent les connexions entre les systèmes. Les fournisseurs cloud peuvent surveiller les charges de travail et les appels API. Les outils de sécurité de l’IA inspectent les prompts, les sorties des modèles et les demandes d’outils.

La position la plus précieuse est le point de décision des politiques. Dans une architecture Zero Trust, ce composant évalue l’accès et décide si son application doit l’autoriser. Les systèmes agentiques rendent cette décision plus riche et plus contestée.

Un fournisseur réseau peut avancer que la communication des agents doit passer par un courtier de sécurité. Un fournisseur d’identité peut centrer la politique sur les identités machine et l’autorisation déléguée. Un fournisseur de sécurité de l’IA peut privilégier l’inspection des prompts et l’évaluation comportementale.

Ces trois visions contiennent chacune une partie de la réponse. Le contexte réseau ne peut révéler toutes les instructions malveillantes. L’inspection des prompts ne peut pas, à elle seule, faire appliquer le blocage d’une requête de base de données. La vérification d’identité ne peut garantir qu’un agent authentifié respecte son objectif.

MCP est devenu un point d’attention car il standardise les connexions entre les modèles et les outils. Une passerelle peut inventorier les serveurs, restreindre les opérations et enregistrer les appels. Cependant, tous les agents n’utilisent pas MCP, et une passerelle ne peut pas gouverner les outils qui la contournent.

La communication d’agent à agent présente un autre défi. La délégation peut traverser des modèles, des fournisseurs ou des frontières organisationnelles. L’agent destinataire a besoin de preuves concernant l’identité, l’autorité et le périmètre demandé de l’expéditeur.

Un message signé peut authentifier l’expéditeur. Il ne prouve pas que le plan de l’expéditeur est sûr. La politique doit distinguer la provenance, qui identifie l’origine d’une demande, de l’autorisation, qui détermine si elle doit se poursuivre.

Le travail de normalisation commence à combler ces lacunes. NIST a lancé son initiative sur les normes pour les agents en février 2026. Son programme couvre l’interopérabilité, les protocoles ouverts, la sécurité, l’identité et une adoption de confiance.

Cette initiative est importante car les organisations ont besoin de représentations comparables de l’identité et de l’autorité des agents. Sans formats communs, chaque plateforme crée des identités et des signaux de politique propriétaires. Les équipes de sécurité peinent alors à appliquer des contrôles dans tous les environnements.

Les normes seules ne peuvent pas trancher la tolérance au risque. Un hôpital, une banque, un sous-traitant de la défense et une agence marketing attribueront des conséquences différentes à la même action d’outil. L’interopérabilité fournit une infrastructure commune, pas une politique universelle.

Le cadrage de Breaking Defense est particulièrement pertinent dans les environnements à haute assurance. Les systèmes de défense combinent souvent des données classifiées, des contraintes de mission, des équipements hérités et une responsabilité stricte. Une action autonome peut avoir des conséquences qui dépassent largement l’automatisation bureautique ordinaire.

Ces environnements créent également une pression en faveur de l’automatisation. Les analystes font face à de grands volumes d’alertes, de documents et de données de capteurs. Les agents peuvent aider à corréler les informations et à exécuter des étapes répétitives, mais une autonomie accrue renforce le besoin d’un contrôle traçable.

La concurrence devrait donc être évaluée à travers des preuves, et non le vocabulaire produit. Les acheteurs doivent tester si un contrôle identifie les agents de manière fiable, rattache les actions à leurs responsables, limite les outils et produit des enregistrements d’audit exploitables.

Ils devraient également tester les cas de défaillance. Que se passe-t-il lorsque le fournisseur d’identité est indisponible ? Un agent peut-il recourir à des autorisations mises en cache ? Un courtier échoue-t-il en mode fermé, ou le trafic contourne-t-il l’inspection ?

La couverture multiplateforme compte autant que les fonctionnalités individuelles. Une organisation peut utiliser un modèle cloud, l’agent de programmation d’un autre fournisseur et plusieurs assistants SaaS. Un contrôle qui ne voit qu’un seul environnement laisse d’importants angles morts.

Le marché se consolidera probablement autour de plateformes intégrées, mais l’intégration peut créer son propre risque de concentration. Un plan de politique compromis pourrait affecter de nombreux agents. La journalisation et l’application indépendantes restent des garde-fous importants.

Google News peut amplifier les titres affirmant que l’IA agentique remplace les modèles de sécurité familiers. La conclusion plus exacte est plus limitée. Les fournisseurs existants doivent étendre Zero Trust des décisions de connexion à la gouvernance de l’identité, de l’intention et de l’action.

Ce que les équipes de sécurité devraient surveiller ensuite

La prochaine phase sera déterminée par des preuves de déploiement mesurables, et non par des affirmations plus larges sur la sécurité autonome.

Le premier signal sera de savoir si les groupes de normalisation produisent des spécifications exploitables pour l’identité des agents et l’autorisation déléguée. NIST a indiqué que son initiative développerait des recherches, des orientations et d’autres livrables. Les entreprises devraient surveiller l’apparition de formats qui fonctionnent chez plusieurs fournisseurs.

Une spécification d’identité utile doit relier un agent à un propriétaire, un objectif, un modèle et des outils approuvés. Elle devrait également préserver l’utilisateur initiateur lors de la délégation. Si les plateformes adoptent des représentations incompatibles, la gouvernance restera fragmentée.

Le deuxième signal est celui des tests de sécurité indépendants. La compétition de NIST a identifié des attaques réussies contre tous les modèles de pointe testés, mais les organisations ont besoin d’évaluations au niveau du déploiement. Les tests devraient inclure les modèles, les outils, les autorisations, la mémoire et les données externes.

Les tests comparatifs devraient mesurer davantage que le succès des injections de prompts. Ils devraient examiner si les agents dépassent le périmètre de leur tâche, utilisent mal des outils légitimes ou dissimulent des actions conséquentes dans de longs flux de travail. Ils devraient également tester la récupération et la qualité des audits.

Si le taux de réussite des attaques diminue tandis que les agents conservent des capacités utiles, la confiance dans les contrôles tenant compte de l’intention se renforcera. Si des modèles améliorés restent vulnérables dans des déploiements riches en outils, les contrôles d’infrastructure deviendront encore plus importants.

Le troisième signal concerne le comportement des entreprises après les pilotes. Les équipes de sécurité doivent suivre combien d’agents reçoivent des identités uniques, des identifiants limités et des responsables désignés. Elles doivent également mesurer les agents abandonnés et les autorisations non révisées.

Les chiffres d’adoption seuls révèlent peu de choses. Une entreprise peut déployer des milliers d’agents tout en les maintenant en lecture seule et isolés. Un seul agent disposant d’un large accès à la production peut présenter un risque plus important que l’ensemble de cette population.

Les rapports d’incident fourniront une autre vérification de la réalité. Les cas rendus publics devraient expliquer si les échecs proviennent d’une injection de prompt, de privilèges excessifs, d’une confusion d’identité ou de l’absence de limites d’approbation. Sans ces précisions, le secteur ne peut pas comparer les défenses.

Les responsables de la sécurité devraient poser des questions directes avant d’élargir un pilote :

• Chaque agent dispose-t-il d’une identité unique et d’un responsable identifiable ?

• Les autorisations peuvent-elles expirer automatiquement lorsque la tâche est terminée ?

• Les journaux conservent-ils à la fois la personne à l’origine de la demande et l’agent qui agit ?

• Quels outils peuvent provoquer des changements irréversibles ?

• Du contenu externe peut-il influencer ces appels d’outils ?

• Quel volume d’actions déclenche une révision ou une suspension ?

• Les équipes d’intervention peuvent-elles désactiver un agent sans arrêter toute la plateforme ?

• Les agents délégués sont-ils limités par la tâche d’origine ?

• Le système échoue-t-il en mode fermé lorsque les services de politique ne sont pas disponibles ?

• Les auditeurs peuvent-ils reconstituer pourquoi une action sensible a eu lieu ?

Ces questions transforment l’affirmation selon laquelle la situation est « renversée » en test de mise en œuvre. Si une plateforme ne peut pas y répondre, son discours sur le Zero Trust reste incomplet. Si elle le peut, l’architecture est peut-être déjà en train de s’adapter.

La conclusion la plus importante est que les organisations ne doivent pas abandonner le Zero Trust. Elles doivent l’appliquer à des unités d’autorité plus petites et plus dynamiques. Chaque agent, appel d’outil, délégation et action à conséquence mérite son propre contexte de politique.

Cette approche introduira des frictions. Certaines tâches automatisées exigeront des outils plus restreints ou une confirmation humaine. Certains pilotes ralentiront pendant que les équipes établiront des inventaires et des contrôles du cycle de vie.

L’alternative est une autorité cachée. Les agents hériteront de larges autorisations humaines, traiteront du contenu non fiable et laisseront des traces incomplètes. Les équipes de sécurité ne découvriront alors les flux de travail autonomes qu’après un incident.

L’IA agentique n’a pas vaincu le Zero Trust. Elle a révélé là où de nombreux programmes Zero Trust se sont arrêtés : à l’authentification, à l’accès réseau ou à la posture des appareils. La prochaine version doit gouverner ce que les machines authentifiées décident de faire.

La question soulevée via Google News mérite donc d’être conservée, même si le titre exagère le renversement. Votre organisation peut-elle retracer l’identité, l’objectif, les éléments de preuve et l’autorité d’un agent avant l’exécution de sa prochaine action ?

Commencez par un flux de travail de production et reconstituez cette chaîne du début à la fin. Si un transfert devient invisible, considérez-le comme une lacune de contrôle. Cet exercice offre davantage de valeur que l’adoption d’une nouvelle étiquette de sécurité, car il vérifie si le Zero Trust accompagne l’agent dans son travail réel.