Délégation d'agents IA : Comment l'autorité déléguée modifie la sécurité des identités et des accès

Les agents d'IA agissent rarement seuls.

Un utilisateur demande à un agent de préparer le renouvellement de son contrat. L'agent consulte un CRM, récupère les enregistrements d'assistance, contacte un autre agent pour analyser l'utilisation du produit et utilise une application pour mettre à jour le compte.

Chaque étape peut impliquer une identité, des informations d'identification, un ensemble d'autorisations et un chemin d'accès différents.

Mais une question relie l'ensemble du flux de travail :

De quelle autorité l'agent IA exerce-t-il ?

C'est le problème de délégation d'agents IA.

La délégation se produit lorsqu'un agent d'IA agit en utilisant une autorité qui lui a été conférée, héritée ou transmise par une autre identité ou un autre système. Cette autorité peut provenir d'un utilisateur humain, d'une application, d'un compte de service, d'une identité machine, d'un autre agent ou d'une combinaison de ces éléments.

Cela distingue la délégation de l'authentification ou de l'autorisation.

• Authentification établit qui ou ce qu'est une identité.
• Autorisation détermine ce à quoi cette identité peut accéder ou ce qu'elle peut faire.
• Délégation détermine de quelle autorité un agent peut exercer lorsqu'il agit.

Pour les équipes de sécurité, cette distinction est importante car un agent d'IA peut s'authentifier sous une identité tout en exerçant des autorisations provenant d'ailleurs.

L'identité qui authentifie n'est pas toujours celle qui a conféré l'autorité.

À mesure que les agents commencent à utiliser des outils, à invoquer des API, à créer des sous-agents et à interagir avec les applications d'entreprise, les organisations doivent préserver la relation entre identité, autorité, finalité, données sensibles et action tout au long de la chaîne de délégation.

Qu’est-ce que la délégation d’agents IA ?

La délégation d'agent IA est le transfert ou l'exercice d'une autorité qui permet à un agent IA d'effectuer une tâche, d'accéder à une ressource, d'invoquer un autre système ou d'agir au nom d'une autre identité.

Prenons l'exemple d'un employé utilisant un assistant IA d'entreprise.

L'employé demande :

“ Examinez les comptes de mes clients et identifiez les renouvellements qui nécessitent une attention particulière. ”

L'agent peut avoir besoin de :

1. Identifier l'utilisateur demandeur.
2. Accédez aux comptes que l'utilisateur peut consulter.
3. Récupérer les informations client.
4. Interroger l'utilisation du produit via une autre application.
5. Faites appel à un agent spécialisé pour analyser l'historique du support.
6. Recommandations de retour.

L'agent ne possède pas nécessairement toutes les autorisations requises pour accomplir ces étapes.

Il peut exercer des autorisations d'utilisateur déléguées, utiliser sa propre identité d'application, invoquer un compte de service ou transmettre du travail à une autre identité d'IA.

Cela crée une chaîne d'autorité.

Délégation d'agents IA vs. Authentification vs. Autorisation

La délégation est souvent regroupée avec l'authentification et l'autorisation, mais chacune répond à une question de sécurité différente.

Cette distinction est importante car un système d'IA authentifié avec succès peut toujours exercer une autorité déléguée inappropriée.

Un agent peut posséder une identité et des identifiants valides tout en recevant plus de pouvoirs que ce que l'utilisateur avait prévu ou que ce que la tâche commerciale exige.

Pour une analyse plus approfondie des deux premiers contrôles, voir Authentification vs. autorisation des agents IA.

Comment les agents d'IA reçoivent une délégation d'autorité

La délégation d'IA ne suit pas un seul modèle technique.

Les agents d'entreprise peuvent recevoir ou exercer leur autorité par plusieurs voies.

Accès utilisateur délégué

Un agent agit au nom d'un utilisateur connecté et accède aux ressources relevant du périmètre autorisé de cet utilisateur.

Ce modèle permet de préserver les limites d'accès de l'utilisateur lorsque les systèmes en aval appliquent correctement l'identité déléguée.

Accès à l'application ou à l'application uniquement

Un agent ou son application agit en utilisant sa propre identité et ses propres autorisations plutôt que celles d'un utilisateur connecté.

