Les identités de machine prennent le dessus – votre modèle d’accès est-il prêt?

Une identité de machine est toute entité non-humaine - logiciel, agent d'IA, microservice ou système automatisé - qui interagit avec des ressources numériques, prend des décisions ou lance des actions par lui-même.

Alors que les identités de machine traditionnelles étaient limitées aux clés API ou aux comptes de services, les identités de machine modernes ont évolué en acteurs beaucoup plus complexes – agents d’IA capables de raisonnement, d’initier des flux de travail et même d’agir.on behalfhumains ou d’autres systèmes.

Ces identités de machine ne sont pas seulement une tendance croissante - elles sont sur le point deoutnumber human users in every system we buildAlors que la plupart des applications se sont historiquement concentrées sur les identités humaines – pensez aux formulaires de connexion, aux mots de passe et aux sessions d’utilisateurs – cette réalité est forcément en train de changer.

Dans cet article, nous plongons plus en profondeur dans les identités de machine – ce qu’elles sont, pourquoi elles comptent et comment construire un contrôle d’accès qui les respecte.

Un certain contexte : la montée des identités de machine

Lorsque vous considérez combien d'agents d'IA sont intégrés dans le logiciel ou combien de fois les outils d'IA externes consomment des API, il devient clair que les identités de machine domineront bientôt nos applications.

Chaque produit que vous construisez – qu’il soit natif de l’IA ou non – aura inévitablement des identités de machine qui interagiront avec elle. Ces identités ne suivront pas non plus simplement passivement des chemins prédéfinis.

Cela soulève une question critique :Are your systems ready for this?Si ce n’est pas le cas, il est temps de repenser la façon dont vous gérez l’identité et l’accès – car séparer les humains des machines dans votre modèle d’identité n’est plus viable.

Nous avons exploré certaines de ces implications dans notre récent article surThe Challenges of Generative AI in Identity and Access Management (IAM), où nous avons brisé la façon dont l'IA brouille les lignes entre les utilisateurs, les robots et les services.

Cette fois, nous voulons parler des identités de machine elles-mêmes.

Qu’est-ce qu’une « machine identité » ?

Pendant des années, le termeMachine d’identitésignifiait quelque chose de simple – une clé API, un secret client ou un compte de service utilisé par un système de back-end pour s’authentifier. Ces identités étaient statiques, prévisibles et relativement faciles à gérer.

That definition no longer fits.

Avec l'émergence des agents d'IA, les identités de machine ont évolué bien au-delà des identifiants statiques.Les identités de machine d'aujourd'hui comprennent les LLM, les pipelines RAG, les agents autonomes et d'innombrables autres systèmes capables dedecision-makingetautonomous action.

Ce ne sont pas seulement des services passifs qui attendent l’entrée – ils sont des participants actifs, générant de nouveaux flux de travail, accédant aux ressources et même générant spontanément de nouvelles demandes.

Considérez un scénario dans lequel un agent d’IA intégré à votre produit doit collecter des données, les traiter et appeler des API externes pour accomplir une tâche.it might act au nom de a human user, déclenchant une cascade d'actions de machine en arrière-plan.

Chaque étape implique des décisions d’identité complexes :

• Qui fait réellement cette demande ?
• Quelles autorisations s’appliquent ?
• Où s’arrête l’homme et où commence la machine ?

C’est pourquoi les identités de machine ne peuvent plus être traitées comme de simples acteurs de back-end.first-class citizensdans le modèle d’identité de votre système, capable de réaliser – et exigeant – le même niveau d’accès, de contexte et de responsabilité que n’importe quel utilisateur humain.

La question n'est plusSivous aurez besoin de gérer les identités de machine de cette façon, maisà quelle vitesseVous pouvez adapter vos systèmes pour gérer cette réalité croissante.

Les identités de machines dépassant les humains changent tout

Cela peut sembler dramatique, mais nous sommes déjà au point de départ où les identités de machines se multiplient plus rapidement que les utilisateurs humains ne le pourraient jamais.

Chaque agent d’IA intégré dans une application, chaque service externe appelant votre API, chaque système automatisé déclenchant des actions – chacun représente une identité de machine.

A single human user might generate dozens of machine identity actions without even realizing it.

Leur assistant personnel de l'IA déclenche une requête, qui appelle un autre service d'IA, qui fait tourner des agents supplémentaires - tous en cascade dans une chaîne d'interactions machine à machine.machine identities dominate your traffic and access control flows.

