Les menaces internes liées aux agents IA placent l’accès de confiance au cœur de la sécurité

Les agents IA ont franchi un seuil critique : ils peuvent désormais utiliser des identifiants de confiance pour lire des données, appeler des outils et modifier des systèmes d’entreprise sans supervision constante.

Cette évolution fait passer la menace interne liée aux agents IA d’une préoccupation de sûreté des modèles à un problème de contrôle des accès. Un agent n’a pas besoin d’intentions malveillantes pour exposer des dossiers, envoyer des messages non autorisés ou exécuter un workflow dangereux. Il lui suffit de disposer d’autorisations légitimes, de recevoir une instruction nuisible et d’avoir suffisamment d’autonomie pour agir.

Le dernier argumentaire de Cybersecurity Insiders illustre ce renversement. Les entreprises considéraient autrefois l’IA comme un logiciel à protéger contre des attaquants externes. Les équipes de sécurité doivent désormais se demander si le logiciel lui-même peut devenir un opérateur de confiance, mais dangereux.

Cela ne signifie pas que chaque agent doit être considéré comme hostile. Cela signifie que les organisations ne peuvent plus traiter l’authentification comme la preuve qu’une action est sûre. Une identité valide indique qui ou quoi a demandé l’accès. Elle ne permet pas d’établir si l’action demandée correspond à l’intention réelle de l’utilisateur.

L’enjeu émergent n’oppose donc pas les humains aux machines. Il oppose un accès large et persistant à une autorisation étroite, propre à chaque tâche. Les équipes de sécurité doivent déterminer si les agents héritent des schémas d’accès permissifs conçus pour les employés et les applications traditionnelles.

La réponse déterminera si l’adoption des agents produit une automatisation maîtrisée ou une nouvelle catégorie d’incidents internes difficiles à détecter.

La menace interne liée aux agents IA commence par un accès légitime

Le risque déterminant n’est pas qu’un agent IA franchisse le périmètre, mais qu’il agisse grâce à l’accès que l’entreprise lui a délibérément accordé.

Les programmes traditionnels de gestion des risques internes se concentrent sur les employés, les sous-traitants et les comptes compromis. Ces acteurs se trouvent déjà à l’intérieur d’une frontière de confiance. Ils peuvent détourner des données ou des systèmes sans exploiter une vulnérabilité exposée vers l’extérieur.

Les agents correspondent étonnamment bien à ce modèle. Ils peuvent détenir des autorisations OAuth, des identités de service, des accès API, des permissions de bases de données et une autorité déléguée. Ils peuvent également combiner ces privilèges au sein d’un workflow en plusieurs étapes.

Un agent chargé de préparer une présentation commerciale peut rechercher des dossiers clients, récupérer des notes internes et rédiger un e-mail. Un agent de programmation peut lire un dépôt, ouvrir un terminal, modifier des fichiers et soumettre une pull request. Un agent de support peut consulter des informations de compte et déclencher un remboursement.

Chaque autorisation prise isolément peut sembler raisonnable. La capacité dangereuse apparaît lorsque l’agent les relie dans une séquence inattendue.

C’est une différence fondamentale entre un agent et une application traditionnelle. Les logiciels traditionnels suivent généralement des parcours prédéterminés. Un agent interprète un objectif, sélectionne des outils et détermine les étapes intermédiaires au moment de l’exécution.

Cette flexibilité crée de la valeur, mais elle fragilise également les hypothèses intégrées aux anciens contrôles. Une autorisation accordée pour un workflow prévu peut permettre plusieurs workflows non prévus. L’agent peut découvrir ces parcours plus vite qu’un opérateur humain.

L’injection de prompt rend le problème plus aigu. L’injection de prompt est une attaque qui place des instructions trompeuses dans les données qu’un système IA lit. L’agent peut confondre ces instructions avec une partie de la tâche qui lui a été confiée.

