Un chatbot répond. Un agent agit. Cette différence d'une lettre dans la définition produit un écart d'un ordre de grandeur dans la surface d'attaque. Côté chatbot : le pire qui peut arriver, c'est une mauvaise réponse. Côté agent : le pire qui peut arriver, c'est qu'un attaquant exécute du code dans votre SI, exfiltre vos données ou émette un paiement.
Voici les 7 surfaces d'attaque que tout agent IA en production doit voir cartographiées avant le go-live. C'est le minimum vital.
Surface 1 — L'entrée utilisateur directe
C'est la plus connue : ce que l'utilisateur tape dans le prompt. Risques :
- Prompt injection directe : "Ignore tes instructions précédentes…".
- Jailbreak : contournement des guardrails d'alignement.
- Abus de privilèges : un user demande à l'agent de faire quelque chose pour lequel l'utilisateur n'a pas le droit.
Défenses : classifieur d'intention en entrée, séparation stricte instructions système / data, vérification des permissions de l'utilisateur au moment de chaque tool call, pas seulement au login.
Surface 2 — Les sources contextuelles (RAG, fichiers, mémoire)
C'est la prompt injection indirecte. Un document indexé dans le RAG contient des instructions cachées qui détourneront l'agent quand il le lira. Vecteurs concrets :
- Fichier PDF avec texte invisible (couleur fond, taille zéro).
- Page web parsée par l'agent.
- Email reçu et résumé par un assistant.
- Sortie d'un outil tiers contrôlable par un attaquant.
C'est la surface la plus dangereuse en 2026, parce qu'elle bypass la vigilance de l'utilisateur final. Cf. Prompt injection indirecte via tool output.
Surface 3 — Les outils que l'agent peut appeler
Chaque outil exposé est une capability. La règle est simple : un outil qui peut faire quelque chose de dangereux sera un jour utilisé pour faire quelque chose de dangereux. La question n'est pas si, c'est quand.
À cartographier pour chaque outil :
- Qu'est-ce qu'il peut écrire / supprimer / publier ?
- Quel scope d'accès (un dépôt, tous les dépôts, la prod, la sandbox) ?
- Est-il réversible ?
- Logge-t-il qui l'a appelé et avec quels paramètres ?
Surface 4 — Les autres agents
Si vous avez un système multi-agent (LangGraph, AutoGen, CrewAI), un agent compromis peut propager la compromission à ses voisins via :
- Les messages qu'il leur envoie (prompt injection inter-agents).
- La mémoire partagée.
- Les outputs d'un agent qui deviennent inputs d'un autre.
Cf. Multi-agent collusion : architecture défensive.
Surface 5 — La mémoire long-terme
Les agents 2026 ont presque tous une mémoire persistante (vector store, base relationnelle, fichier markdown). Cette mémoire est :
- Modifiable par l'agent lui-même, donc par n'importe qui qui contrôle l'agent.
- Lue par toutes les futures invocations, donc capable d'empoisonner durablement le comportement de l'agent.
Risque sous-évalué. Cf. Memory poisoning : empoisonner la mémoire long-terme.
Surface 6 — Les modèles eux-mêmes
L'agent appelle un ou plusieurs LLM. Ces modèles peuvent être :
- Backdoorés à l'entraînement (poisoning dataset, fine-tuning malveillant).
- Manipulés au runtime par jailbreak transitif si un agent en appelle un autre.
- Substitués si le routing modèle n'est pas vérifié (provider compromis, MITM).
Défense : signing des poids, vérification d'intégrité, monitoring du comportement statistique.
Surface 7 — L'infrastructure de l'agent
Souvent oubliée parce qu'elle ne paraît pas spécifique à l'IA. Pourtant :
- Le runtime qui exécute l'agent (containers, lambdas, machines).
- Le stockage des prompts, logs, conversations.
- Le réseau qui relie l'agent à ses outils et à ses LLMs.
- La CI/CD qui déploie les versions de l'agent et de ses prompts.
Toutes les vulnérabilités DevSecOps classiques s'appliquent ici. Avec un multiplicateur : un compromis sur cette couche permet de modifier le prompt système sans que personne ne le voie.
La grille de threat modeling à utiliser
Pour chaque surface, trois questions :
- Qui peut écrire dans cette surface ? (utilisateur final, employé interne, attaquant externe, autre agent)
- Qu'est-ce que l'agent en fait ? (lit, parse, exécute, transmet)
- Quel niveau de privilège est mobilisé ensuite ? (lecture data, écriture data, action externe)
Si à l'intersection des trois vous trouvez : un attaquant externe peut écrire ; l'agent va exécuter ; l'action a un fort privilège — vous avez un chemin critique. Il en faut idéalement zéro. Souvent vous en avez plusieurs au premier audit.
Le minimum livrable avant de mettre un agent en prod
- Un schéma DFD (data flow diagram) qui montre les 7 surfaces.
- Une matrice tool / privilège / réversibilité.
- Un kill-switch documenté et testé.
- Un log audit de chaque tool call (qui, quand, avec quels paramètres, résultat).
- Un plan d'incident agent compromis (runbook 0-72h).
Sans ces cinq livrables, le passage en prod est prématuré. Pour la lecture des privilèges et du sandboxing, Agents autonomes : périmètre de privilèges.