Le secteur israélien de la cybersécurité mise sur l’identité comme prochain champ de bataille de la sécurité de l’IA

Le secteur israélien de la cybersécurité a fait un pari précis, désormais visible dans Google News : les contrôles d’identité deviendront la première ligne de défense contre les agents IA autonomes.

Ce pari redéfinit la manière dont les fournisseurs de sécurité conçoivent la menace liée à l’IA. Le problème immédiat ne se limite plus aux prompts malveillants, aux sorties de modèle dangereuses ou aux données confidentielles saisies dans un chatbot. Il concerne de plus en plus des agents logiciels qui reçoivent des identifiants, appellent des outils et modifient des systèmes métier sans approbation humaine continue.

Des entreprises israéliennes telles que CyberArk, Oasis Security, Apono, Silverfort et Astrix Security abordent ce problème depuis des positions différentes. Pourtant, leur orientation est remarquablement cohérente. Chacune considère un agent IA comme une identité active dont les accès doivent être découverts, limités, surveillés et révoqués.

La compétition émergente dépasse donc une seule catégorie de produits. Les systèmes d’identité traditionnels accordent des permissions à des utilisateurs et applications prévisibles. Le nouveau modèle doit gouverner des logiciels qui interprètent des instructions, sélectionnent des outils, délèguent des tâches et modifient leur comportement selon le contexte.

C’est là que réside la tension centrale. Les entreprises veulent que les agents accomplissent un travail utile sans attendre une approbation à chaque étape. Les équipes de sécurité ont besoin de suffisamment de contrôle pour empêcher qu’un agent compromis transforme un accès légitime en abus authentifié.

Le pari israélien passe de thèse de financement à stratégie produit

La sécurité des identités est devenue une course produit concrète parce que les agents IA commencent à franchir la frontière entre générer des réponses et effectuer des actions.

Les preuves sont visibles chez plusieurs fournisseurs israéliens. CyberArk a introduit Secure AI Agents comme extension de sa plateforme de sécurité des identités. Le produit applique des contrôles de privilèges aux agents autonomes dans les environnements cloud, logiciels et de développement.

Oasis Security est passé de la découverte d’identités non humaines à ce qu’il appelle la gestion des accès agentiques. Son approche évalue ce qu’un agent cherche à accomplir avant d’accorder des permissions étroitement limitées à cette tâche.

Apono a lancé Agent Privilege Guard selon le même principe. Le service relie l’activité des agents à un accès juste-à-temps, ce qui signifie que les identifiants ne deviennent disponibles que lorsqu’une action précise les exige. Ces permissions peuvent ensuite expirer au lieu de rester rattachées à un compte.

Silverfort et Astrix Security sont arrivés depuis des segments adjacents du marché de l’identité. Silverfort s’est concentré sur l’extension de l’authentification et de la protection des identités à travers les systèmes d’entreprise. Astrix s’est spécialisé dans les connexions non humaines, les comptes de service, les jetons et les accès applicatifs.

Ces entreprises ne proposent pas des technologies identiques. Certaines commencent par la découverte, d’autres par l’accès privilégié, l’autorisation ou la détection des menaces. Leur principe commun compte davantage que leurs différences : un agent IA ne doit pas hériter d’une autorité étendue simplement parce qu’un humain a initié sa tâche.

Ce principe a pris du poids commercial lorsqu’Oasis a fait état d’une forte demande des entreprises et d’un important tour de financement. Selon un profil de financement de l’entreprise, Oasis a déclaré que ses nouveaux revenus annuels récurrents avaient été multipliés par cinq au cours de l’année précédente.

L’entreprise a également déclaré que la plupart de ses clients étaient de grandes entreprises, dont beaucoup signaient des contrats pluriannuels. Ces affirmations n’ont pas fait l’objet d’un audit indépendant dans les informations publiées. Elles indiquent néanmoins que les contrôles d’identité se rapprochent des budgets consacrés aux infrastructures critiques.

CyberArk a fourni un autre signal lorsqu’il a rendu son produit de sécurité des agents généralement disponible. Son annonce sur la sécurité des agents présentait la découverte, l’accès sécurisé, la détection en temps réel et la gestion du cycle de vie comme une couche de contrôle unifiée.

