Après les attaques d’agents autonomes, sécuriser les assistants qui agissent pour nous

Un assistant IA qui lit un courriel, modifie un dépôt de code ou déclenche une opération n’est plus seulement un outil de génération : c’est un système capable d’agir avec des accès réels. Pour sécuriser les assistants autonomes, il faut donc traiter ensemble leur identité, leurs permissions, les outils qu’ils utilisent, leur mémoire et la supervision de leurs actions, au lieu de compter uniquement sur des prompts prudents.

Cette évolution explique pourquoi la sécurité des agents est devenue un sujet de normalisation et de gouvernance. En 2026, le NIST travaille à une initiative consacrée aux agents IA, tandis que l’OWASP développe des ressources sur les risques agentiques. Ces travaux convergent sur un principe opérationnel : un agent doit disposer de l’autorité minimale nécessaire, agir dans un périmètre vérifiable et demander une validation humaine lorsque l’impact d’une action le justifie.

Pourquoi la sécurité des assistants autonomes dépasse celle d’un chatbot

Un chatbot répond principalement à une demande dans une conversation. Un agent peut en plus poursuivre un objectif, appeler un outil, conserver un état et enchaîner plusieurs opérations. Il peut ainsi passer d’une recommandation à une modification effective d’un système. La différence n’est pas seulement technique : elle change la manière dont une erreur ou une manipulation peut produire des conséquences.

Le NIST souligne que les agents prennent des actions autonomes susceptibles d’affecter des systèmes ou des environnements réels. Son appel à contributions de janvier 2026 porte explicitement sur le développement et le déploiement sécurisés des systèmes d’agents IA. La synthèse publiée en mai indique que les répondants considèrent certains risques comme nouveaux, tout en jugeant utiles les principes de cybersécurité existants s’ils sont adaptés aux comportements des agents.

Les usages cités par le NIST rendent l’enjeu concret : rédaction ou débogage de code, gestion d’e-mails et de calendriers, achats et fonctions de support. Dans chacun de ces cas, un agent peut toucher des données, des services ou des processus professionnels. Un accès trop large, une instruction mal interprétée ou un contenu malveillant reçu par l’agent peut alors avoir davantage de portée que dans une simple réponse textuelle.

Réponse courte : sécurisez un agent en lui attribuant une identité propre, des permissions minimales et des outils limités, en faisant approuver les opérations à fort impact, puis en surveillant et en journalisant ses actions. Les protections intégrées au modèle ne remplacent pas ces contrôles de déploiement.

Le problème n’est pas que chaque agent soit nécessairement dangereux, ni que toute tâche doive être bloquée. Il est que l’autonomie augmente le nombre d’étapes entre une instruction initiale et son effet final. Une consigne peut être comprise de travers, une réponse d’outil peut être trompeuse, ou une opération apparemment anodine peut déclencher une série de changements. La conception de sécurité doit donc prendre en compte le parcours complet, et non uniquement le texte visible dans la conversation.

Les attaques par prompt injection illustrent ce déplacement. Elles existaient avant l’essor des agents, mais leur impact peut être plus sérieux lorsqu’un système a le droit d’exécuter des actions. Dans sa contribution au RFI du NIST, Anthropic souligne que les conséquences deviennent qualitativement différentes lorsqu’une instruction hostile vise un système autonome capable d’agir. La défense ne peut donc pas se limiter à demander au modèle de reconnaître et de refuser les instructions malveillantes.

Construire une identité et une autorisation propres à chaque agent

Un agent qui agit au nom d’une personne ou d’une équipe doit être identifiable comme une entité distincte. L’identité machine permet de savoir quel agent a lancé une opération, avec quelle autorisation et dans quel contexte. Sans cette séparation, les actions risquent d’être exécutées sous un compte humain partagé ou un compte de service trop puissant, ce qui complique la prévention des abus comme l’analyse d’un incident.

