Modèle de responsabilité partagée des agents IA

Les agents IA étendent l’IA générative au-delà du schéma requête/réponse décrit par le modèle de responsabilité partagée de l’IA . Contrairement à un grand modèle de langage, un agent ne se contente pas de générer du contenu sur lequel un humain doit agir. À la place, un agent :

  • Agit de manière autonome. Il invoque des outils, appelle des API, écrit des données et déclenche des flux de travail sans qu’un humain n’approuve chaque étape.
  • Schémas et boucles. Il décompose les objectifs, raisonne à partir de résultats intermédiaires et se relance de nombreuses fois avant de répondre.
  • Stocke l’état et la mémoire. Le contexte à court terme plus la mémoire persistante influence le comportement futur et peut franchir les limites de la session ou de l’utilisateur.
  • A une identité. Il s’authentifie auprès des systèmes en aval en utilisant des identités gérées, au nom de tokens ou une identité d’agent distincte, et il détient ses propres privilèges.
  • Se combine avec d’autres agents. Dans l’orchestration multi-agents, le résultat d’un agent devient l’instruction d’un autre agent, introduisant une nouvelle limite de confiance.

Chacun de ces comportements introduit des responsabilités qui n’existent pas dans le modèle d’IA requête/réponse.

Remarque

Cet article utilise la « responsabilité » au sens de la gouvernance : qui est censé configurer, opérer et surveiller chaque contrôle. Il s’agit d’un guide illustratif et n’a pas pour but de transmettre des conclusions juridiques ni de modifier ou contredire les termes d’un quelconque accord entre vous et Microsoft.

En quoi les agents d’IA diffèrent du cloud et des charges de travail IA

Le tableau suivant résume en quoi le modèle d’agent IA diffère du modèle cloud standard et du modèle d’IA générative (LLM).

Préoccupation Modèle de cloud standard Modèle IA (LLM) Modèle d’agent IA
Interaction primaire API ou interface graphique De l’invite à la réponse Objectif d’action autonome en plusieurs étapes
Effets secondaires réels Code applicatif, explicite L’humain agit sur le résultat L’agent agit directement via des outils
State Couche applicative et couche de données Invite sans état Mémoire persistante des agents et contexte
Identity Identité utilisateur ou application Identité utilisateur ou application Identité d’agent distincte plus jetons délégués
Limite de confiance De l’utilisateur vers l’application De l’utilisateur au modèle De l’utilisateur à l’agent, puis aux outils, puis à d’autres agents
Risque majeur Mauvaise configuration, exposition des données Injection d’invite (contenu) Injection prompte qui entraîne les actions ; une autonomie excessive ; Adjoint confus

Répartition des responsabilités

Comme pour les modèles de responsabilité partagée cloud et IA , la division des responsabilités évolue selon le modèle de déploiement que vous choisissez. Pour les agents, les options pertinentes sont :

  • Agent SaaS. Un agent prêt à l’emploi, tel que des agents Microsoft 365 Copilot, Microsoft Security Copilot, ou des agents Microsoft Copilot Studio publiés. Microsoft exploite l’orchestrateur, le modèle, les systèmes de sécurité et la plupart des connecteurs d’outils. Vous possédez la configuration, le périmètre de l’accès aux données, l’identité et l’utilisation.
  • Agent PaaS. Vous construisez un agent sur une plateforme d’agent managé, telle que Microsoft Foundry Agent Service, Azure SRE Agent, des agents personnalisés Microsoft Copilot Studio, ou le Microsoft Agent Framework sur un runtime géré par Azure. Microsoft fournit le temps d’exécution, l’hébergement du modèle et les contrôles de sécurité de la plateforme. Vous possédez les instructions de l’agent, la sélection des outils et des plugins, les permissions de l’outil, la logique d’orchestration, la conception de la mémoire, ainsi que l’identité et l’autorisation de l’agent.
  • Agent d’IaaS Vous construisez et hébergez vous-même toute la pile d’agents : un orchestrateur personnalisé sur des machines virtuelles ou des conteneurs, un framework auto-géré, et éventuellement des modèles auto-hébergés. Vous possédez presque tout sauf l’infrastructure physique (et le modèle de base, si vous le consommez comme une API hébergée).

La responsabilité passe à gauche, ce qui signifie que vous prenez plus de responsabilité, à mesure que vous passez du SaaS au PaaS puis aux agents IaaS.

Le schéma suivant illustre les domaines de responsabilité entre vous et Microsoft selon le type de déploiement de l’agent.

Diagramme des couches de responsabilité des agents IA à travers les déploiements IaaS, PaaS et SaaS, avec trois nouvelles couches (mémoire et état des agents, outils et actions, et orchestration des agents) ajoutées au-dessus du modèle de responsabilité partagée IA.

Vue d’ensemble de la couche d’agent IA

Un système agent ajoute trois nouvelles couches au-dessus et autour de la plateforme d’IA, des couches d’application et d’utilisation existantes. La responsabilité de la sécurité incombe à celui qui effectue la tâche, mais un fournisseur peut vous exposer les contrôles sous forme de configuration.