Ce conditionnement est important. Il transforme la sécurité des agents IA, qui était un problème spécialisé de sûreté des modèles, en une extension des opérations d’identité. L’acheteur devient l’équipe déjà responsable des identifiants, des permissions, des comptes privilégiés et des revues d’accès.

Cette évolution explique également pourquoi des plateformes établies et de jeunes startups peuvent se concurrencer sur le même marché. Les grands fournisseurs disposent d’une distribution en entreprise et de données d’identité existantes. Les startups peuvent repenser l’autorisation autour d’une activité d’agent dynamique et de courte durée, sans devoir prendre en charge des décennies d’architecture héritée.

La course a dépassé la simple prévision d’une menace future. Les fournisseurs doivent désormais démontrer que leurs contrôles fonctionnent au sein de véritables workflows d’agents sans rendre ces workflows inutilisablement lents.

Pourquoi Google News se remplit de sécurité des identités pour l’IA

L’augmentation de la couverture dans Google News reflète un véritable changement architectural : les systèmes d’IA acquièrent la capacité d’agir via des connexions d’entreprise de confiance.

Un chatbot classique produit du texte qu’une personne peut examiner. Un agent IA peut appeler une interface de programmation d’application, interroger une base de données, mettre à jour une fiche client ou initier un déploiement logiciel. Chaque action dépend d’une forme d’identité et d’autorité déléguée.

Cette autorité crée un risque plus important qu’une simple réponse erronée. Un chatbot qui hallucine peut induire son lecteur en erreur. Un agent qui hallucine et dispose d’un accès en écriture peut modifier des données de production avant que quiconque ne remarque l’erreur.

Cette distinction modifie également le sens de l’authentification. L’authentification établit quelle identité effectue une requête. L’autorisation détermine si cette identité peut exécuter l’action demandée. Un agent a besoin des deux, mais aucun de ces contrôles n’est suffisant s’il n’est appliqué qu’une seule fois.

Prenons un agent de programmation chargé de diagnostiquer un incident de production. Il pourrait nécessiter un accès en lecture aux journaux, un accès temporaire à un dépôt et l’autorisation de redémarrer un service. Lui attribuer des identifiants d’administrateur permanents faciliterait la tâche, mais augmenterait également les dommages possibles en cas d’injection de prompt ou de compromission.

Une conception plus sûre attribue à l’agent une identité unique et lui accorde une permission limitée pour la tâche immédiate. Le système enregistre qui a demandé l’action, quel agent l’a exécutée, quelles ressources il a touchées et quand son accès a expiré.

Cette approche est souvent décrite comme le moindre privilège, l’accès juste-à-temps ou l’absence de privilèges permanents. Le moindre privilège limite l’accès à ce qu’exige une tâche. L’accès juste-à-temps ne l’accorde qu’au moment nécessaire. L’absence de privilèges permanents supprime l’autorité persistante entre les opérations approuvées.

Il s’agit de concepts de sécurité établis. La difficulté consiste à les appliquer à des agents qui raisonnent sur plusieurs étapes et peuvent appeler d’autres agents. Le système d’autorisation doit distinguer une adaptation légitime d’un comportement qui est sorti du cadre de la tâche approuvée.

La question est devenue suffisamment importante pour attirer des travaux de normalisation. En février 2026, le National Institute of Standards and Technology américain a annoncé une initiative axée sur des agents IA interopérables et sécurisés.

Son initiative sur les normes relatives aux agents comprend des recherches sur l’authentification des agents, l’infrastructure d’identité et les interactions sécurisées entre humains et agents. NIST a également proposé des travaux couvrant l’autorisation, l’audit, la non-répudiation et les contrôles contre l’injection de prompts.

La non-répudiation consiste à créer des preuves qu’une partie identifiée a réalisé une action particulière. Elle devient difficile lorsqu’une requête humaine déclenche plusieurs agents, des identifiants temporaires et des appels d’outils automatisés.

Google News capte donc davantage qu’une campagne marketing coordonnée. Les organismes de normalisation, les fournisseurs établis, les investisseurs et les équipes de sécurité d’entreprise convergent vers le même point de contrôle encore non résolu.

Toutefois, une couverture répétée ne permet pas d’établir quelle architecture de fournisseur l’emportera. Elle montre que le problème est devenu suffisamment intelligible pour que plusieurs marchés se structurent autour de lui.

