Prompt injection et agents IA : sécuriser un système multi-agents sans le brider

Un agent est un système qui peut interpréter un objectif, manipuler du contexte, et parfois agir via des outils. Cela change la nature du risque : une sortie fausse n’est pas seulement un « mauvais texte », elle peut devenir une action non désirée. C’est pourquoi la sécurité des agents doit être pensée comme une architecture, pas comme un filtre cosmétique.

1 Pourquoi la prompt injection devient critique avec les agents

OWASP définit la prompt injection comme une vulnérabilité où des entrées (prompts) modifient le comportement ou la sortie d’un LLM de manière involontaire, et souligne que l’impact dépend fortement du contexte métier et du niveau d’agency (capacité d’action) du système. Source

Dans un système multi-agents, le problème s’amplifie : plus d’agents, plus de mémoire, plus de données externes, plus d’outils. Le risque n’est pas seulement « l’hallucination », mais la capacité à influencer des décisions et actions sur des systèmes connectés.

2 Injection directe vs indirecte : mécanismes et exemples

OWASP distingue des injections directes (prompt fourni par l’utilisateur) et indirectes (instructions présentes dans des sources externes récupérées par le système). Source

Le NIST rappelle également que l’injection indirecte peut exploiter des applications intégrées à des LLM en injectant des instructions dans des données susceptibles d’être récupérées, avec des démonstrations de vols de données propriétaires ou d’exécution de code à distance selon les environnements. Source

3 Impacts en entreprise : de l’erreur au scénario de fuite

OWASP liste des impacts possibles : divulgation d’informations sensibles, manipulation de contenu, accès non autorisé à des fonctions, exécution de commandes dans des systèmes connectés, influence sur des décisions critiques. Source

Trois scénarios fréquents

• Exfiltration : l’agent recompose des données sensibles via mémoire, logs ou outils.
• Privilege escalation : l’agent obtient ou utilise des permissions trop larges par erreur de conception.
• Action non désirée : envoi d’email, création de tickets, modifications d’objets métier sans validation.

4 7 garde-fous prioritaires (défense en profondeur)

1. Least privilege (droits minimaux)

OWASP recommande explicitement le contrôle des privilèges et l’accès minimal, en évitant de fournir des fonctions directement au modèle si cela peut être géré côté code. Source

2. Human-in-the-loop pour les actions à risque

OWASP recommande une approbation humaine pour les actions à fort impact. Source

3. Séparation du contenu non fiable

Marquer clairement les sources externes et limiter leur influence sur les instructions. OWASP recommande de segmenter et d’identifier le contenu externe. Source

4. Formats de sortie attendus et validation déterministe

OWASP propose de définir des formats attendus et de vérifier côté code, afin de réduire les sorties ambiguës et détecter des comportements anormaux. Source

5. Filtrage entrée et sortie

OWASP recommande des filtres et des règles pour traiter le contenu sensible et détecter des patterns d’attaque. Source

6. Journalisation et audit

Sans traces, vous ne pouvez pas prouver la conformité ni comprendre un incident. L’observabilité est un garde-fou en soi : on réduit le risque et on accélère le diagnostic.

7. Red teaming régulier

Le NIST recommande de réaliser du red teaming pour évaluer la résilience face à des attaques GAI, dont la prompt injection. Source

5 Red teaming et tests : passer du bon sens à la preuve

Le NIST propose d’adapter les pratiques cyber pour couvrir les systèmes génératifs et recommande d’évaluer régulièrement les vulnérabilités, dépendances et plans de réponse. Source

6 Checklist avant mise en production

• Chaque agent a un rôle stable, un scope clair, une mémoire limitée
• Chaque agent a des droits minimaux et des secrets séparés
• Actions à risque bloquées sans validation humaine
• Contenu externe marqué comme non fiable et segmenté
• Sorties structurées et validées côté code
• Logs complets : contexte, décisions, outils, résultats
• Red teaming effectué et rejoué à chaque changement majeur

7 FAQ