Ce modèle prend en charge l'automatisation en arrière-plan, mais les équipes doivent définir précisément le périmètre d'accès de l'application car celle-ci peut fonctionner indépendamment des autorisations de l'utilisateur.

Accès au compte de service

Une application ou un agent d'IA utilise un compte de service pour accéder à une base de données, une application SaaS, un référentiel de fichiers ou toute autre ressource d'entreprise.

Si ce compte dispose déjà de larges autorisations, le système d'IA peut hériter d'une empreinte d'accès bien plus importante que celle prévue.

Accès API et OAuth

Un agent utilise des privilèges API ou des étendues OAuth pour interagir avec les services en aval.

L'autorité effective dépend des portées, des rôles, de l'application en aval et du contexte d'identité que le flux de travail préserve.

Délégation d'agent à agent

Un agent confie une partie d'une tâche à un autre agent.

L'agent récepteur peut avoir sa propre identité et ses propres autorisations, recevoir un contexte délégué ou utiliser des outils non disponibles pour l'agent initiateur.

Cela peut créer un problème d'autorité en chaîne où l'action finale se situe à plusieurs étapes de la requête initiale.

Accès délégué vs. accès à l'application uniquement

L'une des distinctions les plus utiles pour l'IA d'entreprise est de savoir si l'agent agit. pour un utilisateur ou comme elle-même.

Aucun des deux modèles n'est intrinsèquement suffisant à lui seul.

L'approche appropriée dépend de la tâche, de l'architecture du système, des ressources, de la sensibilité des données et des actions que l'agent doit effectuer.

Le principal mécanisme de contrôle consiste à expliciter l'autorité et à la limiter à l'objectif visé.

La plus grande erreur en matière de délégation : l’extension des pouvoirs

La délégation ne doit pas signifier l'extension des autorisations.

Considérons cette chaîne :

Utilisateur → Agent A → Agent B → Base de données

L'utilisateur ne peut accéder qu'aux comptes situés en Amérique du Nord.

L'agent A reçoit correctement ce contexte utilisateur.

L'agent A délègue ensuite l'analyse à l'agent B.

L'agent B interroge la base de données via un compte de service disposant d'un accès client global.

Le flux de travail a franchi une limite d'autorisation.

L'agent B peut techniquement avoir l'autorisation de consulter chaque fiche client, mais cela ne signifie pas que l'utilisateur initial a autorisé le flux de travail à le faire.

Voilà pourquoi le moindre privilège pour les agents IA ne peut s'arrêter au premier maillon de la chaîne.

Les équipes de sécurité doivent évaluer l'accès effectif à chaque étape déléguée.

La délégation peut prendre quatre formes différentes.

Un même flux de travail d'entreprise peut contenir les quatre.

C’est ce qui fait de la délégation d’IA un problème d’identité, d’accès et de sécurité des données plutôt qu’un simple problème d’architecture applicative.

Délégation d'agents IA vs. usurpation d'identité

La délégation et l'usurpation d'identité peuvent se ressembler car toutes deux permettent à une entité d'agir en relation avec une autre identité.

Mais l'intention de gouvernance diffère.

Délégation devrait préserver une relation explicite entre l'identité d'origine et l'entité agissant en son nom.

Imitation permet à une autre entité d'agir comme si elle était l'identité d'origine.

Pour les systèmes d'IA, la délégation explicite offre généralement une meilleure responsabilisation car les équipes peuvent préserver les deux aspects de la relation :

Mandant initial → Agent intérimaire

Cette distinction devient importante lors de l'enquête.

Si un agent modifie un dossier client, l'organisation devrait idéalement déterminer :

• Quel agent a effectué l'action
• Quelle identité a initié le flux de travail ?
• Quel pouvoir l'agent a-t-il exercé ?
• Quelles autorisations ont permis cette modification ?
• Quelles données l'agent a-t-il consultées avant d'agir ?
• La question de savoir si l'action est restée conforme à l'objet délégué

Pourquoi les systèmes multi-agents rendent la délégation plus difficile

La délégation devient nettement plus complexe lorsque les agents peuvent invoquer d'autres agents.

Considérer:

Utilisateur → Agent d'orchestration → Agent de recherche → Agent financier → Outil de paiement

L'utilisateur initial peut ne jamais interagir directement avec l'agent financier ou l'outil de paiement.