Ces marchés comprennent la découverte des agents, la gestion des identifiants, l’autorisation à l’exécution, la détection des menaces liées aux identités, les pistes d’audit et l’application des politiques. Ils se chevaucheront, et les acheteurs résisteront à l’idée d’exploiter une console distincte pour chaque couche.

Les gagnants finaux devront relier ces fonctions sans confondre visibilité et contrôle. Découvrir un agent est utile. Montrer ses permissions excessives est mieux. Empêcher une action dangereuse tout en autorisant un travail légitime est l’étape plus difficile et plus précieuse.

Les agents autonomes mettent sous pression le contrôle d’accès traditionnel

La compétition principale oppose des permissions statiques conçues pour des logiciels prévisibles à une autorisation à l’exécution conçue pour des agents dont les actions changent selon le contexte.

La gestion traditionnelle des identités et des accès fonctionne bien lorsque les administrateurs peuvent définir une relation stable entre un utilisateur, un rôle et une ressource. Un comptable appartient à un groupe financier. Un serveur reçoit un compte de service. Une application planifiée utilise un identifiant connu.

Les agents IA fragilisent ces hypothèses. Un même agent peut résumer des documents lors d’une session, mettre à jour un suivi de projet lors d’une autre et invoquer des outils de déploiement lors d’une troisième. L’autorité dont il a besoin change selon l’objectif, l’environnement et les données.

Le contrôle d’accès basé sur les rôles peut attribuer à l’agent un rôle prédéfini. Pourtant, un rôle étendu risque d’accorder davantage d’accès qu’une tâche ne l’exige. Créer un nouveau rôle pour chaque tâche temporaire peut engendrer une surcharge administrative.

L’accès fondé sur l’intention tente de résoudre ce problème en évaluant l’action proposée et sa finalité à l’exécution. Oasis et Apono utilisent tous deux des variantes de ce langage, même si leurs implémentations et leurs points d’application diffèrent.

Apono affirme que son Privilege Guard peut placer les décisions d’accès entre un agent et l’infrastructure d’entreprise. Les demandes à plus haut risque peuvent déclencher une approbation humaine, tandis que les tâches autorisées reçoivent un accès temporaire.

Oasis décrit un processus qui convertit le travail prévu d’un agent en un plan d’action plus précis. Son système peut ensuite calculer quelles ressources et permissions ce plan nécessite.

La promesse est séduisante. Un agent peut continuer à progresser dans les opérations à faible risque tandis que la politique de sécurité bloque ou fait remonter les actions sensibles. Les entreprises obtiennent de l’automatisation sans accorder au modèle une autorité administrative permanente.

La difficulté réside dans la détermination fiable de l’intention. Une requête en langage naturel ne prédit pas toujours la séquence finale d’appels d’outils. Le contexte peut changer, des données externes peuvent contenir des instructions hostiles et un agent peut déléguer une partie de sa tâche.

Un moteur de politiques doit donc évaluer plus que le prompt initial. Il a besoin de l’identité de l’agent, du sponsor humain, de la ressource demandée, de l’action en cours, de la portée des identifiants, du risque environnemental et du comportement antérieur.

Cette exigence met les fournisseurs d’identité historiques sous pression. Leurs systèmes existants contiennent des informations précieuses sur les utilisateurs, les groupes, les comptes et les permissions. Ils peuvent manquer de contexte détaillé sur la raison pour laquelle un agent invoque un outil particulier à un moment donné.

Les startups font face au problème inverse. Elles peuvent se construire autour du comportement dynamique des agents, mais doivent s’intégrer à de nombreux clouds, bases de données, plateformes logicielles et fournisseurs d’identité. Un produit d’autorisation ne peut pas protéger une connexion qu’il ne voit pas.

La concurrence qui en résulte ne se résume pas à startups contre acteurs historiques. C’est une compétition autour du plan de contrôle, c’est-à-dire la couche où les organisations définissent et appliquent qui peut faire quoi.

CyberArk apporte la gestion des accès privilégiés et ses relations existantes avec les entreprises. Okta apporte l’identité des collaborateurs et l’accès aux applications. Les plateformes cloud contrôlent une grande partie des identifiants que les agents utiliseront. Les développeurs d’agents peuvent aussi intégrer l’autorisation dans leurs propres frameworks.