Imaginez un assistant qui examine des documents issus d’un dossier externe. Un document contient du texte caché demandant à l’assistant de récupérer des fichiers confidentiels et d’envoyer leur contenu ailleurs. L’agent pourrait obéir, car les deux actions utilisent des outils approuvés.

Le système peut enregistrer une connexion réussie, un jeton valide et des appels API autorisés. La surveillance conventionnelle voit une activité autorisée. L’entreprise constate une fuite de données.

Les recommandations d’OWASP sur les menaces agentiques identifient les risques issus de la planification autonome, de l’utilisation d’outils, de la mémoire et des interactions entre agents. Il ne s’agit pas de comportements isolés du modèle. Ce sont des risques à l’échelle du système, créés par l’association d’un modèle et d’une autorité.

Le même problème apparaît lorsqu’un agent reçoit un objectif mal spécifié. « Résoudre toutes les demandes en retard » pourrait l’amener à envoyer des messages, modifier des dossiers ou clôturer des cas nécessitant un examen humain. Il n’est même pas nécessaire de compromettre d’abord le modèle.

C’est pourquoi l’intention compte autant que l’identité. Une conception sécurisée doit déterminer qui a autorisé la tâche, quelles ressources elle couvre, quelles actions sont permises et combien de temps cette autorité reste valable.

Sans ces limites, un agent authentifié devient un acteur interne au rythme d’exécution inhabituellement rapide.

L’accès de confiance devient le nouveau périmètre de sécurité

Les agents IA rendent l’accès de confiance plus important que l’emplacement réseau, car leur travail légitime s’étend déjà aux applications, aux clouds et aux magasins de données.

L’architecture zero trust avait anticipé une partie de cette évolution. La norme zero trust du NIST rejette la confiance implicite fondée uniquement sur l’emplacement réseau ou la propriété d’un actif. Elle centre les décisions de sécurité sur les utilisateurs, les actifs, les ressources et l’autorisation explicite.

Ce modèle devient plus urgent lorsque le sujet qui demande l’accès est un système autonome. Un agent peut opérer au-delà de frontières qui ralentissaient autrefois les acteurs internes humains. Il n’a pas besoin de changer d’appareil, d’ouvrir plusieurs interfaces ou de copier manuellement des données entre applications.

Une instruction peut déclencher une chaîne d’appels d’outils. Cette chaîne peut passer d’une plateforme de messagerie à un stockage cloud, puis à une base de données clients et à un service externe. L’agent exécute cette séquence par le biais d’intégrations de confiance.

Un pare-feu réseau voit des connexions autorisées. Les systèmes d’identité voient des identifiants reconnus. Les journaux applicatifs montrent des opérations que le compte attribué était autorisé à effectuer.

Pourtant, le résultat combiné peut toujours enfreindre les politiques.

La sécurité doit donc se rapprocher de chaque action. L’autorisation doit prendre en compte l’identité de l’agent, son propriétaire, la tâche en cours, la ressource demandée, l’outil utilisé et les signaux de risque environnants.

Cela exige une identité distincte pour chaque agent déployé. Les comptes de service partagés compliquent les enquêtes, car plusieurs agents peuvent générer de l’activité sous un même nom. Ils permettent également l’accumulation des autorisations lorsque de nouveaux workflows réutilisent le même compte.

Une identité dédiée crée une piste de responsabilité. Les équipes de sécurité peuvent relier un agent à son sponsor, son objectif, ses outils autorisés, son environnement de déploiement et son calendrier de revue. Elles peuvent suspendre un workflow sans désactiver une automatisation sans rapport.

L’identité seule ne suffit toutefois pas. Un agent identifié de manière unique peut encore disposer de privilèges excessifs. Il peut aussi utiliser une autorisation valide au mauvais moment ou dans le mauvais but.

Des contrôles efficaces doivent réduire à la fois l’étendue et la durée des autorisations. Un agent préparant un rapport trimestriel ne devrait pas conserver un accès permanent à chaque source qu’il a consultée. Il devrait recevoir une autorité strictement limitée à la tâche en cours.

