Ce qui change quand le modèle peut agir

Avec un chatbot, une erreur produit une mauvaise réponse que l’utilisateur peut ignorer. Avec un agent, elle produit un effet : un message envoyé, un fichier supprimé, une commande passée. Le modèle n’a pas besoin d’être « malveillant » : une consigne ambiguë, une hallucination ou une injection cachée dans un document suffisent.

L’OWASP Top 10 for Agentic Applications 2026 décrit dix familles de risques propres aux agents, dans cet ordre : détournement de l’objectif de l’agent, mauvais usage et exploitation des outils, abus d’identité et de privilèges, failles de la chaîne d’approvisionnement agentique, exécution de code inattendue, empoisonnement de la mémoire et du contexte, communications non sécurisées entre agents, défaillances en cascade, exploitation de la confiance entre l’humain et l’agent, et agents hors de contrôle.

Les risques à traiter en priorité

Des permissions plus larges que la mission

Un agent de support qui dispose d’un accès administrateur à la base clients peut tout lire et tout modifier, même si sa mission se limite à consulter une commande. Si un attaquant le manipule, il agit avec ces droits : c’est le problème du « député confus », qui exécute pour le compte d’un tiers ce que ce tiers n’aurait jamais pu faire seul.

Les actions irréversibles

Suppression de données, paiement, envoi à un client, publication, modification de la production : une fois faites, elles ne se rattrapent pas toujours. Ce sont elles qui doivent passer par une confirmation explicite, avec un aperçu de ce qui va se produire.

Les boucles et la consommation non bornée

Un agent qui réessaie sans fin, qui s’appelle lui-même ou qui crée des ressources dans le cloud peut produire une facture importante en quelques heures. L’OWASP classe cette consommation non bornée au sixième rang de son Top 10 LLM 2026.

La confiance excessive

Plus un agent paraît compétent, moins on relit ce qu’il fait. Une validation humaine n’a de valeur que si la personne voit vraiment l’action proposée et peut la refuser facilement.

Les garde-fous d’un agent en production

  • Moindre privilège : un compte de service dédié par agent, des jetons limités à la mission, aucun accès administrateur par commodité. La spécification MCP recommande de commencer par un jeu de permissions minimal et de n’élever les droits qu’au moment où une opération le demande.
  • Liste d’actions autorisées : l’agent choisit parmi des actions définies, avec des paramètres validés par le code, plutôt que de composer librement des commandes.
  • Validation humaine : toute action destructive, payante, irréversible ou touchant la production est présentée pour accord avant exécution.
  • Bac à sable : le code et les commandes générés s’exécutent dans un environnement isolé, sans secret de production ni accès réseau inutile.
  • Plafonds : nombre d’itérations, durée, budget, volume de messages ; au-delà, l’agent s’arrête et demande.
  • Idempotence : une action rejouée après une erreur ne doit pas être appliquée deux fois — un paiement, notamment.
  • Journal des actions : qui a demandé quoi, ce que l’agent a décidé, quels outils il a appelés, avec quel résultat.
  • Retour arrière : corbeille plutôt que suppression, sauvegardes testées, possibilité d’annuler.
  • Environnements séparés : l’agent est mis au point sur des données de test, jamais directement en production.

Mémoire, multi-agents et effets en cascade

Deux évolutions récentes ajoutent des risques. La mémoire : un agent qui retient des informations d’une session à l’autre peut aussi retenir une consigne malveillante lue un jour dans un document, et l’appliquer plus tard. Les systèmes multi-agents : quand un agent transmet sa sortie à un autre, une erreur ou une injection se propage d’étape en étape, chaque agent faisant confiance au précédent. Les parades sont les mêmes qu’entre services informatiques : chaque agent vérifie ce qu’il reçoit, n’a que ses propres droits, et la mémoire reste consultable, corrigeable et effaçable.

Exemple : un agent qui prépare les réponses aux clients

Une PME veut un agent qui lit les e-mails des clients, y compris les pièces jointes PDF, et prépare les réponses. Une conception raisonnable : l’agent lit la boîte avec un accès en lecture seule ; il produit des brouillons, jamais des envois ; le texte des e-mails et des PDF est traité comme une donnée, et toute instruction qu’il contient est signalée au lieu d’être suivie ; une personne relit et envoie ; le coût par jour est plafonné ; chaque brouillon est rattaché au message d’origine dans un journal. L’agent fait gagner du temps sans jamais pouvoir agir seul au nom de l’entreprise.

Ce que Prompt OS ajoute à la mission

Quand une mission décrit un agent, Prompt OS reconnaît le profil « Agent IA » et recommande neuf garde-fous : protection contre l’injection de prompt et contre l’injection indirecte, sécurité des agents et des outils, permissions minimales, prévention de l’exfiltration, validation humaine des actions sensibles, isolation et bac à sable, limites de coûts et de boucles, provenance et sources. Chacun ajoute ses consignes au prompt final ; l’indicateur signale par un point d’exclamation ceux qui manquent. Le guide sur l’injection de prompt détaille la première ligne de défense, et celui sur MCP et RAG les connecteurs.

Conclusion

Un agent utile n’a pas besoin d’être tout-puissant. En bornant ses droits, ses dépenses et ses actions irréversibles, on garde l’essentiel du gain de temps tout en rendant ses erreurs — inévitables — réparables.