Et il ne s'agit pas seulement de vos systèmes internes.Même si votre produit n'est pas natif de l'IA, il est probable que des agents externes de l'IA soientalready interacting with it— scraping de données, déclenchant des API, ou analysant les réponses.sontutilisateurs, que vous l’ayez voulu ou non.

Les implications pour le contrôle d’accès et la sécurité sont massives :

• Les hypothèses statiques sur le volume de l'identité se brisent.
• Les modèles traditionnels qui distinguent nettement les utilisateurs et les services créent des points aveugles.
• Auditer qui a fait ce qui devient presque impossible si le système ne peut pas suivre les actions à travers des couches d’agents d’IA.

Your application is already being used by more machines than humans—you just may not be tracking it yet.

C’est pourquoi la prochaine étape logique est de repenser la façon dont nous approchons la gestion de l’identité – parce que le modèle actuel de scission ne s’étendra tout simplement pas dans cette nouvelle réalité.

Les gazoducs séparés échouent

La plupart des applications fonctionnent encore aujourd’hui avec deux pipelines d’identité distinctes, l’une pour les humains et l’autre pour les machines.Humans get OAuth flows, sessions, MFA, and access tokens.

Les machines sont généralement livréesa static API key or a long-lived secretCaché dans un vault.

Les humains sont dynamiques, imprévisibles et prédisposés à l’erreur, tandis que les machines sont supposées être statiques, prévisibles et étroitement ciblées.

That assumption doesn’t hold up anymore, en particulier avec la montée des agents dirigés par l'IA agissant de manière autonome.

Les agents d’IA n’exécutent pas seulement des tâches étroites et préprogrammées, ils peuvent :

• La raison basée sur le contexte
• Démarrer de nouvelles demandes à mi-exécution
• Des actions en chaîne qui n'ont pas été explicitement conçues à l'avance
• Déléguer des tâches à d’autres agents ou services

Traiter ces agents comme des comptes de service statiques crée de graves risques :

• Points aveugles : les actions de la machine se produisent en dehors de votre logique de contrôle d'accès existante.
• Fragmentation des politiques : les développeurs doivent maintenir et raisonner sur deux modèles d’accès différents.
• Les échecs d’audit : vous perdez la possibilité de suivre l’origine d’une demande à travers des couches d’activité basées sur l’IA.
• Privilege creep : les identités de machine sont souvent trop autorisées parce que c’est « plus facile » que de refactoriser le modèle.

Au fur et à mesure que le nombre d’agents de l’IA augmente, le coût de la gestion – et de la sécurisation – de deux modèles d’identité distincts le fait également.

Nous avons abordé une version de ce défi dansour deep dive into Generative AI’s impact on IAM, où nous avons exploré comment ces lignes floues brisent le contrôle d'accès traditionnel. les identités de machine ne peuvent plus vivre dans un pipeline silosé.

La solution ?A unified identity modelCelle qui traite les identités de machines comme des citoyens de première classe, soumis à la même rigueur, aux mêmes règles et à la même responsabilité que les humains.

Gestion de l’identité unifiée

Le chemin est clair :stop treating machine identities as second-class citizensAu lieu de cela, amenez-les dans le même pipeline d’identité que vos utilisateurs humains, soumis aux mêmes politiques, contrôles et audits.

La gestion unifiée des identités signifie :

• Appliquer les mêmes cadres d’authentification et d’autorisation aux humains et aux machines
• Suivre qui ou ce qui a initié chaque action, même lorsque les demandes sont en cascade à travers plusieurs agents d’IA
• Concevoir des politiques qui justifient l’intention, les relations et la délégation, pas seulement les créances statiques

Il y a beaucoup à gagner de cela -

Cette approche unifiée simplifie l’ensemble de votre modèle d’identité, éliminant la nécessité de juguler les systèmes séparés et réduisant la complexité pour les développeurs et les équipes de sécurité.

Il renforce la responsabilité en vous permettant de tracer même les chaînes les plus complexes d’actions guidées par la machine jusqu’à leur source d’origine.QuellesIl a agiau nomdeQuelleshumaine .

Et le plus important,it scalesAlors que les identités de machine se développent et évoluent inévitablement, votre modèle d’accès reste résilient, capable de gérer le volume et la complexité sans casser ou créer de nouveaux points aveugles.

