Identité non humaine : pourquoi les agents d'IA en ont besoin

Qu'est-ce qu'une identité non humaine ?

UN Identité non humaine est une identité numérique utilisée par des logiciels, des services, des processus automatisés, des appareils, des charges de travail ou des agents d'IA pour authentifier et accéder aux systèmes sans agir en tant qu'utilisateur humain.

Les exemples incluent les comptes de service, les principaux de service, les identités gérées, les charges de travail, les appareils, les robots, les scripts, les pipelines CI/CD, les intégrations d'API et les agents IA.

Une identité non humaine n'est pas automatiquement une clé API, un mot de passe, un jeton, un certificat, une machine, un robot ou un modèle. Il peut s'agir d'informations d'identification, de mécanismes d'authentification, d'entités d'exécution ou de ressources connectées.

Le modèle comporte trois questions :

• Identité: Qui ou quoi agit ?
• Titre : Comment cela prouve-t-il cette identité ?
• Autorisation: À quoi peut-il accéder ou changer ?

Identité, informations d'identification et autorisation

Un identifiant n’est pas l’identité elle-même. C'est une preuve utilisée par une identité pour s'authentifier.

Les principaux types d'identité non humaine

Comptes de service

Ces comptes prennent en charge les applications, les scripts, les planifications et les intégrations. Les risques incluent la propriété partagée, les mots de passe statiques, l’accès excessif et l’absence de date de retrait.

Identités principales des applications et des services

Il s'agit des applications accédant aux API, aux services cloud ou aux ressources, y compris le SaaS et l'automatisation interne.

Identités gérées et de charge de travail

Ceux-ci représentent des charges de travail logicielles telles que des machines virtuelles, des conteneurs, des fonctions sans serveur, des tâches CI/CD et des applications cloud. Les plateformes prises en charge peuvent les utiliser sans stocker de secrets permanents directement dans le code.

Identités des machines et des appareils

Ceux-ci vérifient les serveurs, les ordinateurs portables, les équipements réseau, les systèmes industriels et les appareils IoT via des certificats, des clés ou des enregistrements d'appareils.

Identités des agents IA

Ceux-ci représentent des agents qui interprètent les objectifs, choisissent les outils, accèdent aux ressources et prennent des mesures. Les agents IA s'intègrent dans l'identité non humaine, mais leur comportement adaptatif les rend plus difficiles à gouverner que les comptes de services fixes.

Identité non humaine, identité de machine et identité de charge de travail

Identité non humaine est le large parapluie. L'identité de la machine, l'identité de la charge de travail, les comptes de service et l'identité de l'agent sont des catégories ou des modèles de mise en œuvre plus restreints.

Identité non humaine comparée aux types d'identité associés

La terminologie diffère selon les plateformes. La gouvernance doit se concentrer sur ce que représente l’identité, où elle fonctionne, à quoi elle peut accéder et à qui elle appartient. Toutes les identités non humaines ne représentent pas une machine physique.

Pourquoi les agents IA modifient le problème de l'identité non humaine

Les agents suivent des objectifs, pas seulement des instructions fixes

L'automatisation traditionnelle peut copier une sauvegarde à minuit. Un agent chargé d'enquêter sur des performances inhabituelles et de préparer un rapport peut choisir différentes actions en fonction de ce qu'il constate.

Les agents utilisent plusieurs outils

Un agent peut se déplacer entre les API, les fichiers, les navigateurs, les feuilles de calcul, les bases de données, les outils de communication et les sous-agents. Chaque connexion étend la chaîne d'autorisations.

Les autorisations varient selon la tâche

Les workflows de recherche, de reporting et de support client ne devraient pas bénéficier du même accès simplement parce qu’ils utilisent la même plate-forme.

Les agents peuvent déléguer

Un agent principal peut faire appel à un outil spécialisé ou à un autre agent. L'accès doit être traçable et soit hérité selon des règles claires, soit autorisé séparément.

