Sécuriser les agents IA en entreprise : injection de requêtes, fuites de données et IA fantôme

À jour au 25 octobre 2026. Les attaques et les référentiels évoluent très vite sur ce sujet. Cet article sera complété au fil des nouvelles publications.

Il y a peu, l’IA générative en entreprise se résumait à un assistant conversationnel qui répondait à des questions. Aujourd’hui, les agents lisent les boîtes de réception, résument des documents, interrogent des bases de connaissances, appellent des API, créent des tickets ou modifient du code. Chaque contenu qu’ils lisent devient une porte d’entrée possible, et chaque permission qu’on leur accorde, un levier pour un attaquant.

De l’assistant à l’agent : ce qui change

Un assistant répond ; un agent agit. Il enchaîne des étapes, utilise des outils, conserve une mémoire et peut dialoguer avec d’autres agents. Des protocoles d’intégration standardisés facilitent désormais le branchement d’un agent à des dizaines d’outils et de sources de données.

Le problème de fond tient à la nature même des modèles de langage : ils ne savent pas distinguer de façon fiable une instruction d’une donnée. Un texte qu’ils lisent peut donc être interprété comme un ordre.

Les principales attaques

L’injection de requêtes indirecte

L’attaquant n’a pas besoin d’accéder à l’agent : il lui suffit de placer des instructions dans un contenu que l’agent lira, comme un courriel, une page web, un document partagé ou une entrée de journal. L’agent peut alors divulguer des informations, modifier son comportement ou déclencher des actions.

Ce n’est pas théorique. En juin 2025, Microsoft a corrigé EchoLeak (CVE-2025-32711, score CVSS 9,3), une faille de Microsoft 365 Copilot : un simple courriel piégé pouvait amener l’assistant à exfiltrer des données de l’utilisateur, sans aucun clic de sa part. Aucune exploitation malveillante n’a été signalée.

Des permissions excessives

Plus un agent dispose de droits, plus une manipulation réussie est grave. Un agent qui peut envoyer des courriels, modifier des droits d’accès ou valider des paiements devient un vecteur d’attaque redoutable s’il est détourné.

La fuite de données sensibles

Un agent connecté à de nombreuses sources peut exposer des informations auxquelles l’utilisateur n’a pas droit, par exemple si une base de connaissances a été indexée sans reprendre les droits d’accès des documents d’origine. Les requêtes et réponses elles-mêmes, conservées par un fournisseur, peuvent aussi contenir des données confidentielles.

L’empoisonnement de la mémoire et des connaissances

Un document piégé ajouté à une base de connaissances, ou une information malveillante enregistrée dans la mémoire d’un agent, peut influencer durablement ses réponses et ses actions, bien après l’attaque initiale.

La chaîne d’approvisionnement

Extensions, connecteurs, serveurs d’outils, modèles téléchargés : chaque composant tiers ajouté à un agent élargit la surface d’attaque, au même titre qu’une bibliothèque logicielle.

L’IA fantôme, un risque sous-estimé

Avant même les agents officiels, il y a les usages non maîtrisés : des collaborateurs qui collent des documents confidentiels dans un service d’IA public, installent des extensions de navigateur dotées d’accès étendus ou utilisent leurs comptes personnels. Ces usages, souvent de bonne foi, échappent à toute gouvernance.

Les interdire ne suffit pas. Il faut les mesurer (journaux du proxy et du DNS, solutions de type CASB), proposer une alternative validée et former les équipes aux bons réflexes.

Les référentiels pour s’organiser

OWASP : le projet OWASP GenAI Security publie un Top 10 des risques des applications fondées sur des LLM (édition 2026) et, depuis décembre 2025, un Top 10 dédié aux applications agentiques. On y retrouve notamment l’agentivité excessive, le détournement d’objectif d’un agent (typiquement par injection de requêtes), l’usage abusif de ses outils, l’abus d’identité et de privilèges ou l’empoisonnement de sa mémoire.
ANSSI : les Recommandations de sécurité pour un système d’IA générative (avril 2024) proposent 35 recommandations couvrant tout le cycle de vie, avec un accent sur le cloisonnement, la journalisation et le filtrage des accès.
MITRE ATLAS : une base de connaissances des tactiques et techniques d’attaque contre les systèmes d’IA, construite sur le modèle de MITRE ATT&CK. Elle est précieuse pour bâtir des scénarios de détection.
AI Act : pour les systèmes à haut risque, l’article 15 impose un niveau approprié de cybersécurité (voir notre analyse AI Act : le nouveau calendrier après l’Omnibus numérique).

Une démarche en sept étapes

Inventorier les assistants, agents, connecteurs, extensions et comptes utilisés, y compris les usages non déclarés.
Appliquer le moindre privilège : une identité propre à chaque agent, des droits minimaux, la lecture seule par défaut, des jetons d’accès à courte durée de vie.
Traiter tout contenu externe comme non fiable : séparer instructions et données, filtrer les entrées et les sorties, bloquer les canaux d’exfiltration (liens, images distantes, appels sortants non prévus).
Exiger une validation humaine pour les actions sensibles : paiement, envoi vers l’extérieur, suppression, modification de droits.
Journaliser et superviser : requêtes, appels d’outils et données consultées, remontés dans le SIEM avec des règles de détection dédiées (volumes anormaux, outils inhabituels, destinations inconnues).
Tester régulièrement : des tests d’intrusion ciblant l’injection de requêtes à chaque nouvelle version, nouveau modèle ou nouveau connecteur.
Gouverner : une charte d’usage, un catalogue d’outils validés, une revue des fournisseurs (localisation des données, réutilisation pour l’entraînement) et la formation des équipes.

Et pour le SOC ?

Les agents doivent être surveillés comme des comptes à privilèges : leurs actions doivent être corrélées avec le reste de l’activité dans le SIEM, et un playbook de réponse doit prévoir de révoquer leurs jetons, de désactiver un connecteur ou de purger une mémoire compromise.

À l’inverse, lorsque le SOC utilise lui-même l’IA pour trier les alertes ou résumer les incidents, les mêmes règles s’appliquent : les journaux analysés peuvent contenir des instructions malveillantes, et l’IA doit rester un assistant de l’analyste, pas un décideur.

Sources

← Toutes les analyses