Cette fragmentation pose une question inconfortable aux acheteurs. L’autorité des agents doit-elle résider dans une plateforme d’identité, un produit de sécurité cloud, le framework de l’agent ou une passerelle d’application dédiée ?

Placer le contrôle uniquement à l’intérieur de l’agent est risqué, car un agent compromis ne peut pas être son propre gardien de confiance. Placer chaque décision dans une passerelle externe peut introduire de la latence et faire perdre le contexte détenu par l’agent.

L’architecture la plus probable répartira les responsabilités. Les frameworks d’agents fourniront le contexte des tâches et la traçabilité. Des systèmes de politiques indépendants émettront des identifiants à portée limitée et appliqueront des restrictions. Les plateformes d’identité assureront la propriété, le cycle de vie et les registres d’audit.

Cette répartition nécessite toujours des normes communes. Sans elles, chaque fournisseur décrira différemment les agents, l’autorité déléguée et les journaux d’actions. Les entreprises pourraient se retrouver avec plusieurs enregistrements d’identité incompatibles pour le même processus autonome.

Pour les équipes d’ingénierie, il s’agit également d’un problème de connaissance. Les politiques de sécurité dépendent de la compréhension de l’agent qui a accédé à quels documents locaux, dépôts et outils internes. Une base de connaissances d’ingénierie consultable peut améliorer le contexte, mais l’autorisation doit rester distincte de la récupération d’informations.

La frontière essentielle est simple. L’accès à un contexte utile n’implique pas l’autorisation de modifier le système source. La récupération, le raisonnement et l’exécution exigent des contrôles distincts.

La thèse de l’identité résout l’accès, pas tous les risques liés à l’IA

Traiter les agents comme des identités crée un point de contrôle nécessaire, mais ne rend ni leur raisonnement prévisible ni leurs instructions fiables.

La critique la plus forte de la thèse de l’identité n’est pas que le contrôle d’accès soit inutile. C’est que les fournisseurs d’identité pourraient présenter un problème plus large de sécurité de l’IA à travers les produits qu’ils savent déjà vendre.

Un agent authentifié peut tout de même effectuer une action nuisible. Le système peut savoir exactement quel agent a supprimé un enregistrement tout en échouant à empêcher cette suppression. L’identité établit la responsabilité, pas la justesse.

Le principe du moindre privilège dépend aussi de politiques précises. Si un agent a légitimement besoin d’un accès étendu pour une tâche complexe, le périmètre d’impact autorisé reste important. Un identifiant étroitement délimité peut toujours autoriser la mauvaise opération dans ce périmètre.

L’injection de prompt crée une autre faille. Une instruction malveillante cachée dans un document ou une page web peut détourner le comportement d’un agent. L’agent reste correctement authentifié tout en agissant sur une entrée non fiable.

L’autorisation à l’exécution peut limiter les conséquences, mais seulement si la politique reconnaît que l’action demandée dépasse la tâche prévue. Cette détection devient plus difficile lorsque la demande malveillante ressemble à un travail normal.

La délégation complique encore l’attribution. Un utilisateur peut autoriser un agent, qui appelle ensuite un autre agent par l’intermédiaire d’un service externe. Le second agent peut invoquer plusieurs outils avec des identifiants dérivés de la première requête.

Les équipes de sécurité ont besoin d’une chaîne de preuves reliant le sponsor humain, l’agent principal, les agents délégués, les identifiants émis, les appels d’outils et les modifications résultantes. L’absence d’un seul maillon peut rendre un audit complet impossible.

Des chercheurs ont également remis en question l’idée de traiter les agents comme des identités humaines, estimant qu’elle crée une mauvaise abstraction. Une identité humaine est relativement persistante et engage une responsabilité juridique. Un agent peut être dupliqué, modifié, arrêté ou recréé au cours d’un même workflow.

Certains architectes préfèrent considérer les agents comme des principaux de charge de travail temporaires. Un principal est une entité reconnue par un système d’autorisation. Ce cadre met l’accent sur le processus d’exécution spécifique plutôt que d’attribuer à un agent une identité durable semblable à celle d’un employé.