Les agents agissent au nom des personnes

Les systèmes doivent distinguer les actions humaines, les actions d'agent demandées par l'homme, les étapes sélectionnées par l'agent dans une tâche approuvée et les actions déléguées. L'identité de l'agent doit préserver le lien entre le demandeur, l'exécuteur testamentaire, les informations d'identification et le résultat.

Pourquoi les agents IA ne devraient pas se cacher derrière des comptes humains

Un agent peut utiliser la session de navigateur, le jeton API, le compte de messagerie ou la connexion à une application d'un employé. Le flux de travail peut fonctionner, mais l'attribution devient faible.

Logs show only the employee account, while the agent inherits everything that employee can reach. Les équipes de sécurité ne peuvent pas séparer de manière fiable le comportement humain de l’automatisation, et l’accès peut survivre au-delà de la tâche prévue.

Un meilleur modèle d'attribution est :

• Initié par : Alex
• Exécuté par : Agent chargé des rapports hebdomadaires
• Environnement: Bureau d'entreprise approuvé
• Approuvé par : Responsable financier

Le sponsor reste responsable du but, tandis que l'identité de l'agent montre qui a effectué le travail. Un agent doit agir pour un humain sans se distinguer de cet humain.

Les principaux risques des identités non humaines non gérées

Identités orphelines

L'accès reste actif après le départ d'un employé, la fin d'un projet, le remplacement d'une intégration ou l'abandon d'un agent.

Autorisations excessives

Un accès large est accordé parce que des politiques étroites provoquent des échecs et que la commodité temporaire devient un privilège permanent.

Des références de longue durée

Les mots de passe statiques, les clés API, les certificats et les jetons peuvent rester utilisables longtemps après que le besoin initial ait disparu.

Identités partagées

Plusieurs applications, agents ou employés utilisent un seul compte, ce qui affaiblit l'attribution et la propriété.

L’étalement identitaire

Les comptes de service, les robots, les applications OAuth, les jetons, les scripts et les agents enfants s'accumulent sans inventaire fiable.

Faible responsabilité

Après un incident, la responsabilité peut être contestée entre le demandeur, le propriétaire du flux de travail, le propriétaire de l'application, l'approbateur et les fournisseurs de technologie.

Le plus grand risque n’est souvent pas qu’une identité existe, mais que personne ne sache pourquoi elle existe, ce qu’elle peut faire ou quand elle devrait disparaître.

Un cycle de vie de l'identité non humaine en huit étapes

Étape 1 : Découvrir

Comptes de service d'inventaire, identités d'application, applications OAuth, agents cloud et locaux, robots, scripts, certificats, planifications, intégrations d'API et outils connectés.

Étape 2 : S'inscrire

Enregistrez un nom unique, un type, un objectif, un créateur, un sponsor, un service, un environnement d'exécution, des outils connectés, des données accessibles, un type d'identifiant et une date d'expiration.

Étape 3 : Attribuez un sponsor humain

Une personne nommée doit approuver l'objectif, vérifier l'accès, répondre aux incidents, transférer la propriété et autoriser le retrait.

Étape 4 : Définir la limite d'identité

Documentez les systèmes, dossiers, enregistrements, outils, actions et interdictions explicites autorisés.

Étape 5 : Appliquer le moindre privilège

Accordez uniquement ce dont le flux de travail actuel a besoin. Évitez l’accès administratif permanent ajouté simplement pour réduire les échecs.

Étape 6 : Préférez les informations d’identification de courte durée

Lorsque cela est pris en charge, utilisez des jetons temporaires, des identités gérées, une fédération de charge de travail, des informations d'identification spécifiques aux tâches, l'expiration et la révocation.

Étape 7 : Surveiller le comportement

Capturez les événements d'authentification, les ressources consultées, les outils appelés, les fichiers ouverts, les modifications, les transferts, les échecs, les tentatives et la délégation.