C'est exactement le genre de changement que nous avons discuté dans notreguide to AI Security Posture Management (AISPM), où nous avons exploré comment les systèmes modernes doivent gérer les agents d'IA, la mémoire, les outils externes et les interactions dynamiques -all within a unified framework.

Unifier votre modèle d’identité ne signifie pas que les machines et les humains perdent leurs différences.recognizing that both deserve equally robust access controlLes agents d’IA peuvent agir différemment des humains, mais le besoin de vérifier leurs actions, de suivre leurs autorisations et d’auditer leur comportement est tout aussi réel, sinon plus.

Parce que dans le monde nous entrons rapidement,machine identities won’t just participate in your systems—they’ll dominate themLa question est de savoir si votre modèle d’accès est prêt pour ce changement.

L'intention humaine comme source de l'action des machines

Au cœur de ce défi se trouve un fait simple :machine actions almost always originate from human intentQu’il s’agisse d’un assistant d’IA capturant des données, d’un agent automatisé déclenchant un flux de travail ou d’un service tiers interagissant avec votre API – quelque part, un ensemble humain qui actionne en mouvement.

Les modèles traditionnels de contrôle d’accèsrarely capture that nuanceUne fois qu'une identité machine prend le contrôle, la connexion avec l'humain est perdue dans la traduction.Les demandes apparaissent isolées, ce qui rend presque impossible de tracer une décision à la personne qui l'a autorisée, ou même de savoir s'il y aétaitl’autorisation humaine en premier lieu.

C’est là que le concept de"on behalf of" relationshipsLes systèmes doivent reconnaître non seulementquiIl fait une action, maisPourquoietpour à quiChaque agent de l’IA qui fonctionne à l’intérieur de votre application – ou qui consomme vos services à l’extérieur – devrait faire avancer ce contexte.

Nous en avons profondément parlé dans notre récent article surGestion des autorisations d’IA et contrôle d’accès avec Retrieval-Augmented Generation (RAG) et ReBACLes agents de l’IA agissant de manière autonome doivent hériter – et être limités par – des droits d’accès des humains qu’ils représentent.Rien de moins ouvre la porte à l’exposition de données non intentionnelles, à l’excès de portée, ou pire, les agents de l’IA qui prennent des décisions n’ont jamais été autorisés par un être humain.

Le maintien de cette chaîne de responsabilité garantit que les identitésdon’t just act—they act within the scope of human intentÀ mesure que les agents de l’IA deviennent plus capables et plus complexes, cette connexion maintient votre système sécurisé, audible et aligné sur les attentes de vos utilisateurs.

Les capacités d'IA forcent à repenser les modèles d'accès

Ce qui rend les identités de machine basées sur l’IA si difficiles, ce n’est pas seulement leur volume – c’est leur comportement. Contrairement aux services traditionnels qui suivent des tâches prédictives et prédéfinies, les agents d’IA sontdynamic by designIls peuvent générer de nouvelles actions au milieu du processus, lancer de multiples demandes, déléguer des tâches à d’autres agents et même identifier des ressources supplémentaires dont ils ont « besoin » pour atteindre un objectif – tout cela sans instructions explicites et étape par étape d’un développeur.

Ce niveau d'autonomie rompt avec les modèles traditionnels de contrôle d'accès basé sur les rôles (RBAC).RBAC a été construit pour les environnements statiques où les autorisations sont liées à des rôles bien définis et rarement changent en temps réel.don’t fit neatly into predefined roles- leurs actions dépendent du contexte, des données et de la nature évolutive de la tâche en cours.

Pour gérer cette complexité, les systèmes doivent aller au-delà des rôles statiques etRelationship-Based Access Control (ReBAC)Contrairement au RBAC, le ReBAC évalue l'accès en fonction dethe relationships between entitiesl’agent de l’IA, les données qu’il essaie d’accéder, l’être humain qu’il représente et même le contexte de la demande.Quoiune identité est autorisée à faire; il s'agit dePourquoi the identity is acting, Au nom de quietDans quelles conditions.

Ce changement est crucial car les agents d'IA opèrent de plus en plusautonomouslySans politiques relationnelles et contextuelles, les agents de l’IA risquent de surpasser, d’accéder aux ressources qu’ils ne devraient pas, ou de déclencher involontairement des actions en cascade qui sont difficiles – sinon impossibles – à auditer.