En août 2026, le NIST met l’accent sur une base d’identité forte pour les agents. Il relève aussi une tendance familière dans les premiers déploiements : les fonctionnalités et la valeur métier passent souvent avant la sécurité. Les garde-fous reposant uniquement sur le modèle ne suffisent pas à résoudre les nouveaux défis. L’identité, l’autorisation et des mécanismes d’authentification adaptés sont donc des fondations du déploiement, pas des améliorations facultatives à ajouter après coup.

Éviter les comptes partagés et les privilèges implicites

Chaque agent devrait recevoir une identité technique distincte, associée à une fonction clairement définie. Un agent chargé de classer des demandes n’a pas nécessairement besoin des mêmes droits qu’un agent capable de préparer une modification de code. De même, un agent qui propose une action ne devrait pas automatiquement hériter du pouvoir de l’exécuter. Cette séparation aide à contrôler les capacités, à révoquer un accès et à attribuer une action à son origine.

L’autorisation doit être évaluée au moment de l’action, selon l’identité de l’agent, la ressource concernée, le type d’opération et le contexte prévu. Il ne suffit pas qu’un agent ait été autorisé lors de son lancement si son objectif ou les données disponibles évoluent ensuite. Les systèmes d’identité et de contrôle d’accès doivent refléter les changements de périmètre et permettre de retirer rapidement un droit devenu inutile.

  • Attribuer une identité distincte : évitez qu’un agent partage les identifiants d’un employé ou d’un compte général sans traçabilité.
  • Définir un périmètre fonctionnel : reliez les droits à une tâche et aux ressources nécessaires pour l’accomplir.
  • Réduire la durée des accès : privilégiez des autorisations accordées pour une opération ou une période limitée lorsque l’architecture le permet.
  • Prévoir la révocation : assurez-vous qu’un accès peut être interrompu sans devoir arrêter toute l’organisation ou reconstruire le système.

Une identité robuste ne signifie pas que l’agent devient fiable par nature. Elle rend ses actions attribuables et ses droits contrôlables. Cette distinction est importante : authentifier un agent répond à la question « qui agit ? », tandis que l’autorisation détermine « que peut-il faire ? ». Les deux contrôles doivent rester séparés pour éviter qu’une identité reconnue soit interprétée comme une permission générale.

Appliquer le moindre privilège aux outils et aux environnements d’exécution

Le principe du moindre privilège consiste à donner à l’agent uniquement les capacités indispensables à sa mission. Pour un assistant qui résume des documents, l’accès en lecture peut suffire. Pour un agent qui prépare des changements, l’accès en écriture peut être limité à un espace de travail ou à une branche dédiée. Un outil disponible dans l’environnement ne devrait pas être automatiquement accessible à chaque agent.

L’OWASP recommande que les agents opèrent sous les mêmes contrôles de gestion des changements que les administrateurs humains, avec des garde-fous supplémentaires. Ses recommandations portent notamment sur l’accès minimal aux outils et sur l’approbation explicite des actions qui modifient la sécurité, les permissions ou l’infrastructure. Le NIST insiste également sur la nécessité de contraindre et de surveiller l’étendue des accès de l’agent à son environnement.

Décomposer les permissions par capacité

Un contrôle utile ne se contente pas de classer un agent comme « autorisé » ou « non autorisé ». Il distingue les capacités : consulter une donnée, l’exporter, la modifier, la supprimer, envoyer un message, créer un compte ou changer une configuration. Cette granularité permet de donner à l’agent un accès en lecture tout en réservant les opérations destructrices ou sensibles à un mécanisme de validation.

La même logique s’applique aux outils. Au lieu d’exposer un terminal généraliste à un agent, une application peut lui proposer des fonctions limitées, avec des paramètres validés et des résultats contrôlés. Un outil métier spécifique peut restreindre les actions possibles plus efficacement qu’un accès large à une interface qui permet de contourner les règles. La contrepartie est un travail de conception supplémentaire : il faut définir les fonctions utiles, les erreurs possibles et les limites de chaque interface.

Isoler l’agent et contenir les effets d’une erreur

Le périmètre de l’agent comprend aussi son environnement d’exécution : fichiers visibles, services accessibles, réseau, secrets disponibles et autres agents avec lesquels il peut échanger. L’isolation réduit les conséquences possibles si l’agent est trompé ou se comporte de manière inattendue. Elle facilite aussi la mise en place de limites opérationnelles, comme interdire l’accès à des ressources qui ne sont pas nécessaires à la tâche.

