Comment sécuriser les agents IA pendant leur exécution

L’authentification n’est plus la fin de la décision de sécurité

Un agent d’IA peut s’authentifier correctement, recevoir exactement les autorisations qu’il était censé recevoir, et tout de même effectuer une action non sûre quelques minutes plus tard. Cette possibilité change l’endroit où les équipes de sécurité d’entreprise doivent prendre leurs décisions, car les organisations passent d’assistants qui répondent à des questions à des agents autonomes qui raisonnent, invoquent des outils, accèdent à des applications, se coordonnent avec d’autres agents et exécutent des workflows en plusieurs étapes avec peu d’intervention humaine. Une fois que ces systèmes peuvent choisir eux-mêmes leur cheminement dans une tâche, une authentification réussie n’établit que les conditions de départ de l’exécution.

Ces conditions de départ ne peuvent pas déterminer chaque choix ultérieur, car le logiciel agent sélectionne des outils, des appels API, des sources d’information et des séquences d’actions en fonction du contexte qu’il rencontre. Les applications conventionnelles exécutent une logique définie par les développeurs, tandis qu’un agent peut adapter son parcours à mesure qu’un workflow se développe. Cette flexibilité peut créer une valeur métier importante, car le système peut réagir à l’évolution des circonstances. Le même mécanisme permet au risque de sécurité d’évoluer pendant l’exécution du workflow.

Cette évolution du risque inclut des préoccupations familières liées à la sécurité de l’IA, comme l’injection de prompt, les vulnérabilités des modèles et les fuites de données, mais l’exécution autonome crée une exigence plus large. Les entreprises doivent savoir quel agent agit, donc chaque agent a besoin de sa propre identité. Une fois cette identité établie, les contrôles de sécurité doivent aussi évaluer si les choix changeants de l’agent restent appropriés pendant l’exécution.

La confiance à l’exécution répond à cette étape ultérieure en évaluant si un agent authentifié et autorisé continue à se comporter de manière cohérente avec sa tâche, la politique de l’organisation et le contexte actuel. Pour les équipes de sécurité, la décision continue après qu’un fournisseur d’identité a accepté l’agent et qu’un système d’autorisation lui a accordé ses permissions. La frontière de sécurité s’étend jusqu’à l’exécution.

L’identité et le zero trust restent la base

Parce que l’évaluation à l’exécution commence avec un acteur connu, les contrôles d’entreprise établis restent fondamentaux. Les fournisseurs d’identité, l’authentification multifacteur (MFA), le contrôle d’accès basé sur les rôles (RBAC) et les architectures zero trust répondent à trois questions de sécurité : qui ou quoi agit, à quelles ressources il peut accéder, et quelles actions il est autorisé à effectuer. Le NIST SP 800-207 reste une référence pour ces principes zero trust. Les agents autonomes ont besoin de ces contrôles, car la gouvernance à l’exécution dépend d’identités connues et d’un accès limité.

Même lorsque ces contrôles fonctionnent comme prévu, un agent peut utiliser une identité d’entreprise et des identifiants API valides pour travailler à travers Microsoft 365, ServiceNow, Salesforce ou GitHub, chaque ressource étant couverte par des permissions que l’organisation a volontairement accordées. Les identifiants peuvent être légitimes, l’authentification peut réussir, et les règles d’autorisation peuvent fonctionner correctement. Le problème de sécurité qui subsiste est la manière dont l’agent exerce ces pouvoirs valides à mesure que sa tâche évolue.

Cet usage peut changer en continu, car un agent continue d’interpréter son objectif après la connexion. Il récupère de nouvelles informations, raisonne sur ce qu’il trouve, invoque des outils, évalue les résultats et adapte les étapes suivantes à mesure que son contexte change. Chaque décision peut respecter les règles de permission en place tout en allant au-delà de ce que l’utilisateur a demandé ou de ce que la politique de l’organisation juge approprié. L’authentification et l’autorisation définissent les pouvoirs disponibles de l’agent ; les contrôles à l’exécution évaluent si un usage particulier de ces pouvoirs est justifié pour la tâche en cours.

La distinction est résumée par la formulation centrale de la confiance à l’exécution : « L’authentification vérifie qui est un agent d’IA. La confiance à l’exécution vérifie en continu ce qu’il fait. » Le principe du moindre privilège reste une partie de cette même base, car réduire les pouvoirs disponibles limite les conséquences potentielles d’une mauvaise décision. La confiance à l’exécution ajoute une autre décision : déterminer si l’exercice d’un pouvoir disponible est nécessaire et approprié à un moment donné.