Les identifiants de courte durée réduisent le temps disponible pour un usage abusif. L’accès juste-à-temps accorde l’autorité au début de la tâche et la retire ensuite. Les politiques au niveau des outils limitent les opérations que l’agent peut appeler.

Ces contrôles reflètent la leçon centrale de la menace interne liée aux agents IA. La confiance doit s’attacher à une action précise, dans des conditions précises, et non à un agent pour toujours.

Les entreprises doivent également séparer la lecture de l’action. Un agent qui résume un calendrier nécessite une autorité différente de celle d’un agent qui planifie des réunions. Un système qui propose des modifications de code ne devrait pas recevoir automatiquement l’autorisation de les déployer.

Cette distinction peut disparaître lors d’une adoption rapide. Les équipes commencent avec un assistant en lecture seule, puis ajoutent progressivement l’accès en écriture, le contrôle du navigateur et l’automatisation des workflows. L’évaluation initiale des risques ne correspond plus au système déployé.

Les inventaires d’agents doivent donc suivre les capacités, et non seulement les installations. Les équipes de sécurité doivent savoir quels agents peuvent accéder à des données sensibles, invoquer des outils externes, communiquer publiquement, modifier des dossiers ou autoriser des transactions.

L’inventaire doit évoluer aussi vite que les agents eux-mêmes.

Pourquoi les contrôles internes existants ne détectent pas le comportement des agents

Les contrôles conçus autour de la vitesse et des motivations humaines peinent lorsque des logiciels peuvent exécuter des centaines d’actions légitimes sans fatigue ni hésitation.

Les programmes de gestion des risques internes humains recherchent souvent des changements de comportement reconnaissables. Un employé télécharge des volumes inhabituels de données, se connecte à une heure inattendue ou accède à un service qui ne relève pas de son rôle habituel.

Ces signaux restent utiles, mais les agents créent une référence différente. Ils peuvent fonctionner en continu. Ils peuvent traiter plus de dossiers qu’une personne. Leur activité peut provenir d’une infrastructure cloud stable plutôt que du terminal d’un employé.

Un taux d’action élevé peut indiquer une automatisation normale plutôt qu’un comportement malveillant. Un taux faible peut néanmoins dissimuler une divulgation soigneusement ciblée. Le volume seul devient un signal peu fiable.

L’intention est également plus difficile à déduire. Un utilisateur humain effectue généralement des actions au cours d’une session interactive. Les enquêteurs peuvent comparer ces actions aux responsabilités professionnelles, aux communications et aux processus métier connus.

Un agent traduit une instruction large en décisions intermédiaires. L’utilisateur peut ne jamais voir ces décisions. L’action finale peut se situer à plusieurs étapes de la demande initiale.

Les journaux doivent préserver cette chaîne. Les enquêteurs devraient pouvoir reconstituer l’instruction de l’utilisateur, les décisions du modèle, le contexte récupéré, les choix d’outils, les résultats des autorisations et les effets finaux.

Cela ne signifie pas qu’il faut stocker chaque calcul interne du modèle. Cela signifie qu’il faut conserver une trace vérifiable des actions externes importantes et de l’autorité qui soutient chacune d’elles.

Les journaux applicatifs standards ne fournissent souvent que des fragments. Un système enregistre le jeton. Un autre enregistre la requête de base de données. Un troisième enregistre un message sortant. Sans identifiant de tâche partagé, l’organisation ne peut pas les relier en un seul workflow d’agent.

Le problème d’observabilité s’amplifie dans les systèmes multi-agents. Un agent peut déléguer une recherche à un autre, qui demande à un troisième système d’exécuter un outil. L’autorité peut circuler dans cette chaîne même si l’utilisateur d’origine n’a jamais approuvé chaque participant.