Il existe un arbitrage entre autonomie et friction. Des restrictions trop faibles rendent l’agent efficace à court terme, mais augmentent l’exposition. Des restrictions trop fortes peuvent empêcher une tâche légitime ou pousser les utilisateurs à contourner le système. Il faut donc partir du cas d’usage réel, accorder seulement les droits nécessaires et élargir le périmètre de façon contrôlée lorsque des besoins démontrés le justifient.

Un test pratique consiste à demander, pour chaque outil et chaque droit : si cet accès était utilisé à mauvais escient, quel serait le dommage possible ? Si la réponse dépasse les conséquences acceptables pour la tâche, le périmètre doit être réduit, l’action isolée ou la validation renforcée. Cette question relie directement les permissions techniques à l’impact métier au lieu de traiter la configuration comme une simple liste de rôles.

Protéger le contexte, la mémoire et les agents contre l’injection

Un agent peut utiliser des informations venant de sources différentes : demandes de l’utilisateur, documents consultés, résultats d’outils et mémoire conservée entre les étapes. Toutes ces données ne sont pas équivalentes. Une instruction présente dans un document externe ne devrait pas être considérée comme une autorisation de modifier le système, et une réponse d’outil ne devrait pas être acceptée aveuglément comme une instruction de confiance.

La prompt injection devient particulièrement préoccupante lorsque l’agent peut exécuter une action après avoir traité un contenu non fiable. Un message, une page ou un document peut contenir des consignes qui cherchent à détourner le comportement de l’agent. Les protections du modèle peuvent aider à reconnaître certains cas, mais elles ne constituent pas une frontière d’autorisation. La décision d’exécuter une action doit également être encadrée par les permissions, la validation des paramètres et les politiques du système.

Traiter les entrées selon leur provenance

Le système doit distinguer les instructions de contrôle approuvées des données que l’agent est chargé de lire. Cette distinction peut être matérialisée dans l’architecture, les métadonnées et le flux de traitement, plutôt que laissée à la seule interprétation du modèle. Les contenus externes doivent être traités comme des données potentiellement hostiles, même lorsqu’ils semblent professionnels ou proviennent d’un outil habituellement utile.

Il est également important de vérifier les sorties d’outils avant de les réutiliser. Une réponse qui contient une commande, une URL, un identifiant ou une proposition d’action ne doit pas acquérir automatiquement une autorité simplement parce qu’elle a été produite par une intégration. Des contrôles de type, de format, de destination et de cohérence métier peuvent éviter qu’une valeur inattendue ne déclenche une opération importante.

Limiter les risques liés à la mémoire persistante

L’OWASP AIVSS 2026 décrit les systèmes agentiques comme des systèmes qui peuvent fonctionner de façon continue, poursuivre des objectifs dans le temps et interagir avec des outils externes. Cette continuité rend l’état persistant, la mémoire et le contexte particulièrement importants. Si une information malveillante ou erronée est enregistrée puis réutilisée, son influence peut dépasser la session où elle a été introduite. L’OWASP reconnaît ainsi le memory/context poisoning comme une surface d’attaque à prendre en compte.

La mémoire ne devrait donc pas être une zone opaque dans laquelle toutes les informations reçues sont conservées sans distinction. Il faut savoir quelles données sont enregistrées, d’où elles proviennent, combien de temps elles restent disponibles et qui peut les modifier. Les éléments persistants qui influencent des décisions futures méritent des règles d’accès, de validation et de suppression. Les utilisateurs doivent aussi disposer d’un moyen de corriger ou d’effacer une mémoire incorrecte lorsque le produit le prévoit.

  • Ne transformez pas un contenu externe en règle durable sans validation adaptée.
  • Associez les informations mémorisées à leur provenance et à leur niveau de confiance lorsque l’architecture le permet.
  • Limitez la durée de conservation aux besoins du cas d’usage.
  • Contrôlez les mécanismes d’écriture et de mise à jour de la mémoire comme des capacités sensibles.
  • Testez si une instruction hostile peut influencer une action ultérieure, y compris après un changement de session.