Cette décision comble une lacune architecturale lorsque les contrôles de l’IA s’arrêtent aux identifiants, aux règles d’accès et aux permissions définies au moment du déploiement. Cette lacune apparaît dans des organisations de tailles et de secteurs différents : un déploiement qui considère l’accès légitime comme suffisant ne dispose d’aucun mécanisme pour évaluer les choix autonomes ultérieurs. Le zero trust établit les conditions dans lesquelles un agent peut opérer, tandis que les contrôles à l’exécution évaluent les actions que l’agent choisit dans ces conditions.

Le risque évolue pendant que l’agent s’exécute

La lacune architecturale s’élargit à mesure que le nombre d’entrées et de capacités disponibles pour un agent augmente. Un agent moderne peut interagir avec des grands modèles de langage (LLM), des serveurs Model Context Protocol (MCP), des systèmes de retrieval-augmented generation (RAG) qui fournissent le contexte du modèle à partir d’informations récupérées, des bases de données vectorielles, des API d’entreprise, des plateformes SaaS, des référentiels de connaissances internes et d’autres agents d’IA. Chaque interaction peut ajouter une information ou une action possible à un workflow inachevé. Un outil compromis, une source de connaissances empoisonnée, une API trop permissive ou un prompt manipulé peuvent par conséquent influencer les décisions plus tard dans la séquence.

Parce que ces entrées arrivent pendant l’exécution, le risque lié à l’agent peut évoluer après qu’un examen au moment du déploiement a établi sa configuration initiale et ses permissions disponibles. Les décisions ultérieures dépendent du contexte recueilli après le déploiement et souvent après le démarrage d’un workflow particulier, de sorte qu’un nouveau contexte peut modifier ce que l’agent pense que l’objectif exige. Les équipes de sécurité sont donc confrontées à un jugement en temps réel : déterminer si l’action suivante reste cohérente avec la tâche et la politique compte tenu de tout ce que l’agent a rencontré jusqu’à présent.

La dérive d’objectif est une forme de ce problème en temps réel, car un agent peut commencer avec un objectif légitime et élargir progressivement son interprétation de l’intention de l’utilisateur en essayant d’améliorer le résultat. Prenons un agent chargé de préparer un rapport client : il peut décider que des informations confidentielles sans lien direct apporteraient un contexte supplémentaire utile et les récupérer. Son identité peut rester valide, et ses permissions sur le référentiel peuvent autoriser cette récupération, alors même que son interprétation de la tâche a dépassé le périmètre prévu.

Le cas du rapport client montre pourquoi le seul droit d’accès à une ressource ne peut pas trancher la décision à l’exécution. Un système de contrôle d’accès peut conclure à juste titre que l’agent peut lire un référentiel tout en ne disposant pas du contexte de la tâche nécessaire pour décider si un document particulier a sa place dans ce rapport. La décision de sécurité dépend donc à la fois de l’intention et du contexte actuel. Empêcher une récupération inutile exige un contrôle capable d’évaluer l’action proposée pendant l’exécution du workflow.

L’invocation excessive d’outils crée le même problème architectural par le biais des actions. Un agent disposant de nombreuses intégrations d’entreprise peut appeler des API inutiles, modifier des configurations, ouvrir des référentiels sensibles ou effectuer des opérations administratives parce que son modèle juge ces étapes utiles pour atteindre l’objectif. Un large accès aux outils augmente les choix disponibles pour le modèle, de sorte qu’un contrôle à l’exécution doit déterminer quelles capacités disponibles sont requises par la tâche en cours.

L’empoisonnement de la mémoire peut modifier ces choix sur une période plus longue. La mémoire persistante peut améliorer la personnalisation et la continuité entre les interactions, mais des attaquants peuvent placer des instructions trompeuses dans la mémoire à long terme ou dans les systèmes de récupération. Les décisions futures peuvent alors s’appuyer sur des informations malveillantes ou obsolètes que l’agent considère comme un contexte pertinent. Comme un comportement dangereux peut survenir bien après l’entrée de l’information dans le système, l’intégrité et le cycle de vie de la mémoire deviennent une composante de la sécurité de l’exécution.

La même dépendance à l’intégrité des entrées s’étend au-delà de la mémoire persistante à la manipulation du contexte. Les documents récupérés, les prompts système, l’historique des conversations et les sources de données externes peuvent tous influencer la prochaine décision d’un LLM, de sorte qu’un attaquant qui modifie ces entrées peut orienter un comportement autonome sans compromettre le modèle sous-jacent. MITRE ATLAS répertorie les comportements adverses contre les systèmes d’IA et fournit un framework pour examiner ce type de menace. Le modèle peut rester intact tandis que des informations non sûres modifient ses choix.

