Le périmètre de l'entreprise inclut désormais chaque agent d'IA

Les équipes de sécurité des entreprises ont passé des années à renforcer les contrôles autour des utilisateurs humains : MFA résistant au phishing, posture des terminaux, accès conditionnel et gouvernance des identités. Ce travail est important, mais il a également créé un angle mort dangereux. La surface d'attaque qui connaît la croissance la plus rapide dans de nombreuses organisations n'est plus le compte de l'employé. C'est la population tentaculaire d'identités non humaines, y compris les comptes de service, les workloads, les intégrations d'API, les bots, les pipelines d'automatisation, et maintenant les agents d'IA agissant sur l'ensemble des systèmes de l'entreprise avec une autorité déléguée.

Les agents d'IA intensifient ce changement car ils ne se contentent pas de s'authentifier auprès d'une seule application et d'attendre des instructions. Ils enchaînent les outils, récupèrent des données, appellent des API, prennent des décisions, déclenchent des flux de travail et opèrent de plus en plus avec des autorisations étendues sur les systèmes cloud, SaaS et internes. En pratique, de nombreuses entreprises déploient des capacités agentiques sur une hygiène d'identité machine faible : secrets partagés, informations d'identification codées en dur, portées de token excessives, inventaire médiocre et peu de gouvernance du cycle de vie. Cette combinaison crée une surface d'attaque qui s'étend plus rapidement que ce que la plupart des programmes d'IAM, de sécurité et de risque sont préparés à contrôler.

Pourquoi les identités non humaines sont devenues un risque prioritaire

Les identités non humaines existent depuis des années, mais leur échelle et leur puissance ont changé. Les architectures cloud-natives ont créé de grandes populations de principaux de service, d'identités de workload (workload identities), de rôles de calcul éphémères, de comptes d'automatisation et d'intégrations tierces. L'adoption de l'IA rend maintenant cette courbe de croissance plus abrupte. Chaque nouvel agent, plateforme d'orchestration, plugin, connecteur de récupération et flux de travail en arrière-plan introduit des informations d'identification, des autorisations, des relations de confiance et des chemins d'exécution supplémentaires.

Contrairement aux utilisateurs humains, ces identités sont souvent créées rapidement, leur propriétaire est ambigu et elles sont surveillées de manière incohérente. Elles peuvent contourner les processus normaux d'arrivée, de mutation et de départ des employés. Elles sont fréquemment exemptées de MFA car elles ne peuvent pas répondre à des défis interactifs. Leurs secrets sont souvent stockés dans des dépôts de code, des variables CI/CD, des fichiers de configuration, des notebooks, des extensions de navigateur ou des plateformes de fournisseurs en dehors de la pile IAM principale. Beaucoup sont surprivilégiées car la réduction de la portée prend du temps, tandis qu'un accès large permet aux prototypes de fonctionner immédiatement.

Les attaquants le comprennent. Une clé d'API compromise, un token divulgué ou un compte de service mal configuré peut fournir un accès discret et durable sans avoir besoin de hameçonner un employé. Lorsque cette identité appartient à un flux de travail basé sur l'IA, le rayon de l'explosion peut être plus grand : accès à des données sensibles, capacité à déclencher des actions en aval et apparence d'un comportement automatisé légitime qui se fond dans le bruit opérationnel.

Comment les agents d'IA aggravent le problème

1. Ils multiplient les identités plus vite que la gouvernance ne peut les rattraper

Les déploiements d'agents arrivent rarement sous la forme d'une plateforme unique gouvernée de manière centralisée. Ils émergent à travers des projets pilotes en ingénierie, support, finance, marketing et opérations. Les équipes connectent les agents aux systèmes de billetterie, aux CRM, aux dépôts de code, aux outils de messagerie, aux magasins de documents et aux bases de connaissances internes. Chaque connexion nécessite généralement des informations d'identification, des tokens, des rôles ou un accès délégué. Le nombre d'identités augmente plus vite que l'environnement de contrôle.

2. Ils encouragent des autorisations étendues par commodité

Les premières implémentations d'agents commencent souvent avec des privilèges de type « faites en sorte que ça marche ». L'accès en lecture devient un accès en lecture-écriture. La portée limitée du dépôt devient un accès à l'échelle de l'organisation. Les tokens de test temporaires deviennent des dépendances de production. Comme les agents dépendent de l'enchaînement d'actions sur plusieurs systèmes, les équipes accordent généralement l'union de toutes les autorisations possibles au lieu de l'ensemble minimal nécessaire pour une tâche spécifique.

3. Ils créent des chemins d'abus indirects

Un attaquant n'a pas toujours besoin de voler les informations d'identification de l'agent. L'injection de prompt, la sortie d'outils malveillants, les sources de connaissances empoisonnées ou les intégrations en amont compromises peuvent influencer un agent à utiliser ses autorisations légitimes de manière nuisible. Si l'identité derrière l'agent est surprivilégiée, l'attaquant peut transformer la logique de l'application en levier opérationnel.

4. Ils affaiblissent la responsabilité

Quand un agent entreprend une action, qui est responsable ? Le propriétaire métier, le développeur, l'équipe de la plateforme, le fournisseur du modèle ou l'équipe des identités ? Dans de nombreuses entreprises, la réponse n'est pas claire. Cette ambiguïté ralentit la révocation, affaiblit les normes de journalisation et laisse les intervenants en cas d'incident se demander si une action était une automatisation autorisée, une erreur de modèle ou une utilisation malveillante.