Ces mesures ne suppriment pas l’injection ou l’empoisonnement du contexte. Elles réduisent la possibilité qu’un contenu non fiable devienne une autorité implicite ou un état durable. Elles aident aussi à expliquer, lors d’une enquête, quelles informations ont orienté l’agent et à quel moment elles ont été introduites.

Définir les actions qui exigent une approbation humaine

La validation humaine est utile lorsqu’elle intervient sur une décision identifiable et compréhensible, pas lorsqu’elle devient une confirmation mécanique de chaque étape. Il faut déterminer à l’avance quelles actions l’agent peut effectuer seul, lesquelles il peut préparer sans les appliquer et lesquelles sont interdites sans approbation explicite. Cette politique doit être liée à l’impact de l’action, et non au seul nom de l’outil utilisé.

L’OWASP recommande une approbation explicite pour toute action qui modifie la sécurité, les permissions ou l’infrastructure. Ce principe peut aussi guider les opérations métier sensibles : suppression de données, envoi externe, publication, achat ou changement difficile à annuler. La décision doit tenir compte des conséquences, du contexte et de la possibilité de revenir à l’état antérieur.

Construire une échelle d’autonomie compréhensible

Une politique simple peut distinguer trois niveaux. Au premier, l’agent observe et propose : il rassemble des informations ou prépare un brouillon, sans modifier l’état du système. Au deuxième, il exécute des opérations réversibles et de faible impact dans un périmètre délimité. Au troisième, les actions sensibles ou difficiles à annuler nécessitent un examen explicite par une personne autorisée.

Cette échelle n’est pas une norme universelle ; c’est une façon de rendre les décisions de produit et de sécurité explicites. Pour chaque action, l’équipe doit préciser qui valide, quelles informations sont présentées, combien de temps l’approbation reste valable et ce qui se passe si elle n’arrive pas. Une approbation donnée pour une opération ne devrait pas se transformer en autorisation générale pour les opérations suivantes.

  1. Décrire l’action proposée : indiquer la ressource concernée, la modification envisagée et le résultat attendu.
  2. Présenter le contexte utile : montrer les informations qui ont conduit l’agent à cette proposition et les limites connues.
  3. Permettre une décision réelle : offrir des choix clairs, notamment refuser ou demander une modification, au lieu d’un simple bouton de confirmation ambigu.
  4. Exécuter uniquement l’opération approuvée : vérifier que les paramètres n’ont pas changé entre l’approbation et l’exécution.
  5. Enregistrer la décision : conserver une trace de l’approbateur, de l’action et du résultat conformément aux règles de l’organisation.

La validation humaine a aussi ses limites. Si les demandes sont trop fréquentes ou présentées sans explication, les personnes risquent de confirmer par habitude. Il est donc préférable de réserver les demandes d’approbation aux actions dont le risque le justifie, tout en rendant les contrôles automatiques suffisamment stricts pour les autres opérations. La qualité de l’interface compte : une personne ne peut pas exercer une supervision utile si elle ne comprend ni l’impact ni le périmètre de ce qu’elle valide.

Surveiller l’exécution et préparer la réponse aux incidents

Les permissions définissent ce qu’un agent peut faire ; la surveillance permet de vérifier ce qu’il fait réellement. Une trace exploitable devrait relier l’identité de l’agent, la demande reçue, les outils appelés, les ressources consultées ou modifiées, les validations obtenues et le résultat observé. Le niveau de détail doit être adapté aux besoins d’enquête et aux exigences de protection des données de l’organisation.

La surveillance ne doit pas se limiter à conserver des journaux pour une consultation ultérieure. Des alertes peuvent signaler une séquence inhabituelle, une tentative d’accès hors périmètre, une répétition d’échecs ou un volume d’actions qui s’écarte du comportement attendu. Les contrôles les plus pertinents dépendent du cas d’usage : un agent de support et un agent de déploiement n’ont pas les mêmes risques ni les mêmes indicateurs.