Les systèmes multi-agents étendent ces défaillances individuelles par propagation. Des agents spécialisés peuvent déléguer des tâches ou consommer les résultats les uns des autres, ce qui signifie que l’action incorrecte d’un agent peut devenir une entrée de confiance pour un autre. Les agents en aval peuvent alors amplifier la première erreur, créant des défaillances en cascade dans un workflow d’entreprise. L’analyse de sécurité doit donc suivre les actions déléguées et le contexte échangé tout au long de la séquence.

Ces menaces entrent par des mécanismes différents, mais chacune modifie le comportement d’un agent pendant l’exécution. La dérive d’objectif modifie son interprétation de l’objectif ; la mémoire empoisonnée et le contexte manipulé modifient les informations utilisées pour les décisions ; l’invocation excessive d’outils affecte la manière dont les capacités accordées sont exercées ; et l’amplification multi-agents propage une mauvaise décision aux étapes autonomes suivantes. Ensemble, ces mécanismes expliquent pourquoi la question opérationnelle doit suivre l’agent tout au long de son travail.

Une formulation en cycle de vie résume cette exigence : « La question n’est plus de savoir si un agent d’IA s’est authentifié avec succès. La question la plus importante est de savoir s’il continue à se comporter de manière sûre tout au long de son cycle de vie. » Pour les organisations qui attribuent déjà aux agents des identifiants valides et un accès à de véritables systèmes métier, chaque étape conséquente présente à nouveau ce jugement. Les faits qui façonnent la décision suivante continuent d’arriver pendant l’exécution, donc la décision de sécurité doit elle aussi rester active.

La confiance à l’exécution transforme l’autorisation en boucle de contrôle continue

Une décision de sécurité active exige une évaluation répétée du comportement à l’exécution par rapport à la politique de l’organisation. L’authentification établit l’identité et l’autorisation établit les pouvoirs disponibles ; l’évaluation à l’exécution examine les usages proposés de ces pouvoirs à mesure que le workflow se développe. Les actions sensibles deviennent des points de décision explicites où le système peut autoriser l’exécution, restreindre la capacité disponible, demander une approbation ou bloquer l’action conformément à la politique.

La validation de l’intention fournit un tel point de décision avant qu’une opération sensible n’ait lieu. L’évaluation pose les questions suivantes : « Cette action est-elle nécessaire ? Est-elle attendue ? Dépasse-t-elle le périmètre demandé ? Une personne raisonnable effectuerait-elle la même action ? » Ces questions relient une action individuelle à l’objectif initial et fournissent des informations que l’autorisation permanente ne peut pas fournir à elle seule. Dans l’exemple du rapport client, l’évaluation peut distinguer une récupération pertinente d’une demande inutile de données confidentielles.

Cette évaluation au niveau de l’action a besoin de preuves, que la surveillance comportementale fournit dans le temps. Les équipes de sécurité peuvent observer l’usage des outils, l’activité API, les schémas de raisonnement, la fréquence d’exécution, les actions déléguées et les workflows anormaux afin d’identifier les comportements qui s’écartent de l’exécution attendue. Ces signaux exposent une séquence en cours de développement aux contrôles de sécurité alors qu’une intervention reste encore possible, y compris dans les cas où le raisonnement du modèle ne deviendrait autrement visible qu’au travers d’une action externe.

Une fois que la surveillance met en évidence le comportement pertinent, l’application des politiques peut transformer ces preuves en contraintes sur les actions individuelles. Une entreprise peut bloquer les transactions financières au-dessus des seuils d’approbation, empêcher les modifications de privilèges, restreindre les opérations administratives, limiter la récupération de données sensibles et exiger une approbation pour les activités à haut risque. La politique régit ce qu’un agent peut faire dans son contexte d’exécution actuel, donnant à l’entreprise une décision liée à la tâche et à l’action proposée.

Cette décision contextuelle modifie aussi la manière dont le moindre privilège peut fonctionner. Un agent devrait recevoir les capacités requises pour sa tâche actuelle, avec des permissions de courte durée émises selon les conditions d’exécution plutôt qu’un accès large et permanent à des dizaines d’outils d’entreprise. Le projet OWASP GenAI Security met de plus en plus l’accent sur cette approche du moindre privilège à l’exécution dans ses recommandations pour les applications d’IA agentique. Une permission peut alors expirer avec le besoin qui la justifiait, réduisant les capacités disponibles pour les décisions autonomes ultérieures.