La différence peut sembler sémantique, mais elle affecte la conception des politiques. Une identité persistante aide à suivre l’historique et la propriété. Un principal temporaire limite la réutilisation des identifiants et reflète mieux une exécution de courte durée.

Une architecture mature pourrait nécessiter les deux. L’organisation a besoin d’un enregistrement durable décrivant l’agent et son propriétaire. Chaque exécution devrait aussi recevoir une identité d’exécution distincte, dotée d’une autorité limitée.

Une autre incertitude concerne les affirmations des fournisseurs. Les entreprises de sécurité peuvent démontrer qu’elles découvrent des agents connus et négocient des connexions prises en charge. Il est bien plus difficile de prouver qu’elles couvrent chaque agent fantôme, identifiant copié ou appel d’outil indirect.

La couverture évolue également à mesure que les employés adoptent de nouveaux outils d’agents. Un développeur peut connecter un assistant à un dépôt à l’aide d’un jeton personnel. Un département peut déployer un agent via un service logiciel sans en informer l’équipe de sécurité.

Les systèmes de découverte peuvent analyser les environnements cloud et les intégrations logicielles, mais aucun outil ne garantit une visibilité complète. Les acheteurs devraient considérer les pourcentages d’inventaire et les déclarations automatisées de propriété comme des informations fournies par les fournisseurs, sauf validation indépendante.

Les données d’enquête exigent une prudence similaire. CyberArk a indiqué que près de 40 % des organisations financières et logicielles interrogées disposaient déjà d’une IA agentique en production. Moins d’une sur dix aurait déployé à grande échelle des contrôles de sécurité pour les agents.

Cette étude portait sur 104 responsables de la sécurité en Amérique du Nord et en Europe. Elle décrit un écart préoccupant au sein de cet échantillon, et non l’ensemble du marché mondial des entreprises.

Des analyses plus larges vont dans le même sens, avec des estimations différentes. Une analyse sur l’identité des agents a relevé que les fournisseurs de sécurité se précipitaient pour gouverner les systèmes autonomes à mesure que les entreprises étendaient leurs pilotes d’agents.

Le rapport a également mis en évidence une idée opérationnelle cruciale : les organisations doivent pouvoir révoquer immédiatement un agent. Un interrupteur d’arrêt ne résout pas toutes les défaillances, mais il offre un contrôle final lorsque les politiques automatisées et la surveillance échouent.

Les acheteurs devraient tester cette capacité sous contrainte. La révocation doit se propager aux sessions actives, aux jetons mis en cache, aux agents délégués et aux outils en aval. Désactiver un compte visible ne suffit pas si ses copies temporaires restent actives.

La sécurité des identités traite donc la partie du risque lié à l’IA que les entreprises peuvent gouverner le plus directement. Elle contrôle l’autorité, enregistre les actions et limite l’exposition. Elle ne garantit ni un raisonnement sûr, ni des décisions exactes, ni des entrées fiables.

Cette limite n’affaiblit pas la catégorie. Elle clarifie ce que la catégorie doit démontrer.

Le marché se consolide autour du plan de contrôle

L’opportunité autour de l’identité attire à la fois des startups spécialisées et de grandes plateformes de sécurité, car l’accès des agents se situe entre des données précieuses et une action automatisée.

L’acquisition de CyberArk par Palo Alto Networks a rendu les enjeux stratégiques particulièrement clairs. Cette combinaison place la sécurité des identités aux côtés des produits de réseau, de cloud, de terminaux et d’opérations de sécurité.

Cette transaction suggère que l’identité devient une couche transversale des portefeuilles de sécurité. Si les agents IA touchent aux applications, à l’infrastructure et aux données sensibles, leurs permissions relient plusieurs marchés que les fournisseurs vendaient auparavant séparément.

L’acquisition de Wiz par Google a fourni un autre point de référence pour la cybersécurité israélienne. Wiz a bâti sa position autour de la visibilité cloud et des relations de risque. L’identité des agents étend ce graphe à la question de savoir quel processus autonome peut agir sur chaque ressource.

Les grandes plateformes peuvent combiner les données d’accès avec des signaux réseau, la configuration cloud et le renseignement sur les menaces. Cette ampleur les aide à détecter lorsqu’une identité légitime se comporte anormalement.