L'action finale peut néanmoins toujours découler de la requête initiale de l'utilisateur.

Les équipes de sécurité doivent préserver la chaîne plutôt que de traiter chaque invocation comme un événement d'authentification indépendant.

C'est ici Gestion des identités et des accès pour les agents d'IA et la gouvernance de l'identité de l'IA devient particulièrement importante.

Les sept risques liés à la délégation d'agents d'IA

1. Autorité déléguée excessive

L'agent reçoit plus de pouvoirs que ce que requiert sa tâche.

Un utilisateur peut autoriser un assistant IA à résumer un dossier tandis qu'une intégration sous-jacente lui donne accès à un référentiel entier.

2. Expansion de l'autorité à travers les houblons

Un agent, un outil, une application ou un compte de service en aval dispose de permissions plus étendues que l'identité qui a initié le flux de travail.

Le flux de travail y accède donc au fur et à mesure de son déplacement.

3. Contexte de perte d'identité

Un système en aval ne voit que l'agent ou le compte de service et perd l'identité de l'initiateur d'origine.

Cela rend la responsabilisation et l'application des politiques plus difficiles.

4. Exposition excessive aux données

Les autorisations déléguées peuvent exposer des informations sensibles qui ne sont pas nécessaires à la tâche.

L'accès peut techniquement réussir tout en violant le principe du moindre privilège ou la finalité commerciale.

5. Chaînes de délégation qui perdurent au-delà de la tâche

Les jetons persistants, les comptes de service, les autorisations OAuth ou les permissions d'application peuvent rester disponibles après la fin de la requête initiale.

Une intention commerciale temporaire peut créer un accès technique durable.

6. Fuite de contexte entre agents

Un agent initiateur peut transmettre des informations contextuelles sensibles à un autre agent qui n'en a pas besoin dans leur intégralité.

La délégation concerne donc à la fois l'autorité et l'information.

7. Responsabilité floue

Lorsque plusieurs agents et outils participent à un flux de travail, les équipes peuvent avoir du mal à déterminer qui a approuvé l'accès, quelle identité a provoqué l'action et qui est responsable de la correction.

Le risque lié à la délégation est aussi un problème de données

Les autorisations à elles seules ne permettent pas aux équipes de sécurité de déterminer quels chemins de délégation sont les plus importants.

Considérons deux agents disposant d'un accès en lecture délégué.

L'agent A peut récupérer les ressources marketing publiques.

L'agent B peut récupérer les informations personnelles des clients, les dossiers des employés, les contrats, les identifiants, les informations financières et la propriété intellectuelle.

Le modèle de délégation peut être similaire dans un système IAM.

Le risque, lui, ne l'est pas.

L'accès délégué devient un risque de sécurité significatif lorsque les équipes relient la chaîne d'identité et d'autorisation aux données sensibles sous-jacentes.

C'est le même principe que celui sous-jacent Gouvernance de l'accès à l'IALes organisations doivent connecter les systèmes d'IA et les voies d'accès aux données sensibles que ces autorisations exposent.

Comment sécuriser la délégation des agents IA

1. Attribuer à chaque agent IA une identité identifiable

Les organisations doivent faire la distinction entre l'agent et les identifiants, applications et comptes de service qu'il utilise.

Identité IA, identité machine et compte de service fournir un contexte de gouvernance connexe mais différent.

2. Préserver le principe d'origine

Lorsqu'un agent agit pour le compte d'un utilisateur, préservez la relation avec cet utilisateur tout au long du flux de travail afin que les contrôles en aval puissent évaluer l'autorité d'origine.

3. Expliciter la délégation

Les équipes doivent savoir quand un agent agit pour le compte d'un utilisateur, soit en son nom propre, soit par le biais d'une application, soit par l'intermédiaire d'un autre agent.

La délégation cachée rend l'accès effectif difficile à comprendre.

4. Prévenir l'expansion de l'autorité

Un agent ou un outil en aval ne devrait pas automatiquement acquérir une autorité plus étendue simplement parce que sa propre identité technique dispose de plus d'autorisations.

Préserver ou réduire la limite d'accès pertinente tout au long du flux de travail.

5. Appliquer le principe du moindre privilège tenant compte des données