Les permissions dynamiques appliquent ce principe lorsqu’un workflow traverse plusieurs systèmes. Un agent peut avoir besoin d’une capacité limitée dans chaque système, de sorte que le contrôle peut accorder l’accès pour l’étape en cours tout en maintenant hors de l’ensemble des capacités actives les fonctions administratives ou d’accès aux données sans lien avec cette étape. Le moindre privilège reflète alors à la fois le droit maximal de l’agent et les besoins de la tâche à un moment donné.

Certaines décisions à fort impact exigent aussi une autorité humaine dans ce parcours de politique. Les approbations financières, les changements d’identité, les actions réglementaires et les décisions ayant un impact sur le client peuvent nécessiter une confirmation explicite avant que l’agent ne les exécute. La confiance à l’exécution fournit le mécanisme permettant de reconnaître ces actions et de les acheminer pour approbation, préservant l’autorité humaine là où les conséquences le justifient tout en permettant aux autres étapes de se poursuivre sous une politique automatisée.

À mesure que les agents gagnent en autonomie, la même boucle de contrôle devra fonctionner à travers des systèmes qui collaborent, planifient leur propre travail et exécutent des processus métier de plus en plus complexes. Un événement d’authentification ne décrit alors qu’un moment dans une séquence de décisions bien plus longue. Ce changement donne à l’exigence de sécurité plus large toute sa portée : « L’avenir de la sécurité de l’IA ne sera pas défini uniquement par des modèles plus puissants ou une meilleure authentification. Il sera défini par notre capacité à établir, mesurer et vérifier en continu la confiance pendant que des systèmes intelligents prennent des décisions en temps réel. »

La confiance à l’exécution dépend d’un contexte sécurisé et de décisions observables

La vérification continue dépend d’abord de la protection des systèmes qui fournissent le contexte d’un agent. Avec Model Context Protocol, les entreprises ont besoin d’une vérification des serveurs de confiance, d’outils authentifiés, de capacités approuvées, d’interactions surveillées et d’une application des politiques. Un agent gouverné par une politique à l’exécution peut toujours être influencé par un outil ou un serveur non sûr lorsque les composants environnants se trouvent hors de la frontière de contrôle. La sécurité de MCP doit donc couvrir les systèmes auxquels un agent se connecte et les capacités que ces connexions fournissent.

L’infrastructure RAG a besoin de contrôles similaires, car les informations récupérées peuvent façonner la décision suivante avant que l’agent n’invoque un outil ou n’effectue une action externe. L’intégrité des documents et la validation de la source aident à établir si les éléments récupérés sont dignes de confiance, tandis que le contrôle d’accès limite ce que la couche de récupération peut exposer. L’audit de la récupération enregistre quelles informations ont alimenté une décision, et la détection d’empoisonnement traite les tentatives d’introduire des contenus qui influenceront un comportement ultérieur.

La mémoire persistante étend cette exigence à travers les workflows, car le contexte stocké peut influencer des décisions longtemps après sa création. Les politiques d’expiration et la gestion du cycle de vie déterminent combien de temps ce contexte reste disponible, tandis que la vérification d’intégrité aide à établir si les informations conservées ont été modifiées de manière inappropriée. La journalisation des accès enregistre les interactions avec la mémoire, et la protection des données sensibles limite ce qui peut être conservé ou exposé. La mémoire devient une infrastructure pertinente pour la sécurité lorsque des décisions autonomes ultérieures en dépendent.

Une fois ces entrées protégées, les équipes de sécurité ont aussi besoin de preuves les reliant à l’exécution. Les équipes doivent voir pourquoi un agent a sélectionné certains outils, quelles données ont influencé ses décisions, comment il est parvenu à ses conclusions, quelles actions il a effectuées, quelles politiques ont été déclenchées et quelles protections ont empêché un comportement non sûr. La journalisation à l’exécution, les pistes d’audit et l’analytique comportementale fournissent cet enregistrement opérationnel, ce qui en fait des composants essentiels des opérations d’IA d’entreprise lorsque la gouvernance à l’exécution dépend de preuves sur les décisions qu’elle régit.