Elle peut aussi créer un risque d’intégration. Une plateforme constituée par acquisitions peut exposer plusieurs moteurs de politiques, enregistrements d’identité et interfaces d’administration. Les clients jugeront si les composants fonctionnent comme un seul système de contrôle ou demeurent des produits faiblement connectés.

Les startups spécialisées soutiennent que les anciennes plateformes ont été conçues pour les utilisateurs humains, les applications conventionnelles ou les comptes de service statiques. Leur avantage réside dans la capacité à modéliser dès le départ des agents éphémères et des permissions au niveau des tâches.

Les acteurs établis répondent par leur distribution et leur infrastructure déjà déployée. Les acheteurs en entreprise leur font déjà confiance pour gérer les comptes privilégiés ou authentifier les employés. Ajouter des agents à une plateforme d’identité existante peut être plus simple que d’introduire un fournisseur de sécurité supplémentaire.

Les fournisseurs cloud occupent une troisième position. Ils émettent de nombreux identifiants de charge de travail et contrôlent l’infrastructure sur laquelle les agents s’exécutent. Ils peuvent intégrer des identités de courte durée, l’évaluation des politiques et la journalisation à proximité de l’environnement d’exécution.

Les fournisseurs d’applications détiennent une autre pièce du puzzle. Un agent qui accède aux données clients via un service logiciel dépend du modèle d’autorisation de ce service. Les contrôles d’identité externes ne peuvent pas créer des permissions fines que l’application sous-jacente ne prend pas en charge.

Le marché pourrait donc se répartir entre plusieurs couches :

• Les plateformes d’identité assurent la propriété des agents, leur cycle de vie et les politiques à l’échelle de l’organisation.

• Les systèmes cloud émettent des identités de charge de travail et des identifiants temporaires.

• Les frameworks d’agents exposent le contexte des tâches, la délégation et l’activité des outils.

• Les passerelles d’application évaluent les opérations à haut risque avant leur exécution.

• Les produits d’analytique de sécurité détectent les comportements anormaux une fois l’accès accordé.

• Les applications appliquent l’autorisation finale au niveau de la ressource.

Cette structure crée des opportunités de partenariat, mais favorise aussi la consolidation. Les acheteurs préféreront moins de surfaces de politiques, en particulier lorsque chaque intégration supplémentaire peut devenir un nouveau point de défaillance.

L’avantage de l’industrie israélienne réside dans son réseau dense d’expertise en identité, cloud et sécurité d’entreprise. Les fondateurs et employés circulent fréquemment entre unités de technologie militaire, startups, centres de recherche multinationaux et entreprises de sécurité cotées.

Ce réseau ne garantit pas le leadership du marché. Les fournisseurs de plateformes américains, les fournisseurs cloud et des spécialistes de l’identité tels qu’Okta et 1Password poursuivent la même opportunité.

Les frameworks open source peuvent aussi influencer le lieu où l’application des contrôles se produit. Si les développeurs d’agents adoptent des interfaces communes d’identité et d’autorisation, les fournisseurs pourront rivaliser sur l’implémentation. Si chaque framework crée son propre modèle, les grandes plateformes pourraient gagner en influence grâce à leur couverture d’intégration.

Les normes façonneront cet équilibre. Les travaux du NIST examinent comment les organisations peuvent identifier les agents, les autoriser, auditer leurs actions et relier l’activité aux humains responsables.

Un modèle commun réduirait les coûts d’intégration et faciliterait la comparaison des affirmations des fournisseurs. Il pourrait aussi limiter les tentatives de transformer des formats propriétaires d’identité d’agents en mécanismes de verrouillage client.

Le plan de contrôle n’appartiendra pas automatiquement à l’entreprise possédant la plus grande activité existante dans l’identité. Il reviendra à l’architecture qui combine un contexte fiable, une application indépendante des politiques, une intégration étendue et des opérations utilisables.

Ce que les acheteurs devraient surveiller après le cycle d’actualités Google

La prochaine étape sera déterminée par la validation technique et le comportement des entreprises, non par le volume de titres dans Google News.

Le premier signal sera de savoir si l’autorisation à l’exécution résiste à une délégation complexe. Les démonstrations de produits montrent souvent un agent demandant l’accès à une ressource. Les déploiements réels impliqueront des agents qui appellent des outils, lancent des sous-processus et délèguent du travail au-delà des frontières organisationnelles.