Prévoir un arrêt et un retour en arrière

Un déploiement sûr prévoit comment suspendre l’agent, révoquer ses identifiants et interrompre ses appels d’outils. Si une action a déjà modifié un système, il faut également savoir si elle peut être annulée, restaurée ou compensée. La possibilité d’un retour arrière doit être examinée lors de la conception, en particulier pour les opérations qui touchent à des données, à des permissions ou à une infrastructure.

La réponse à un incident impliquant un agent doit examiner à la fois le modèle et l’environnement. Il faut déterminer si l’origine se trouve dans une instruction malveillante, une permission excessive, une réponse d’outil incorrecte, une mémoire contaminée ou une configuration défaillante. Cette analyse évite de conclure trop vite qu’un problème est seulement un « mauvais prompt », alors qu’une autorisation ou une intégration peut être en cause.

Des essais réguliers sont nécessaires pour vérifier que les mécanismes prévus fonctionnent dans le produit réel. Les équipes peuvent simuler des entrées hostiles, des réponses d’outils inattendues et des tentatives de sortie du périmètre, puis contrôler si l’agent s’arrête, demande une validation ou reste limité aux actions prévues. L’objectif n’est pas de prouver qu’aucun incident ne peut survenir, mais de vérifier que les protections réduisent l’impact et que l’organisation sait détecter une déviation.

Intégrer la sécurité à tout le cycle de vie de l’agent

La sécurité d’un agent ne se décide pas une seule fois au moment du lancement. Elle doit accompagner le choix du cas d’usage, la conception des outils, la sélection des données, les tests, le déploiement et les changements de configuration. Une évolution de modèle, de connecteur ou de permissions peut modifier le comportement du système et créer un risque qui n’existait pas dans la version précédente.

Le NIST prépare des guides pratiques sous forme de « Control Overlays for Securing AI Systems », qui couvrent explicitement l’utilisation de systèmes d’agents IA, en mode agent unique comme en mode multi-agent. Cette approche reconnaît que les principes généraux de cybersécurité restent utiles, mais qu’ils doivent être adaptés aux architectures et aux comportements propres aux agents. La synthèse du RFI de mai 2026 souligne aussi le besoin de conseils d’implémentation, d’échange d’informations et de standards.

Avant le déploiement : définir le cas d’usage et les limites

Commencez par formuler la tâche, les ressources nécessaires et les dommages possibles si l’agent se trompe ou est manipulé. Déterminez ensuite les opérations qu’il peut seulement proposer, celles qu’il peut exécuter de manière encadrée et celles qui exigent une autorisation. Ce travail évite de commencer par une démonstration de capacités puis de découvrir après coup que le système a accès à des fonctions sans rapport avec son rôle.

Les essais doivent inclure les conditions réelles d’utilisation, et pas seulement des exemples idéaux. Vérifiez comment l’agent réagit aux instructions contradictoires, aux entrées non fiables, à une réponse mal formée d’un outil et à l’absence d’informations nécessaires. Testez aussi les contrôles d’identité, de permissions, d’approbation et de journalisation. Une politique écrite n’apporte pas de protection si elle n’est pas appliquée par les composants qui exécutent effectivement les actions.

Pendant l’exploitation : contrôler les changements et réévaluer le risque

Les connexions à de nouveaux outils, l’élargissement d’un rôle ou l’ajout d’une mémoire persistante doivent être traités comme des changements de sécurité. L’OWASP demande que les agents soient soumis à des contrôles de gestion des changements comparables à ceux appliqués aux administrateurs humains, avec des protections supplémentaires. Cela implique une trace des modifications et une évaluation de leurs effets sur le périmètre et les risques.

Les équipes produit, sécurité, opérations et métier ont chacune une part du travail. Les développeurs conçoivent les interfaces et les limites d’exécution ; les responsables sécurité définissent les exigences et les scénarios de menace ; les équipes métier déterminent les conséquences acceptables et les approbations requises ; les opérations surveillent les usages et les incidents. Une gouvernance claire évite de laisser la responsabilité de l’action à l’utilisateur final alors que les permissions et les mécanismes de contrôle sont décidés ailleurs.