Cet enregistrement donne à l’observabilité une fonction de contrôle directe. Les enregistrements reliant entrées, décisions et actions permettent à une équipe d’évaluer un comportement anormal, d’auditer une récupération, d’enquêter sur une action déléguée et de vérifier une intervention de politique. Les mêmes preuves permettent aux opérations de sécurité de reconstituer un incident et de déterminer à quel endroit une protection est intervenue. Pour les systèmes autonomes, la visibilité sur l’exécution soutient à la fois l’application immédiate et la responsabilité a posteriori.

Étendez le programme de sécurité dont vous disposez déjà

Parce que la confiance à l’exécution s’appuie sur l’identité, la politique, la surveillance et les mécanismes de réponse aux incidents, les entreprises peuvent l’introduire en étendant les contrôles et les processus opérationnels qu’elles utilisent déjà. La séquence de mise en œuvre commence par l’inventaire des agents et de leurs capacités, puis par l’application du moindre privilège aux outils et aux API, et par la classification des actions autonomes à haut risque. Ces étapes établissent les objets et les frontières dont la politique à l’exécution a besoin avant qu’une application des règles puisse être pertinente.

Une fois ces frontières connues, une organisation peut mettre en œuvre l’application des politiques à l’exécution, surveiller en continu les anomalies comportementales, protéger la mémoire et les sources RAG, et exiger une approbation humaine pour les opérations critiques. L’ordre a son importance, car la classification donne à l’application des politiques et à l’approbation humaine un périmètre défini, tandis qu’un contexte protégé réduit le risque que des récupérations empoisonnées ou la mémoire orientent les actions ultérieures. Ces contrôles relient l’exécution des agents aux mêmes responsabilités de sécurité qui régissent déjà les systèmes d’entreprise.

La dernière étape opérationnelle consiste à intégrer la télémétrie d’exécution dans les workflows existants du centre des opérations de sécurité (SOC). Un SOC est la fonction qui surveille les événements de sécurité et coordonne l’investigation et la réponse ; la télémétrie des agents fournit donc aux équipes opérationnelles existantes des preuves sur le comportement autonome en parallèle des autres activités de l’entreprise. Une fois cette connexion en place, les événements de politique à l’exécution, les anomalies comportementales, les enregistrements de récupération, les actions déléguées, les approbations et les interventions de protection peuvent entrer dans les processus établis de surveillance et de réponse aux incidents.

Points clés à retenir pour les décideurs

• Étendez les décisions de sécurité à l’exécution : L’authentification et l’autorisation établissent l’identité d’un agent d’IA et ses pouvoirs disponibles, tandis que la confiance à l’exécution évalue la manière dont ces pouvoirs sont utilisés. Les responsables de la sécurité peuvent appliquer des vérifications continues à l’intention, au contexte, à l’usage des outils et aux actions sensibles tout au long d’un workflow.
• Appuyez la confiance à l’exécution sur l’identité et le zero trust : Les identités individuelles des agents, le moindre privilège, la MFA, le RBAC et les contrôles zero trust fournissent la base de la gouvernance à l’exécution. Les équipes IAM et sécurité peuvent associer ces contrôles à des politiques conscientes de la tâche qui déterminent si chaque usage d’une capacité autorisée est approprié.
• Traitez le risque lié aux agents comme dynamique : Les données récupérées, la mémoire persistante, les appels d’outils, les systèmes externes et les autres agents peuvent modifier le comportement pendant l’exécution. Les équipes de sécurité peuvent surveiller la dérive d’objectif, la manipulation du contexte, l’usage excessif des outils et la propagation multi-agents comme des risques opérationnels en temps réel.
• Transformez l’autorisation en boucle de contrôle continue : La surveillance à l’exécution et l’application des politiques créent des points de décision pour les actions sensibles, permettant des permissions dynamiques, des blocages ou une approbation humaine. Les équipes plateforme peuvent lier des capacités de courte durée à la tâche en cours et acheminer les décisions à fort impact vers l’autorité appropriée.
• Protégez le contexte derrière les décisions des agents : Les serveurs MCP, les systèmes RAG et la mémoire persistante influencent directement le comportement autonome et doivent faire partie de la frontière de sécurité. Les équipes plateforme et sécurité peuvent vérifier les sources, contrôler l’accès, protéger l’intégrité et journaliser les entrées et les actions à l’origine des décisions conséquentes.
• Intégrez la confiance à l’exécution aux opérations de sécurité existantes : Les entreprises peuvent commencer par inventorier les agents, cartographier leurs capacités et classer les actions à haut risque avant d’appliquer des politiques à l’exécution. Les équipes SOC peuvent ensuite intégrer la télémétrie des agents, les anomalies, les approbations et les événements de politique dans les workflows établis de surveillance et de réponse aux incidents.