dans notredeep dive into dynamic AI access control, nous avons exploré comment les systèmes modernes doivent s'adapter à ces dynamiques basées sur l'IA en mettant en œuvrereal-time, event-driven policy checksReBAC est l’un des moyens les plus efficaces de capturer les relations nuancées que l’IA introduit et d’assurer l’accès.uniquementquand elle s’aligne à la fois sur la politique et sur l’intention humaine.

Modèles de mise en œuvre pratiques

Transposer ces concepts en pratique signifie réfléchir à la façon dont votre système gère les vérifications d'identité, la délégation et l'audit, en particulier à mesure que les agents de l'IA prennent des rôles de plus en plus complexes.

Un modèle puissant est lecheck_agent() approach, qui capture explicitement la délégation et les relations "au nom" dans votre logique de contrôle d'accès.Un agentCette méthode permet d’évaluerPour qui agit l’agentetQuel contexte s’applique.

Ainsi, au lieu d’une traditionPermit.ioContrôle d’accès comme :

permit.check(identity, action, resource)

Vous changez de :

permit.check(
  {
    key: agent_identity,
    attributes: {"on_behalf": [user_identity]}
  },
  action,
  resource
)

Cela garantit que les décisions d'accès tiennent compte à la fois des autorisations de l'agent d'IA et de l'homme qu'il représente, en appliquant les limites de la délégation et en empêchant les chaînes d'accès non autorisées.

Permit.iosupporte ce modèle nativement, permettant aux applications d'exécuterfine-grained, relationship-aware policiesEn outre, des outils commeOpal(Open Policy Administration Layer) aide à synchroniser les politiques et à obtenir des données dynamiques, telles que les relations actuelles ou les scores de risque, de sorte que chaque vérification reflèteContexte en temps réel.

Pour les scénarios impliquant des agents d'IA opérant avec des niveaux de confiance variables ou des profils de risque, vous pouvez également incorporeridentity ranking systemscommeArcJetPlutôt que de traiter toutes les identités de machine de la même manière, ArcJet les note en fonction des signaux comportementaux, ce qui permet à votre système d’appliquer des politiques plus strictes aux acteurs à faible confiance et plus flexibles aux agents vérifiés.

Ces modèles pratiques n’améliorent pas seulement la sécurité – ils rendent votre systèmemore auditableChaque action d’IA porte son origine, son contexte et son raisonnement, vous permettant de suivre la chaîne complète des décisions si quelque chose ne va pas.

Comme nous l’avons exploré précédemment, ces modèles deviennent particulièrement puissants lorsqu’ils sont appliqués à des workflows d’IA complexes où les agents interagissent avec des outils externes, des stocks de mémoire et des ressources sensibles.

Préparer la majorité de l'identité machine

Les identités de machine ne viennent pas – elles sont déjà là.vastly outnumber human usersLes agents d’IA, les services automatisés et les flux de travail autonomes ne sont plus des processus d’arrière-plan – ils participent activement à votre application, prennent des décisions, déclenchent des actions et consomment des ressources.

L’ancienne façon de gérer l’identité, c’est-à-dire de diviser les êtres humains et les machines en pipelines statiques distinctes, ne s’étendra tout simplement pas dans cette nouvelle réalité.L’avenir de l’identité et du contrôle d’accès dépend de l’unification de votre modèle, du traitement de l’identité de la machine en tant quefirst-class citizenset assurerevery action—human or machine—can be traced, authorized, and audited.

Les outils et les cadres pour le faire existent déjà.ReBACLa mise en œuvreon-behalf-of delegation patternsou à adopterreal-time dynamic access control, vous pouvez commencer à construire des systèmes aujourd'hui qui sont prêts pour la majorité de l'identité de machine.

Si vous êtes intéressé à plonger plus profondément dans ce changement, consultez notre série complète sur les défis d'identité d'IA:

• Les défis de l'IA générative dans la gestion de l'identité et de l'accès (IAM)
• Où puis-je aller ? - Gestion des autorisations
• The When – Contrôle d’accès dynamique d’IA pour un timeline changeant

Car la question n’est plusSiLes identités de machine domineront vos systèmes - c'est si votre modèle d'accès est prêt pour eux quand ils le font.

Si vous avez des questions, assurez-vous de nous rejoindreLa communauté Slack, où des milliers de développeurs construisent et mettent en œuvre l'autorisation.