Déterminez non seulement à quels systèmes l'agent peut accéder, mais aussi quelles données sensibles se cachent derrière ces autorisations.

Réduisez ensuite les pouvoirs délégués qui excèdent le but approuvé par l'agent.

6. Outils et actions de portée séparément

L’autorisation de consulter des informations ne doit pas automatiquement autoriser la modification des enregistrements, l’envoi de messages, l’initiation de paiements, la suppression de données ou l’exécution d’actions administratives.

7. Limiter la durée de la délégation

Dans la mesure du possible, alignez l'accès délégué sur la durée de la tâche plutôt que de créer un accès persistant qui perdure au-delà des besoins de l'entreprise.

8. Contrôle de la délégation d'agent à agent

Définissez quels agents peuvent invoquer d'autres agents, quel contexte ils peuvent partager, quelle autorité peut accompagner la requête et quelles actions en aval nécessitent une approbation.

9. Surveiller l'activité relative aux données sensibles

L'autorisation indique ce qu'un agent peut faire.

Surveillance de l'activité des données aide les équipes à comprendre ce que les identités font réellement avec les informations sensibles.

10. Préserver la lignée de délégation

Les enquêteurs devraient être en mesure de reconstituer :

Initiateur → Agent → Identité déléguée → Outil → Données → Action

11. Révoquer l'accès en cas de changement de finalité

Les agents, applications, intégrations et comptes de service ne doivent pas conserver d'autorité déléguée après une modification du flux de travail, du projet, du propriétaire ou de l'objectif commercial.

Liste de contrôle de sécurité pour la délégation d'agents IA

Comment BigID contribue à la gouvernance de la délégation des agents d'IA

La délégation d'agents IA crée un problème que les listes d'autorisations seules ne peuvent résoudre.

Les équipes de sécurité doivent établir des liens entre l'acteur IA, les identités sous-jacentes, les autorisations héritées, les chemins d'accès délégués, les données sensibles, l'activité, la propriété et les actions qui en résultent.

BigID aborde ce problème en partant des données vers l'extérieur.

BigID aide les organisations :

• Gouverner les identités des IA : Découvrez les agents, les copilotes, les applications d'IA, les flux de travail autonomes, les propriétaires, les autorisations et le contexte du cycle de vie.
• Comprendre les voies d'accès à l'IA : Connectez les systèmes d'IA aux applications, aux API, aux utilisateurs, aux comptes de service, aux identités des machines, aux autorisations héritées et aux données sensibles associées à cet accès.
• Gouverner les agents autonomes : Inventaire des agents d'IA, établissement de la propriété, cartographie des accès, connexion des agents aux données sensibles, priorisation des risques et surveillance de l'activité.
• Ajouter le contexte d'identité de la machine : Comprendre les comptes de service, les applications, les API, les charges de travail, l'automatisation et les autres identités non humaines qui prennent en charge l'accès à l'IA.
• Identifier les accès excessifs : Identifiez les accès inutiles ou à haut risque qui exposent des données sensibles de l'entreprise.
• Renforcer les plus démunis : Prioriser la réduction des accès en fonction de l'identité, des autorisations, de la sensibilité des données, de l'activité, de la propriété et du contexte métier.
• Surveiller l'activité liée aux données sensibles : Ajouter le contexte de l'activité pour comprendre comment les identités interagissent avec les informations sensibles.
• Remise en état du lecteur : Réduire les accès à risque, attribuer les responsabilités, faire respecter les politiques et coordonner les mesures correctives.

L’objectif n’est pas simplement de savoir qu’un agent possède une autorisation. Il s’agit de comprendre d’où provient cette autorisation, quelles données sensibles elle permet d’accéder, si l’accès correspond à la finalité prévue, ce que l’agent a réellement fait et quelles mesures doivent être prises lorsque le risque est trop élevé.

FAQ sur la délégation d'agents IA

Qu'est-ce que la délégation d'agents IA ?

La délégation d'agents d'IA se produit lorsqu'un agent d'IA reçoit ou exerce une autorité d'une autre identité ou d'un autre système pour accéder à des ressources, exécuter des tâches, invoquer des outils ou prendre des mesures. Cette autorité peut provenir d'un utilisateur, d'une application, d'un compte de service, d'une identité machine ou d'un autre agent d'IA.

Qu’est-ce que l’autorité déléguée en IA ?