Étape 8 : Rotation, transfert et retraite

Lorsque le flux de travail change ou se termine, faites pivoter les informations d'identification, transférez la propriété, supprimez les planifications, révoquez les autorisations, déconnectez les outils, retirez les identités des enfants et conservez les enregistrements d'audit.

Liste de contrôle du cycle de vie de l'identité non humaine

Comment accorder le moindre privilège aux agents IA

Le moindre privilège doit suivre le flux de travail, et non la capacité maximale de l'agent.

Un agent de reporting hebdomadaire peut avoir besoin d'un dossier de reporting, de deux tableaux de bord, de téléchargements CSV, d'un répertoire de sortie et de l'autorisation de préparer un brouillon. Il se peut qu'il n'ait pas besoin de l'intégralité du disque dur, de chaque profil de navigateur, de la messagerie personnelle, des contrôles de facturation, de la gestion des autorisations, de la suppression du fichier source ou de l'autorisation d'envoyer le rapport à l'extérieur.

Définissez quatre couches :

• Portée des ressources : Quels systèmes, dossiers, applications et enregistrements ?
• Portée des actions : Lire, écrire, modifier, supprimer, publier ou envoyer ?
• Portée temporelle : Permanent, programmé, temporaire ou basé sur des tâches ?
• Portée de l'approbation : Quelles actions nécessitent une confirmation explicite ?

Le moindre privilège limite ce qu'un agent peut voir, ce qu'il peut faire, combien de temps il peut le faire et avec l'approbation de qui.

Pourquoi les agents Desktop AI ont besoin de limites d’identité claires

Les agents de bureau peuvent interagir avec les fichiers locaux, les applications installées, les sessions de navigateur, les informations d'identification enregistrées, les téléchargements, les captures d'écran, le contenu du presse-papiers, les contrôles du système d'exploitation et les applications de communication. Leur frontière d’identité peut donc s’étendre sur bien plus d’une API.

Un flux de travail de bureau peut impliquer :

Demandeur humain -> canal de communication -> agent de bureau -> appareil d'entreprise -> identité du navigateur -> application métier -> dossier de sortie

L'organisation doit savoir qui a soumis la tâche, quel agent l'a reçue, quel appareil et quel compte ont été utilisés, quelles actions ont eu lieu, quel résultat a été créé et qui l'a examiné.

L'exécution locale peut réduire certaines transmissions de données, selon la configuration. Il ne supprime pas le risque d’identité et ne précise pas qui représente l’agent et quelles autorisations il utilise.

EasyClaw illustre pourquoi les agents de bureau ont besoin de limites explicites entre les fichiers, les navigateurs, les applications et les sorties.

Comment EasyClaw s'intègre dans une stratégie d'identité d'agent gouvernée

EasyClaw est un agent de flux de travail d'IA natif de bureau pour le travail impliquant des fichiers locaux, des applications, des interfaces de navigateur, des rapports, des révisions et des dossiers de projet. Il ne s'agit pas d'une plate-forme de gestion des identités ni d'un remplacement des contrôles IAM, d'accès privilégié, de rotation des informations d'identification ou de menaces.

Son rôle pratique est d'illustrer pourquoi un agent de bureau doit fonctionner dans une limite d'identité nommée, limitée, visible et révisable.

Identifier le demandeur humain

Définissez qui peut émettre des tâches EasyClaw, quels canaux sont approuvés, comment les demandeurs s'authentifient et qui peut démarrer des flux de travail sensibles. Chaque demande doit renvoyer à une personne spécifique.

Identifier l'environnement d'exécution EasyClaw

Enregistrez le déploiement EasyClaw, l'appareil d'entreprise, le compte du système d'exploitation, le profil du navigateur, les applications approuvées et le propriétaire du flux de travail. Le demandeur et l’environnement d’exécution sont connectés, mais ce ne sont pas le même acteur.

