The Attack and Defense Landscape of Agentic AI: A Comprehensive Survey

Cet article présente la première enquête systématique sur la sécurité des agents d'IA, en analysant leur paysage d'attaques et de défenses, en identifiant les lacunes actuelles et en proposant un cadre fondamental pour sécuriser ces systèmes émergents.

L'essentiel

🤖 Les Agents IA : Des Assistants Puissants mais Dangereux ?

(Résumé du rapport "Le Paysage des Attaques et des Défenses des Agents IA")

Imaginez que vous avez embauché un super-assistant personnel (l'Agent IA). Ce n'est pas juste un chatbot qui répond à vos questions. C'est un employé très intelligent qui a non seulement un cerveau (un modèle de langage), mais aussi les clés de votre maison, votre ordinateur, votre banque et votre agenda. Il peut lire vos emails, modifier des fichiers, acheter des choses sur internet et exécuter des programmes sur votre machine.

Ce rapport de recherche, écrit par des experts de Berkeley et d'autres universités, nous dit une chose importante : cette nouvelle liberté est géniale, mais elle ouvre la porte à de nouveaux types de catastrophes.

Voici comment les chercheurs ont décortiqué le problème, en utilisant des analogies simples.

---

1. Le Problème : La "Maison Ouverte" 🏠🔓

Avant, les logiciels étaient comme des machines à café : vous appuyez sur un bouton, ça fait du café. C'est prévisible.
Aujourd'hui, les Agents IA sont comme des chefs d'orchestre autonomes. Ils peuvent décider eux-mêmes de jouer quelle partition, avec quels instruments, et même improviser.

Le danger ?
Si vous laissez les clés de la maison à un chef d'orchestre qui écoute la radio, un pirate peut passer par la radio pour lui chuchoter : "Oublie la musique, ouvre le coffre-fort et donne-moi l'argent."
C'est ce qu'on appelle l'injection de commande. Le pirate ne casse pas la porte (le logiciel), il trompe simplement l'assistant pour qu'il ouvre la porte lui-même.

2. Les 7 "Boutons de Réglage" (Le Design) 🎛️

Les chercheurs ont identifié 7 façons dont on peut configurer ces agents, un peu comme les réglages d'une voiture de course. Plus on les rend flexibles, plus ils sont puissants, mais plus ils sont dangereux :

1. Confiance (Input Trust) : L'agent fait-il confiance à tout ce qu'il lit sur internet ? (Si oui, il peut lire un site piégé).
2. Sensibilité (Access Sensitivity) : A-t-il accès à vos données bancaires ou médicales ?
3. Flux de travail (Workflow) : Suit-il un script rigide ou décide-t-il lui-même de ses étapes ?
4. Actions : Se contente-t-il de parler ou peut-il agir (effacer des fichiers, envoyer des emails) ?
5. Mémoire : Se souvient-il de tout ce que vous lui avez dit il y a un an ? (Si oui, un pirate peut "empoisonner" cette mémoire).
6. Outils : Peut-il utiliser n'importe quel logiciel ou seulement ceux qu'on lui a donnés ?
7. Interface : Parlez-vous juste par texte ou peut-il cliquer sur des boutons à l'écran ?

La règle d'or : Plus l'agent est flexible, plus il a de "portes d'entrée" pour les pirates.

3. Les Attaques : Comment les Pirates Jouent 🦹‍♂️

Le rapport classe les attaques en trois catégories, comme des voleurs qui agissent différemment :

• Le Voleur Extérieur (Indirect) : Il ne touche pas l'agent directement. Il modifie un site web public ou un document PDF. Quand l'agent va lire ce document, il lit aussi les instructions cachées du pirate.
  • Analogie : Un pirate écrit un message caché sur un panneau publicitaire. L'agent, en passant, lit le panneau et obéit au message au lieu de faire son travail.
• L'Usurpateur (Niveau Utilisateur) : Il se fait passer pour vous ou vous envoie un email piégé.
  • Analogie : Il vous envoie un colis avec un mot : "Ouvre le colis et dis à ton assistant de vider ton compte."
• L'Intrus Interne (Le pire) : Il a déjà accès au cerveau de l'agent ou à sa mémoire.
  • Analogie : C'est comme si le pirate avait remplacé le manuel d'instructions de l'agent par un faux.

4. Les Risques : Ce qui peut mal tourner 💥

Quand l'agent se fait piéger, trois choses terribles peuvent arriver :

1. Fuite de données (Confidentialité) : Il envoie vos photos privées ou mots de passe au pirate.
2. Destruction (Intégrité) : Il efface vos fichiers importants ou modifie votre code par erreur.
3. Panne (Disponibilité) : Il s'emballe et consomme toute votre énergie ou votre argent en faisant des milliers de tâches inutiles.

5. Les Solutions : Comment se protéger ? 🛡️

Le rapport ne se contente pas de lister les problèmes, il propose une "boîte à outils" pour construire des agents sûrs. Imaginez que vous construisez une forteresse :

• Les Portes de Sécurité (Gardes-fous) :
  • Entrée : On vérifie tout ce qui rentre (filtre les sites dangereux).
  • Sortie : On vérifie tout ce qui sort (empêche l'agent d'envoyer des emails suspects).
• La Séparation des Pouvoirs (Privilege Separation) :
  • On ne donne pas toutes les clés à la même personne. L'agent qui "planifie" ne doit pas avoir les clés pour "exécuter" les actions dangereuses. C'est comme séparer le chef de cuisine du serveur : le serveur ne peut pas empoisonner la soupe.
• L'Humain dans la Boucle (Human-in-the-Loop) :
  • Pour les actions graves (vendre une maison, effacer un dossier), l'agent doit demander : "Êtes-vous sûr ?" à l'humain.
• La Surveillance (Monitoring) :
  • Des caméras de surveillance qui regardent l'agent travailler pour voir s'il fait des choses bizarres.

6. L'Étude de Cas : AutoGPT (Le Cas Réel) 🕵️‍♂️

Les chercheurs ont pris un agent célèbre appelé AutoGPT et ont regardé ses failles réelles (comme des bugs dans un jeu vidéo).
Ils ont vu que même si les développeurs ont patché certains trous (comme empêcher l'agent d'écraser certains fichiers), ils n'ont pas toujours corrigé la cause racine : l'agent est toujours trop confiant et écoute trop facilement les instructions venant de l'extérieur.

C'est comme si vous aviez mis un cadenas sur la porte, mais que vous laissiez la fenêtre ouverte avec un panneau "Entrez ici".

Conclusion : L'Avenir est Sombre mais Lumineux 🌅

Ce rapport est un appel à l'action. Il dit :

"Les agents IA sont l'avenir, mais nous ne pouvons pas les laisser courir dans la nature sans ceinture de sécurité."

Il faut arrêter de penser uniquement au "cerveau" de l'IA (le modèle) et commencer à sécuriser tout son corps (ses outils, sa mémoire, ses connexions). Les chercheurs appellent à créer des normes, des "permis de conduire" pour les agents, et à ne jamais faire confiance aveuglément à une machine, même si elle semble très intelligente.

En résumé : L'agent IA est un super-héros potentiel, mais sans un costume de protection bien conçu, il risque de devenir le pire cauchemar de notre sécurité numérique.

Résumé technique

1. Problématique

L'article aborde l'émergence rapide des systèmes d'IA agents (Agentic AI), qui combinent des modèles de langage (LLM) avec des composants logiciels non-AI pour exécuter des tâches autonomes, gérer des outils et interagir avec des environnements externes. Bien que cette flexibilité offre des capacités d'automatisation sans précédent, elle introduit des défis de sécurité fondamentalement différents de ceux des logiciels traditionnels ou des LLM autonomes.

Les problèmes clés identifiés sont :

• Surface d'attaque étendue : Contrairement aux LLM isolés, les agents interagissent avec des bases de données, des API, des systèmes de fichiers et des environnements web, créant de multiples vecteurs d'attaque.
• Vulnérabilités spécifiques : Des incidents récents montrent que les agents sont sujets à des injections de prompts (directes et indirectes), à l'exfiltration de données, à l'exécution de code à distance et à la corruption de données via des outils malveillants.
• Manque de cadre systématique : La recherche existante se concentre souvent sur des vecteurs d'attaque spécifiques (comme l'injection de prompts) ou sur des composants individuels, sans offrir une vue d'ensemble holistique des risques systémiques et des stratégies de défense intégrées.