L'autorité déléguée correspond au pouvoir d'autorisation ou de décision qu'un agent d'IA exerce au nom d'une autre entité. Une délégation sécurisée doit préserver le lien entre le mandant initial, l'agent agissant, le périmètre autorisé et l'action qui en résulte.

Quelle est la différence entre l'authentification, l'autorisation et la délégation pour les agents d'IA ?

L'authentification établit l'identité de l'IA. L'autorisation détermine les ressources auxquelles cette identité peut accéder ou les actions qu'elle peut effectuer. La délégation détermine l'autorité exercée par l'agent d'IA lors de l'exécution d'une tâche ou de l'accès à une ressource.

Un agent IA peut-il agir au nom d'un utilisateur ?

Oui. Un agent d'IA peut utiliser l'accès utilisateur délégué lorsque l'architecture et la plateforme d'identité le permettent. Dans ce modèle, les systèmes en aval peuvent appliquer les restrictions d'accès en fonction du périmètre autorisé de l'utilisateur connecté, plutôt que d'accorder à l'agent un accès illimité à l'application.

Les agents IA peuvent-ils déléguer des tâches à d'autres agents IA ?

Oui. Les systèmes multi-agents permettent à un agent d'invoquer ou d'assigner des tâches à un autre. Les organisations doivent définir quels agents peuvent déléguer, quelles identités et autorisations sont associées à la tâche, quel contexte peut être partagé et quelles actions ultérieures nécessitent une approbation supplémentaire.

Quelle est la différence entre l'accès délégué et l'accès limité à l'application ?

L'accès délégué permet à une application ou à un agent d'agir au nom d'un utilisateur connecté, dans la limite des autorisations déléguées applicables. L'accès applicatif seul permet à l'application ou à l'agent d'agir en utilisant sa propre identité et ses propres autorisations, sans dépendre de l'accès d'un utilisateur connecté.

Qu’est-ce que l’expansion d’autorité dans un flux de travail d’IA ?

L'extension d'autorisation se produit lorsqu'un agent, une application, un compte de service, un outil ou une autre identité en aval accorde un accès plus étendu que celui autorisé par la tâche ou l'identité initiatrice. Cela peut exposer des données ou des actions en dehors du périmètre de délégation prévu.

Pourquoi les comptes de service sont-ils importants pour la délégation d'agents IA ?

Les applications et agents d'IA peuvent utiliser des comptes de service pour accéder aux ressources de l'entreprise. Si ces comptes disposent d'autorisations étendues ou permanentes, un flux de travail d'IA peut obtenir des accès dépassant le cadre de l'utilisateur initial ou l'objectif métier prévu par l'agent.

Comment le principe du moindre privilège s'applique-t-il à la délégation en IA ?

Le principe du moindre privilège exige que chaque agent et chaque chemin d'accès délégué ne reçoive que les données et les actions nécessaires à la tâche approuvée. Les organisations doivent également empêcher les agents, applications et outils en aval d'étendre l'autorité effective du flux de travail.

Pourquoi la sensibilité des données est-elle importante pour l'accès délégué à l'IA ?

Deux autorisations déléguées peuvent sembler similaires tout en présentant des niveaux de risque très différents. L'accès à des documents publics entraîne des conséquences différentes de l'accès à des données personnelles de clients, à des données d'employés, à des identifiants, à des informations financières, à du code source ou à la propriété intellectuelle.

Comment les organisations doivent-elles surveiller la délégation des agents d'IA ?

Les organisations doivent préserver l'identité et le contexte de délégation tout au long des flux de travail, surveiller l'activité relative aux données sensibles, suivre les actions des agents et des outils, maintenir la propriété et conserver suffisamment de traçabilité pour reconstituer le chemin depuis l'initiateur initial jusqu'à l'action finale, en passant par chaque identité déléguée.

Comment BigID contribue-t-il à la gouvernance de la délégation des agents d'IA ?

BigID connecte les agents d'IA, les utilisateurs, les applications, les API, les comptes de service, les identités des machines, les autorisations, l'activité, la propriété et les données sensibles pour aider les organisations à identifier les accès excessifs, à renforcer le principe du moindre privilège, à gouverner les identités et les agents d'IA, à prioriser les risques et à piloter les mesures correctives.