Limiter la portée des fichiers et des applications

Un flux de travail de reporting peut nécessiter un dossier, un classeur Excel, des tableaux de bord sélectionnés, un modèle PDF et un répertoire de sortie. Il ne doit pas accéder automatiquement à tous les fichiers locaux, comptes de navigateur, lecteurs cloud, paramètres administratifs ou systèmes non liés. Une portée claire réduit également la sélection de fichiers erronés et les écrasements accidentels.

Gardez les actions consécutives derrière l’approbation

Exigez l'approbation humaine pour les messages externes, la publication publique, la suppression ou l'écrasement de fichiers, la soumission d'informations financières, la modification des dossiers clients, la modification des autorisations, l'exécution des paiements et la modification des contrats.

EasyClaw peut organiser des travaux intermédiaires, préparer des packages de révision et renvoyer des livrables utilisables. Les décisions irréversibles, visibles de l’extérieur, financièrement importantes ou juridiquement conséquentes doivent rester du ressort de l’humain responsable.

Documenter le cycle de vie du flux de travail

Chaque flux de travail doit avoir un nom, un objectif, un sponsor, des entrées approuvées, des actions, une destination de sortie, une date de révision, une condition d'arrêt et une procédure de retrait. Les nouveaux comptes, chaînes ou destinations doivent déclencher un examen.

EasyClaw doit fonctionner comme un agent de bureau visible et étendu au sein d'un flux de travail approuvé, et non comme un logiciel invisible empruntant un accès illimité à un compte humain.

Exemple : Donner à un agent de reporting EasyClaw une limite d'identité claire

Un responsable des opérations demande : « Préparez le rapport de performance de cette semaine, comparez-le avec celui de la semaine dernière et renvoyez le projet pour examen.

Le flux de travail EasyClaw approuvé ouvre les tableaux de bord sélectionnés, télécharge les exportations en cours, lit le suivi Excel hebdomadaire, compare le rapport précédent, prépare un brouillon, enregistre le package et le renvoie. EasyClaw gère l'exécution de nombreux documents, tandis que les contrôles d'identité et de sécurité définissent ce qu'il peut utiliser.

Limites d'identité pour un flux de travail de reporting EasyClaw

La chaîne d'attribution doit rester visible :

• Initié par : Responsable des opérations
• Exécuté par : Flux de travail de reporting EasyClaw
• Données consultées : Tableaux de bord et dossier de reporting approuvés
• Révisé par : Responsable des opérations
• Distribué par : Propriétaire humain après approbation

Cela sépare la demande, l’exécution, l’accès, l’approbation et la distribution. Si les chiffres semblent erronés, l’équipe peut inspecter les sources approuvées, les fichiers utilisés, les résultats générés et la décision du réviseur. EasyClaw est la couche d'exécution du workflow ; les systèmes d'identité existants restent responsables de l'authentification, des informations d'identification, des autorisations et de la politique.

Conclusion : chaque agent a besoin d'une identité, d'un propriétaire et d'une date d'expiration

L'identité non humaine comprend les applications, les services, les machines, les charges de travail, les scripts, les robots, les processus automatisés et les agents d'IA.

Les agents d’IA font monter les enjeux car leur comportement peut être adaptatif, délégué et réparti entre les outils. Les organisations doivent savoir quel agent agit, qui le sponsorise, quelles informations d'identification et autorisations il utilise, comment les actions sont enregistrées, quand l'approbation est requise et quand l'accès expire.

EasyClaw n'est pas une plateforme de gestion d'identité. Son modèle d'exécution de bureau montre pourquoi les flux de travail des agents nécessitent des propriétaires nommés, un accès restreint aux fichiers et aux applications, une exécution visible, des sorties révisables et une approbation humaine pour les actions consécutives.

Chaque agent IA a besoin d'une identité, d'un sponsor humain, d'une limite d'autorisation et d'une date d'expiration.

FAQ