La confiance récursive décrit cette relation en expansion. Une organisation fait confiance à un agent, qui fait confiance à un autre service, lequel dépend d’une autre identité ou d’un autre outil. La surface d’attaque effective s’étend à chaque maillon.

La menace interne liée aux agents IA peut exploiter cette chaîne sans produire d’événement d’intrusion évident. Une réponse d’outil compromise peut influencer l’agent de planification. Une entrée mémoire empoisonnée peut affecter des décisions futures. Un document externe peut rediriger un workflow de confiance.

Les défenses existantes au niveau des terminaux et du réseau restent importantes. Elles peuvent bloquer les logiciels malveillants, détecter des destinations suspectes et isoler une infrastructure compromise. Elles ne peuvent pas déterminer de manière fiable si une action métier autorisée reflète le résultat voulu par l’utilisateur.

Ce jugement exige un contexte plus riche.

Les organisations devraient établir des références comportementales pour chaque rôle d’agent. Un agent de reporting peut normalement lire des sources de données approuvées et écrire dans un magasin de documents précis. Une tentative d’envoi d’e-mail ou d’accès à des identifiants sortirait de ce profil.

Les politiques peuvent également imposer des contraintes de séquence. La lecture d’une page web non fiable ne devrait pas autoriser immédiatement l’accès à des dossiers confidentiels. Un changement dans la sensibilité des données devrait déclencher une nouvelle décision d’autorisation.

L’approbation humaine reste utile pour les actions à fort impact. Toutefois, les écrans d’approbation doivent présenter des informations significatives. Une demande vague de « continuer » n’aide pas le réviseur à comprendre quelles données seront transférées ou quels enregistrements seront modifiés.

L’approbation doit préciser l’action, la destination, les ressources concernées et la conséquence attendue. Sinon, l’humain devient un point de contrôle cérémoniel plutôt qu’un mécanisme de sécurité.

Le principe du moindre privilège doit suivre la tâche, pas l’agent

Le modèle d’accès le plus sûr donne à un agent l’autorité minimale requise pour une tâche donnée et impose une nouvelle décision lorsque la tâche change.

Le moindre privilège est depuis longtemps un principe de sécurité. Les systèmes agentiques rendent sa mise en œuvre plus exigeante, car leurs flux de travail sont dynamiques.

Une application classique reçoit des autorisations correspondant à un ensemble stable de fonctionnalités. Un agent peut choisir différents outils selon la demande, les informations récupérées ou les résultats d’une étape antérieure.

Lui accorder à l’avance toutes les autorisations possibles simplifie le développement. Cela crée aussi une accumulation d’autorité dormante. Un agent manipulé peut utiliser des capacités que la tâche en cours n’a jamais nécessitées.

L’autorisation liée à la tâche offre une meilleure voie. Le système évalue l’objectif déclaré et émet une capacité limitée pour la ressource nécessaire. Cette capacité expire à la fin de l’étape ou de la session.

Le modèle du moindre privilège de Microsoft recommande de définir l’identité, le périmètre, l’accès aux outils et l’auditabilité avant d’élargir l’autonomie. Il souligne également l’importance d’identités d’agents dédiées assorties de propriétaires responsables.

Prenons un agent qui traite des notes de frais. Il doit lire les documents soumis, les comparer à la politique interne et préparer une recommandation. Il n’a pas besoin d’une autorité permanente pour effectuer des paiements.

Si l’entreprise autorise ultérieurement le remboursement automatique sous un seuil défini, cette autorisation d’écriture doit être distincte. Le système doit enregistrer la politique qui l’a autorisée et exiger une escalade hors de cette limite.

Cette décomposition limite les dommages lorsqu’un problème survient. Une instruction malveillante dans un reçu pourrait influencer la recommandation. Elle ne devrait pas accorder automatiquement la capacité de rediriger des fonds.