Couche de plateforme d’IA (héritée)

La couche de plateforme IA héberge et protège le modèle, les données d’entraînement, les poids et les API d’inférence, et fournit des systèmes de sécurité intégrés en entrée et sortie. La responsabilité à ce niveau est héritée du modèle de responsabilité partagée de l’IA.

Couche d’orchestration d’agents

La couche d’orchestration est la « boucle de pilotage » : planification, raisonnement, sélection d’outils, prompt système et instructions de l’agent, et coordination entre agents. C’est à ce niveau que se situent les risques d’autonomie excessive et d’injection d’instructions menant à l’action.

Considérations de sécurité :

  • Limitez les instructions et la portée de l’agent (fonctionnalité minimale).
  • Validez et désinfectez tout contenu non fiable qui entre dans la boucle, y compris les documents récupérés, les sorties d’outils et les messages d’autres agents. Traitez tout cela comme une entrée non fiable, pas comme des instructions fiables.
  • Appliquez des garde-fous de planification : limites d’étapes et d’itérations, détection de boucles, plafonds de budget et de coûts, et listes d’autorisation définissant quels outils peuvent être enchaînés.
  • Pour les systèmes multi-agents, traiter chaque message inter-agent comme une frontière de confiance et réappliquer la sécurité des entrées.

Outils et couche d’actions

La couche outils et actions contient les connecteurs, plugins, fonctions, serveurs Model Context Protocol (MCP) et API que l’agent peut invoquer pour lire et modifier l’état dans le monde réel. Cette couche est la plus grande différence avec le modèle LLM.

Considérations de sécurité :

  • Minimum de privilèges par outil. Chaque outil ou connecteur ne doit contenir que les autorisations requises. N’accordez pas à l’agent une identité permanente dotée de privilèges étendus.
  • Autorisation à chaque action, pas seulement au début de la session. Vérifiez à nouveau que cette action, sur cette ressource, est autorisée. Cette vérification atténue les risques liés au problème de l’adjoint confus et à une délégation trop large.
  • Points de contrôle avec intervention humaine. Exigez-les pour des actions à fort impact, irréversibles ou sensibles telles que les écritures, suppressions, paiements, modifications de production et envois externes.
  • Audit des actions. Enregistrez chaque invocation d’outil avec les entrées, sorties, l’identité utilisée et la justification de la décision.
  • Bac à sable et contrôle des sorties réseau. Appliquez-les aux outils d’exécution de code et de navigation.

Mémoire d’agent et couche d’état

La couche de mémoire de l’agent englobe le contexte conversationnel à court terme ainsi que la mémoire persistante, les bases de données vectorielles et les blocs-notes temporaires qui influencent le comportement futur.

Considérations de sécurité :

  • Délimitez et isolez la mémoire pour chaque utilisateur et chaque locataire. Empêcher toute fuite de mémoire entre utilisateurs ou entre sessions.
  • Protégez contre l’empoisonnement de la mémoire. Le contenu injecté peut persister et se déclencher à nouveau plus tard.
  • Classifier, conserver et supprimer la mémoire stockée. Appliquer la classification des données, la conservation et le droit de suppression.
  • Chiffrer les mémoires et imposer le contrôle d’accès. Traitez la mémoire comme des données sensibles.

Couche applicative d’IA (héritée)

La couche applicative de l’IA est l’application ou l’interface qu’utilise l’utilisateur, ainsi que l’ancrage, les extensions et le système de sécurité de l’application.

Couche d’utilisation de l’IA (héritée, étendue)

La couche d’utilisation de l’IA décrit comment les utilisateurs et les applications consomment l’agent. Avec les agents, la responsabilité des actions autonomes devient centrale : politiques d’utilisation acceptable, éducation des utilisateurs sur les risques spécifiques à chaque agent, et prise de responsabilité claire des actions que l’agent entreprend au nom de l’utilisateur.

Matrice de responsabilités

La matrice suivante résume la responsabilité à travers les modèles de déploiement. C = Client, M = Microsoft, S = Partagé. La matrice est un guide général ; Les responsabilités spécifiques pour un service donné peuvent varier en fonction des conditions et de la configuration du service.

Responsabilités héritées en cloud et IA

Zone de responsabilité agent d’IaaS Agent PaaS agent de SaaS
Données client (y compris le contenu d’ancrage et de mémoire) C C C
Identités et utilisateurs C C C
Gestion des accès (RBAC, MFA, Accès conditionnel) C C C
Appareils clients et points de terminaison C C S
Hébergement et poids du modèle de base C/M1 M M
Sécurité du contenu d’entrée/sortie des modèles C/M1 S M
Infrastructure physique (hôtes, réseau, centre de données) M M M

Responsabilités spécifiques à chaque agent