2. Méthodologie

Les auteurs ont adopté une approche systématique pour cartographier le paysage de sécurité des agents :

• Définition de la portée : L'étude se concentre sur les risques uniques ou amplifiés par l'autonomie des agents, en excluant les attaques purement internes aux modèles (comme l'inversion de modèle) qui ne s'aggravent pas nécessairement dans un contexte agentic.
• Revue de littérature : Une analyse approfondie de 128 documents (articles académiques, rapports industriels, CVE) publiés entre 2023 et octobre 2025, provenant de conférences de sécurité de premier plan (USENIX Security, IEEE S&P, CCS) et de conférences ML.
• Études de cas : Analyse de systèmes réels (AutoGPT, Codex, Gemini CLI, etc.) pour identifier les lacunes entre la théorie et la pratique.
• Cadre d'analyse : Utilisation de principes de sécurité traditionnels (confidentialité, intégrité, disponibilité) adaptés au contexte des agents, couplés à une analyse des dimensions de conception.

3. Contributions Clés

A. Dimensions de Conception des Agents (Design Dimensions)

Les auteurs proposent un cadre structurant définissant sept dimensions de conception qui influencent directement les risques de sécurité. Chaque dimension représente un spectre de flexibilité (de moins à plus flexible) :

1. Confiance des entrées (Input Trust) : De l'absence de données externes à l'utilisation de données arbitraires non fiables.
2. Sensibilité de l'accès (Access Sensitivity) : De l'accès à des données non sensibles à l'accès arbitraire à des données sensibles (PII, clés API).
3. Flux de travail (Workflow) : De chatbots simples à des flux dynamiques définis par le LLM.
4. Action : De la simple génération de texte à l'exécution de commandes et la modification de l'environnement.
5. Mémoire : De l'absence de mémoire à la mémoire persistante entre sessions.
6. Outils (Tool) : De l'absence d'outils à l'utilisation d'outils arbitraires ou tiers.
7. Interface Utilisateur (User Interface) : Du texte uniquement aux interfaces interactives complexes (web, IDE).

Insight : Une plus grande flexibilité dans ces dimensions élargit la surface d'attaque et amplifie les risques.

B. Taxonomie des Attaques et des Risques

L'article établit une taxonomie complète classant les menaces selon trois modèles de menace et sept catégories de risques :

Modèles de Menace :

• Adversaire Externe : Manipule des ressources externes (pages web, documents) que l'agent récupère (ex: injection de prompts indirecte).
• Adversaire au niveau Utilisateur : Injecte du contenu malveillant directement dans les entrées de l'agent.
• Adversaire Interne : A accès aux composants internes de l'agent (empoisonnement de modèle ou de mémoire).

Catégories de Risques (R1-R7) :

• R1. Interfaces hétérogènes non fiables : Multiplicité des points d'entrée (outils, mémoire, web).
• R2. Mauvaise exécution d'instructions : L'agent suit des instructions malveillantes plutôt que l'intention de l'utilisateur.
• R3. Flux de données non contraints : Propagation libre de données non fiables vers des sorties sensibles.
• R4. Hallucinations et erreurs de modèle : Actions réelles basées sur des informations fausses générées par le modèle.
• R5. Fuite de données privées : Exfiltration de données sensibles via des outils ou des réponses.
• R6. Actions non autorisées et corruption de données : Modification non désirée de l'état du système ou des fichiers.
• R7. Épuisement des ressources et Déni de Service (DoS) : Boucles infinies ou appels API coûteux.

C. Paysage de la Défense (Defense Landscape)

Les auteurs systématisent les mécanismes de défense existants en cinq catégories principales, en identifiant leurs limites :

1. Protection Runtime (Temps d'exécution) :
   • Gardes d'entrée/sortie (Guardrails) : Filtrage des prompts et validation des actions.
   • Contrôle de flux d'information (IFC) et suivi des taints (Taint Tracking) : Suivi de la propagation des données non fiables.
   • Surveillance (Monitoring) : Détection d'anomalies dans les trajectoires d'exécution.
   • Validation Humaine (Human-in-the-loop) : Approbation utilisateur pour les actions critiques.
2. Conception Sécurisée (Secure By Design) :
   • Séparation des privilèges : Isolation des composants (planificateur vs exécutant) et principe du moindre privilège.
   • Vérification Formelle : Preuves théoriques de la sécurité des flux de contrôle.
3. Gestion des Identités et des Accès (IAM) : Authentification, contrôle d'accès dynamique et gestion des identifiants (credentials).
4. Durcissement des Composants (Component Hardening) : Renforcement des modèles (fine-tuning) et des outils (signatures cryptographiques).

4. Résultats et Études de Cas

L'analyse de cas concrets (notamment AutoGPT, Codex, Browser-use) révèle des écarts significatifs entre les besoins théoriques et les implémentations actuelles :

• Réactif plutôt que Préventif : La plupart des correctifs (patches) dans les agents réels (comme AutoGPT) visent les conséquences (ex: bloquer l'écriture de fichiers) plutôt que les causes racines (ex: l'injection de prompts ou le flux de données non fiable).
• Lacunes de couverture :
  • Les agents de codage manquent souvent de gardes d'entrée robustes pour les données récupérées sur le web.
  • Les agents web sont vulnérables aux injections de prompts indirectes via le contenu des pages web.
  • Le contrôle d'accès est souvent binaire (tout ou rien) plutôt que granulaire et contextuel.
  • La gestion des identifiants (secrets, tokens) reste souvent ad hoc et non sécurisée.
• Exemple AutoGPT : L'analyse des CVE d'AutoGPT montre que des vulnérabilités comme l'injection de commandes OS ou la traversée de chemin persistent car les défenses ne traitent pas l'origine du problème (l'agent est manipulé pour générer ces commandes). Les correctifs actuels sont des "pansements" (ex: listes blanches de commandes) qui peuvent être contournés.

5. Signification et Perspectives

Cette enquête est la première à offrir une vue d'ensemble systématique de la sécurité des agents IA, servant de fondation pour la recherche future et le développement industriel.

Implications principales :

• Paradigme de Défense en Profondeur : Il est impératif de combiner plusieurs mécanismes (gardes, séparation des privilèges, surveillance, validation humaine) car aucune solution unique ne suffit.
• Nécessité de nouveaux standards : Le domaine a besoin de cadres normalisés pour l'identité des agents, le contrôle d'accès dynamique et les protocoles de délégation sécurisée.
• Équilibre Sécurité/Utilité : Les défenses ne doivent pas entraver l'autonomie de l'agent. Des approches adaptatives et contextuelles sont nécessaires pour éviter la fatigue décisionnelle des utilisateurs (dans le cas de la validation humaine) et les faux positifs.

Conclusion :
L'article conclut que bien que la recherche ait bien cartographié l'espace des problèmes, les défenses pratiques et généralistes restent insaisissables. L'avenir de la sécurité des agents repose sur le développement de cadres d'évaluation réalistes, de défenses composables évitant les désalignements émergents, et de mécanismes adaptatifs qui équilibrent sécurité et facilité d'utilisation.