Le même modèle s’applique au travail de connaissance. Un agent de recherche peut parcourir les documents approuvés d’une équipe, mais la destination de son résultat doit rester contrainte. Des sources sensibles ne doivent pas se retrouver dans des prompts publics, des canaux externes ou des projets sans rapport.

Les décisions d’accès nécessitent le contexte des données. L’étiquette d’un fichier, l’appartenance à un projet, une conservation légale, une restriction client ou le niveau de confidentialité peuvent modifier la pertinence d’un même appel d’outil.

Les organisations qui construisent une base de connaissances IA devraient considérer les limites d’autorisation comme faisant partie de la qualité de récupération. Une réponse utile doit s’appuyer sur des informations pertinentes sans franchir les limites de propriété ou de confidentialité.

La conception des outils compte également. Les outils génériques créent des modes de défaillance génériques. Un connecteur de base de données capable d’exécuter des requêtes arbitraires présente davantage de risques qu’une fonction conçue pour renvoyer des champs approuvés.

Les développeurs devraient exposer l’opération utile la plus restreinte. Plutôt que de donner à un agent un accès complet à la messagerie, un service pourrait lui permettre de récupérer les messages correspondant à un identifiant de dossier. Plutôt qu’un accès au shell, il pourrait exposer une commande de build contrôlée.

La liaison d’outils associe des identités d’agents précises à des opérations précises. L’agent ne peut pas invoquer chaque intégration disponible simplement parce que la plateforme sait que ces outils existent.

Les entrées et les sorties doivent aussi être validées hors du modèle. Un modèle ne devrait pas être seul responsable de déterminer si l’action qu’il propose enfreint une politique.

Une couche de politique distincte peut inspecter les destinations, les classifications de données, les limites de transaction et le contexte de la tâche. Elle peut bloquer, transformer ou faire remonter une opération avant son exécution.

Cette séparation répond à une idée fausse courante sur la sécurité des agents. De meilleurs prompts et des modèles plus robustes peuvent réduire les erreurs, mais ils ne peuvent pas remplacer des limites applicables.

Un prompt est une instruction. Une politique d’autorisation est un contrôle.

La distinction est importante, car un agent peut mal comprendre un prompt, hériter d’un contexte empoisonné ou recevoir des instructions contradictoires. Un moteur de politiques devrait continuer à appliquer les limites même lorsque le modèle se comporte de manière imprévisible.

Le Zero Trust aide, mais ne résout pas la question de l’intention

Le Zero Trust peut réduire la portée d’un agent, mais il ne peut pas déterminer automatiquement si une action autorisée sert le véritable objectif de l’utilisateur.

C’est le compromis central du débat sur les accès de confiance. Les fournisseurs de sécurité présentent de plus en plus l’identité, l’accès conditionnel et le Zero Trust comme des réponses aux risques liés aux agents. Ces contrôles répondent à d’importantes faiblesses.

Le Zero Trust for AI de Microsoft étend la vérification explicite et le moindre privilège aux données IA, aux modèles, aux charges de travail, aux utilisateurs et au comportement des agents. Microsoft décrit également les agents manipulés, surprivilégiés ou désalignés comme de possibles « agents doubles ».

Ce cadrage est utile, mais les organisations devraient éviter de considérer le Zero Trust comme une catégorie de produit complète. NIST décrit le Zero Trust comme un ensemble de principes architecturaux, et non comme l’achat d’une technologie unique.

Une organisation peut déployer des contrôles d’identité modernes tout en laissant aux agents des autorisations excessives. Elle peut exiger une authentification sans parvenir à distinguer une tâche d’agent d’une autre. Elle peut collecter des journaux que personne ne consulte.

Les cas les plus difficiles impliquent des actions à la fois autorisées et plausibles.

Un agent de service client peut légitimement accéder à des données clients et envoyer des messages. Un agent de programmation peut légitimement modifier des fichiers source. Un agent d’approvisionnement peut légitimement contacter des fournisseurs.