Lacunes de contrôle courantes que les entreprises doivent s'attendre à trouver

La plupart des organisations qui évaluent ce domaine découvrent les mêmes schémas : inventaire incomplet des identités machine, aucun propriétaire faisant autorité enregistré pour les comptes de service, secrets à longue durée de vie sans politique de rotation, utilisation incohérente des coffres-forts (vaults), autorisations excessives, surveillance limitée de l'utilisation des tokens, intégrations SaaS tierces en dehors de l'examen des achats, et aucun processus d'approbation standard pour connecter les agents d'IA aux données ou aux systèmes d'action de l'entreprise.

Une autre lacune majeure est l'asymétrie des politiques. Les identités humaines ont généralement des exigences de gouvernance strictes, tandis que les identités machine sont traitées comme des détails d'implémentation. Ce n'est plus défendable. Si une identité non humaine peut lire les dossiers des clients, approuver des modifications, envoyer des messages, exécuter du code ou déclencher des paiements, elle devrait faire face à des contrôles proportionnels à ce risque, et non à des contrôles plus faibles parce qu'aucun humain ne se connecte de manière interactive.

Recommandations de gouvernance qui comptent maintenant

Établir un inventaire des identités machine avec un propriétaire désigné

Chaque identité non humaine devrait avoir un propriétaire enregistré, un objectif, un environnement, des systèmes connectés, un type d'informations d'identification, un niveau de privilège et une date de révision. Pas de comptes de service orphelins, pas de connecteurs d'agents inconnus, pas de secrets de production sans propriétaire métier.

Classifier les autorisations des agents par sensibilité de l'action

Séparez les identités qui ne font que récupérer des informations de celles qui peuvent modifier des enregistrements, déclencher des flux de travail, déplacer des fonds, changer l'infrastructure ou accéder à des données réglementées. Appliquez des seuils d'approbation plus élevés, des portées plus strictes et une journalisation plus forte aux agents capables d'agir.

Privilégier par défaut les informations d'identification éphémères et l'accès par courtier

Remplacez les clés d'API statiques et les secrets à longue durée de vie partout où c'est possible par des tokens à courte durée de vie, la fédération d'identité de workload (workload identity federation), l'accès juste-à-temps et la récupération de secrets centralisée. Si une plateforme d'agent ne peut pas prendre en charge la gestion moderne des informations d'identification, cette limitation devrait jouer contre son approbation pour la production.

Exiger le moindre privilège par tâche, et non par plateforme

Ne donnez pas à un agent un accès large parce qu'il pourrait en avoir besoin un jour. Concevez les autorisations autour de flux de travail spécifiques. Si nécessaire, divisez un processus agentique en plusieurs identités avec des portées et des contrôles distincts.

Mettre en œuvre des portes de politique pour les actions à haut risque

Pour les opérations sensibles, ajoutez une approbation humaine, des limites de transaction, des restrictions d'environnement ou des points de contrôle doubles. L'objectif n'est pas d'éliminer l'autonomie partout, mais de s'assurer que l'autonomie est limitée là où l'impact sur l'entreprise est le plus élevé.

Journaliser les décisions des agents et l'utilisation des identités d'une manière que les enquêteurs peuvent suivre

Les équipes de sécurité ont besoin de traçabilité à travers le prompt, le contexte récupéré, les appels d'outils, l'utilisation des informations d'identification, les actions en aval et les changements qui en résultent. Les journaux d'authentification standard seuls sont insuffisants lorsque le risque inclut la manipulation indirecte du comportement d'un agent.

Créer un processus de révision formel pour les déploiements d'agents

Les équipes de sécurité, d'IAM et de risque devraient définir une révision légère mais obligatoire pour tout agent qui se connecte aux systèmes de l'entreprise. Au minimum, examinez l'accès aux données, les autorisations d'action, le modèle d'informations d'identification, la surveillance, la gestion des pannes et la capacité de coupe-circuit (kill-switch).

Le changement stratégique que les dirigeants de la sécurité doivent opérer

Le vrai problème n'est pas que les agents d'IA sont particulièrement dangereux. C'est qu'ils arrivent au-dessus de parcs d'identités qui étaient déjà sous-gouvernés du côté non humain. Les entreprises qui continuent de centrer leur stratégie d'identité presque exclusivement sur les utilisateurs de la main-d'œuvre passeront à côté de l'endroit où l'autorité opérationnelle se déplace réellement. De plus en plus de décisions, d'accès aux données et d'actions commerciales sont délégués à des entités logicielles.

Les organisations qui gèrent bien cela traiteront les identités de machines et d'agents comme des sujets de sécurité de première classe, avec des attentes de gouvernance à la hauteur de leur pouvoir. Cela signifie un inventaire avant la mise à l'échelle, le moindre privilège avant la commodité, l'accès éphémère avant les secrets statiques et une propriété responsable avant que l'expérimentation ne se propage. Les agents d'IA peuvent créer une réelle valeur pour l'entreprise, mais seulement si les identités qui les sous-tendent sont gouvernées avec le même sérieux que les humains qui accomplissaient autrefois ces tâches.

Le périmètre a de nouveau changé. Cette fois, il ne s'agit pas seulement des appareils ou des utilisateurs. Il s'agit de chaque identité non humaine que votre entreprise autorise à penser, décider, se connecter et agir.