Zone de responsabilité agent d’IaaS Agent PaaS agent de SaaS
Instructions de l’agent, prompt système et périmètre C C S
Sélection d’outils, de plugins et de connecteurs C C S
Autorisations par outil (principe du moindre privilège) C C S
Identité de l’agent et gestion des jetons délégués C S S
Vérifications d’autorisation par action C S S
Approbation avec intervention humaine pour les actions à fort impact C C C
Garde-fous d’orchestration (limites de boucle, d’étape et de coût) C S M
Contrôles des limites de confiance entre plusieurs agents C S S
Conception de la mémoire, isolation et défense contre l’empoisonnement C S M
Mise en bac à sable des outils et des actions, et contrôle des sorties réseau C S M
Journalisation d’audit et supervision des actions C S S
Plateforme d’exécution et d’orchestration des agents C M M
Politique d’utilisation acceptable et responsabilité des actions C C C

1 Client si vous hébergez vous-même le modèle sur IaaS ; Microsoft si vous consommez une API de modèle hébergée depuis votre agent hébergé en IaaS.

Responsabilités que vous conservez toujours

Quel que soit le modèle de déploiement, vous êtes toujours responsable de :

  • Les données, y compris tout ce qui a été écrit sur la mémoire de l’agent et transmis aux outils.
  • Identité et moindre privilège : l’identité propre à l’agent et la portée de chaque accréditation ou token qu’il peut utiliser.
  • Autorisation d’actions : ce que l’agent est autorisé à faire, en particulier les opérations irréversibles ou sensibles.
  • Surveillance humaine : quelles actions nécessitent l’approbation et qui est responsable du comportement de l’agent.
  • Utilisation acceptable et gouvernance : politiques, éducation des utilisateurs et conformité au comportement autonome.

Principaux risques spécifiques à l’agent contre lesquels concevoir

Ces risques correspondent au Top 10 OWASP pour les applications LLM, au Top 10 OWASP pour l’IA Agentique, au MITRE ATLAS, et à la classification de gravité des vulnérabilités du Centre d'intervention en matière de sécurité Microsoft (MSRC) pour les systèmes d’IA. Ils mettent en avant la dimension d’action propre aux agents.

Risque Mitigation
De l’injection d’invite à l’action. Des contenus non fiables, tels qu’une page web, un document, un e-mail ou un autre agent, détournent l’agent en le poussant à invoquer des outils de manière malveillante. Considérez tous les résultats des outils, des systèmes de récupération d’informations et des agents comme non fiables. Isoler les instructions des données. Soumettez les actions à fort impact à un point de contrôle.
Une autonomie excessive. L’agent dispose de plus d’outils, d’autorisations ou d’autonomie que ce dont la tâche en a besoin. Appliquer le principe de fonctionnalité minimale et celui du moindre privilège pour chaque outil, et limiter la portée des instructions.
Député confus ou délégation trop large. L’agent utilise son identité privilégiée pour faire quelque chose que l’utilisateur demandeur ne peut pas. Utilisez des jetons On-Behalf-Of et une autorisation par action. Évitez une identité trop large.
Empoisonnement de la mémoire. Le contenu injecté persiste et se redéclenche plus tard ou d’une session à l’autre. Isoler et valider les données en mémoire, assurer la traçabilité et appliquer les politiques de rétention.
Boucles illimitées, coût et épuisement des ressources. Planification incontrôlée. Faire respecter les limites d’étapes, d’itérations et de budget, et détecter les boucles.
Défaillances liées à la confiance dans les systèmes multi-agents. Un agent compromis ou hallucinant contamine les collaborateurs. Appliquez de nouveau les contrôles de sécurité des entrées à chaque limite entre agents. Vérifie, ne fais pas confiance.
Agents malveillants ou usurpateurs. Un agent non autorisé agit dans l’environnement, ou l’identité de cet agent est usurpée. Faire respecter une identité forte de l’agent, une attestation, ainsi que la détection et la surveillance.

Configurez avant de personnaliser

Le même principe que Microsoft recommande pour l’IA s’applique aux agents, et il est d’autant plus vrai pour les agents, car l’autonomie multiplie le coût des erreurs.

  1. Commencez avec des agents SaaS (Microsoft 365 Copilot, Microsoft Security Copilot, ou des agents Microsoft Copilot Studio publiés). Microsoft s’occupe de l’orchestration, de la sécurité et de la plupart des outils de sécurité. Vous configurez la portée et l’identité des données.
  2. Recourez à des agents de type PaaS (Microsoft Foundry Agent Service, Azure SRE Agent, des agents Microsoft Copilot Studio personnalisés ou Microsoft Agent Framework sur un environnement d’exécution managé) uniquement lorsque les solutions prêtes à l’emploi ne conviennent pas. Vous prenez en charge la logique de l’agent, les outils, les permissions, la mémoire et l’identité.
  3. Construisez uniquement des agents IaaS avec une expertise approfondie en sécurité de l’IA, en identité et en gestion des risques liés aux systèmes autonomes. Vous possédez presque toute la pile.

Règle générale : Plus l’autonomie et l’ensemble d’outils et d’autorisations que vous accordez à un agent est important, plus la matrice de responsabilités vous revient, quel que soit le modèle de déploiement. L’autonomie ne réduit jamais la responsabilité.

Étapes suivantes

  • Last updated on