La version malveillante ou erronée de chacune de ces actions peut sembler presque identique au niveau de l’identité.

L’autorisation contextuelle réduit l’écart. Le système peut se demander si la destination est approuvée, si les champs demandés sont nécessaires, si l’action correspond au comportement historique et si la classification des données autorise le transfert.

Néanmoins, les modèles contextuels génèrent des faux positifs et des faux négatifs. Des contrôles stricts peuvent interrompre des flux de travail utiles. Des contrôles souples peuvent préserver la productivité tout en autorisant des combinaisons nuisibles.

L’organisation doit décider où s’arrête l’autonomie. Les tâches à faible impact et réversibles peuvent tolérer davantage de liberté. Les tâches à fort impact et irréversibles exigent une vérification plus rigoureuse et souvent une approbation humaine.

La réversibilité mérite une attention particulière. Un agent qui rédige un message crée un artefact vérifiable. Un agent qui envoie le message modifie le monde extérieur. Un agent qui recommande de supprimer des enregistrements diffère de celui qui effectue la suppression.

L’architecture de sécurité devrait refléter ces distinctions.

Les équipes devraient également tester les agents comme des systèmes, et non uniquement comme des modèles. Les évaluations de modèles peuvent mesurer si un agent suit les instructions dans des conditions contrôlées. Le risque en production dépend des outils, des identifiants, de la mémoire, des sources de données et des applications environnantes.

Les exercices de red team devraient introduire des documents malveillants, des objectifs ambigus, des réponses d’outils compromises et des combinaisons d’autorisations inattendues. L’objectif est d’observer si les contrôles externes contiennent la défaillance.

Le cadre d’OWASP aide les équipes à recenser ces menaces, tandis que le modèle d’accès cloud de NIST explique comment les politiques au niveau de l’identité et les contrôles applicatifs granulaires soutiennent le Zero Trust à travers des services distribués.

Aucun des deux ne garantit qu’un agent comprend l’intention métier. Cette incertitude doit rester visible dans les décisions de déploiement.

Les responsables de la sécurité devraient donc questionner les affirmations selon lesquelles une plateforme « sécurise les agents » sans en expliquer le périmètre. Découvre-t-elle les identités d’agents ? Gouverne-t-elle les autorisations ? Inspecte-t-elle les appels d’outils ? Protège-t-elle les prompts et les données ? Préserve-t-elle des pistes d’audit intersystèmes ?

La plupart des produits ne couvrent qu’une partie du cycle de vie. Les entreprises auront toujours besoin d’une gouvernance des politiques, de processus opérationnels, de réponse aux incidents et de contrôles spécifiques aux applications.

La menace interne des agents IA n’est pas une vulnérabilité unique avec un correctif unique. Elle découle de l’intégration de décideurs probabilistes dans des flux de travail de confiance.

Trois signaux indiqueront si les accès de confiance s’améliorent

La prochaine étape de la sécurité de l’IA se mesurera par des contrôles déployables et des preuves issues d’incidents, et non par des promesses plus vastes sur des agents responsables.

Le premier signal est l’adoption d’identités d’agents distinctes et gouvernées. Les organisations devraient pouvoir recenser les agents, identifier leurs propriétaires, examiner leurs autorisations et les désactiver individuellement.

Le cadre d’identité des agents de Microsoft Entra montre la direction prise par les principales plateformes d’identité. Il prend en charge des structures d’agents dédiées, la journalisation de l’activité, la gouvernance et l’accès conditionnel pour les acteurs non humains.

D’autres fournisseurs d’identité et de cloud subiront une pression pour proposer des contrôles comparables dans des environnements hétérogènes. Les entreprises n’exploitent rarement qu’une seule plateforme d’agents ou qu’un seul système d’identité.

Les progrès deviendront crédibles lorsque les administrateurs pourront suivre une action d’agent à travers les applications sans dépendre d’un compte de service partagé. Si les identités dédiées restent facultatives ou spécifiques à une plateforme, la visibilité demeurera fragmentée.

