Les agents d'IA ne travaillent plus seuls.
Un agent effectue des recherches. Un autre récupère les données de l'entreprise. Un autre évalue les informations. Un autre appelle une API. Un autre modifie un enregistrement ou déclenche un flux de travail.
Cela crée un nouveau problème de sécurité.
Une organisation peut sécuriser chaque agent individuellement et malgré tout perdre le contrôle lorsque L'identité, l'autorité, les données sensibles, le contexte et les instructions circulent entre eux.
Prenons l'exemple d'une chaîne simple :
Utilisateur → Agent A → Agent B → Agent C → Données ou action d'entreprise
L'agent A peut commencer par être autorisé à travailler uniquement avec un client, une zone géographique, un ensemble de données ou un processus métier spécifique.
Mais que se passe-t-il lorsqu'il délègue une partie de la tâche à l'agent B ?
L'agent B hériter le périmètre de l'utilisateur ?
Bénéficie-t-il des autorisations plus étendues de l'agent A ?
Peut-il passer ces autorisations à l'agent C ?
Un agent peut-il divulguer des informations sensibles à un autre agent qui ne devrait jamais y avoir accès ?
Un agent compromis peut-il amener un pair de confiance à accomplir une action qu'il ne pourrait pas accomplir lui-même ?
Et lorsqu'un problème survient, l'équipe de sécurité peut-elle reconstituer qui a demandé la tâche, quels agents y ont participé, quelles autorisations ont été transférées entre eux, quelles données ils ont manipulées et quel agent a effectivement pris la décision finale ?
Ces questions définissent sécurité des agents IA entre agents.
La sécurité multi-agents ne se limite pas à la sécurisation de chaque agent. Les organisations doivent également sécuriser l'identité, la confiance, l'autorité, les données, le contexte et les actions qui circulent entre les agents.
Sécurité entre agents : points clés
- La sécurité individuelle des agents ne sécurise pas l'ensemble du flux de travail. Des risques peuvent survenir lorsque des agents délèguent des tâches, transfèrent un contexte, héritent d'autorisations, échangent des données ou s'invoquent mutuellement.
- L'authentification ne répond qu'à une partie de la question. Les équipes doivent également comprendre quelles autorisations un agent peut déléguer à un autre et si ces autorisations correspondent à l'intention de l'utilisateur initial.
- L'autorité devrait se restreindre à mesure que les agents délèguent. Un agent en aval ne devrait pas obtenir des autorisations plus étendues simplement parce qu'un agent en amont peut l'atteindre.
- Le contexte crée des risques liés aux données. Les agents peuvent divulguer des informations sensibles à leurs pairs via des invites, la mémoire, les messages, les documents récupérés, les résultats d'outils et l'état partagé des tâches.
- Les systèmes multi-agents traversent des domaines de confiance. Les agents d'entreprise peuvent communiquer avec des agents de fournisseurs, des agents SaaS, des systèmes partenaires, des API et des services autonomes qui suivent des politiques différentes.
- BigID apporte le contexte des données à l'identité et à l'accès des agents. BigID connecte les identités IA, les identités machine, les autorisations, les données sensibles, l'activité, la propriété, les politiques et la correction afin que les équipes puissent gérer l'accès derrière les flux de travail multi-agents.
Qu’est-ce que la sécurité des communications entre agents IA ?
La sécurité des communications entre agents d'IA consiste à protéger l'identité, l'authentification, l'autorisation, la délégation, la communication, les données, le contexte et les actions échangées lorsque des agents d'IA interagissent avec d'autres agents d'IA.
Cela s'applique lorsqu'un agent :
- Découvre un autre agent
- Délègue une tâche
- Transmet des instructions ou un contexte
- Partage des données
- Demande les capacités d'un autre agent
- Reçoit les résultats d'un autre agent
- Invoque un agent sur une autre plateforme ou un autre domaine de confiance
- Permet à un autre agent d'appeler des outils ou des API.
- Intègre des agents supplémentaires dans le flux de travail
La communication entre agents étend le périmètre de sécurité au-delà du système d'IA individuel.
L'organisation doit désormais répondre à six questions distinctes :
Qui est cet agent ?
Pourquoi un autre agent devrait-il lui faire confiance ?
Quelle autorité peut-elle déléguer ?
Quelles données peuvent franchir la frontière ?
Quelles actions l'agent récepteur peut-il effectuer ?
Quel contexte doit accompagner la tâche ?
Cela crée un modèle de sécurité multi-agents pratique :
Identité de l'agent + Confiance + Délégation + Données + Contexte + Action
Gouverner l'identité de l'IA à partir des données
Sachez quels agents existent, ce qu'ils héritent et quelles données sensibles ils peuvent atteindre.
Connectez les agents d'IA, les copilotes, les comptes de service, les identités des machines, les autorisations, la propriété, l'activité et l'exposition des données sensibles dans les flux de travail d'IA d'entreprise.
Pourquoi les systèmes multi-agents changent le modèle de sécurité
Une architecture à agent unique crée déjà de nouvelles identité et accès questions.
Une architecture multi-agents les multiplie.
Imaginez un flux de travail d'entreprise où :
- Un utilisateur demande à un agent orchestrateur de préparer une analyse de renouvellement client.
- L'organisateur demande à un agent de recherche de recueillir des informations publiques.
- Il demande à un agent de données de récupérer les enregistrements CRM, d'assistance, d'utilisation et de contrats.
- Elle demande à un agent financier de calculer les aspects économiques du renouvellement.
- Il demande à un agent d'intervention de mettre à jour le CRM et de créer des tâches de suivi.
Chaque agent peut utiliser un agent différent :
- Identité
- Compte de service
- API
- Ensemble d'autorisations
- Rôle dans le cloud
- Autorisation OAuth
- Source de données
- Fournisseur
- Modèle
- Limite de politique
La sécurisation de l'orchestrateur à elle seule ne sécurise pas ce flux de travail.
Il en va de même de la vérification que chaque agent participant possède des identifiants valides.
L'organisation doit également comprendre comment la confiance et l'autorité évoluent à chaque passation de pouvoir.
Le chemin de sécurité multi-agents
Sécurité multi-agents
Chaque transfert crée une nouvelle décision de confiance et d'autorisation
Sécurisez le flux de travail depuis l'utilisateur initial jusqu'aux données ou actions finales, en passant par chaque agent délégué.
Utilisateur
Définit l'intention et l'autorité initiale
Agent A
Interprète la tâche et délègue le travail
Agent B
Reçoit le contexte, la portée et l'autorité
Agent C
Peut introduire un autre ensemble d'identités ou de privilèges
Données + Action
Récupérer, partager, mettre à jour, exécuter ou déclencher
Chaque flèche doit préserver l'identité, limiter l'autorité, protéger les données et constituer une preuve.
L'authentification d'agent à agent n'est pas une autorisation d'agent à agent.
L'authentification établit l'identité.
L'autorisation détermine ce que cette identité peut faire.
Cette distinction est d'autant plus importante dans les systèmes multi-agents qu'un agent de confiance peut toujours effectuer une requête inappropriée.
Le courant Protocole Agent2Agent, Initialement développé par Google et faisant désormais partie de l'écosystème de la Linux Foundation, il prend en charge la communication interopérable entre les agents.
A2A considère les agents comme des applications d'entreprise et s'appuie sur des pratiques de sécurité web éprouvées pour l'authentification. Chaque serveur A2A demeure responsable de l'autorisation des requêtes en fonction de l'identité authentifiée, des capacités demandées, de la politique d'accès aux données, des étendues et de son propre modèle d'autorisation.
Ses recommandations en matière de sécurité préconisent l'authentification des requêtes, l'autorisation côté serveur, moindre privilège, les contrôles de confidentialité des données et l'observabilité de l'entreprise.
Mais un protocole ne peut pas déterminer à lui seul la politique d'autorisation commerciale d'une organisation.
L'agent destinataire doit encore décider :
- Puis-je faire confiance à l'agent qui m'appelle ?
- Quel principe représente-t-il ?
- Quelle tâche l'utilisateur initial a-t-il approuvée ?
- Quel périmètre l'agent appelant peut-il déléguer ?
- Quelles données puis-je renvoyer ?
- Quelles actions puis-je effectuer ?
- Puis-je déléguer à nouveau ?
L'authentification réussie prouve qu'un agent a présenté des informations d'identification acceptables. Elle ne prouve pas que chaque requête émanant de cet agent mérite d'être autorisée.
La spécification A2A actuelle reconnaît également le risque lié aux chaînes d'agents. Elle avertit que l'échange d'identifiants au sein de la chaîne peut exposer ces identifiants à plusieurs agents y participant et recommande de lier les identifiants à l'agent ayant émis la demande d'autorisation.
Plus la chaîne d'agents est longue, plus il devient important de préserver l'identité de celui qui a demandé l'autorisation, de celui qui l'a reçue et des lieux où cette autorisation peut être exercée.
Trois décisions de sécurité différentes
L'identité seule ne détermine pas l'autorité
Qui es-tu?
Vérifiez l'identité de l'agent qui effectue la demande.
Que pouvez-vous faire ?
Déterminez à quelles données, capacités, ressources ou actions l'agent peut accéder.
Que pouvez-vous transmettre ?
Contrôler les pouvoirs et le contexte que l'agent peut transférer à un autre agent.
Un agent de confiance peut toujours formuler une demande non autorisée. Un agent autorisé peut toujours déléguer trop de pouvoirs.
Le problème de la délégation : à qui appartient l'autorité ?
Délégation se situe au cœur de la sécurité multi-agents.
Un agent accomplit souvent une tâche pour le compte d'une autre personne.
Cela crée une chaîne de principes :
Utilisateur → Agent A → Agent B → Outil ou Données
Les équipes de sécurité doivent conserver suffisamment de contexte pour comprendre à la fois l'appelant immédiat et l'autorité initiale à l'origine de la tâche.
Autrement, les agents en aval peuvent acquérir des privilèges que l'utilisateur d'origine n'a jamais détenus ni n'a jamais eu l'intention de déléguer.
La délégation devrait réduire l'autorité, et non l'accroître.
Supposons qu'un responsable régional des ventes demande à un agent d'analyser les clients nord-américains.
L'agent A reçoit un accès approprié à cette fin.
L'agent A délègue une partie de l'analyse à l'agent B.
L'agent B utilise un compte de service global lui donnant accès à tous les dossiers clients.
Techniquement, l'agent B a la permission.
Sur le plan opérationnel, la délégation a dépassé les limites qui lui avaient été fixées.
Risque de délégation
L'autorité doit rester circonscrite à mesure que la tâche progresse.
Utilisateur
Comptes Amérique du Nord
Agent A
Préserve le périmètre utilisateur
Agent B
Utilise un compte de service global
Données mondiales
L'autorité a été élargie
L'autorisation existe. La délégation enfreint néanmoins la limite prévue.
Cette distinction constitue l'un des principes les plus importants du contrôle d'accès multi-agents :
L'autorité en aval doit rester égale ou inférieure à l'autorité légitimement déléguée en amont.
Le problème du shérif adjoint confus refait surface avec les agents IA.
Les systèmes multi-agents peuvent créer une forme moderne du problème du député confus.
Un agent disposant de faibles privilèges peut ne pas avoir accès à des informations sensibles.
Mais il se peut qu'il connaisse un autre agent qui a cet accès.
Si le mandataire privilégié fait confiance aux demandes simplement parce qu'elles proviennent d'un pair reconnu, moins privilégiés L'agent peut utiliser l'agent plus privilégié comme chemin vers des ressources qu'il ne pourrait pas atteindre directement.
Le flux de travail peut ressembler à ceci :
Agent à faible privilège → Agent à privilège élevé de confiance → Données sensibles
L'agent privilégié devient le suppléant.
Une autorisation multi-agents robuste devrait évaluer :
- Qui a formulé la demande ?
- Quel agent l'a délégué ?
- L'objectif commercial visé
- Le périmètre délégué
- La ressource demandée
- La sensibilité des données
- L'action demandée
L'identité à elle seule ne peut répondre à ces questions.
Le contexte de l'agent peut divulguer des données sensibles
Les agents échangent plus que des ordres.
Ils peuvent échanger :
- Invites
- Historique des conversations
- Documents récupérés
- Sortie de l'outil
- Dossiers clients
- Résumés
- Mémoire
- Données structurées
- Dossiers
- Identifiants ou secrets
- Artefacts de raisonnement intermédiaires exposés par l'application
Cela fait de la communication entre agents une frontière de sécurité des données.
L'agent A peut légitimement accéder à des informations sensibles dans le cadre de ses fonctions.
L'agent B n'aura peut-être pas besoin de ces informations.
Transmettre l'intégralité du contexte de travail de l'agent A à l'agent B peut étendre silencieusement l'exposition des données sensibles, même lorsque les deux agents fonctionnent comme prévu.
Déléguer une tâche ne doit pas automatiquement signifier déléguer tout le contexte qui l'a engendrée.
Les organisations doivent minimiser les informations échangées entre les agents en fonction de leur finalité.
Quelles données un agent devrait-il être autorisé à transmettre à un autre ?
La réponse dépend de :
- Sensibilité des données
- Objectif commercial
- L'identité de l'agent destinataire
- Le propriétaire de l'agent récepteur
- Ses autorisations
- Son environnement de traitement
- Son fournisseur ou domaine de confiance
- Politiques applicables
- exigences réglementaires
- Comportement de rétention
- Outils et agents en aval
Par exemple, un agent de recherche peut avoir besoin du nom d'une entreprise.
Il se peut qu'il n'ait pas besoin des informations de paiement du client, des informations personnelles des employés, des termes du contrat, des identifiants ou de l'historique d'assistance confidentiel.
Découverte et classification des données sensibles Donner aux organisations le contexte nécessaire pour prendre ces décisions en fonction des informations pertinentes et non pas uniquement du nom de l'agent.
La sécurité des agents interdomaines fait monter les enjeux
Les flux de travail multi-agents franchissent de plus en plus les frontières organisationnelles et celles des fournisseurs.
Un agent d'entreprise interne peut invoquer :
- L'agent d'un fournisseur SaaS
- Un agent de fournisseur de cloud
- Un agent partenaire
- Un agent de marché
- Un service de recherche externe
- Un service d'IA spécifique à l'industrie
Les agents peuvent ne pas partager les mêmes :
- fournisseur d'identité
- Système d'identification
- politique de sécurité
- schéma de classification des données
- Modèle d'audit
- Règles de conservation
- hypothèses de confiance
A Projet de loi Internet de 2026 sur la confiance entre agents interdomaines Ce document aborde ce problème émergent en définissant les exigences relatives à l'identité des agents, à l'authentification, à l'autorisation, à la délégation, à la gestion des informations d'identification, à la révocation et à l'auditabilité.
Ce document reste un travail en cours plutôt qu'une norme Internet, mais le problème de sécurité qu'il décrit est important dès maintenant.
L'interopérabilité des agents sans confiance interopérable peut ouvrir la voie à un transfert rapide d'informations et de données sensibles par-delà les frontières de sécurité.
Qu'est-ce que le protocole Agent2Agent ?
Agent2Agent, ou A2A, fournit un protocole ouvert qui permet à des agents d'IA indépendants de découvrir des capacités, d'échanger des informations, de collaborer sur des tâches et de communiquer entre différents frameworks et fournisseurs.
Google a initialement développé ce protocole et l'a ensuite mis à disposition de l'écosystème de la Linux Foundation.
Protocole A2A et de contexte de modèle, ou MCP, résoudre différents problèmes d'interopérabilité :
| Protocole | Connexion principale | Priorité à la sécurité |
|---|---|---|
| A2A | De l'agent à l'agent | Identité de l'agent, authentification, autorisation, échange de tâches, communication, délégation |
| MCP | Application ou agent d'IA pour les outils et les sources de données | Accès aux outils, ressources, connecteurs, autorisations, exposition des données |
Un flux de travail multi-agents peut utiliser les deux.
Un agent peut utiliser A2A pour déléguer du travail à un autre agent, tandis que l'agent destinataire utilise MCP ou une autre couche d'intégration pour accéder aux systèmes de l'entreprise.
Cela crée un chemin de sécurité connecté :
Agent → Agent → Outil → Données → Action
Les équipes de sécurité ont besoin d'une visibilité sur l'ensemble de la chaîne.
La découverte d'agents crée une autre décision de confiance
Les systèmes multi-agents ont besoin de moyens pour trouver les agents et comprendre ce qu'ils peuvent faire.
Les registres d'agents, les catalogues, les descriptions de fonctionnalités et les mécanismes tels que les cartes d'agent A2A peuvent faciliter la découverte.
Mais la découverte soulève elle-même des questions de sécurité :
- Qui a enregistré l'agent ?
- Les équipes peuvent-elles vérifier son identité ?
- À qui appartient-il ?
- Un attaquant peut-il se faire passer pour lui ?
- Ses capacités ont-elles changé ?
- Quels schémas d'authentification utilise-t-il ?
- À quels domaines de données peut-il accéder ?
- Les agents d'entreprise doivent-ils lui faire confiance automatiquement ?
La présence d'un agent dans un annuaire ne doit pas automatiquement instaurer une confiance illimitée.
Discovery identifie un collaborateur potentiel.
L'authentification confirme une identité.
L'autorisation détermine ce que cette identité peut demander.
La gouvernance détermine si l'organisation doit autoriser cette relation.
L'injection rapide peut se propager à travers les agents
Injection rapide Cela devient plus complexe dans les systèmes multi-agents car une interaction compromise peut influencer les agents situés en aval.
Considérer:
Document malveillant → Agent A → Agent B → Agent d'action
L'agent A récupère un document malveillant.
Le document contient des instructions qui modifient la tâche de l'agent A.
L'agent A transmet des instructions ou un contexte modifiés à l'agent B.
L'agent B considère l'agent A comme un pair de confiance.
L'agent B invoque ensuite un agent d'action.
L'injection initiale a désormais franchi plusieurs limites de confiance.
Cela signifie que les organisations ne doivent pas automatiquement considérer le contenu inter-agents comme fiable simplement parce qu'il a été généré par un autre agent approuvé.
Un expéditeur de confiance ne garantit pas un contexte fiable.
Risques liés à la sécurité des communications entre agents IA
Plusieurs risques prennent une importance particulière dans les environnements multi-agents.
Délégation de privilèges sans portée
Un agent transmet à un autre agent une autorité plus étendue que celle requise par la tâche déléguée.
Attaques d'un adjoint confus
Un agent disposant de privilèges inférieurs utilise un agent disposant de privilèges supérieurs pour accéder à des données ou effectuer une action en dehors du cadre initial.
Perte d'identité
Les systèmes en aval peuvent voir l'agent immédiat, mais perdent l'identité de l'utilisateur, de l'application ou du flux de travail d'origine qui a initié la requête.
Fuite de contexte
Un agent partage des informations sensibles, l'historique des conversations, des données récupérées ou des données de mémoire avec un autre agent qui n'en a pas besoin.
Échec de la confiance inter-domaines
Des agents issus de différentes organisations ou plateformes se font confiance sans contrôles suffisants en matière d'identité, d'autorisation, de politique ou de données.
Usurpation d'identité d'agent
Un attaquant enregistre, usurpe ou compromet un agent et tente de gagner la confiance de ses pairs légitimes.
Boucles de délégation et prolifération des agents
Les agents délèguent sans cesse des tâches, créant ainsi des chaînes qu'il devient difficile d'inventorier, de tracer, de limiter ou d'interrompre.
Communication inter-agents non sécurisée
Une authentification des messages, des contrôles d'intégrité, une protection contre la relecture ou des contrôles de transport insuffisants peuvent exposer les communications des agents à la manipulation.
Extension des pouvoirs via les comptes de service
Un agent en aval utilise une application ou un compte de service dont les autorisations dépassent celles de l'utilisateur ou de l'agent en amont.
Action sans traçabilité
Plusieurs agents contribuent à une décision, mais les journaux d'activité n'affichent que l'identité de celui qui a exécuté l'action finale.
Sécurité individuelle des agents vs. sécurité multi-agents
| question de sécurité | Agent unique | Système multi-agents |
|---|---|---|
| Identité | Quel agent agit ? | Quels agents ont participé et qui a initié la tâche ? |
| Accéder | Jusqu'où cet agent peut-il aller ? | Quelle autorité se propage lorsque des agents délèguent ? |
| Données | Quelles données sensibles l'agent peut-il accéder ? | Quelles données un agent peut-il exposer à un autre ? |
| Confiance | L'organisation devrait-elle faire confiance à cet agent ? | Pourquoi les agents devraient-ils se faire confiance à chaque transfert de responsabilité ? |
| Action | Que peut faire cet agent ? | Quel agent a pris la décision et quel agent l'a exécutée ? |
| Audit | Les équipes peuvent-elles retracer l'activité de l'agent ? | Les équipes peuvent-elles reconstituer l'intégralité de la chaîne de délégation et de décision ? |
L'identification individuelle des agents est nécessaire, mais insuffisante pour garantir la sécurité multi-agents.
OWASP oriente la sécurité des agents vers un contrôle en temps réel.
Le Norme de contrôle des agents OWASP, publié en septembre 2026, reflète un changement important du marché.
OWASP soutient que les entreprises ont besoin d'agents que les équipes peuvent inspecter, tracer, instrumenter et contrôler en temps réel.
Les organisations ont besoin de visibilité sur :
- Quels sont les agents ?
- Ce à quoi ils peuvent accéder
- Ce qu'ils ont fait
- Pourquoi ils ont agi
- Comment les équipes peuvent appliquer une politique en cours d'exécution
Cela permet d'étendre la sécurité des agents au-delà de la simple approbation préalable au déploiement.
Les systèmes multi-agents évoluent en permanence à mesure que les agents acquièrent de nouveaux outils, pairs, autorisations, sources de données, modèles et responsabilités métier.
La sécurité des agents ne peut s'arrêter à l'enregistrement ou au déploiement. Les contrôles doivent suivre les agents à mesure que leurs identités, leurs accès, leurs pairs, leurs outils, leurs données et leurs autorisations évoluent en cours d'exécution.
Les risques liés à l'identité nécessitent des données contextuelles
Sachez ce que chaque agent peut atteindre avant que l'autorité ne soit transférée en aval.
Reliez les agents, les comptes de service, les identités des machines, les API, les autorisations, les chemins d'accès, les données sensibles, la propriété et l'activité pour identifier les cas où l'accès à l'IA dépasse les besoins légitimes de l'entreprise.
Comment sécuriser la communication entre agents
1. Inventaire de chaque agent
Identifier les agents, copilotes, assistants, orchestrateurs, flux de travail autonomes, applications basées sur l'IA et agents tiers.
Enregistrer:
- Propriétaire
- Objectif commercial
- Environnement
- Agents connectés
- Identités des machines
- Comptes de service
- Accès aux données
- Outils
- Actions autorisées
Gouvernance de l'identité IA elle fournit les bases nécessaires pour comprendre quelles identités alimentées par l'IA opèrent au sein de l'entreprise.
2. Authentifier chaque limite d'agent
Ne vous fiez pas à votre localisation sur le réseau ni à vos interactions antérieures comme preuve d'identité.
Validez les identités aux frontières entre agents et utilisez les contrôles d'authentification d'entreprise appropriés.
3. Autorisez la tâche, pas seulement l'agent.
Un agent de confiance ne devrait pas bénéficier d'une autorisation illimitée pour demander toutes les fonctionnalités.
Évaluer:
- La compétence demandée
- La tâche
- Le principal d'origine
- Le périmètre délégué
- Les données cibles
- L'action demandée
4. Limiter l'autorité déléguée
Lorsque l'agent A délègue des autorisations à l'agent B, ne transférez pas automatiquement l'ensemble complet des autorisations de l'agent A.
N’accordez à l’agent B que l’autorisation nécessaire à l’exécution de la tâche déléguée.
5. Préserver la chaîne principale
Conserver suffisamment de contexte d'identité pour retracer un flux de travail à travers la chaîne de délégation.
Les équipes devraient pouvoir répondre à :
Qui a initié cela ?
Quels agents s'en sont occupés ?
Quelle identité a accédé aux données ?
Quel agent a pris la décision ?
Quel agent a exécuté l'action ?
6. Minimiser le partage de données entre agents
Ne transmettez que le contexte dont un autre agent a besoin.
Ne transmettez pas automatiquement les messages complets, l'historique des conversations, les dossiers clients, les documents récupérés ou les métadonnées sensibles.
7. Connecter l'accès des agents à la sensibilité des données
Une même autorisation peut engendrer des risques très différents selon les informations qu'elle sous-tend.
Découvrir et classer les données sensibles, puis connectez-la aux identités d'IA, aux identités de machines et aux autorisations effectives.
8. Appliquer le principe du moindre privilège aux identités des IA et des machines
Les agents agissent généralement via des comptes de service, des API, des applications, des rôles cloud, des autorisations OAuth et d'autres identités de machines.
Sécurité de l'identité des machines aide les organisations à comprendre l'accès automatisé qui sous-tend les flux de travail de l'IA.
9. Considérez les messages des agents comme des entrées non fiables.
Un pair de confiance peut toujours envoyer un contexte compromis, manipulé, incorrect ou malveillant.
Appliquer des contrôles d'entrée, d'invite, de données et de stratégie à la communication inter-agents.
10. Restreindre les actions de l'agent
Autorités distinctes de lecture, d'écriture, d'exécution, d'approbation, de suppression, d'envoi, de publication et d'administration.
Exiger une approbation humaine pour les actions ayant des conséquences, le cas échéant.
11. Surveiller l'activité des agents
Les autorisations décrivent les comportements potentiels.
L'activité reflète le comportement réel.
Surveillance de l'activité des données peut ajouter du contexte sur la manière dont les informations sensibles sont consultées, déplacées, partagées, modifiées, téléchargées ou supprimées.
12. Intégrer la révocation et la réparation au système
Les équipes ont besoin de moyens pour :
- Désactiver un agent
- Supprimer une relation entre pairs
- Révoquer les identifiants
- Réduire les autorisations
- Bloquer une source de données
- Restreindre un outil
- données à risque de mise en quarantaine
- Attribuer des mesures correctives
- Analyser les données concernées
flux de travail de remédiation aider à transformer les constats relatifs aux risques liés à l'identité et aux données en mesures correctives.
Le test de confiance multi-agents
Liste de contrôle de préparation en matière de sécurité entre agents
Préparation à la sécurité multi-agents
Votre équipe de sécurité peut-elle répondre à ces questions ?
✓ Quels agents d'IA peuvent communiquer avec d'autres agents ?
✓ À qui appartient chaque agent ?
✓ Pouvons-nous vérifier l'identité des agents à chaque transfert de responsabilité ?
✓ Peut-on retracer l'humain, l'application ou le flux de travail d'origine à l'origine d'une tâche déléguée ?
✓ Quelles autorisations un agent peut-il déléguer à un autre ?
✓ Les agents en aval peuvent-ils acquérir une autorité plus étendue que le demandeur initial ?
✓ Quelles données sensibles les agents peuvent-ils échanger ?
✓ Devons-nous minimiser le contexte lors des transferts entre agents ?
✓ Quelles identités de machine et quels comptes de service prennent en charge les flux de travail des agents ?
✓ Un agent disposant de privilèges inférieurs peut-il invoquer un agent disposant de privilèges supérieurs ?
✓ Quelles interactions entre agents franchissent les frontières entre fournisseurs ou domaines de confiance ?
✓ Un agent compromis peut-il manipuler un pair de confiance ?
✓ Quelles actions nécessitent une confirmation humaine ?
✓ Peut-on retracer l'accès aux données sur l'ensemble de la chaîne d'agents ?
✓ Peut-on révoquer rapidement une autorisation d'agent ou une autorisation déléguée ?
✓ Peut-on prouver ce qui s'est passé après un incident ?
Comment BigID aborde la sécurité des communications entre agents
BigID aborde la sécurité multi-agents en se basant sur l'identité et les données sous-jacentes à chaque interaction.
L'authentification de l'agent est importante.
Mais les organisations doivent aussi comprendre Quelles identités d'IA participent au flux de travail, quelles identités de machines leur confèrent cet accès, quelles autorisations elles héritent, quelles données sensibles elles peuvent atteindre, comment ces données circulent et dans quels cas l'autorité dépasse les objectifs commerciaux légitimes.
BigID aide les organisations :
- Découvrir et gérer les identités des IA : Agents d'inventaire, copilotes, applications d'IA, flux de travail autonomes, propriétaires, autorisations héritées, activité et contexte du cycle de vie.
- Accès à l'IA de gouvernance : Connectez les agents et les systèmes d'IA aux données sensibles de l'entreprise, aux applications, aux API, aux comptes de service et aux autorisations qui régissent leur accès.
- Identités machine sécurisées : Identifier les comptes de service, les applications, les API, les charges de travail, les jetons et autres identités de machines que les systèmes d'IA utilisent pour accéder aux ressources de l'entreprise.
- Ajouter le contexte des données sensibles : Identifier les informations personnelles, réglementées, confidentielles, exclusives, d'identification, financières, de santé et essentielles à l'activité de l'entreprise auxquelles les agents ont accès.
- Identifier les accès excessifs : Identifiez les autorisations trop larges, obsolètes, héritées, inutiles ou à haut risque qui peuvent étendre le rayon d'action de l'autorité déléguée de l'agent.
- Renforcer les plus démunis : Prioriser la réduction des accès en fonction de l'identité, des autorisations, de la sensibilité, de l'exposition, de la propriété et du contexte métier.
- Ajouter le contexte de l'activité : Comprendre comment les identités accèdent, déplacent, partagent, modifient, téléchargent ou suppriment des informations sensibles.
- Associer l'identité à la gouvernance de l'IA : Associer les actifs d'IA aux données, à la traçabilité, à la propriété, à l'accès, aux politiques, aux risques, à la surveillance et aux éléments de gouvernance.
- Remise en état du lecteur : Réduire l'accès, appliquer la politique, désigner des responsables et coordonner les mesures correctives lorsque l'accès des agents crée un risque.
Le rôle de BigID n'est pas de remplacer le protocole d'authentification permettant aux agents de communiquer. BigID ajoute le contexte des données (identité, accès, exposition, activité, gouvernance et remédiation) dont les organisations ont besoin pour comprendre si ces relations entre agents engendrent des risques.
Cette distinction devient de plus en plus importante à mesure que les flux de travail multi-agents traversent davantage d'applications, d'API, de plateformes cloud, de bases de données, d'identités et de domaines de confiance.
La sécurité des communications entre agents doit préserver bien plus que la simple connectivité. Elle doit garantir l'intention, l'autorité, la responsabilité et le contrôle jusqu'aux données elles-mêmes.
Connecter les points entre les données et l'IA
Contrôler chaque agent ayant accès aux données sensibles
Découvrez comment BigID connecte les identités IA, les identités machine, les autorisations, les données sensibles, l'activité, la propriété, l'exposition, les politiques et la remédiation à travers les flux de travail des agents d'entreprise.
FAQ sur la sécurité des communications entre agents IA
Qu’est-ce que la sécurité des communications entre agents IA ?
La sécurité des échanges entre agents d'IA protège l'identité, la confiance, l'authentification, l'autorisation, la délégation, la communication, les données sensibles, le contexte et les actions échangées lorsque des agents d'IA interagissent entre eux.
Qu'est-ce que la sécurité multi-agents ?
La sécurité multi-agents protège les systèmes dans lesquels plusieurs agents d'IA collaborent, délèguent des tâches, échangent des informations, accèdent à des ressources et agissent. Elle étend la sécurité au-delà des agents individuels pour englober les relations, les limites de confiance, les permissions, les flux de données et les chaînes de délégation qui les unissent.
Pourquoi la sécurité entre agents est-elle importante ?
Les interactions entre agents peuvent transférer des informations sensibles, des autorisations, des instructions et des pouvoirs entre plusieurs systèmes d'IA. Sans contrôles rigoureux, les agents en aval peuvent obtenir un accès excessif, exposer des données, abuser de leurs pairs de confiance ou effectuer des actions contraires aux intentions de l'utilisateur initial.
Qu'est-ce que l'authentification d'agent à agent ?
L'authentification entre agents vérifie l'identité d'un agent d'IA qui sollicite une communication ou des services auprès d'un autre agent. L'authentification détermine l'identité de l'appelant, tandis que l'autorisation définit les capacités, les données ou les actions que l'agent est autorisé à utiliser.
Qu’est-ce que l’autorisation d’agent à agent ?
L'autorisation entre agents détermine ce qu'un agent authentifié peut demander ou faire. Elle peut prendre en compte l'identité de l'agent, le mandant d'origine, le périmètre délégué, la tâche demandée, les données cibles, les compétences disponibles, les permissions, la politique et l'objectif commercial.
Qu'est-ce que la délégation d'agents IA ?
La délégation d'agents IA se produit lorsqu'un agent attribue une partie ou la totalité d'une tâche à un autre agent. Une délégation sécurisée doit préserver le contexte de la tâche d'origine tout en limitant l'agent destinataire aux seules autorisations et données nécessaires.
Pourquoi les autorisations déléguées devraient-elles être plus restreintes ?
Un agent en aval ne doit pas recevoir plus d'autorisations que celles que l'utilisateur initial ou l'agent délégant était censé lui accorder. Limiter le périmètre de délégation réduit les accès excessifs et restreint l'impact en cas de compromission ou de manipulation d'un agent.
Qu’est-ce que le problème du député confus dans les agents IA ?
Le problème du mandataire confus survient lorsqu'un agent ayant moins de privilèges convainc ou manipule un agent ayant plus de privilèges d'accéder à des données ou d'effectuer une action que l'agent ayant moins de privilèges ne pourrait pas effectuer directement.
Quels sont les risques liés aux données entre les agents d'IA ?
Les agents peuvent exposer des données sensibles via des invites, des documents récupérés, des messages, la mémoire, les résultats d'outils, des charges utiles structurées, des fichiers, des API et le contexte de tâches partagé. Les organisations doivent minimiser le partage de données entre agents et appliquer une politique adaptée au niveau de sensibilité et à la finalité des données.
Quel est l'impact de l'injection rapide sur les systèmes multi-agents ?
L'injection de messages peut pénétrer dans un agent via un contenu non fiable, puis se propager par le biais des messages de l'agent, des tâches déléguées, du contexte partagé ou des résultats d'outils. Les agents en aval ne doivent pas considérer un contenu comme sûr simplement parce qu'il a été fourni par un agent de confiance.
Qu'est-ce que le protocole Agent2Agent ?
Agent2Agent (A2A) est un protocole ouvert de communication et de collaboration entre agents d'IA indépendants. Il prend en charge la découverte d'agents, l'échange de tâches, les modèles d'authentification, l'autorisation, l'interopérabilité et la communication d'entreprise entre différents frameworks et fournisseurs d'agents.
Quelle est la différence entre A2A et MCP ?
A2A prend principalement en charge la communication et la collaboration entre agents. MCP connecte principalement les applications et agents d'IA aux outils, ressources et sources de données. Un flux de travail multi-agents peut utiliser les deux protocoles.
Comment les organisations doivent-elles sécuriser les systèmes d'IA multi-agents ?
Les organisations doivent inventorier les agents, authentifier les limites des agents, autoriser des tâches spécifiques, limiter l'autorité déléguée, préserver le contexte principal, minimiser le partage de données, appliquer le principe du moindre privilège, gérer les identités des machines, restreindre les actions, surveiller l'activité, conserver les pistes d'audit et prendre en charge la révocation et la correction rapides.
Comment BigID prend-il en charge la sécurité entre agents ?
BigID connecte les identités IA, les identités machine, les comptes de service, les autorisations, les données sensibles, l'activité, la propriété, l'exposition, les politiques et le contexte métier. Cela permet aux organisations d'identifier les accès excessifs des agents, de renforcer le principe du moindre privilège, de maîtriser les risques liés à l'identité IA, de surveiller l'utilisation des données sensibles et de faciliter la correction des problèmes dans les environnements multi-agents.
Auteur