Les standards en préparation peuvent aider à rendre ces pratiques plus cohérentes et interopérables, mais ils ne remplacent pas l’analyse du contexte de chaque organisation. NIST indique vouloir catalyser un écosystème d’agents de confiance et faire avancer les travaux sur leur sécurité et leur identité. L’OWASP annonce également des ressources 2026, dont l’Agentic AI Top 10, un Agent Control Standard et des contenus destinés aux systèmes génératifs et agentiques. Ces travaux structurent le domaine ; les contrôles doivent néanmoins être adaptés aux risques et aux capacités réellement déployées.

Choisir les contrôles selon le niveau d’autonomie et le risque

Il n’existe pas une configuration unique pour tous les assistants. Un outil qui suggère une réponse dans une interface interne n’a pas le même profil qu’un agent capable de modifier des comptes ou de déployer du code. Le niveau de protection doit suivre les capacités, la sensibilité des ressources, l’exposition à des données non fiables et la gravité d’une action erronée.

Avant de donner davantage d’autonomie, les responsables peuvent examiner quatre dimensions : quelles informations l’agent peut lire, quelles décisions il peut prendre, quelles actions il peut exécuter et combien de temps son état ou sa mémoire persiste. Deux agents utilisant le même modèle peuvent ainsi nécessiter des contrôles différents, parce que leurs outils et leurs conséquences ne sont pas les mêmes.

  • Pour un assistant consultatif : limiter les données accessibles, distinguer les suggestions des décisions et fournir une traçabilité suffisante pour vérifier les réponses.
  • Pour un agent qui rédige ou prépare : isoler les brouillons, séparer la préparation de l’exécution et vérifier les contenus avant leur envoi ou leur publication.
  • Pour un agent qui modifie des systèmes : réduire les droits, encadrer les opérations réversibles et imposer une approbation explicite pour les changements sensibles.
  • Pour un agent persistant ou multi-agent : contrôler les échanges, les délégations, les mémoires et les identités de chaque composant, sans supposer qu’un autre agent constitue une frontière de confiance.

Retarder l’autonomie peut être le bon choix lorsqu’une organisation ne peut pas encore fournir d’identité distincte, de limitation des accès ou de surveillance suffisante. Une solution moins autonome, qui prépare une action pour validation, peut apporter une partie du bénéfice métier tout en conservant un contrôle humain plus direct. À l’inverse, une automatisation plus étendue peut être pertinente lorsque le périmètre est bien défini, les opérations testées et les moyens d’arrêt opérationnels.

Le compromis se mesure donc au-delà de la rapidité. Il faut inclure le coût des validations, les erreurs possibles, la difficulté de revenir en arrière, la charge de surveillance et les effets d’un accès compromis. L’objectif n’est pas de minimiser toute autonomie, mais d’éviter qu’une capacité d’action dépasse le niveau de contrôle et de responsabilité disponible. À mesure que les usages s’élargissent, une réévaluation devient nécessaire : une permission raisonnable pour une expérimentation peut être excessive dans un déploiement à plus grande échelle.

Pour les équipes qui construisent ou achètent des assistants autonomes, le point de départ est concret : inventorier les actions possibles, attribuer une identité à chaque agent, supprimer les accès inutiles, fixer les seuils d’approbation et vérifier les traces d’exécution. Ajoutez ensuite des tests ciblant l’injection, les réponses d’outils et la mémoire persistante. Ces décisions transforment la sécurité des agents d’une promesse de comportement du modèle en un ensemble de contrôles techniques et organisationnels vérifiables.

La convergence des travaux du NIST, de l’OWASP et des contributions du secteur dessine une approche claire : standards adaptés, identité machine robuste, permissions minimales, approbation humaine pour les actions à fort impact et surveillance pendant l’exécution. Les agents peuvent alors agir au service des utilisateurs sans recevoir une confiance ou une autorité illimitée. Pour chaque nouveau cas d’usage, commencez par définir le périmètre d’action acceptable, puis faites en sorte que l’architecture l’impose réellement.