Le deuxième signal est l’utilisation plus large d’autorisations à courte durée de vie et limitées à la tâche. Les plateformes d’agents devraient demander un accès pour une opération définie au lieu d’hériter d’autorisations permanentes d’un utilisateur ou d’un développeur.

Ce changement exigera une meilleure intégration entre les systèmes d’orchestration et l’infrastructure d’identité. La plateforme doit décrire ce que l’agent compte faire sous une forme qu’un moteur de politiques peut évaluer.

Les interfaces d’approbation doivent également s’améliorer. Les utilisateurs devraient voir la ressource, l’action, la destination et l’effet attendu avant d’accorder une autorité sensible.

Si les fournisseurs livrent ces contrôles par défaut, la thèse des accès de confiance gagne en force. Si une configuration sécurisée exige une ingénierie sur mesure importante, les équipes sous pression de livraison continueront à choisir des autorisations étendues.

Le troisième signal est l’émergence de preuves publiques issues d’incidents réels et de tests indépendants. Les équipes de sécurité doivent savoir comment les agents échouent en dehors des démonstrations.

Des divulgations utiles expliqueront l’instruction initiale, le chemin d’accès, les outils impliqués, le contrôle qui a échoué et le point auquel le confinement a réussi. De vagues références à des sorties non sûres n’offriront pas suffisamment d’orientations architecturales.

Les évaluations indépendantes devraient tester des systèmes d’agents complets face à l’injection de prompts, à l’autonomie excessive, à la mémoire empoisonnée, à l’exposition d’identifiants et à la manipulation inter-agents. Elles devraient également mesurer si les contrôles préservent un travail utile.

Le signalement d’incidents clarifiera quels risques dominent. L’injection de prompts reçoit beaucoup d’attention, mais les erreurs de configuration, les autorisations excessives, les identités partagées et les intégrations non examinées pourraient s’avérer tout aussi importantes.

Le résultat orientera les dépenses et les priorités de conception. Si la plupart des incidents impliquent des identifiants volés, la protection des identités deviendra prioritaire. Si des agents valides utilisent à répétition de manière abusive des outils autorisés, l’autorisation à l’exécution et les contrôles comportementaux deviendront le principal champ de bataille.

Les entreprises n’ont pas besoin d’attendre des normes parfaites. Elles peuvent dès maintenant recenser les agents, séparer les identités, supprimer les autorisations inutilisées, contraindre les outils, enregistrer les chaînes d’actions et exiger une approbation pour les opérations irréversibles.

Elles devraient également définir ce qui se passe lorsqu’un agent se comporte de manière inattendue. La suspension rapide, la révocation des identifiants, l’isolement des flux de travail et la préservation des preuves doivent figurer dans le plan de réponse aux incidents.

La question pratique est simple : votre organisation peut-elle expliquer chaque action conséquente d’un agent et révoquer son autorité sans désactiver tout un processus métier ?

Si la réponse est non, l’agent bénéficie de davantage de confiance que l’architecture de sécurité ne peut en gérer sans risque.

La menace interne liée aux agents d’IA modifie l’ordre des opérations. Les entreprises ne peuvent pas accorder un accès étendu d’abord, puis ajouter une supervision après le déploiement. L’identité, les limites des tâches, l’auditabilité et le confinement doivent précéder l’autonomie.

Pour les développeurs et les acheteurs en entreprise, la prochaine évaluation doit aller au-delà de la capacité d’un agent à réussir une démonstration. Demandez-vous à quoi il peut accéder, comment cette autorité expire et si un contrôle indépendant peut interrompre l’action finale.

L’accès de confiance est désormais le champ de bataille, car l’accès transforme la sortie d’un modèle en conséquences réelles. Les organisations qui encadreront cette transition capteront la valeur de l’automatisation sans considérer chaque action authentifiée comme intrinsèquement digne de confiance.