Les acheteurs devraient demander si chaque action déléguée reçoit sa propre identité et son propre identifiant traçables. Ils devraient également tester si la révocation de la requête initiale désactive tous les accès descendants.

Si les fournisseurs parviennent à imposer cette chaîne de manière cohérente, la thèse de l’identité se renforce. Si le contrôle disparaît après la première délégation, le marché ne fait encore que résoudre l’automatisation simple plutôt que la sécurité des agents autonomes.

Le deuxième signal est la convergence autour des normes. Le NIST a déjà défini l’identité et l’autorisation des agents comme un domaine de travail officiel. L’enjeu sera une mise en œuvre interopérable, et non une nouvelle collection de principes.

Les entreprises devraient surveiller l’émergence de formats communs couvrant la propriété des agents, l’autorité déléguée, la provenance des actions et le périmètre des identifiants. Leur adoption par les plateformes cloud et les frameworks d’agents compterait davantage qu’un soutien des seuls fournisseurs de sécurité.

Une norme partagée renforcerait le marché en rendant les politiques portables. Une fragmentation persistante favoriserait les grandes plateformes capables d’absorber les coûts d’intégration et de maintenir des graphes d’identité propriétaires.

Le troisième signal est la preuve d’un usage courant en entreprise. Les levées de fonds et les enquêtes des fournisseurs témoignent de l’intérêt, mais elles ne prouvent pas que les organisations peuvent exploiter ces contrôles à grande échelle.

Parmi les indicateurs utiles figurent le nombre d’actions d’agents recevant des identifiants temporaires, la fréquence à laquelle les politiques bloquent des requêtes dangereuses et la rapidité avec laquelle les équipes peuvent enquêter sur une activité déléguée. Les acheteurs devraient également mesurer les faux positifs et les délais d’approbation.

Un système d’autorisation qui bloque trop peu crée des risques. Un système qui interrompt le travail ordinaire sera contourné. Les produits gagnants devront démontrer qu’ils peuvent restreindre l’accès sans transformer chaque appel d’outil en ticket manuel.

Les responsables de la sécurité peuvent commencer avant de choisir une plateforme. Ils devraient inventorier les agents, les comptes de service, les jetons d’API et les applications connectées aux agents. Chaque agent doit avoir un responsable désigné et une procédure documentée de révocation immédiate.

Les équipes devraient séparer les accès en lecture des accès en écriture et distinguer les actions routinières de celles irréversibles. Les opérations à haut risque nécessitent des approbations plus strictes, des durées de vie d’identifiants plus courtes et des éléments d’audit plus clairs.

Les développeurs devraient éviter de placer des secrets permanents dans les prompts, les fichiers de configuration ou la mémoire des agents. Les identifiants de courte durée réduisent l’exposition, mais ils doivent rester liés à la tâche approuvée et à l’identité d’exécution.

Les travailleurs du savoir ont également un rôle à jouer. Connecter un assistant aux e-mails, documents, calendriers et systèmes de gestion de projets peut lui conférer davantage d’autorité que ne le laisse supposer son interface visible. Les utilisateurs devraient comprendre quelles actions nécessitent une vérification et lesquelles se produisent automatiquement.

Le récit qui émerge via Google News est donc crédible, mais incomplet. Les entreprises israéliennes de cybersécurité ont identifié l’identité comme la frontière applicable entre le raisonnement des agents et l’action en entreprise.

Elles n’ont pas encore prouvé qu’une seule architecture peut gouverner chaque agent, outil, identifiant et tâche déléguée. Les normes restent inachevées, les mesures en entreprise restent limitées et les affirmations des fournisseurs sur leur couverture doivent être testées.

La question pratique n’est plus de savoir si les agents ont besoin de contrôles d’accès. Elle est de savoir si ces contrôles peuvent suivre l’autorité tout au long d’un workflow autonome.

Les organisations devraient suivre de près les prochaines intégrations de produits, les mises en œuvre de normes et les preuves de déploiement. Si ces trois signaux convergent, l’identité deviendra la couche opérationnelle de la sécurité de l’IA en entreprise. Dans le cas contraire, l’attention actuelle mettra en lumière un problème avant que le marché n’ait produit une réponse complète.